PCI DSS 1.1.1: All security policies and operational procedures that are identified in Requirement 1
PCI DSS v4.0.1 control 1.1.1: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 1.1.
Requirement 1: Install and Maintain Network Security Controls › Section 1.1
All security policies and operational procedures that are identified in Requirement 1 are:
- Documented.
- Kept up to date.
- In use.
- Known to all affected parties.
Summary
The policies and procedures behind Requirement 1 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 | |
|---|---|
| 1.1.1 | Examine documentation and interview personnel to verify that security policies and operational procedures identified in Requirement 1 are managed in accordance with all elements specified in this requirement. |
More of Requirement 1's controls are documents than any other requirement's. The configuration standards in 1.2.1, the network diagram in 1.2.3, the data-flow diagram in 1.2.4 and the list of allowed services in 1.2.5 are four artefacts each with its own control, and each is separately tested for being current. That changes what 1.1.1 is left governing: not those artefacts, which are covered, but the procedures that keep them current. An entity can maintain all four diligently and still fail here, because the maintenance is one person's habit rather than a process, which is also why it stops when that person changes role.
What to prepare
- The Requirement 1 documents as a set, separating the four that are themselves controls from the procedures around them.
- An owner and a review date on each procedure.
- The process by which each artefact is updated, and its trigger.
- Who the affected parties are, including anyone who changes a cloud security group.
How to implement it
1. Write the maintenance procedures, not another copy of the artefacts. The diagrams and standards already have controls; what is missing is who updates them, when, and on what trigger.
2. Hang the triggers off change control. 1.2.2 already routes network changes through a process, so "does this change the diagram or the service list" belongs there.
3. Include the cloud engineers as affected parties. A security group rule is an NSC configuration change whether or not the person making it thinks of it that way.
4. Check "in use" by asking how the last update happened. If the answer is a name rather than a process, the procedure is the gap.
Where this commonly fails
- Four well-maintained artefacts with no documented procedure behind any of them.
- Maintenance dependent on one person, which is invisible until they move.
- Procedures that describe a network team as the only affected party.
- A document set assembled at assessment time and used at no other point.
Related controls
Others in section 1.1:
| Control | What it requires |
|---|---|
| 1.1.2 | Roles and responsibilities for performing activities in Requirement 1 are documented, assigned… |
All controls · 1.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.