PCI DSS 4.0.1 Wants a Name Next to Every Control. Most Compliance Binders Still Say "The Team."
October 13, 2026
Ric Hall, CRO— AI-assisted and reviewed prior to publication.
PCI DSS 4.0.1 requires every one of its twelve requirement areas to have roles and responsibilities that are documented, assigned, and understood, not just a policy that references "IT" or "security." Assessors now interview the named person and check their training record. If your attestation still points to a department instead of a person, you have a gap an auditor will find.
What exactly changed in PCI DSS 4.0.1 around roles and responsibilities?
The requirement isn't new in concept, but it's now explicit and repeated across the standard. Sub-requirements like 1.1.2, 6.1.2, 7.1.2, 8.1.2, and 9.1.2 each state that roles and responsibilities for that specific requirement area are documented, assigned, and understood, a pattern the PCI Security Standards Council's own summary of changes lists as an "evolving requirement" across multiple sections of the standard.
That phrasing matters for how an assessor tests it. A written org chart naming "the security team" doesn't satisfy "understood." The assessor has to interview the specific person assigned to a control area and confirm they can describe what they own. One breakdown of PCI DSS Requirement 7's access-control provisions puts it plainly: a role matrix is only the intended model, and the assessment has to confirm that identity and access systems, database privileges, cloud roles, and service accounts actually enforce it in practice, not on paper.
The 51 requirements that PCI DSS 4.0 originally marked as future-dated, including most of the roles-and-responsibilities language, became fully mandatory on March 31, 2025. There is no more grace period to point to. Mid-market merchants who treated that date as a distant milestone are now discovering the gap during their current assessment cycle, according to one recent analysis of mid-market PCI gaps, which notes that 2026 is the first full calendar year in which every PCI DSS assessment occurs entirely after that deadline.
How does this show up in an actual assessment, and what does an assessor want to see?
An assessor wants a name, a title, a training date, and a description of what that person actually does when the control in question is triggered. This is most visible in incident response, where the standard goes further than most other sections. Requirement 12.10.4 requires personnel responsible for responding to security incidents to be appropriately and periodically trained, and 12.10.4.1 requires that training frequency be set by a targeted risk analysis, not a default annual calendar, a distinction explained in detail in an incident response requirements breakdown.
The standard also added Requirement 12.10.7, which requires specific procedures, owned by specific people, for what happens when stored primary account number data turns up somewhere it shouldn't be. The defined approach for Requirement 12.10.7 requires determining how the data got there, whether sensitive authentication data came with it, and how to remediate the process gap that caused it, then verifying through interviews and records that the procedure was actually followed, not just written down.
That interview-and-records testing procedure is the operational reality procurement and compliance leaders need to plan around. A written incident response plan with no named, trained responder behind it fails the assessment the same way a missing plan would. The PCI Security Standards Council's Internal Security Assessor program exists precisely because organizations need staff who can hold that line internally, build internal expertise, and support the consistent application of PCI DSS controls before an external QSA ever shows up.
Where the documentation gap actually lives
Most compliance teams have no trouble producing a policy document. The gap is almost always one layer down, in the evidence that a specific person understood and executed their assigned piece of the control. Three places this surfaces most often in a PCI DSS 4.0.1 assessment:
- Access reviews under Requirement 7 that list "IT Operations" as the reviewer instead of a named individual with a documented review cadence and sign-off.
- Incident response training records that show a generic annual session rather than a frequency justified by the targeted risk analysis 12.10.4.1 requires.
- Physical access and account provisioning logs where the approver field is a role, not a person, making it impossible to confirm who actually authorized the access.
None of these are expensive fixes. They're staffing and documentation fixes, which is exactly why they get missed. A security budget can buy a tool to automate log review, which 4.0.1 now requires, but it can't buy a documented understanding of a specific employee's role. That has to be built and demonstrated.
Why this is a procurement and accountability problem, not just a technical one
Boards and procurement teams evaluating a payment processor, merchant, or service provider increasingly ask for more than a certificate of compliance. They ask who on staff owns each control area and what qualifies that person to own it. A named employee with a current PCI credential, audit background, or formal security certification is evidence an executive can point to when a regulator, acquiring bank, or cyber insurer asks the same question after an incident.
This is also where the standard's own training infrastructure and outside certifications overlap. The ISA designation itself is explicitly aimed at job titles like internal auditor, IT audit director, and corporate security officer, roles that already map closely to formal information systems audit training. Building that internal capability on a foundation like Forge University's CISA certification prep gives a team member the audit methodology and controls-testing background that makes the "understood" part of PCI DSS 4.0.1's language defensible under interview, not just documented on paper.
The accountability case runs both directions. For the organization, a named and trained control owner is the difference between a clean assessment and a documented finding that has to be remediated before the next attestation cycle. For the individual, it's a credential that turns a generic job description into named, auditable ownership of a regulated control area, which is increasingly what separates a senior compliance analyst from someone who gets passed over for the role. If your team is mapping out who owns what and whether their qualifications would hold up in an interview with a QSA, the curriculum overview and FAQ on Forge University's resources page is a reasonable place to see how certification maps to the actual control areas PCI DSS tests.
None of this requires an overhaul. It requires an honest inventory of which PCI DSS requirement areas currently have a named, trained, documented owner and which ones still say "the team." Where the answer is the latter, you have a specific, fixable gap, not an abstract compliance risk. If you want a study plan built around closing that kind of staffing and documentation gap, you can start training whenever you're ready.
The March 2025 deadline already passed. What hasn't passed is the ongoing testing cycle that keeps checking for the same thing: a name, a title, a training record, and a person who can explain their piece of the control without reading from a policy binder. That's a lower bar than a new technical control, and a far easier one to fail by neglect.