Requirement 12 is where PCI DSS stops being a set of technical controls and becomes a managed programme, and it is the requirement most often met with documents that nobody reads or tests. PCI DSS v4.0.1 Requirement 12, "Support Information Security with Organizational Policies and Programs", covers the information security policy and its ownership, acceptable use, compliance management, annual scope confirmation, security awareness, personnel screening and incident response. This guide works through 12.1, 12.2, 12.4, 12.5, 12.6, 12.7 and 12.10 in depth. Targeted risk analysis (12.3) and third-party service provider management (12.8 and 12.9) have their own NHI Mgmt Group guides and are only summarised here. It is written for PCI programme owners, CISOs, GRC leads and incident response managers preparing for a Qualified Security Assessor (QSA) or a self-assessment. Requirement text is paraphrased from secondary sources that reproduce it; check every point against the current standard in the PCI SSC Document Library.
Source note: requirement wording is paraphrased from PCI DSS v4.0.1 as reproduced by secondary sources (the ComplianceAsCode PCI DSS v4 control file and Microsoft Learn) and from PCI SSC publications, because the standard itself is a PDF in the PCI SSC Document Library. Confirm against the official text before relying on it.
Key takeaways
- Named ownership is required: 12.1.4 formally assigns responsibility for information security to a CISO or another security-knowledgeable member of executive management, and 12.1.3 requires all personnel to acknowledge their responsibilities.
- Scope is confirmed, not assumed: 12.5.2 requires the entity to document and confirm PCI DSS scope at least once every 12 months and on significant change; service providers do it every six months (12.5.2.1).
- Awareness training has set content: 12.6.3 requires training on hire and at least every 12 months, and 12.6.3.1 and 12.6.3.2 add threats to the CDE, including phishing and social engineering, and acceptable use of end-user technologies.
- Incident response is tested and staffed: 12.10.2 requires the plan to be reviewed, updated and tested at least every 12 months, and 12.10.3 requires designated people available 24/7.
- Unexpected PAN is an incident: 12.10.7 requires incident response procedures to start when stored PAN is found anywhere it is not expected.
How Requirement 12 is structured
Requirement 12 has ten sections. Version 4.0.1 (June 2024) updated its applicability notes on the relationship between customers and third-party service providers but did not add or remove requirements, according to the PCI SSC. The wider standard is summarised in the PCI DSS 4.0 Guide.
| Section | Subject | Applies to | Covered in |
|---|---|---|---|
| 12.1 | Information security policy, review, roles, executive ownership | All entities | This guide |
| 12.2 | Acceptable use policies for end-user technologies | All entities | This guide |
| 12.3 | Targeted risk analyses, cipher suite and technology reviews | All entities | PCI DSS Customised Approach and Targeted Risk Analysis Guide |
| 12.4 | PCI DSS compliance management | Service providers only | This guide |
| 12.5 | Inventory and scope documentation and confirmation | All; 12.5.2.1 and 12.5.3 service providers only | This guide |
| 12.6 | Security awareness programme | All entities | This guide |
| 12.7 | Personnel screening | All entities | This guide |
| 12.8, 12.9 | Third-party service provider management and support | 12.8 all; 12.9 service providers | PCI DSS for Service Providers and Responsibility Matrix Guide |
| 12.10 | Incident response | All entities | This guide |
12.1 and 12.2: policy, ownership and acceptable use
- 12.1.1 overall policy: an information security policy is established, published, maintained and disseminated to all relevant personnel, and to relevant vendors and business partners. Keep it short and directive; detailed standards and procedures sit beneath it and are owned under each requirement's x.1.1 and x.1.2. See the Information Security Policy Template.
- 12.1.2 annual review: the policy is reviewed at least once every 12 months and updated when needed. Record the review even when nothing changes, with the approver and date.
- 12.1.3 roles and acknowledgement: the policy defines security roles and responsibilities for all personnel, and all personnel are aware of and acknowledge them. An HR or learning system acknowledgement on joining and on each major revision is the usual evidence.
- 12.1.4 executive ownership: responsibility for information security is formally assigned to a CISO or another security-knowledgeable member of executive management. A board minute, terms of reference or appointment letter is stronger evidence than an organisation chart. See the CISO Guide: First 90 Days.
- 12.2.1 acceptable use: acceptable use policies for end-user technologies are documented and implemented. In the standard these include explicit management approval for use of technologies, acceptable uses, and a list of company-approved products. Generative AI tools, remote access software and personal devices are the obvious current additions. See the Acceptable Use Policy Template and the AI Acceptable Use Policy Template.
12.3 in brief: risk analyses and annual reviews
12.3.1 requires a documented targeted risk analysis for each requirement that allows the entity to set a frequency (for example 5.2.3.1, 5.3.2.1, 10.4.2.1 and 12.10.4.1); 12.3.2 requires one for each requirement met with the customised approach. Two further items feed other requirements directly: 12.3.3 requires cryptographic cipher suites and protocols in use to be documented and reviewed at least once every 12 months, and 12.3.4 requires hardware and software technologies in use to be reviewed at least once every 12 months, which surfaces end-of-life platforms before they become findings.
12.4 and 12.5: compliance management and scope
12.4 (service providers only): 12.4.1 requires executive management to establish responsibility for protecting cardholder data and for a PCI DSS compliance programme. 12.4.2 requires reviews at least once every three months to confirm personnel are performing their tasks in accordance with security policies and procedures, and 12.4.2.1 requires those reviews to be documented. Typical review areas include daily log reviews, firewall rule set reviews, configuration standards, anti-malware alerts, change management and security alert responses; sample the evidence rather than ask teams whether they did it.
12.5.1 inventory: an inventory of in-scope system components, including a description of function or use, is maintained and kept current. Most technical requirements depend on it: coverage under 5.2.1, logging under 10.2, configuration standards under 2.2.1. See the Asset Inventory and CMDB Security Guide.
12.5.2 scope confirmation: the entity documents and confirms its PCI DSS scope at least once every 12 months and upon significant change to the in-scope environment. The PCI SSC highlighted this annual scope confirmation exercise in its 2024 guidance on adopting PCI DSS v4.x. In the standard, the confirmation covers identifying data flows, locations of account data, CDE and connected-to system components, segmentation controls and connections from third parties. A PCI SSC FAQ on reducing scope recommends data flow diagrams to identify all cardholder data flows and confirm that segmentation isolates the CDE.
| Scope confirmation step | Method | Output |
|---|---|---|
| Map account data flows | Workshops with payment, product and finance teams; review of payment integrations | Updated data flow diagrams |
| Find where account data lives | Data discovery scans for PAN on file shares, databases, logs, ticketing and collaboration tools | Data location list; 12.10.7 cases for unexpected PAN |
| Identify CDE and connected-to systems | Compare network flows and identity relationships with the 12.5.1 inventory | Updated inventory and system categories |
| Validate segmentation | Review of segmentation controls and penetration test results under 11.4.5 | Segmentation evidence |
| List third-party connections | Review of VPNs, APIs, SaaS integrations and remote support tools | Connection register linked to 12.8.1 |
| Approve and record | Sign-off by the 12.1.4 owner | Dated scope statement |
12.5.2.1 and 12.5.3 (service providers only): service providers confirm scope at least once every six months and on significant change, and must review the impact on scope and control applicability of significant changes to organisational structure, with results communicated to executive management. See the PCI DSS Scoping and Network Segmentation Guide.
Where identity fits
Scope is increasingly defined by identity as much as by network. A CI/CD pipeline's deployment key, an automation account with rights on CDE databases, or an AI agent with a token for a payment API makes those systems connected-to, even with no network path a firewall review would catch. Include non-human identities with access to CDE components in the scope confirmation, and record who owns each one. See the PCI DSS Requirements for Service Accounts and NHIs Guide and the AI Agents and PCI DSS guide.
12.6 and 12.7: awareness and screening
12.6.1 and 12.6.2 programme: a formal security awareness programme makes all personnel aware of the security policy and procedures and their role in protecting cardholder data, and the programme itself is reviewed at least every 12 months and updated for new threats and vulnerabilities that could affect the CDE.
12.6.3 delivery: personnel receive training on hire and at least once every 12 months, using multiple methods of communication, and acknowledge it at least once every 12 months. 12.6.3.1 requires the training to include awareness of threats and vulnerabilities that could affect the CDE, including phishing and related attacks and social engineering. 12.6.3.2 requires it to cover acceptable use of end-user technologies under 12.2.1.
Training complements the automated anti-phishing mechanisms required by 5.4.1; it does not replace them. See the PCI DSS Requirement 5 Guide, the Phishing Simulation Programme Guide and the CIS Control 14 Security Awareness and Skills Training Guide.
| Audience | Content beyond the baseline | Method |
|---|---|---|
| All personnel | Policy, phishing and social engineering, acceptable use, reporting | E-learning plus simulations and short reminders |
| Contact centre and store staff | Handling card data on calls and terminals, pretext calls, terminal tampering | Role-based sessions, floor walk-throughs |
| Engineers and administrators | Secrets in code and logs, privileged access, secure configuration | Technical workshops, code review guidance |
| Help desk | Identity verification for resets and MFA changes | Scenario training. See the Help Desk Identity Verification Policy Template |
| Executives and assistants | Payment fraud, impersonation, deepfakes | Briefings. See the Security Awareness for Executives and Assistants Guide |
12.7.1 screening: potential personnel who will have access to the CDE are screened, within the constraints of local laws, before hire. The depth of screening is the entity's choice; document what is checked per role, how local law limits it, and how contractors supplied by third parties are screened. Insider cases show why: the Coinbase insider breach involved bribed support agents with access to customer data. See the Insider Threat Programme Guide.
12.10: incident response
12.10 is the operational core of Requirement 12. 12.10.1 requires an incident response plan that exists and is ready to be activated for suspected or confirmed incidents. In the standard, the plan covers roles, responsibilities and communication strategies, including notifying payment brands and acquirers; incident response procedures with specific containment and mitigation activities; business recovery and continuity; data backup processes; analysis of legal requirements for reporting compromises; coverage and responses of all critical system components; and reference to or inclusion of incident response procedures from the payment brands.
| Sub-requirement | Requirement (paraphrased) | Evidence |
|---|---|---|
| 12.10.1 | Plan exists and is ready to activate | Approved plan with payment brand and acquirer contacts |
| 12.10.2 | Plan reviewed, updated and tested at least every 12 months | Exercise report, plan version history |
| 12.10.3 | Specific personnel available 24/7 | On-call rota, escalation paths, contact tests |
| 12.10.4 | Responders appropriately and periodically trained | Training records per responder |
| 12.10.4.1 | Training frequency set by targeted risk analysis | Targeted risk analysis per 12.3.1 |
| 12.10.5 | Plan includes monitoring and responding to alerts from security monitoring systems | Alert sources listed in the plan, runbooks per alert type |
| 12.10.6 | Plan evolves with lessons learned and industry developments | Post-incident reviews, change log |
| 12.10.7 | Procedures initiated when stored PAN is found where it is not expected | Procedure covering retrieval, deletion or migration, root cause and remediation |
12.10.5 alert sources: in the standard, the alert sources include intrusion detection and prevention, network security controls, change and tamper detection for critical files, the change and tamper detection mechanism for payment pages under 11.6.1, and detection of unauthorised wireless access points. Map each to a runbook.
12.10.7 unexpected PAN: treat each discovery as an incident: determine what to do with the data (secure deletion or migration into the CDE), find how it got there, and close the process gap, for example a debug log, a support ticket form or a spreadsheet export. Data discovery during 12.5.2 is the usual trigger.
Testing: 12.10.2 testing can be a tabletop for many entities, but a test that never touches technical steps (isolating a host, revoking a key, preserving logs) leaves gaps. NIST SP 800-61 Rev. 3, published in April 2025 as a CSF 2.0 Community Profile, is a useful structure for the plan and its tests. See the Incident Response Plan Template, the Retail Incident Response Guide and the NIST SP 800-61 Incident Response Guide.
Decision guidance
- Merchant or service provider: service providers carry 12.4, 12.5.2.1, 12.5.3 and 12.9 on top of the merchant set; check your status before planning effort. See the PCI DSS SAQ Types guide.
- One policy set or a PCI-specific set: organisations with an ISO/IEC 27001 ISMS usually extend their existing policies with PCI-specific clauses rather than writing a parallel set; small merchants can use a single concise policy with an appendix per requirement. See the PCI DSS 4.0 to ISO 27001 Mapping Guide.
- In-house or retained incident response: 12.10.3 requires 24/7 availability; smaller entities commonly meet it with an incident response retainer plus a named internal decision-maker on call.
- Who owns scope confirmation: place it with the PCI programme owner but make engineering and payment product leads co-sign, because they know where new data flows appear.
How to implement Requirement 12
- Appoint and record ownership: formalise the 12.1.4 executive owner and the 12.4.1 compliance responsibility for service providers.
- Refresh the policy stack: update the information security and acceptable use policies, map each PCI requirement's x.1.1 and x.1.2 to its procedure owner, and run acknowledgements.
- Build the calendar: one schedule for the annual and periodic activities (12.1.2, 12.3.3, 12.3.4, 12.5.2, 12.6.2, 12.6.3, 12.10.2, and quarterly 12.4.2 reviews for service providers) with owners and evidence locations.
- Run the first scope confirmation: data discovery, data flow mapping and inventory reconciliation; open 12.10.7 cases for unexpected PAN.
- Update awareness content: add CDE threats, phishing, social engineering and acceptable use; pilot with one business unit, measure, then roll out.
- Test incident response: exercise a realistic scenario (skimming script on the payment page, stolen service account key), record gaps, update the plan and keep the previous version so the change history is visible.
- Review and improve: feed lessons learned and assessment findings back into policy and training each cycle (12.10.6).
Detection and measurement
| Metric | Target (our recommendation) | Sub-requirement |
|---|---|---|
| Personnel with current policy acknowledgement | Above 98% | 12.1.3 |
| Personnel trained on hire and within the last 12 months | 100% of those with CDE impact | 12.6.3 |
| Phishing simulation report rate | Rising quarter on quarter | 12.6.3.1 |
| Days since last documented scope confirmation | Below 365 (below 183 for service providers) | 12.5.2, 12.5.2.1 |
| Unexpected PAN discoveries closed with root cause | 100% within the agreed period | 12.10.7 |
| Incident response actions from the last exercise closed | 100% before the next exercise | 12.10.2, 12.10.6 |
Framework mapping
| PCI DSS v4.0.1 | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 |
|---|---|---|---|
| 12.1 policy and ownership | PL-1, PM-2 | GV.PO-01, GV.RR-02 | Governance across controls |
| 12.2 acceptable use | PL-4 | GV.PO-01 | Control 14 |
| 12.5 inventory and scope | CM-8 | ID.AM-01, GV.OC-03 | Control 1, Control 3 |
| 12.6 awareness | AT-2, AT-2(3) | PR.AT-01 | Control 14 |
| 12.7 screening | PS-3 | GV.RR-02 | Not covered directly |
| 12.10 incident response | IR-2, IR-3, IR-4, IR-8 | RS.MA-01 | Control 17 |
In ISO/IEC 27001:2022 Annex A, the closest controls are 5.1 Policies for information security, 5.10 Acceptable use, 6.1 Screening, 6.3 Awareness, education and training, and 5.24 to 5.28 on incident management.
Common failure patterns
- Policy without evidence: a well-written policy but no review record, no acknowledgements and no named executive owner.
- Scope copied forward: last year's scope statement re-signed without data discovery, missing a new payment integration or a SaaS tool that now receives PAN.
- Training that ignores the CDE: a generic annual module with no content on card data handling, phishing or acceptable use, failing 12.6.3.1 and 12.6.3.2.
- Untested plan: an incident response plan whose payment brand contacts and on-call numbers are out of date because the 12.10.2 test was a document review.
- No 12.10.7 trigger: PAN found in a log or ticket is quietly deleted with no incident record or root cause.
- Contractors outside the programme: outsourced staff never screened, trained or asked to acknowledge the policy.
Practitioner checklist
- Record the executive owner for information security and, for service providers, the PCI compliance programme (12.1.4, 12.4.1).
- Review the information security policy every 12 months and collect acknowledgements (12.1.2, 12.1.3).
- Maintain acceptable use policies with approved technologies, including AI tools (12.2.1).
- Keep the in-scope inventory current and confirm scope every 12 months, or six for service providers (12.5.1, 12.5.2).
- Include non-human identities with CDE access in scope confirmation.
- Deliver awareness training on hire and annually with CDE threats and acceptable use content (12.6.3.x).
- Screen personnel with CDE access before hire within local law (12.7.1).
- Test the incident response plan at least every 12 months, keep 24/7 cover and handle unexpected PAN as an incident (12.10.x).
Standards and references
- PCI SSC: Document Library (PCI DSS v4.0.1)
- PCI SSC: Now is the time to adopt the future-dated requirements of PCI DSS v4.x
- PCI SSC: Just Published, PCI DSS v4.0.1
- PCI SSC FAQ 1178: How do I reduce the scope of a PCI DSS assessment?
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: PCI DSS 4.0 Guide, PCI DSS Readiness Checklist, PCI DSS for Service Providers and Responsibility Matrix Guide, Incident Response Plan Template, Security Programme Building Guide. This guide summarises PCI DSS v4.0.1 Requirement 12 and is not legal or assessment advice.