Biometric Data Under GDPR:
Compliance Requirements and Best Practices

Why GDPR Treats Biometrics Differently

The General Data Protection Regulation draws a hard line around biometric data. Under Article 9, biometrics used for uniquely identifying a natural person fall into the "special categories" of personal data — the same classification given to genetic data, health records, and political opinions. The rationale is straightforward: a fingerprint or facial geometry cannot be revoked and reissued the way a password or API token can. Once a biometric template leaks, the damage is permanent and irreversible.

This elevated classification triggers a cascade of obligations that go far beyond what standard personal data requires. Organizations must secure an explicit, affirmative legal basis for processing, conduct a Data Protection Impact Assessment (DPIA) before any biometric system goes live, and implement technical safeguards that satisfy the regulation's privacy-by-design and privacy-by-default mandates (Article 25). Failure to comply carries penalties of up to 4% of global annual turnover or 20 million euros — whichever is greater.

The Six Pillars of Biometric GDPR Compliance

Meeting Article 9 obligations requires a systematic approach. The following framework covers the core requirements that every biometric data controller must address.

The Encryption Problem: Why Standard Approaches Fall Short

Traditional encryption protects biometric templates at rest and in transit, but it fails at the critical moment — computation. To match a live biometric sample against an enrolled template, a conventional system must decrypt both values into plaintext, compute the inner product or distance metric, and then re-encrypt. During that computation window, the raw biometric data sits exposed in server memory, vulnerable to memory-scraping attacks, insider threats, and cold-boot exploits.

From a GDPR perspective, this decryption-for-comparison pattern is deeply problematic. The regulation demands state-of-the-art security measures (Recital 83), and if a plaintext biometric template can be extracted from memory during a match operation, then the processing system has an inherent vulnerability that privacy-by-design is meant to eliminate.

Fully Homomorphic Encryption: Computing on Ciphertext

Fully Homomorphic Encryption (FHE) eliminates the decryption window entirely. With FHE, biometric templates are encrypted once at enrollment and never decrypted on the server. The inner-product comparison between a live sample and the stored template is performed directly on ciphertexts, producing an encrypted match score that only the data controller (or a threshold of key holders) can decrypt.

H33 implements this using the BFV (Brakerski/Fan-Vercauteren) lattice-based FHE scheme with carefully chosen parameters: polynomial degree N=4096, a single 56-bit modulus, and plaintext modulus t=65537. These parameters satisfy the CRT batching condition (t ≡ 1 mod 2N), enabling SIMD batching — 4,096 plaintext slots divided by 128 biometric dimensions yields 32 users packed into a single ciphertext.

// H33 BFV biometric verification — single API call
POST /v1/auth/verify
Content-Type: application/json
Authorization: Bearer h33_pk_...

{
  "batch": ["user_01", "user_02", ..., "user_32"],
  "probe_ct": "<base64-encoded BFV ciphertext>",
  "threshold": 0.85
}

// Response: encrypted match scores + Dilithium attestation
// Server NEVER sees plaintext biometric data

This architecture directly satisfies GDPR Article 32's requirement for appropriate technical measures. The biometric data is processed without ever being exposed in plaintext — not at enrollment, not at verification, and not during batch matching. There is no decryption window to attack.

Performance at Scale

Privacy-preserving computation historically meant unacceptable latency. Early FHE implementations measured verification times in seconds or even minutes. H33's production pipeline demolishes that assumption. On a Graviton4 c8g.metal-48xl instance (96 cores), the full-stack pipeline — FHE batch verification, ZKP proof lookup, and Dilithium attestation — completes a 32-user batch in approximately 1,109 microseconds. That translates to roughly ~42 microseconds per authentication and a sustained throughput of 1.595 million authentications per second.

DPIA Considerations for FHE-Based Biometrics

Even with FHE eliminating the plaintext exposure risk, GDPR Article 35 still requires a Data Protection Impact Assessment. However, the risk profile changes dramatically. The DPIA for an FHE-based system can document that:

• No plaintext biometric data exists on the server at any point in the processing lifecycle, eliminating the highest-severity breach scenario.
• Template storage is minimal — approximately 256 KB per user with SIMD batching (down from ~32 MB without batching), satisfying data minimization.
• Erasure is cryptographic — deleting the user's key share renders the encrypted template permanently unrecoverable, providing stronger erasure guarantees than overwriting plaintext storage.
• Post-quantum security ensures that harvested ciphertexts remain protected against future quantum computers, addressing the "harvest now, decrypt later" threat that regulators are increasingly concerned about.

"The ability to perform biometric matching entirely within the encrypted domain represents a fundamental shift in the privacy calculus. It transforms the DPIA from a risk-mitigation exercise into a risk-elimination exercise for the most critical threat vector: plaintext exposure during computation."

Data Subject Rights Under FHE

GDPR Articles 15 through 22 grant data subjects a suite of rights over their personal data. FHE-based biometric systems handle these rights with structural advantages:

Right to Erasure (Article 17)

Deleting a biometric template in a traditional system requires overwriting the stored data and verifying that no copies remain in backups, caches, or replicated storage. In an FHE system, erasure can be achieved by destroying the decryption key share associated with the user. The remaining ciphertext is computationally indistinguishable from random noise without the key — cryptographic erasure is provably complete.

Right to Portability (Article 20)

Because biometric templates are stored as encrypted BFV ciphertexts in a standardized format, portability is straightforward. The encrypted template can be exported and re-enrolled in any system that supports the same BFV parameter set, without ever decrypting the underlying biometric data during the transfer.

Post-Quantum Compliance: Looking Ahead

The GDPR's requirement for "state-of-the-art" security measures is not static — it evolves with the threat landscape. As quantum computing advances, regulators will increasingly expect organizations to demonstrate that their biometric protection is resilient against quantum attacks. H33's pipeline is fully post-quantum secure across every component: the BFV FHE scheme rests on lattice hardness, ZKP proofs use SHA3-256, and all attestation signatures use Dilithium (ML-DSA). No component in the chain relies on RSA or elliptic curves.