Security Awareness Program Review

PCI DSS requires you to review your security awareness program at least once every 12 months and update it whenever new threats, vulnerabilities, or CDE changes mean your workforce needs different guidance. To operationalize it fast, run a documented annual review with defined inputs (threat intel, incidents, CDE changes), produce a versioned update, and retain evidence that the update was approved and rolled out. ¹

Key takeaways:

• You need a formal, evidenced annual review of the security awareness program, not just annual training. ¹
• Updates must be risk-driven and event-driven, tied to new threats/vulnerabilities and changes affecting the CDE or personnel responsibilities. ¹
• Auditors look for operational proof: review records, version history, approvals, and deployment/communications artifacts.

“Security awareness program review” in PCI DSS is a governance control with teeth. It’s easy to treat it as a calendar reminder or a training refresh, but the requirement is broader: you must periodically validate that the entire program still fits your current CDE reality and the threat environment, then update it as needed. ¹

For a CCO, GRC lead, or compliance owner, the fastest path is to convert this into a repeatable operational workflow: define who owns the review, what inputs must be assessed, what constitutes a material change, and what artifacts you will retain to prove the review happened and resulted in updates when warranted. Your QSA (or internal audit) will test for evidence of review cadence, evidence of “as needed” updates, and evidence that personnel received accurate role-based guidance about protecting cardholder data.

This page gives you requirement-level implementation guidance you can put into a control narrative, a runbook, and an evidence kit. It focuses on what to do, what to save, and what examiners commonly challenge.

Regulatory text

Requirement (excerpt): “The security awareness program is reviewed at least once every 12 months, and updated as needed to address any new threats and vulnerabilities that may impact the security of the entity's CDE, or the information provided to personnel about their role in protecting cardholder data.” ¹

Operator interpretation (what this means in practice):

• You must perform a program-level review on an annual cadence. This is not limited to reissuing training content; it includes checking whether your awareness topics, role-based guidance, communications, and measurement still match your environment. ¹
• You must also update the program whenever conditions change, particularly:
  • New threats/vulnerabilities relevant to your CDE
  • Changes to the CDE or to how personnel interact with cardholder data
  • Gaps found through incidents, testing, or monitoring that indicate personnel guidance is outdated or incomplete ¹

Plain-English requirement

Run a documented annual checkup of your security awareness program, and refresh it whenever the threat landscape or your CDE changes mean employees need different instructions to protect cardholder data.

Who it applies to

Entities: Merchants and service providers that store, process, or transmit account data, and organizations whose people, processes, or systems can affect the security of the cardholder data environment (CDE). ¹

Operational context where it matters most:

• You have multiple teams touching payment flows (engineering, IT ops, customer support, fraud, finance).
• You rely on third parties that can affect CDE security (e.g., managed service providers, call center partners, e-commerce plugins).
• Your CDE scope changes frequently (new payment channels, new segmentation, cloud migrations).
• You’ve had phishing, credential theft, malware alerts, or policy exceptions that indicate awareness content may be stale.

What you actually need to do (step-by-step)

1) Define ownership, scope, and review criteria

Create a short “Security Awareness Program Review Procedure” that answers:

• Owner: Who runs the review (often Security/GRC) and who approves changes (CISO/CCO/IT leadership).
• Scope: What “program” includes (training modules, new-hire onboarding, periodic reminders, role-based guidance, acceptable use, phishing simulations if used, executive communications).
• Review criteria: What inputs must be checked and what triggers an update. Tie triggers to “new threats and vulnerabilities” and “information provided to personnel about their role in protecting cardholder data.” ¹

Practical minimum: one page of criteria plus a checklist used each cycle.

2) Build a required-inputs package (so the review is evidence-driven)

For each review cycle, compile and attach:

• Security incidents and near-misses with a human-factor element (phishing clicks, mis-sends, mishandling PAN, credential sharing).
• Vulnerability themes relevant to your environment (for example: MFA fatigue attacks if you use push-based MFA; social engineering patterns targeting your help desk).
• Material changes to the CDE: new systems in scope, new admin workflows, new payment channels, major architecture changes.
• Results from any internal security testing that indicates awareness gaps (e.g., recurring misconfigurations caused by misunderstanding process or policy).

Map each input to at least one of:

• “New threats and vulnerabilities that may impact the security of the entity’s CDE”
• “Information provided to personnel about their role in protecting cardholder data” ¹

3) Perform the annual review meeting and record decisions

Hold a working session with the actual stakeholders who can validate reality:

• Security/GRC (program owner)
• IT operations / platform owners in the CDE
• AppSec or engineering (if payment apps are developed/maintained)
• HR/L&D (if they publish training)
• Support/call center leadership (if they handle payment-related interactions)

Use a standard agenda:

1. Confirm program components and current version
2. Review required inputs package
3. Decide whether updates are needed; if yes, capture actions, owners, due dates
4. Confirm communication plan for updates

Record minutes and outcomes. Auditors want to see that the review produced decisions, not vague discussion. ¹

4) Update the program “as needed” and version-control it

If the review identifies changes, produce a concrete delta:

• Revised training content (slides, LMS module, microlearning)
• Updated role-based job aids (e.g., “How to handle card data in customer support tickets”)
• Updated security tips aligned to current threats (phishing themes, impersonation patterns)
• Revised onboarding content for roles with CDE access

Use basic version control:

• Version number / effective date
• Change log (“what changed and why”)
• Approver and approval date

This is the easiest way to prove you updated “as needed.” ¹

5) Roll out changes and keep deployment proof

Decide how updates reach personnel:

