PCI DSS 3.3.1: SAD is not stored after authorization, even if encrypted
PCI DSS v4.0.1 control 3.3.1: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 3.3.
Requirement 3: Protect Stored Account Data › Section 3.3
SAD is not stored after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process.
Summary
Never keep sensitive authentication data once the transaction is authorised, encrypted or not, and be able to show it is genuinely gone.
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.3.1.a | If SAD is received, examine documented policies, procedures, and system configurations to verify the data is not stored after authorization. |
| 3.3.1.b | If SAD is received, examine the documented procedures and observe the secure data deletion processes to verify the data is rendered unrecoverable upon completion of the authorization process. |
The most consequential storage rule in the standard, and the one whose breach does the most damage: full track data, card verification codes and PINs are what make a stolen record directly usable. Note "even if encrypted": encryption is not a mitigation here, it is explicitly ruled out as one. 3.3.1.a examines policies and procedures; 3.3.1.b examines data sources to verify SAD is not retained. The second is where entities are surprised, because SAD arrives in places nobody designed: gateway request logs, application error traces containing the request body, and support tickets. Distinguish it from 3.2.1, which governs account data retention generally; this one is absolute after authorisation.
What to prepare
- Data flows showing where SAD enters, and where it is rendered unrecoverable at the end of authorisation.
- Evidence from real data sources: log samples, database contents, error stores and backups searched for SAD patterns.
- The retention position for pre-authorisation SAD, which is permitted but bounded and covered by 3.2.1.
- Deletion mechanism evidence, showing unrecoverability rather than deletion.
How to implement it
1. Search rather than assert. The only credible evidence for 3.3.1.b is that someone looked. Grep the logs, the error tracker and a restored backup for track patterns and three-digit codes adjacent to a PAN. Finding nothing after looking is evidence; assuming nothing is not.
2. Look hardest where the data was never meant to be. Verbose request logging, a debug flag left on, an exception handler that serialises the whole payload, and screenshots attached to support tickets are the usual sources. None of them are in the data model.
3. Check the third parties who log on your behalf. Error tracking, APM and session replay all capture request payloads by default, and a redaction rule that was correct when written stops matching when a field is renamed.
4. Make unrecoverable mean unrecoverable. Overwritten, not deleted; and consider the backup that still contains yesterday’s copy. The requirement says rendered unrecoverable upon completion of authorisation, which is a much shorter window than a backup cycle.
Where this commonly fails
- Believing encryption solves it, when the requirement explicitly says "even if encrypted".
- SAD in application logs because the payment request was logged for debugging and the flag stayed on.
- A redaction rule matching a field name that the payment provider has since renamed.
- Pre-authorisation storage that is never bounded, so data legitimately held for minutes is still there months later.
- Backups excluded from the search, so production is clean and the restore is not.
Related controls
Others in section 3.3:
| Control | What it requires |
|---|---|
| 3.3.1.1 | The full contents of any track are not stored upon completion of the authorization process |
| 3.3.1.2 | The card verification code is not stored upon completion of the authorization process |
| 3.3.1.3 | The personal identification number (PIN) and the PIN block are not stored upon completion… |
| 3.3.2 | SAD that is stored electronically prior to completion of authorization is encrypted using… |
| 3.3.3 | Issuers: Any storage of sensitive authentication data… |
← 3.2.1 · All controls · 3.3.1.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.