3.3.1 SAD not retained after authorization, even encrypted
Once authorization is complete, sensitive authentication data may not be kept at all, and encrypting it does not make storage acceptable. Any SAD the entity receives must be made unrecoverable when the authorization process ends. Guidance notes that SAD may sit briefly in non-persistent memory (RAM) after authorization only where there is a legitimate business need, it never reaches persistent storage, controls keep the memory non-persistent, and it is cleared once the purpose ends. Guidance also defines authorization as finished when the merchant gets a transaction response such as an approval or decline. Applicability: issuers and companies supporting issuing services that have a legitimate business need, documented, for keeping SAD are exempt and are covered instead by Requirement 3.3.3; SAD comprises the elements in 3.3.1.1 to 3.3.1.3. Objective under the customized approach: none, this requirement cannot be met through the customized approach.
Source: PCI DSS v4.0.1, 3.3.1. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open PCI DSS v4.0.1 in the compliance library.
Version 4.0.1 is the active version; 4.0 has been retired. Appendix A1 applies only to multi-tenant service providers, A2 only to card-present POS POI terminals that still use SSL or early TLS, and A3 only when a payment brand or acquirer requires it. Which requirements apply to you follows your validation type.
These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.
system holds itEvidence a system already holds
- Payment application or switch configuration showing SAD is purged at authorization response · Cloud console / configuration management
- Data discovery scan results across databases, logs and file shares showing no SAD · Vulnerability scanner / patch tooling
periodic reviewEvidence produced at each review
- Observation record of the secure deletion process for SAD · Document repository
- Evidence that memory handling keeps SAD non-persistent where it is briefly held · Document repository
governing documentDocuments that govern the control
- Policy and procedure prohibiting post-authorization SAD retention · Policy repository / GRC workspace
First move
Common gaps auditors find
- Debug or trace logging enabled in production writes SAD to disk
- Entity assumes encrypted SAD may be kept after authorization
- Crash dumps or memory dumps containing SAD not included in scans
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheet3.2.1 Data retention and disposal minimise stored account data · 3.3.1.1 Full track data not retained after authorization