PCI DSS 4.1.1: All security policies and operational procedures that are identified in Requirement 4
PCI DSS v4.0.1 control 4.1.1: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 4.1.
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks › Section 4.1
All security policies and operational procedures that are identified in Requirement 4 are:
- Documented.
- Kept up to date.
- In use.
- Known to all affected parties.
Summary
Have written policies and procedures for how you protect cardholder data in transit, keep them current, and make sure the people who do the work have actually read them.
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 | |
|---|---|
| 4.1.1 | Examine documentation and interview personnel to verify that security policies and operational procedures identified in Requirement 4 are managed in accordance with all elements specified in this requirement. |
The four bullets are tested as four separate things, and "in use" plus "known to all affected parties" are where entities lose this. A procedure that exists in a document repository nobody opens satisfies "documented" and fails the other two. The assessor interviews your people; if the engineer who manages the load balancer certificates has never seen the procedure, the control fails regardless of how good the document is.
What to prepare
- The policy and procedure documents covering Requirement 4, with an owner and a review date on each.
- Evidence of the last review: an approval record, a version history, or a dated sign-off.
- Evidence that the people doing the work know them, such as onboarding records, training completion, or acknowledgement records.
- A list of who "all affected parties" actually means for transport encryption in your organisation.
How to implement it
1. Write procedures for what your team actually does. For Requirement 4 that usually means: how a certificate is requested, issued, installed and renewed; what TLS configuration is approved; who may change it; and how an expiring certificate is detected before it expires rather than after.
2. Give each document an owner and a review cycle. Annual is the common cadence and is what an assessor will look for. Record the review even when nothing changed, because "reviewed, no changes required" is evidence and silence is not.
3. Close the "known to all affected parties" gap deliberately. Identify every role that touches PAN in transit, including people outside the security team such as the network engineers and whoever operates the CDN, and record that they have been made aware.
Where this commonly fails
- A polished policy that describes a certificate process nobody follows, because the real process is a calendar reminder on one person's laptop.
- Documents last reviewed at the previous assessment, so the review cycle is visibly assessment-driven rather than operational.
- Procedures that stop at the web servers and never mention the CDN, load balancer or API gateway that actually terminates TLS.
Related controls
Others in section 4.1:
| Control | What it requires |
|---|---|
| 4.1.2 | Roles and responsibilities for performing activities in Requirement 4 are documented, assigned… |
← 3.7.9 · All controls · 4.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.