PCI DSS 3.3.1: Never keep sensitive authentication data once the transaction is authorised, encrypted or not, and be able to show it is genuinely gone.
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.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
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 standard prohibits this storage because SAD lets criminals make counterfeit cards and fraudulent transactions: full track data (3.3.1.1), the card verification code (3.3.1.2) and the PIN and PIN block (3.3.1.3) are what make a stolen record directly usable, and each of those sub-requirements is tested by examining data sources. Note "even if encrypted": encryption is not a mitigation here, it is explicitly ruled out as one. 3.3.1.a examines policies, procedures and system configurations; 3.3.1.b observes the secure deletion processes to verify SAD is rendered unrecoverable. The data-source searches sit in 3.3.1.1 to 3.3.1.3, and they are 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 prohibits SAD after authorisation, encrypted or not. The only exception is for issuers and companies that support issuing services with a legitimate, documented business need, and 3.3.3 then applies to them.
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 position on pre-authorisation SAD: whether you may store it at all is set by the payment brands and acquirers, and where you do, 3.2.1 covers its retention and 3.3.2 requires it to be encrypted.
- 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.1 to 3.3.1.3 is that someone looked. Grep the logs, the error tracker and a restored backup for track patterns and three- and four-digit codes next 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 tools can capture request payloads, so check what each one records, 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… |
Terms
Glossary entries that name this control, each with its own example, limits and sources:
- Account Data
- Authorization
- Card Verification Code (CVC)/Card Verification Value (CVV)
- Magnetic Stripe Data
- Sensitive Authentication Data (SAD)
- Track 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.