Biometric Retention Policy

Effective Date: May 20, 2026 Version: 1.0 Owner: DPO + Head of Identity Engineering — privacy@vereid.com. Provider: VEREID, a product of AIARCO Pty Ltd, ABN [TBD: counsel review], NSW, Australia. Scope: All biometric data processed in VEREID Social, VEREID Auth, VEREID ID and AIARCO ID. Statutory backdrop: Illinois BIPA, Texas CUBI, Washington biometric statute, GDPR Art. 9 (biometric data uniquely identifying a natural person), AU Privacy Act 1988 APP 3.3 (sensitive information), and emerging US state biometric laws.

1. Definitions

• Selfie / liveness frame — a still image (or short video frame sequence) captured during the verification flow to prove the subject is a live human, not a replay or mask.
• Face template — a numeric vector ("embedding") of fixed length derived from a face image by a face-recognition model. Re-identification of the original image from the vector is not possible at our chosen model.
• Document portrait — the face crop extracted from a government-issued ID document submitted by the subject.
• Match — the act of comparing the selfie face template to the document portrait face template to produce a similarity score and pass/fail verdict.

2. Default retention table

The 30-day clock starts at the completion of the verification job (the moment the verdict is written), not at upload.

3. Per-tenant override mechanism (B2B)

B2B Customers may request a shorter retention period in their DPA. They cannot request a longer one. The single exception is the 7-year document-image retention, which is fixed by AML law and is not negotiable.

3.1 How override is configured

• The Customer's tenant record carries a retention_overrides JSON column:

  {
    "face_template_days": 7,
    "raw_selfie_days": 7,
    "liveness_signals_days": 7
  }
  

• A value of 0 means "delete immediately on verdict write" (still post-match; we cannot delete during processing without breaking the match itself).
• A nullable value means "use default".
• Values above the default are rejected at API gateway with 400 retention_override_too_long.

3.2 How override is enforced

• The S3 lifecycle rule is computed per-prefix per-tenant. Prefixes are tenant_id/job_id/; lifecycle rules are templated at tenant-onboarding and on every override change.
• The Aurora purge worker (identity-retention-worker, runs every 1 hour) selects rows where processed_at + retention_days < now().
• Both paths emit RetentionDeleteEvent to EventBridge for monitoring.
• A RetentionMissedDeletion alarm fires if any row exceeds its retention by > 60 minutes.

3.3 How override is recorded in the DPA

The Customer's DPA exhibit Retention Overrides is signed alongside the master DPA. The consent_events row at end-user verification time includes a snapshot hash of the override config so we can prove which rule was in force.

4. End-user revocation (BIPA-style right)

An end-user can revoke biometric consent at any time:

• via POST /v1/me/biometric-revoke (authenticated),
• via in-product privacy settings,
• via email to privacy@vereid.com.

On revocation:

1. Face templates and raw selfies tied to that subject are shredded within 7 days (faster than the 30-day default).
2. Biometric login factors are disabled on their account.
3. Audit row written.
4. Subject confirmed by email.

The 7-year document image is not automatically deleted by a biometric revocation — that document is held under AML legal obligation. The subject can request its deletion under POST /v1/me/delete; if no legal-hold blocks it, we will delete.

5. Deletion verification

We treat retention as a security-critical control. Each scheduled purge produces a verifiable record:

5.1 Cryptographic shred

• Face templates and raw selfies are encrypted with a per-record KMS Data Encryption Key (DEK) wrapped by the CMK. Deletion shreds the wrapped DEK row from the kms_dek_envelope table.
• Without the DEK, the ciphertext is unrecoverable even if the underlying storage block has not yet been overwritten.

5.2 Tombstone audit row

• Every deletion writes a row to biometric_retention_audit:

  (artifact_id, artifact_type, tenant_id, subject_id_hash, scheduled_at, deleted_at, deletion_method, executor_role, kms_dek_id_shredded)
  

• subject_id_hash is a pepper-keyed hash so audit rows cannot be used to re-identify a subject.

5.3 S3 lifecycle confirmation

• S3 lifecycle deletion events are routed via EventBridge to the audit pipeline and reconciled daily against the biometric_retention_audit table. Mismatches page the on-call.

5.4 Quarterly attestation

