PCI DSS 6.1.1: All security policies and operational procedures that are identified in Requirement 6
PCI DSS v4.0.1 control 6.1.1: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 6.1.
Requirement 6: Develop and Maintain Secure Systems and Software › Section 6.1
All security policies and operational procedures that are identified in Requirement 6 are:
- Documented.
- Kept up to date.
- In use.
- Known to all affected parties.
Summary
The policies and procedures behind Requirement 6 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 | |
|---|---|
| 6.1.1 | Examine documentation and interview personnel to verify that security policies and operational procedures identified in Requirement 6 are managed in accordance with all elements specified in this requirement. |
Requirement 6 is the only requirement where "in use" can be enforced rather than described. Code review, testing, approval and deployment are steps a pipeline can refuse to skip, so the strongest possible evidence here is a build that will not deploy without them, and the weakest is a document describing a process people follow by convention. That is a genuine advantage and it is worth taking. The requirement also mandates its central document separately, in 6.2.1, leaving 6.1.1 to cover vulnerability intake, patching timescales, change control and the payment-page script process. Note that 6.5.1 is referenced by 1.2.2, so Requirement 6's change procedure is load-bearing for Requirement 1 as well.
What to prepare
- The Requirement 6 documents as a set: secure development, vulnerability intake and ranking, patching, change control, payment-page scripts.
- An owner and a review date on each.
- Pipeline configuration where a procedure is enforced technically, which is stronger evidence than the document.
- Who the affected parties are, spanning development and operations.
How to implement it
1. Enforce what you can in the pipeline. A required review, a blocking scan and a gated deploy are procedures that cannot silently stop being followed.
2. Write the procedures where developers already look. A repository or a wiki reaches them; a policy library does not, and "known to all affected parties" is tested by asking them.
3. Cover the operations half too. Change control and patching sit with different people than secure development, and an entity usually has good documentation for one and none for the other.
4. Do not let 6.2.1 stand in for the rest. It is one document with its own control; the vulnerability and change procedures have no equivalent push.
Where this commonly fails
- Excellent development documentation and nothing covering change control, or the reverse.
- Procedures in a policy library no developer has opened.
- A documented process the pipeline does not enforce, which drifts silently.
- Patching timescales stated in one place and practised differently, which fails "in use".
Related controls
Others in section 6.1:
| Control | What it requires |
|---|---|
| 6.1.2 | Roles and responsibilities for performing activities in Requirement 6 are documented, assigned… |
← 5.4.1 · All controls · 6.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.