PCI DSS 7.1.1: All security policies and operational procedures that are identified in Requirement 7
PCI DSS v4.0.1 control 7.1.1: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 7.1.
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know › Section 7.1
All security policies and operational procedures that are identified in Requirement 7 are:
- Documented.
- Kept up to date.
- In use.
- Known to all affected parties.
Summary
The policies and procedures behind Requirement 7 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 | |
|---|---|
| 7.1.1 | Examine documentation and interview personnel to verify that security policies and operational procedures identified in Requirement 7 are managed in accordance with all elements specified in this requirement. |
Requirement 7 already mandates its central document in 7.2.1, the written definition of how access is decided. What 7.1.1 covers is everything around it, and the distinctive problem is who the affected parties are. Requirement 7 runs on decisions made by business managers: who approves a privilege under 7.2.3, who signs the six-monthly review under 7.2.4, who confirms application account access remains appropriate under 7.2.5.1. Those people are line managers and system owners across the business, most of whom have never read an access control procedure and would not describe themselves as performing a PCI DSS activity. A procedure written for the identity team is documented and in use for the identity team, and unknown to the people whose approvals the requirement actually depends on.
What to prepare
- The Requirement 7 documents: the access policy from 7.2.1, approval procedures, the review procedure, and the least-privilege model.
- An owner and a review date on each.
- The affected parties named as roles, including approvers outside IT.
- Evidence those approvers received the procedure in a usable form.
How to implement it
1. Write a short version for approvers. The person signing an access review needs to know what they are attesting to, and a full access control policy is not that document.
2. Put the guidance in the workflow. Approval requests that carry the criteria with them reach the approver at the moment they matter, which a policy repository does not.
3. Refresh when managers change. Approver populations turn over with reorganisations, and awareness decays with them.
4. Do not let 7.2.1 stand in for the rest. It is one document with its own control; the review and approval procedures have no equivalent push.
Where this commonly fails
- Procedures written for and known only to the identity team.
- Approvers who sign reviews without knowing what the criteria are.
- A policy last revised before the current organisational structure existed.
- Least privilege described in a document and never translated into anything a manager can apply.
Related controls
Others in section 7.1:
| Control | What it requires |
|---|---|
| 7.1.2 | Roles and responsibilities for performing activities in Requirement 7 are documented, assigned… |
← 6.5.6 · All controls · 7.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.