• LMS assignment to impacted roles
• Targeted communications (email, intranet post, Slack/Teams announcement)
• Manager talking points for teams with higher exposure
• Updated runbooks for operational teams handling card data

Retain proof of distribution and completion where applicable.

6) Create an “audit-ready” control narrative (what your QSA will test)

Write a short narrative that states:

• The program review occurs at least annually
• The inputs reviewed
• How “as needed” updates are triggered and implemented
• Where artifacts are stored and who approves changes ¹

If you use Daydream or a GRC system, treat this as a single control with a recurring task, assigned owners, and an evidence collection workflow so you don’t rebuild the evidence pack each assessment cycle.

Required evidence and artifacts to retain

Keep evidence in one folder (or GRC record) per review cycle:

Governance

• Security Awareness Program Review Procedure (current)
• Annual review calendar invite and attendee list
• Meeting minutes / decision record
• Approval record (email approval, ticket approval, e-signature)

Inputs reviewed

• Incident summaries relevant to awareness topics
• Summary of new threats/vulnerabilities considered
• CDE change summary (or references to change tickets/architecture updates)

Program outputs

• Updated security awareness program materials (versioned)
• Change log showing “what changed and why”
• Communications plan and copies of communications
• LMS assignment/completion evidence for impacted groups (if training was updated)

Follow-through

• Tickets/tasks showing updates were implemented
• Exceptions and compensating actions, if any

Common exam/audit questions and hangups

Expect these lines of questioning:

1. “Show me the annual review.” They will ask for dated evidence and proof it covers the whole program, not only a training completion report. ¹
2. “What triggers an out-of-cycle update?” “As needed” must be defined and evidenced by inputs like new threats, vulnerabilities, or CDE changes. ¹
3. “How did the review incorporate lessons learned?” If you had phishing incidents or operational mistakes, auditors often expect to see awareness content adjusted accordingly.
4. “How do you ensure role relevance?” The requirement explicitly points to personnel understanding their role in protecting cardholder data. Be ready to show role-based guidance and targeted distribution. ¹
5. “Where is the version history?” If your materials have no versioning, the auditor may struggle to confirm updates occurred.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Treating annual training completion as the “review”	The requirement is about reviewing and updating the program, not just reassigning a module. 1	Run a documented review meeting and produce a decision record plus change log.
No defined inputs	Review becomes subjective and hard to defend	Require incident themes, CDE changes, and threat/vulnerability considerations in every cycle.
Updates made but not traceable to triggers	Auditors cannot see “as needed” logic	Record “why this update was required” mapped to threats/vulns or role guidance gaps. 1
One-size-fits-all content	Role-based expectations get missed	Maintain job aids for high-impact roles (support, IT admins, developers with CDE access). 1
Evidence scattered across systems	Evidence collection becomes a scramble	Centralize evidence in a single repository or GRC record; assign an owner for evidence assembly.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific requirement, so treat risk in operational terms rather than penalty speculation. The practical failure mode is predictable: outdated guidance leads to human errors (phishing success, mishandling of cardholder data, poor incident escalation), and you cannot show operating effectiveness during PCI DSS assessment. ¹

Practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Assign an executive owner and a program operator.
• Draft the review procedure: scope, required inputs, triggers for updates, approval path. ¹
• Create templates: review checklist, minutes/decision log, change log, evidence index.
• Establish a single evidence repository location and access controls.

Days 31–60 (run the first review and close gaps)

• Gather the required-inputs package (incidents, CDE changes, threat/vulnerability themes).
• Hold the review meeting; document outcomes and actions. ¹
• Update awareness materials where required; version and approve them.
• Publish communications and assign any updated training to impacted roles.

Days 61–90 (make it repeatable and audit-ready)

• Confirm rollout proof: communications sent, LMS assignments/completions where applicable, updated job aids in the right places.
• Build the control narrative for your PCI DSS evidence binder.
• Add the annual review to your compliance calendar with automated reminders and pre-work tasks.
• If you use Daydream, configure a recurring control task with required evidence fields so each cycle produces a complete evidence pack without manual chasing.

Frequently Asked Questions

Does PCI DSS require security awareness training annually or a review of the program annually?

This requirement is specifically about reviewing the security awareness program at least once every 12 months and updating it as needed. Training cadence may be addressed elsewhere, but your evidence here must show a program review and, when appropriate, program updates. ¹

What counts as “updated as needed”?

Updates are required when new threats/vulnerabilities or changes affecting the CDE mean personnel need different guidance about protecting cardholder data. Your best defense is a change log that ties each update to a specific input from the review. ¹

If we had no incidents and no major changes, can the annual review conclude “no changes”?

Yes, if you can show the review occurred, the required inputs were assessed, and the decision was documented. Keep the minutes and checklist that supports the “no change needed” conclusion. ¹

Who should approve the review and any updates?

Use an approver who can commit the organization to program changes, typically Security leadership with GRC visibility. The key is consistency and auditable approval records tied to the versioned materials. ¹

How do we handle third-party personnel (contractors or call centers) who interact with cardholder data?

Include them in scope where their roles affect the CDE or cardholder data handling. Keep evidence that they received relevant role-based guidance or that your third party contract requires equivalent security awareness and you verified it. ¹

What’s the fastest way to make this “audit-proof”?

Standardize the cycle: checklist + inputs package + minutes/decision log + versioned artifacts + rollout proof, stored together. A GRC workflow (including Daydream) helps by making evidence fields mandatory and repeatable each cycle. ¹

What you actually need to do

Use the cited implementation guidance when translating the requirement into day-to-day operating steps. ²

Footnotes

1. PCI DSS v4.0.1 Requirement 12.6.2

2. Just Published: PCI DSS v4.0.1