This article accompanies Hour 5: Blockchain, IoT & Biometrics in our full-day CPD programme on XpertAcademy. Completion of the full one-hour session, including the related learning materials, contributes to the one-hour CPD certificate issued for that session. You can access the course here: CPD Event B: Full-Day AI, Technical Privacy & Emerging Technology Training.

Blockchain, IoT and biometric systems are often discussed as separate technology areas. That is understandable. A distributed ledger, a connected health device and a facial recognition access system do not look like the same privacy problem.

For DPOs and privacy teams, however, they often create the same kind of governance difficulty. They make evidence harder. It can become harder to prove what data is being collected, harder to explain who can identify someone, harder to reverse design choices, and harder to show that risks were assessed before the technology became operationally convenient.

This article is general guidance, not legal advice on a specific product, deployment or jurisdiction. It is intended to help privacy, legal, security, procurement and technology owners ask better questions before emerging technology becomes embedded in live services.

The shared issue is not novelty. It is whether the organisation can still explain necessity, identifiability, minimisation, security and accountability once the technology is live.

Why these technologies belong in the same privacy conversation

The practical link between blockchain, IoT and biometrics is evidence difficulty.

Biometric systems can turn a body, face, voice, gait or behavioural pattern into an identity control. IoT products can turn ordinary environments into streams of sensor readings, device identifiers, telemetry, location signals, health indicators, audio, images or usage patterns. Blockchain systems can make records persistent across a distributed architecture, sometimes with many parties relying on the integrity and availability of the same ledger.

The privacy risk is not always that the technology is unlawful or inappropriate. These technologies can support useful services. Biometrics can improve access security or reduce fraud. IoT can support health monitoring, safety, energy efficiency, logistics or product performance. Blockchain can support auditability, provenance, integrity and multi-party coordination.

The risk is that the assessment is done too late, at the wrong level, or on the wrong facts. A project team may approve "a device", "a biometric login" or "a blockchain proof" without explaining the processing around it. That is where DPIA work becomes harder than it first appears. XpertDPO has written separately about AI governance and DPIAs and why AI DPIAs become harder than they first appear. The same governance pattern appears here: the tool name is rarely enough.

Short use cases that show the practical risk

The governance questions become clearer when the technology is put into a real setting.

Use case Practical privacy issue
Biometric access for staff areas A fingerprint, face or palm system may be introduced as a security improvement, but the DPIA still needs to test necessity, alternatives, special category biometric data, false rejection, accessibility, retention, template protection and whether employees have a genuine alternative route.
Facial age assurance in an online service Age estimation may help tailor protections for children, but the review has to test proportionality, biometric or image-processing risk, vendor role, retention, accuracy across groups, transparency and whether the system creates exclusion or over-collection.
Smart sensors in a workplace or campus Occupancy, desk, access, camera, Wi-Fi or environmental sensors may be installed for safety or efficiency, but can drift into employee monitoring, behavioural profiling, location tracking or attendance inference if the purpose and access controls are loose.
Connected health or wellbeing device A wearable, app-connected device or remote-monitoring product may collect heart rate, sleep, activity, location or usage signals. The assessment should consider special category data, clinical reliance, security updates, cloud processing, family or carer access and what happens if the device is inaccurate or unavailable.
Blockchain credentials or certificates A school, employer, membership body or professional network may want tamper-resistant credentials. The governance issue is whether personal data, identifiers or hashes need to be on-chain, who controls correction, how revocation works and how long the evidence remains linkable.
Connected toy or consumer product A product may generate telemetry such as battery, Bluetooth, motor or interaction data. The privacy outcome depends on whether data is stored, whether an account is required, whether remote servers are involved, and whether the service can explain access, deletion and sharing in plain terms.

These examples are deliberately ordinary. Most organisations do not start by deploying a science-fiction system. They start with a door-entry tool, a classroom platform, a connected device, a new analytics layer, a proof-of-origin record or a vendor feature inside something they already use. That is why the review should focus on the processing, not the label.

Biometrics: identity, sensitivity and error

Biometric data needs careful language. Not every piece of biometric data is automatically special category biometric data under UK GDPR or EU GDPR. The key question is purpose. Where biometric data is used for the purpose of uniquely identifying someone, it becomes special category biometric data. That raises the threshold for lawful processing and safeguards.