• The Identity Engineering lead and DPO co-sign a quarterly attestation that:
  • No biometric template exceeds 30 days (or shorter per override).
  • No raw selfie exceeds 30 days (or shorter per override).
  • Deletion completion rate ≥ 99.99% within SLA.
  • All exceptions reviewed and resolved.

5.5 Annual independent test

• External auditor (SOC 2 Type II auditor) samples ≥ 30 deletions per quarter and verifies via direct S3 + DB inspection that the artefacts are gone.

6. Legal holds

A legal-hold mechanism can pause the auto-purge for a specific subject_id (e.g. ongoing law-enforcement request, regulatory investigation, civil litigation):

• Hold is added by Legal via an admin endpoint that requires MFA + two-person approval.
• Hold is logged with case reference and expiry date.
• Hold is reviewed every 90 days; any hold > 1 year requires re-approval.
• A daily report lists every active hold.

7. Excluded behaviours

We commit publicly that we will not:

• Sell biometric data to any third party.
• Use biometric data to train any model owned by VEREID or any third party, beyond the model-vendor's terms (and we have opted out of any AWS Rekognition data-improvement programme).
• Retain biometric data beyond the periods stated above.
• Use the biometric system for emotion recognition, demographic inference (race / ethnicity / political opinion), or any EU AI Act prohibited practice.
• Provide biometric query access to law-enforcement except on lawful instrument and with notice to the subject where law permits.

8. Incident handling

A breach involving biometric data is a P0 incident. Notification timelines:

• GDPR: 72 hours to the lead supervisory authority + affected data subjects without undue delay.
• Australian Notifiable Data Breaches scheme: as soon as practicable.
• BIPA: notify affected Illinois residents per Illinois data-breach statute.
• All B2B Customers whose tenant data is affected: within 24 hours of confirmation.
• Public statement within 72 hours.

9. Engineering test hooks

These hooks make the policy testable end-to-end:

• pytest tests/biometric/test_retention.py runs nightly in CI; asserts no test-fixture artefact survives the configured TTL.
• make biometric-purge-smoke runs in staging weekly with synthetic artefacts.
• biometric-retention-dashboard Grafana view shows oldest artefact age per tenant.

10. Statutory mapping

11. Vendor commitments

We have separately attested with each biometric-adjacent vendor that:

• AWS Rekognition — we have opted out of any data-improvement programme; CompareFaces and DetectFaces calls do not persist images on AWS's side for VEREID's account. Confirmed in writing by AWS account team [TBD: counsel review — attach correspondence reference].
• AWS Textract — same opt-out posture. Synchronous calls only; no asynchronous job parking that would leave images in AWS storage outside our own bucket.
• No third-party face-match vendor is used. We do not use FaceTec, iProov, Onfido, Sumsub, Persona, Jumio, Veriff, or any other vendor that would receive biometric data.

12. Internal access controls

Access to the biometric data path is tightly scoped:

• Only two production roles can decrypt biometric ciphertext: role-identity-worker (the worker that performs the match — short-lived task role) and role-identity-investigator (manual-review console, requires MFA + just-in-time elevation via the access-broker).
• Engineering staff have no standing decrypt permission; every decrypt is a JIT-elevated session logged to CloudTrail and routed to the audit pipeline.
• The CMK pii-vault-and-audit has a KMS key policy that forbids decryption from outside vpc-vereid-prod and outside the role list above.
• Quarterly review of decrypt events: any unusual decrypter, frequency or volume page the on-call.

13. Subject-facing transparency

In the verification UI the subject sees, before any camera activation:

1. A plain-English explanation of what a face template is and what we will do with it.
2. The retention period applicable to this verification (default 30d or shorter per tenant override; explicitly displayed).
3. A clearly toggled consent checkbox (no pre-tick) and a "Why we need this" expandable.
4. A link to this policy.

Consent is recorded server-side with the version hash of the on-screen text so we can prove later exactly what the subject saw.

14. Change history

[TBD: counsel review — confirm shorter-only override stance against AU AML/CTF and EU AML expectations; confirm BIPA 3-year statutory ceiling is met by 30-day floor; confirm Texas CUBI 1-year-after-purpose ceiling met; pick external auditor; obtain AWS written confirmation of no-retention posture for Rekognition / Textract.]