PCI DSS 3.2.1: Account data storage is kept to a minimum through implementation of data retention and disposal
PCI DSS v4.0.1 control 3.2.1: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 3.2.
Requirement 3: Protect Stored Account Data › Section 3.2
Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following:
- Coverage for all locations of stored account data.
- Coverage for any sensitive authentication data (SAD) stored prior to completion of authorization. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.
- Limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements.
- Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification.
- Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy.
- A process for verifying, at least once every three months, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable.
Summary
Keep account data only as long as you have a written reason to, prove where all of it lives, and be able to show it is genuinely destroyed when that reason expires.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 3.2.1.a | Examine the data retention and disposal policies, procedures, and processes and interview personnel to verify processes are defined to include all elements specified in this requirement. |
| 3.2.1.b | Examine files and system records on system components where account data is stored to verify that the data storage amount and retention time does not exceed the requirements defined in the data retention policy. |
| 3.2.1.c | Observe the mechanisms used to render account data unrecoverable to verify data cannot be recovered. |
The three procedures test different things and are commonly failed separately. 3.2.1.a examines the policy and asks whether it covers every bullet. 3.2.1.b goes to the actual systems and checks the data there does not outlive what the policy says. 3.2.1.c watches your deletion mechanism run and verifies the data cannot be recovered afterwards. A policy that is correct on paper fails at 3.2.1.b if a forgotten export still holds card numbers. Note also the quarterly bullet: verifying that over-retained data has been deleted is itself a recurring obligation, not a one-off clean-up. If you never store account data, this control does not disappear, it becomes a control about proving that.
What to prepare
- A data retention and disposal policy naming every location account data can be stored, with a retention period and a written business, legal or regulatory justification for each.
- A current data-flow and data-location inventory. This is the same evidence 12.5.2 asks you to confirm at least annually.
- Records of the quarterly verification that data past its retention period has actually gone.
- A description of the deletion mechanism, and evidence it renders data unrecoverable rather than merely deleting a row or a pointer.
How to implement it
1. Find the data before writing the policy. Retention policies are usually written against the systems people remember. The failures are the ones they do not: database backups, CSV exports sitting in a shared drive, application and payment-gateway logs, support tickets with a card number pasted in by a customer, and email. A policy that does not name a location cannot govern it.
2. Write a justification per data element, not one for the whole database. The requirement asks for a defined retention period and a documented business justification. "We keep orders for seven years for tax" is a justification for the order record. It is not a justification for the PAN attached to it, which almost never needs to be kept at all.
3. Make deletion a scheduled job, not a task someone remembers. The quarterly verification exists because manual clean-up does not survive staff turnover. A job that runs on a schedule and writes a log gives you both the deletion and the evidence of it in one step.
4. Prove unrecoverability, not just deletion. 3.2.1.c is an observation: the assessor watches. A soft-delete flag, a truncated table with the backup untouched, or a file removed from a filesystem that still holds the blocks will all fail it. Say explicitly how each storage type is rendered unrecoverable, including in backups.
5. If you are a SAQ A merchant, aim the evidence at "none". The strongest answer here is a documented, verified position that no account data is stored anywhere in your environment, supported by the same inventory. That is far easier to defend than a retention schedule for data you did not need in the first place.
Where this commonly fails
- Backups excluded from the retention policy, so account data deleted from production continues to exist for the length of the backup cycle with no justification.
- Logs that capture full card numbers from a form post or an API error, which nobody classifies as account data storage until an assessor greps them.
- A policy that covers cardholder data but is silent on sensitive authentication data stored before authorisation completes, which is its own bullet in this requirement.
- The quarterly verification treated as an annual task, so the evidence covers one quarter in four.
- A merchant who believes they store nothing, has never looked, and cannot produce the inventory that would show it.
Related controls
← 3.1.2 · All controls · 3.3.1 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.