In practice, biometric recognition systems also create risks that are not solved by saying the technology is accurate. The organisation still needs to consider necessity, proportionality, false acceptance, false rejection, discrimination, accessibility, exclusion, public-space monitoring, transparency, opt-out or alternative routes, retention and security of biometric templates.

This matters in ordinary operational contexts. A fingerprint access system used for staff entry, a facial recognition feature in a smart camera, a voice recognition tool in a customer service workflow, or biometric age assurance can each carry different risk. The question is not simply whether the system works. It is whether biometric processing is necessary for the purpose, whether a less intrusive method could achieve the same aim, whether people understand what is happening, and whether those who cannot or do not wish to use the biometric route have a workable alternative where one is needed.

The ICO's biometric recognition guidance is direct that organisations using biometric recognition systems must complete a DPIA before use. That does not mean every DPIA will reach the same conclusion. It does mean that a biometric system should not drift into live use on the strength of a security or convenience argument alone.

AI governance can also overlap. Some biometric systems may use AI, and the EU AI Act includes specific rules around prohibited practices, high-risk biometric systems and transparency in some biometric contexts. The privacy assessment should not collapse the regimes into one form, but the records should connect. The DPIA, AI assessment, vendor review and security review should describe the same system.

IoT: sensor data, telemetry and the people around the device

IoT privacy risk is often underestimated because individual data points can look small. A device identifier, timestamp, firmware log, motion event, diagnostic signal, battery status, location ping, voice activation record or app setting may not look sensitive in isolation. Combined over time, or combined with account data, household context, workplace context, health data or location patterns, those points can build a detailed picture of behaviour.

The ICO's consumer IoT guidance is useful because it looks beyond the device itself. IoT processing can involve manufacturers, operating system providers, app developers, cloud providers, AI service providers, biometric technology providers, sensor and telemetry providers, cybersecurity providers and others in the supply chain. That creates role-mapping and accountability work before the privacy team even reaches the user interface.

The design context also matters. Many IoT products are used by more than one person. A smart speaker may be used by a household and heard by visitors. A connected TV may reveal viewing patterns. A smart security camera may capture neighbours, delivery workers or passers-by. A fitness tracker, fertility tracker, sleep monitor or smart health device may process health or biometric information. A workplace sensor may create monitoring risk even if the original purpose is safety or occupancy management.

Transparency is therefore not just a privacy notice. IoT products may need layered explanations, just-in-time notices, privacy dashboards, app settings, physical indicators, voice cues, account controls and clear moments for consent where consent is the lawful basis. Where storage and access technologies are used, PECR may also be relevant in the UK, particularly for non-essential telemetry, advertising, profiling or location-related processing.

Security is part of the privacy analysis, not a separate technical courtesy. Device lifecycle, default settings, passwords or passkeys, multifactor authentication, secure updates, vulnerability disclosure, encryption, cloud processing, local processing, firmware integrity and deletion tools can all affect the risk to people. NIST and ENISA materials can help security teams think about IoT baselines, but privacy teams still need to translate those controls into GDPR accountability evidence.

Blockchain: permanence, roles and minimisation before the ledger

Blockchain projects can be attractive because they promise integrity, traceability and shared trust. Those same features can create data protection difficulty where personal data is involved.

The starting question should be whether personal data needs to be processed through a blockchain at all. If the purpose can be met without placing personal data, identifiers, hashes, encrypted personal data or linkable metadata on-chain, that should be considered early. Data minimisation is much easier before a ledger is designed than after multiple parties have built reliance on it.

The EDPB's blockchain guidance highlights the need to assess architecture and actor responsibilities at the design stage. Public, permissioned, private and consortium arrangements can create different role-mapping questions. Who determines the purposes and means? Who can write to the ledger? Who runs nodes? Who validates transactions? Who controls smart contracts? Who can change governance rules? Who handles off-chain storage? Who responds to rights requests or security incidents?

Immutability is a central concern. A record that is difficult to change or delete may be valuable for integrity, but it can sit awkwardly beside accuracy, storage limitation, erasure and rectification obligations. Encryption, hashing and pseudonymisation may reduce risk, but they do not automatically remove data protection obligations. Encrypted personal data can still be personal data where identification remains reasonably possible, and cryptographic protections may weaken over time.

This is where the existing XpertDPO article on pseudonymisation, anonymisation and data minimisation in AI systems is relevant beyond AI. The lesson is similar: do not treat a technical protection label as a compliance conclusion. Ask what can identify someone, who has the means to link data back, what will happen over the lifetime of the system, and what evidence supports the claim that the risk has been reduced.

