PCI DSS 3.1.1: All security policies and operational procedures that are identified in Requirement 3
PCI DSS v4.0.1 control 3.1.1: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 3.1.
Requirement 3: Protect Stored Account Data › Section 3.1
All security policies and operational procedures that are identified in Requirement 3 are:
- Documented.
- Kept up to date.
- In use.
- Known to all affected parties.
Summary
The policies and procedures behind Requirement 3 are written down, current, followed, and known to the people they apply to.
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.1.1 | Examine documentation and interview personnel to verify that security policies and operational procedures identified in Requirement 3 are managed in accordance with all elements specified in this requirement. |
Requirement 3 is the only requirement whose procedures have to be known by people who never handle the data deliberately. Anyone who takes a support call, writes a log line, attaches a file to a ticket or forwards an email can create stored account data without intending to. That is why "known to all affected parties" reaches customer service, developers who decide what an application logs, and anyone who handles correspondence, none of whom would describe themselves as storing cardholder data. It is also the mechanism behind 12.10.7, the procedure for PAN turning up where it is not expected: the data usually got there because the person who created it did not know there was a rule, rather than because a control failed.
What to prepare
- The Requirement 3 documents as a set: retention and disposal, where account data is permitted to exist, encryption and key management, masking, and what to do on discovery.
- An owner and a review date on each.
- The affected parties named as roles, including non-technical ones.
- Evidence the rules reached them in a form they would read.
How to implement it
1. Write a short rule for the people who create data accidentally. "Never put a card number in a ticket, a log, an email or a screenshot, and here is what to do if you find one" is the version that reaches a support desk.
2. Give developers the logging rule specifically. What an application writes to its logs is a design decision made once and repeated everywhere, and 3.5.1.1 makes payment application logs explicitly in scope.
3. Connect it to discovery. People will find PAN where it should not be, and knowing what to do is part of "in use" for this requirement.
4. Do not let 3.2.1 stand in for the rest. Retention has its own control; the handling rules do not.
Where this commonly fails
- Procedures known to the platform and security teams and to nobody who talks to customers.
- No logging rule, so applications write what is convenient and PAN accumulates in log stores.
- Rules written in a data protection policy nobody outside compliance opens.
- Discovery handled ad hoc, so the same accidental storage recurs.
Related controls
Others in section 3.1:
| Control | What it requires |
|---|---|
| 3.1.2 | Roles and responsibilities for performing activities in Requirement 3 are documented, assigned… |
← 2.3.2 · All controls · 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.