A database of 153 million driver's licenses is for sale on the dark web. You're under pressure to collect and verify more identity documents. Your fraud team wants them. Your compliance officer wants them. Your business units want frictionless onboarding that requires them.
Here's the decision you actually need to make: not how to store ID documents, but whether you should store them in the first place.
The Decision You're Facing
Every time you implement a new customer verification flow, vendor onboarding process, or access control mechanism, you're making a storage decision. The question isn't "What encryption standard should we use?" It's "Does this use case justify creating a persistent copy?"
AI systems can now identify vulnerabilities faster than humans. This means the time between discovering a flaw and attackers exploiting it is shorter. Your threat model must account for automated exploitation that moves faster than your patch cycle.
Key Factors That Affect Your Choice
Regulatory obligation. Some uses require you to retain identity documents. For example, the Bank Secrecy Act customer identification programs mandate verifying and recording identifying information. But "record" doesn't always mean "store a scanned copy in a database."
Retrieval necessity. Can you perform your compliance function with metadata instead of the document itself? If you need to prove you verified an ID on a specific date, a cryptographic hash of the document plus verification timestamp often satisfies the requirement without creating a retrievable target.
Access pattern. How many people need to see this document, and how often? If your fraud team reviews IDs during account opening but never revisits them, you're creating permanent risk for temporary value.
Breach liability. Under GDPR, you're the data controller. Under state data breach notification laws, you're the entity that must report. The liability follows the storage decision, not the business justification.
Path A: Don't Store the Document
Choose this when:
- Your verification requirement can be satisfied with metadata (verification date, document type, issuing jurisdiction, expiration date).
- You're using a third-party identity verification service that can attest to the check without passing you the document.
- The use case is one-time verification (age verification, right-to-work check, account opening).
- You have no litigation hold or regulatory retention mandate specific to that document class.
Implementation:
Record the verification event, not the document. Your compliance record should show: who verified, what document type, when, what data points matched, and the verification method. If you're using a service like IDology or Jumio, their attestation becomes your audit trail.
For PCI DSS environments, this approach eliminates a data category from your Cardholder Data Environment entirely. You can't lose what you don't have.
Regulatory alignment:
FFIEC IT Examination Handbook guidance on authentication emphasizes risk-based controls. If you can demonstrate effective identity verification without retention, you've reduced your risk profile. NIST SP 800-63B identity proofing requirements focus on verification strength, not document retention.
Path B: Store Metadata Only
Choose this when:
- You need to prove verification occurred but don't need the original document.
- Your legal team requires evidence of due diligence but not the underlying artifact.
- You're subject to audit but the auditor accepts verification logs.
- You want to re-verify identity without re-collecting documents.
Implementation:
Extract and store: document number (or a hash of it), issue date, expiration date, issuing authority, verification timestamp, and verification method. Discard the image immediately after extraction.
If you must retain proof of the document's appearance, store a cryptographic hash. You can later prove "this is the document we saw" without storing the document itself.
Regulatory alignment:
The Corporate Transparency Act beneficial ownership reporting requires you to verify identity, but FinCEN doesn't mandate that you retain copies of the verification documents indefinitely. Many institutions satisfy this with structured data extraction.
Path C: Store the Document in a Restricted Environment
Choose this when:
- You have an explicit regulatory mandate to retain the document (certain securities registrations, some lending programs).
- You're subject to litigation hold.
- Your regulator has specifically required document retention in writing.
- You operate in a jurisdiction where attestation-only verification isn't accepted.
Implementation:
Isolate the storage environment from your primary network. Apply Role-Based Access Control with named individuals, not role accounts. Log every access with justification. Encrypt at rest with a Key Encryption Key that's stored separately from your Data Encryption Key.
Set a retention schedule based on your regulatory obligation plus your litigation risk window. If BSA requires five years, don't keep documents for ten "just in case."
Implement Segmentation Testing to verify that an attacker who compromises your customer-facing systems can't reach the document repository. This isn't optional if you're treating ID documents as crown-jewel assets.
Regulatory alignment:
The FFIEC BSA/AML Examination Manual requires that you maintain records sufficient to reconstruct transactions and verify customer identity. For certain account types, that means retaining the ID document. But even here, the requirement is often "five years from account closure," not "forever."
Summary Matrix
| Factor | Don't Store | Metadata Only | Restricted Storage |
|---|---|---|---|
| Regulatory mandate | No retention requirement | Verification proof required | Document retention required |
| Access frequency | One-time verification | Periodic re-verification | Ongoing compliance review |
| Breach liability | Minimal | Limited to structured data | Full document exposure |
| Implementation cost | Low | Medium | High |
| Audit acceptance | Depends on jurisdiction | Widely accepted | Always accepted |
| PCI DSS impact | Removes data category | Minimal scope | Expands CDE if in scope |
The Nexus breach mentioned in recent reporting shows what happens when organizations store ID verification data in environments accessible to attackers. Until you treat ID verification data as a liability rather than an asset, you're building inventory for the next breach disclosure.
Your default should be Path A. Move to Path B only when you need verification proof. Reserve Path C for explicit regulatory mandates you can cite by statute and section number.
The question isn't whether your encryption is strong enough. It's whether you needed to encrypt anything at all.
