PCI DSS 12.1.2: The information security policy
PCI DSS v4.0.1 control 12.1.2: the requirement in full, the 1 testing procedure 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 information security policy is:
- Reviewed at least once every 12 months.
- Updated as needed to reflect changes to business objectives or risks to the environment.
Summary
Review the information security policy every year, and change it when the business or the risks change.
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.2 | Examine the information security policy and interview responsible personnel to verify the policy is managed in accordance with all elements specified in this requirement. |
Two elements, and the second is the one that separates a maintained policy from a re-dated one. Reviewed at least once every 12 months is a date; updated as needed to reflect changes to business objectives or risks to the environment is a judgement, and a policy that has been reviewed five years running with no change is either describing a business that has not changed at all or is not really being read. The procedure examines the policy and interviews responsible personnel, so the reviewer is asked what changed and why. This is the maintenance obligation behind 12.1.1, which requires the policy to exist and be current in the first place.
What to prepare
- The policy with its version history and review dates.
- What each review changed, or the recorded conclusion that nothing needed changing.
- The business or risk changes that should have prompted an update.
- The reviewer, available for interview.
How to implement it
1. Record the reasoning, not just the date. "Reviewed, no changes required, because the environment and objectives are unchanged" is evidence; a new date on an unchanged document is not.
2. Trigger reviews on change as well as on the calendar. An acquisition, a new payment channel or a move to cloud are all changes to business objectives, and the annual cycle will miss them by up to a year.
3. Keep the version history visible. It is the cheapest evidence that the second element is being met.
4. Give it to a reviewer who knows the business. The interview asks what changed, and a purely editorial review cannot answer.
Where this commonly fails
- An annual re-dating with no substantive change through several years of change.
- Reviews performed by someone with no visibility of business objectives.
- Significant business change absorbed with no policy review until the next cycle.
- No record of what the review considered, so the second element cannot be shown.
Related controls
Others in section 12.1:
| Control | What it requires |
|---|---|
| 12.1.1 | An overall information security policy… |
| 12.1.3 | The security policy clearly defines information security roles and responsibilities for all… |
| 12.1.4 | Responsibility for information security is formally assigned to a Chief Information Security… |
← 12.1.1 · All controls · 12.1.3 →
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.