PCI DSS 3.3.2: SAD that is stored electronically prior to completion of authorization is encrypted using
PCI DSS v4.0.1 control 3.3.2: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 3.3.
Requirement 3: Protect Stored Account Data › Section 3.3
SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.
Summary
If you hold sensitive authentication data before authorisation completes, it must be strongly encrypted while you hold it.
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.2 | Examine data stores, system configurations, and/or vendor documentation to verify that all SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography. |
The narrow window 3.3.1 leaves open. SAD may exist before authorisation finishes, and while it does it must be encrypted with strong cryptography: the permission is about timing, not about the data being less sensitive. Two things follow. The window should be as short as you can make it, because everything in it is subject to this control. And "before authorisation" includes the places data waits: a queue, a retry buffer, a temporary file, a crash dump. After authorisation, 3.3.1 takes over and the answer is not encryption but destruction.
What to prepare
- The data flow showing where SAD exists before authorisation and for how long.
- Evidence of encryption at each of those points, including queues and temporary storage.
- Evidence it is rendered unrecoverable once authorisation completes, which is 3.3.1.
How to implement it
1. Shorten the window before encrypting it. Data that never rests needs less protecting; a synchronous authorisation with no retry buffer removes most of this control's surface.
2. Encrypt the queue, not just the database. Message brokers and retry stores are where pre-authorisation data actually sits, and they are rarely covered by whatever encrypts the primary datastore.
3. Watch the failure paths. A timeout that writes the request payload to a dead-letter queue or a log is the commonest way SAD survives authorisation without anyone deciding it should.
4. Make the transition explicit. Something has to delete this data when authorisation completes, or 3.3.1 is failed by the same store that satisfies 3.3.2.
Where this commonly fails
- Pre-authorisation SAD in an unencrypted queue while the database is encrypted.
- Crash dumps and error payloads containing SAD, outside any encryption.
- The window never bounded, so data permitted for seconds persists for months.
- Encryption treated as making retention acceptable after authorisation, which 3.3.1 forbids outright.
Related controls
Others in section 3.3:
| Control | What it requires |
|---|---|
| 3.3.1 | SAD is not stored after authorization, even if encrypted |
| 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.3 | Issuers: Any storage of sensitive authentication data… |
← 3.3.1.3 · All controls · 3.3.3 →
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.