PCI DSS 10.1.1: All security policies and operational procedures that are identified in Requirement 10
PCI DSS v4.0.1 control 10.1.1: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 10.1.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data › Section 10.1
All security policies and operational procedures that are identified in Requirement 10 are:
- Documented.
- Kept up to date.
- In use.
- Known to all affected parties.
Summary
The policies and procedures behind Requirement 10 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 | |
|---|---|
| 10.1.1 | Examine documentation and interview personnel to verify that security policies and operational procedures identified in Requirement 10 are managed in accordance with all elements specified in this requirement. |
Requirement 10 carries more separately-tested numbers than any other requirement, and its procedures are load-bearing for controls outside it. Daily review under 10.4.1, a periodic review at a frequency from a risk analysis under 10.4.2.1, twelve months of retention with three immediately available under 10.5.1, prompt backup under 10.3.3, prompt failure detection under 10.7.2. Other requirements then inherit them: 5.3.4 points at 10.5.1 by name, so an entity that documents retention loosely fails a Requirement 5 control without touching Requirement 5. The other thing worth writing down is onboarding: logging is configured for the systems that existed when it was set up, and there is rarely a procedure saying a new system must be added to it, which is how "in use" decays at the edges rather than in the middle.
What to prepare
- The Requirement 10 documents as a set: what is logged, what is reviewed and how often, retention, protection, and failure response.
- An owner and a review date on each.
- The onboarding procedure that brings a new system into logging.
- Who the affected parties are, including any managed provider.
How to implement it
1. Write the numbers down once and reference them. Retention, review frequencies and what counts as prompt should exist in one place, because several controls inside and outside Requirement 10 depend on the same values.
2. Document what "security-relevant" means for the daily review. 10.4.1 requires the review; deciding its scope is your procedure, and without it a managed provider is reviewing something well-defined and possibly wrong.
3. Make logging part of build and onboarding. A system provisioned outside the logging pipeline is invisible, and nothing else in the requirement detects that.
4. Include the provider as an affected party where log review or retention is outsourced.
Where this commonly fails
- Retention documented loosely, which also fails 5.3.4 through the reference.
- No onboarding step, so newer systems are outside logging entirely.
- The definition of security-relevant left to whoever performs the review.
- Procedures written when the SIEM was deployed and never revised.
Related controls
Others in section 10.1:
| Control | What it requires |
|---|---|
| 10.1.2 | Roles and responsibilities for performing activities in Requirement 10 are documented… |
← 9.5.1.3 · All controls · 10.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.