Requirements 1 through 11 address the technical controls that protect the CDE. Requirement 12 addresses the organizational structure, governance processes, and documentation that makes those technical controls sustainable. A company can have technically excellent security and still fail a PCI DSS assessment if the policies, procedures, risk assessments, and training programs required by Requirement 12 are absent or deficient.
The Information Security Policy
A formal information security policy is the foundational document of Requirement 12. It must: address all areas of information security relevant to the CDE, be approved by management, published, and communicated to all relevant personnel, be reviewed at least annually and updated when the environment changes, and assign information security responsibilities to an identified Information Security Officer (or equivalent role).
Risk Assessment — The Targeted Risk Analysis (TRA)
PCI DSS v4.0 introduced the Targeted Risk Analysis (TRA) as a formal mechanism for certain requirements where the standard allows organization-specific frequency determination. Organizations must conduct a TRA for each of the 13 specific sub-requirements that reference it, documenting the risks being assessed, the control frequency selected, and the reasoning.
| KEY IDEA | The TRA is a new governance requirement that distinguishes v4.0 from v3.2.1. For each of the 13 sub-requirements that reference a TRA, the organization must document: what specific risks exist in their environment for that control, what frequency of control execution is appropriate given those risks, and how that decision was made. The TRA must be reviewed annually. |
Acceptable Use Policies and User Training
Acceptable use policies for end-user technologies must be developed and signed by users. Security awareness training must be provided to all personnel at hire and annually thereafter. Training must address: threats to cardholder data, phishing awareness (new v4.0 emphasis), physical security, clean desk policies, and how to respond to suspected security incidents.
Vendor and Third-Party Risk Management
Third-party service providers (TPSPs) with access to the CDE or cardholder data must be managed through a formal vendor management program. Requirements: due diligence before engagement, contractual security obligations (including PCI DSS compliance obligations), annual review of TPSP compliance status (AoC or other evidence), and identification of which PCI DSS requirements are managed by each TPSP.
| Vendor Management Control | Requirement | Evidence |
|---|---|---|
| Vendor inventory | List of all TPSPs with CDE access | TPSP register maintained and current |
| Pre-engagement due diligence | Verify TPSP's PCI DSS compliance before engagement | Completed vendor security questionnaire, AoC review |
| Contractual obligations | Written agreement covering security responsibilities | Executed DPA/security addendum in vendor contract |
| Annual compliance review | Verify TPSP remains compliant annually | Current AoC, annual compliance confirmation letter |
| Responsibility matrix | Document which PCI DSS requirements each TPSP manages | Responsibility assignment matrix (RACI) per TPSP |
Incident Response Plan
A formal incident response (IR) plan for security incidents that may impact cardholder data must be developed, documented, and tested annually. The IR plan must cover: roles and responsibilities (including card network notification requirements), containment procedures, preservation of evidence, root cause analysis, post-incident review, and notification to card networks and acquiring bank in the event of a confirmed breach.
| IMPORTANT | The incident response notification requirements for card data breaches are among the most consequential in PCI DSS. Organizations must notify their acquiring bank immediately upon discovering or suspecting a breach. The acquiring bank notifies the card networks. Response timelines — including forensic investigation, containment, and customer notification — are controlled by card network rules, not just the organization's preference. |
Personnel Background Screening
Personnel policies must include background screening for new hires who have access to the CDE. The scope and type of background check must be appropriate for the access level being granted.
Physical and Logical Security — Policies and Procedures
All security controls implemented under Requirements 1–11 must be supported by documented policies and procedures. These are both a governance requirement and a practical necessity — controls that are not documented cannot be consistently applied, and undocumented controls cannot be tested by QSAs.
| The most common Requirement 12 failure is not missing policies — it is policies that have never been communicated to employees, or that describe controls as they should work rather than as they actually work. QSAs will interview employees and compare what they say to what the policy documents state. Policies must reflect operational reality, and employees must actually know what they are required to do. |