Accountability sits with the regulated entity that collected or retained the documents, not with the existence of the rule change itself. Organisations must be able to show a defensible retention schedule, deletion process, and audit trail. If they cannot demonstrate those controls, they risk privacy breaches, regulatory scrutiny, and avoidable exposure in the event of a data incident.
Why This Matters for Security Teams
Identity document copies are often retained because AML, fraud, and onboarding teams assume the file itself is evidence of compliance. That assumption is risky. Once a retention deadline passes, the organisation must be able to justify why the records still exist, who approved the exception, and how deletion is enforced. The issue is not simply privacy hygiene; it is accountability across compliance, legal, security, and records management.
For regulated entities, the practical question is whether retention is still necessary under the applicable rule set and whether the organisation can prove that necessity. Guidance from the FATF Recommendations — AML and KYC Framework supports customer due diligence and recordkeeping, but it does not remove the need to follow local privacy, storage limitation, and deletion obligations. Security teams also need to treat these records as sensitive personal data, because legacy copies are a frequent target during breaches and internal misuse.
In practice, many security teams discover this gap only after a retention review, complaint, or incident has already exposed that deleted records were still live in backups, shared drives, or case management systems.
How It Works in Practice
Accountability usually sits with the regulated entity because that entity decides what to collect, where to store it, how long to retain it, and who can access it. The control problem is not limited to file deletion. Teams need a retention policy that maps each identity document type to a lawful purpose, a disposal trigger, and a responsible owner. That policy must also account for downstream systems, including case tools, archives, email attachments, imaging repositories, and backup infrastructure.
A defensible process typically includes:
- classification of identity document copies by purpose, sensitivity, and retention rule
- clear ownership across compliance, privacy, legal, and security teams
- automated deletion or archive expiry where possible
- exception handling for investigations, disputes, or ongoing AML obligations
- logging that shows when deletion occurred, what was deleted, and who approved any hold
From a control standpoint, the organisation should align retention governance with NIST Cybersecurity Framework 2.0 functions for governance and protection, and use NIST SP 800-53 Rev 5 Security and Privacy Controls to structure audit logging, media sanitisation, and access restrictions. For many organisations, ISO/IEC 27001:2022 Information Security Management and ISO/IEC 27002:2022 Information Security Controls provide the management-system discipline needed to keep retention rules current and enforced.
Where identity document copies feed KYC workflows, the same governance should extend to Non-Human Identity and automation accounts that access or move those records, because overly broad service access can silently defeat deletion and retention controls. These controls tend to break down when multiple business units store the same document in disconnected systems because no single owner can prove complete deletion.
Common Variations and Edge Cases
Tighter retention control often increases operational overhead, requiring organisations to balance evidentiary preservation against privacy minimisation and case-handling speed.
There is no universal standard for this yet across all jurisdictions, so the lawful retention period may differ by country, regulator, and product line. That means one branch may be required to keep source documents longer than another, and a global policy may need local overlays rather than a single fixed deletion date. Best practice is evolving toward purpose-based retention, not blanket retention.
Edge cases usually appear when:
- records are subject to legal hold, fraud investigation, or dispute resolution
- backups and archives cannot delete individual files on demand
- third-party KYC utilities retain copies after the customer file is closed
- shared service accounts can still access legacy repositories after staff believe deletion is complete
In those cases, accountability still remains with the regulated entity, even if a processor, platform, or outsourced operations team performed the storage. The entity must be able to show that vendor contracts, access controls, and deletion workflows match the promised retention period. When personal data and financial onboarding records overlap, the safest approach is to document the rule hierarchy explicitly and review it against AML obligations, privacy requirements, and any applicable regulator guidance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Retention accountability depends on governance, risk ownership, and policy enforcement. |
| NIST SP 800-53 Rev 5 | AU-11 | Audit evidence is needed to prove records were deleted or held lawfully. |
Assign a named owner for retention rules and verify deletion controls through governance reviews.