DPIA triggers and the timing problem

Not every emerging technology use case automatically requires the same level of assessment. But blockchain, IoT and biometric deployments frequently contain high-risk indicators: innovative technology, systematic monitoring, large-scale processing, special category data, location data, vulnerable people, children, employees, invisible processing, profiling, automated decisions, public-space capture, security risks or processing that may determine access to a service, opportunity or benefit.

The DPIA question should therefore be asked before procurement, integration, device rollout, biometric enrolment or ledger design has gained too much momentum. A DPIA at the end of the project may identify risks, but it may have very little practical power to change the architecture.

For biometric recognition, the ICO position is especially clear: complete the DPIA before using the system. For IoT, DPIA screening should look at the complete ecosystem, not just the physical device. For blockchain, the assessment should consider the processing as a whole, including on-chain and off-chain elements, governance arrangements, retention, security, roles and rights handling.

A good DPIA record should not be a technology essay. It should answer practical questions: what is the purpose, why is this technology necessary, what alternatives were considered, what personal data is involved, who may be affected, what could go wrong, what controls reduce the risk, what residual risk remains, who accepts it and when the assessment must be reopened.

Vendor and security controls need to be evidence, not comfort

Emerging technology reviews often fail at the boundary between privacy and security. A vendor may provide a security certificate, architecture diagram or high-level privacy statement, but the DPIA still needs deployment-specific answers.

For biometrics, ask where biometric samples and templates are stored, whether comparison happens locally or in the cloud, how templates are protected, what key management is used, how false matches and false rejections are monitored, whether demographic performance has been tested, how alternatives are handled and what happens on termination.

For IoT, ask what data the device, app, cloud service and support channels collect; which telemetry is essential; whether non-essential telemetry can be switched off; how updates are delivered; how long security updates are provided; whether there is a vulnerability disclosure route; how deletion works; and whether multiple users or bystanders are addressed.

For blockchain, ask what data is placed on-chain, what remains off-chain, whether hashes or identifiers are linkable, who can run nodes, who can access keys, who can change smart contracts or permissions, how errors are corrected, what governance exists for forks or protocol change, and how rights requests will be handled.

These questions sit naturally in specialist support and DPO support work because they are not only legal questions. They require privacy, technical, security, procurement and operational evidence to meet in one record.

Accountability evidence that survives scrutiny

The useful outcome is not a larger folder. It is a clearer judgement trail.

For each emerging technology use case, the organisation should be able to show the approved purpose, the role mapping, the data flows, the categories of personal data, the affected groups, the DPIA screening decision or DPIA, the lawful basis and special category condition where relevant, the minimisation decision, the security controls, the transparency route, the vendor evidence, the residual risk decision, the approval conditions and the review triggers.

The review triggers are important. Reopen the assessment when a biometric system moves from authentication to identification, when an IoT product adds a new sensor or analytics feature, when telemetry is used for a new purpose, when a blockchain architecture changes, when a vendor changes hosting or subprocessors, when AI is added, when data is shared with new parties, when retention changes, when complaints or incidents arise, or when regulator guidance changes.

The Council of Europe's AI Convention, discussed in XpertDPO's Council of Europe AI Convention article, is a useful reminder that technology governance is not only about system performance. It is also about human rights, democracy, rule of law and accountable institutional choices. Even where that instrument is not the direct legal route for a specific project, the governance signal is relevant: emerging technology should be explainable as a decision about people, not just a technical deployment.

How XpertDPO can support emerging technology review

XpertDPO supports organisations where emerging technology assessments need to become clearer, more connected and more reviewable.

That may involve AI Governance and DPIA Lifecycle Support where biometric, IoT or blockchain work overlaps with AI governance; focused DPIA Support where a specific deployment needs screening, challenge or second review; or DPO Support where an in-house DPO needs independent specialist input without losing ownership of the decision.

The aim is not to turn every new technology project into a long compliance exercise. It is to help the organisation show that the right questions were asked at the right time, that the evidence is coherent, and that decisions about residual risk were made by the right owners.

This article is intended to support the learning covered in Hour 5: Blockchain, IoT & Biometrics in our XpertAcademy CPD programme. The relevant CPD certificate is issued for completion of the full one-hour session on XpertAcademy, including the related learning materials, rather than for reading this article on its own. You can return to the course here: CPD Event B: Full-Day AI, Technical Privacy & Emerging Technology Training.

Sources