Requirement 12: Support Information Security with Organizational Policies and Programs

PCI DSS v4.0.1 Requirement 12: the information security policy, targeted risk analyses, scope validation, third-party management and incident response.

PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1

Requirement 12 carries the most controls of any requirement, because it is where the programme around the technology lives. Several of its controls were new in v4.0, including the targeted risk analysis in 12.3.1, which became mandatory on 31 March 2025.

PCI DSS v4.0.1 breaks this requirement into 10 sections containing 37 individual controls.

What this requirement is actually asking

Targeted risk analysis (12.3.1) is the mechanism that unlocks flexibility elsewhere in the standard. Wherever a control lets you choose your own frequency (anti-malware scan intervals, some review cycles) the justification is a documented targeted risk analysis, reviewed at least once every 12 months and updated when that review shows it is needed. Without it, the flexible option is simply a gap.

12.5.2 requires scope to be documented and confirmed at least once every 12 months and upon significant change to the in-scope environment. Service providers do this at least once every six months and upon significant change (12.5.2.1). This confirmation is the entity's own work and does not replace the scoping check the assessor makes at each assessment.

12.10 covers incident response: a plan that is reviewed and tested at least once every 12 months (12.10.2), personnel available 24/7 (12.10.3), and responders trained at a frequency set in a targeted risk analysis (12.10.4.1).

Does it apply to you?

Every entity, though 12.4.1, 12.4.2, 12.4.2.1, 12.5.2.1, 12.5.3, 12.9.1 and 12.9.2 apply only to service providers. Nothing here can be outsourced away, though 12.8 and 12.9 govern how responsibility is shared with providers.

The controls

Requirement 12 contains 37 controls across 10 sections. Each links to its own page with the requirement in full and the testing procedures an assessor uses to verify it.

12.1: The information security policy itself, reviewed at least once every 12 months

Control What it requires Guidance
12.1.1 An overall information security policy… Yes
12.1.2 The information security policy… Yes
12.1.3 The security policy clearly defines information security roles and responsibilities for all… Yes
12.1.4 Responsibility for information security is formally assigned to a Chief Information Security… Yes

12.2: Acceptable use of end-user technologies

Control What it requires Guidance
12.2.1 Acceptable use policies for end-user technologies are documented and implemented… Yes

12.3: Targeted risk analyses, which underpin flexible controls elsewhere

Control What it requires Guidance
12.3.1 For each PCI DSS requirement that specifies completion of a targeted risk analysis… Yes
12.3.2 A targeted risk analysis is performed for each PCI DSS requirement that the entity meets… Yes
12.3.3 Cryptographic cipher suites and protocols in use are documented and reviewed at least once… Yes
12.3.4 Hardware and software technologies in use are reviewed at least once every 12 months… Yes

12.4: Managing PCI DSS compliance as an ongoing programme

Control What it requires Guidance
12.4.1 Service providers: Responsibility is established by executive management for the protection of cardholder data… Yes
12.4.2 Service providers: Reviews are performed at least once every three months to confirm that personnel are performing… Yes
12.4.2.1 Service providers: Reviews conducted in accordance with Requirement 12.4.2 are documented… Yes

12.5: Documenting and validating scope

Control What it requires Guidance
12.5.1 An inventory of system components that are in scope for PCI DSS… Yes
12.5.2 PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon… Yes
12.5.2.1 Service providers: PCI DSS scope is documented and confirmed by the entity at least once every six months and upon… Yes
12.5.3 Service providers: Significant changes to organizational structure result in a documented (internal) review… Yes

12.6: Security awareness education

Control What it requires Guidance
12.6.1 A formal security awareness program is implemented to make all personnel aware of the entity’s… Yes
12.6.2 The security awareness program… Yes
12.6.3 Personnel receive security awareness training… Yes
12.6.3.1 Security awareness training includes awareness of threats and vulnerabilities that could impact… Yes
12.6.3.2 Security awareness training includes awareness about the acceptable use of end-user… Yes

12.7: Personnel screening

Control What it requires Guidance
12.7.1 Potential personnel who will have access to the CDE are screened… Yes

12.8: Managing third-party service provider risk

Control What it requires Guidance
12.8.1 A list of all third-party service providers (TPSPs) with which account data is shared… Yes
12.8.2 Written agreements with TPSPs are maintained… Yes
12.8.3 An established process is implemented for engaging TPSPs… Yes
12.8.4 A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12… Yes
12.8.5 Information is maintained about which PCI DSS requirements are managed by each TPSP… Yes

12.9: Obligations that TPSPs owe their customers

Control What it requires Guidance
12.9.1 Service providers: TPSPs provide written agreements to customers that include acknowledgments that TPSPs… Yes
12.9.2 Service providers: TPSPs support their customers’ requests for information to meet Requirements 12.8.4 and 12.8.5… Yes

12.10: Incident response, tested at least once every 12 months

Control What it requires Guidance
12.10.1 An incident response plan exists and is ready to be activated in the event of a suspected… Yes
12.10.2 At least once every 12 months, the security incident response plan… Yes
12.10.3 Specific personnel are designated to be available on a 24/7 basis to respond to suspected… Yes
12.10.4 Personnel responsible for responding to suspected and confirmed security incidents… Yes
12.10.4.1 The frequency of periodic training for incident response personnel is defined in the entity’s… Yes
12.10.5 The security incident response plan includes monitoring and responding to alerts from security… Yes
12.10.6 The security incident response plan is modified and evolved according to lessons learned… Yes
12.10.7 Incident response procedures are in place, to be initiated upon the detection of stored PAN… Yes

Evidence your assessor will ask for

  • The policy, with evidence of review at least once every 12 months (12.1.2) and the formal assignment of information security to a member of executive management (12.1.4)
  • A targeted risk analysis for each requirement that specifies one (12.3.1)
  • A current scope document with the data flows that justify it
  • A TPSP register with written acknowledgement of responsibility (12.8.2) and monitoring evidence (12.8.4)
  • Incident response test records, and evidence the plan was updated afterwards

Where this commonly fails

  • A policy that was written once, approved once, and never reviewed again
  • Choosing the flexible option on a control without producing the risk analysis that permits it
  • A third-party register that lists vendors but has no responsibility matrix for any of them

Terms

Glossary entries that name a control in this requirement:

Official source

The commentary on this page is our own. The requirement title, and the control text in the tables above (shortened where it ends in an ellipsis), are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. Each control's own page carries its requirement text in full. For the authoritative wording, including each testing procedure and the customized approach objective, download the standard 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.