PCI DSS 3.3.1.1: The full contents of any track are not stored upon completion of the authorization process
PCI DSS v4.0.1 control 3.3.1.1: 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
The full contents of any track are not stored upon completion of the authorization process.
Summary
The full contents of the magnetic stripe or chip track are never kept once the authorisation is done.
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.1 | Examine data sources to verify that the full contents of any track are not stored upon completion of the authorization process. |
One of three controls under 3.3.1 naming a specific element of sensitive authentication data, and each procedure says the same thing: examine data sources. This is checked in the data, not in a design document. Track data is the richest of the three because it contains everything needed to construct a counterfeit card, and it is almost never stored deliberately. It arrives as a byproduct: raw terminal or gateway messages written to an application log, a debug capture left enabled after an integration problem, a crash dump, or an archived message queue. Note that "the full contents of any track" covers track 1 and track 2, so partial storage of one is still storage.
What to prepare
- The list of every place transaction messages come to rest, including logs and archives.
- Evidence of searching those places for track patterns.
- Debug and verbose logging settings on payment integrations.
- Message queue and archive retention.
How to implement it
1. Search for it rather than reasoning about it. The procedure examines data sources, so run the search yourself first across logs, archives, backups and support attachments.
2. Turn off raw message logging on payment integrations. It is enabled during implementation and troubleshooting and is the single most common route to stored track data.
3. Check the queues and the archives. A message broker that retains payloads is storing whatever the payload contained.
4. Fix the source, not the file. Deleting a log that will be rewritten tomorrow addresses the instance and not the control.
Where this commonly fails
- Verbose integration logging left on after go-live.
- Message archives retaining full payloads because retention was set for operational reasons.
- Crash dumps and error reports containing memory with track data in it.
- Searching the database and not the logs, which is where it usually is.
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.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.3.1 · All controls · 3.3.1.2 →
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.