PCI DSS 12.1.3: The security policy clearly defines information security roles and responsibilities for all
PCI DSS v4.0.1 control 12.1.3: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 12.1.
Requirement 12: Support Information Security with Organizational Policies and Programs › Section 12.1
The security policy clearly defines information security roles and responsibilities for all personnel, and all personnel are aware of and acknowledge their information security responsibilities.
Summary
The policy says what everyone is responsible for, people understand it, and they have acknowledged it.
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 | |
|---|---|
| 12.1.3.a | Examine the information security policy to verify that they clearly define information security roles and responsibilities for all personnel. |
| 12.1.3.b | Interview personnel in various roles to verify they understand their information security responsibilities. |
| 12.1.3.c | Examine documented evidence to verify personnel acknowledge their information security responsibilities. |
Three procedures testing three different things, and they fail independently. 12.1.3.a examines the policy for clearly defined roles and responsibilities for all personnel. 12.1.3.b interviews personnel in various roles to verify they understand theirs. 12.1.3.c examines documented evidence that they acknowledged them. So a complete policy with signed acknowledgements can still fail on the interview, which is the common outcome: people sign what they have not read. Note the scope is all personnel, not just technical staff, which makes this the general counterpart to the per-requirement role controls in every x.1.2. Those name who performs a requirement's activities; this one says every person has security responsibilities and knows what theirs are.
What to prepare
- The policy section defining roles and responsibilities, covering all personnel.
- Acknowledgement records, current and covering everyone.
- People from a range of roles who can describe their responsibilities.
- How the responsibilities are communicated beyond the signature.
How to implement it
1. Write responsibilities people recognise as theirs. "Comply with the information security policy" is not a responsibility anyone can restate; "do not share your credentials, report suspected phishing to this address, and do not put card numbers in tickets" is.
2. Separate the acknowledgement from the understanding. The signature satisfies 12.1.3.c and nothing else, and 12.1.3.b is asked of the person.
3. Cover non-technical roles. The interview samples various roles, and the policy has to have said something meaningful to each of them.
4. Refresh acknowledgements when the policy changes materially, since an acknowledgement of a superseded version is weak evidence.
Where this commonly fails
- Acknowledgements collected at onboarding and never refreshed.
- Responsibilities written generically, so nobody can restate their own.
- Technical roles covered in detail and everyone else covered by one sentence.
- Signed records with no evidence anyone read what they signed.
Related controls
Others in section 12.1:
| Control | What it requires |
|---|---|
| 12.1.1 | An overall information security policy… |
| 12.1.2 | The information security policy… |
| 12.1.4 | Responsibility for information security is formally assigned to a Chief Information Security… |
← 12.1.2 · All controls · 12.1.4 →
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.