PCI DSS 8.1.1: All security policies and operational procedures that are identified in Requirement 8
PCI DSS v4.0.1 control 8.1.1: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 8.1.
Requirement 8: Identify Users and Authenticate Access to System Components › Section 8.1
All security policies and operational procedures that are identified in Requirement 8 are:
- Documented.
- Kept up to date.
- In use.
- Known to all affected parties.
Summary
The policies and procedures behind Requirement 8 are written down, current, actually 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 | |
|---|---|
| 8.1.1 | Examine documentation and interview personnel to verify that security policies and operational procedures that are identified in Requirement 8 are managed in accordance with all elements specified in this requirement. |
Every requirement opens with a control of this shape and the same four bullets, so the useful question is what makes it different here. Requirement 8 is the only one whose own body separately mandates communication of part of its policy: 8.3.8 requires the authentication policy to reach all users and interviews users to check they are familiar with it. That leaves a real division. 8.3.8 covers the user-facing half, the guidance on choosing and protecting factors. 8.1.1 covers everything else in Requirement 8, which is mostly operational procedure users never see: how accounts are provisioned and approved, how a factor is reset, how service-account credentials are managed, how terminations are actioned. Those are the documents that go stale, because nothing else in the requirement forces anyone to look at them. Of the four bullets, in use and known to all affected parties are where this is lost, and the affected parties for Requirement 8 include the service desk, the identity team and whoever administers each application with its own user store.
What to prepare
- The Requirement 8 documents as a set, listed rather than assumed: identity lifecycle, authentication policy, MFA, service and application accounts, reset and verification.
- An owner and a review date on each.
- Evidence they are in use, meaning the current process matches what is written.
- Who the affected parties are for each document, which is rarely the same list twice.
How to implement it
1. List the documents before assessing them. Requirement 8 spreads across identity, security and application teams, so the set is usually assembled for the first time during the assessment, and assembling it is where gaps show.
2. Check "in use" against the people, not the document. The service desk reset procedure is the usual divergence: the written one requires verification and the practised one is faster.
3. Do not let 8.3.8 stand in for this. Distributing the authentication policy to users is one document reaching one audience. The operational procedures have different audiences and no equivalent push.
4. Give each document a named owner in the same place as the roles from 8.1.2. Unowned documents are the ones that fail "kept up to date".
Where this commonly fails
- The user-facing authentication policy maintained because 8.3.8 forces it, and the operational procedures behind it years out of date.
- Procedures describing a directory or a tool that has since been replaced.
- Application owners who administer their own user store never counted as affected parties.
- A document set that exists only as an assessment artefact, assembled each year and used at no other time.
Related controls
Others in section 8.1:
| Control | What it requires |
|---|---|
| 8.1.2 | Roles and responsibilities for performing activities in Requirement 8 are documented, assigned… |
← 7.3.3 · All controls · 8.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.