PCI DSS 10.1.1: The policies and procedures behind Requirement 10 are written down, current, followed, and known to the people they apply to.

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's 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 whose anti-malware logs fall short of the 10.5.1 retention 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 without a procedure that adds each new system to it, "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, time synchronisation, 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 counts as a security event for the daily review. 10.4.1 fixes which logs are reviewed daily, but what counts as a security event varies by organisation and is yours to define. Without that definition a managed provider reviews against its own, which may be wrong for your environment.

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

• Anti-malware logs not retained as 10.5.1 requires, 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.