PCI DSS Requirement 12: policies and programs

By Sam Rivera, Founder, SentinelPanda · August 6, 2026 · 3 min read · PCI DSS

The requirement people skim because it looks like paperwork. It contains the targeted risk analysis machinery the rest of v4.0 depends on, and the scope validation everything else rests on.

Policy is the least interesting part

Yes, Requirement 12.1 requires an overall information security policy, published, disseminated, reviewed at least once every twelve months, and updated when the environment changes. Requirement 12.2.1 requires acceptable use policies for end-user technologies. This is genuinely necessary and genuinely uninteresting.

The reason to read Requirement 12 carefully is everything else in it — particularly the risk analysis machinery, which the rest of the standard now leans on.

Targeted risk analyses

Requirement 12.3.1 introduced the targeted risk analysis (TRA) in v4.0, and it is the connective tissue of the whole version. Several requirements no longer specify a fixed frequency; instead they say the frequency is defined by a TRA. Each analysis must document the asset being protected, the threat, factors contributing to likelihood and impact, a review of how frequently the control must be performed, and be reviewed at least every twelve months.

Requirements that depend on a TRA include the malware evaluation frequency for systems not commonly affected (5.2.3.1), POI device inspection frequency (9.5.1.2.1), application and system account access review frequency (7.2.5.1), and payment page tamper detection frequency (11.6.1). If your TRAs are missing, those requirements have no defensible frequency behind them.

Requirement 12.3.3 requires review of cryptographic cipher suites and protocols in use at least annually, and 12.3.4 a review of hardware and software technologies to confirm they remain vendor-supported and can meet security requirements — the control that surfaces end-of-life systems before an assessor does.

People and third parties

• Security awareness training on hire and at least annually, with personnel acknowledging they have read and understood the policy (12.6.2, 12.6.3).
• Training must cover phishing and social engineering specifically (12.6.3.1), distinct from the technical anti-phishing mechanisms under 5.4.1.
• Personnel screened prior to hire, within the limits of local law (12.7.1).
• A list of third-party service providers with a description of the services provided (12.8.1), written agreements acknowledging their responsibility for account data (12.8.2), due diligence before engagement (12.8.3), monitoring of their PCI DSS compliance status at least annually (12.8.4), and a documented matrix of which requirements are managed by them, by you, or shared (12.8.5).

Incident response and scope validation

Requirement 12.10 requires an incident response plan that is tested at least annually, with defined roles, communication and contact strategies, procedures for containment and recovery, and review of the plan after each incident. Requirement 12.10.5 requires monitoring and response to alerts from security monitoring systems, and 12.10.7 requires procedures for responding to the detection of stored PAN where it is not expected.

Requirement 12.5.2 is the one worth ending on: PCI DSS scope must be documented and confirmed at least once every twelve months, and upon significant change. Service providers do this every six months (12.5.2.1). Scope validation covers identifying all data flows, all locations of account data, all system components in the CDE and connected to it, and confirming any segmentation.

Every other requirement in the standard applies to whatever your scope says it does. Getting scope wrong does not produce one finding — it produces an assessment built on a false premise. Keeping scope, evidence, third-party matrices, and annual review dates coherent across a year is precisely the ongoing bookkeeping SentinelPanda is designed to hold in one place.