PCI DSS 4.0.1 made security awareness a formal, auditable program — not a slide deck you run once at induction. If you store, process, or transmit account data, aligning training with Requirement 12.6 is now a continuous control with named evidence.
TL;DR
- PCI DSS 4.0.1 Requirement 12.6 needs a documented awareness program, annual review, hire-and-annual training, and staff acknowledgments.
- Since 31 March 2025, training must explicitly cover phishing and social engineering (12.6.3.1) and acceptable use of end-user technologies (12.6.3.2).
- Map modules and simulations to cardholder-data roles; collect completion and acknowledgment evidence QSAs can sample.
- Cyber Aware supports short lessons, phishing drills, and exportable records that sit beside your ROC narrative.
- Skip generic annual videos that never mention phishing, CDE access, or policy acknowledgment timestamps.
Why this matters
Cardholder data is still stolen through people: a phished help-desk reset, a shared terminal left unlocked, a finance clerk who pays a fake acquirer invoice. PCI DSS v4.0.1 — the clarification release that followed v4.0 — keeps Requirement 12.6 focused on a formal security awareness program that makes personnel aware of the entity's information security policy and their role in protecting account data.
In practice, assessors look for five things that weak programs miss: a written program description (12.6.1), at least annual program review and update for new threats (12.6.2), training at hire and at least every 12 months with acknowledgments (12.6.3), explicit phishing and social-engineering content (12.6.3.1), and acceptable use of end-user technologies tied to your 12.2.1 inventory (12.6.3.2). Future-dated phishing and acceptable-use expectations took effect on 31 March 2025, so 2026 assessments treat them as current obligations, not roadmap items.
Technical controls around the CDE still matter. Training is how you prove humans understand them.
Who this is for
This guide is for PCI compliance leads, CISOs, and training owners at merchants and service providers preparing a ROC or SAQ under PCI DSS 4.0.1. If QSA sampling will touch your people controls, use the steps below.
What you will need
- Your current information security policy and acceptable-use policy (end-user technologies list under 12.2.1)
- A roster of personnel in scope — anyone who can affect the security of account data, not only CDE admins
- A security awareness training catalogue you can map to 12.6 topics
- Phishing simulation capability for ongoing social-engineering practice
- A place to store completion timestamps and policy acknowledgments
- Thirty days before the next evidence request or assessment window
The steps
1. Write the program, not only the course list
Draft a one- to three-page security awareness program description: purpose, audience, topics, cadence (hire + annual), owners, how content is updated, and how acknowledgments are collected. This is the 12.6.1 artefact. A LMS screenshot is not a program.
Expected outcome: a dated program document linked from your PCI evidence index.
Common mistake: pointing the QSA at "we use Vendor X" with no scope, frequency, or update process.
2. Map every in-scope role to topics
List roles that touch account data, payment devices, support tools, or network paths to the CDE. Assign baseline modules (policy, phishing, acceptable use, incident reporting) and deeper modules for admins, developers, and finance. Include contractors who meet the same bar.
Expected outcome: a role-to-module matrix the assessor can sample.
Common mistake: training only IT while cashiers, contact centre, and AP still handle PAN or payment redirects.
3. Cover phishing and social engineering explicitly
12.6.3.1 expects awareness of phishing and related social engineering. Build short story-led lessons plus scheduled simulations that look like payment, HR, and vendor lures. Failures get automatic remediation, not public shaming. Track report rate in human risk reporting.
Expected outcome: content outline and sample simulation results dated inside the assessment period.
Common mistake: a single 2019 phishing slide with no 12-month activity.
4. Teach acceptable use of end-user technologies
12.6.3.2 ties training to the technologies you allow under 12.2.1 — email, browsers, messaging, remote access, removable media, BYOD, and so on. Staff should know what is approved, what is banned, and how to request an exception.
Expected outcome: a module or policy acknowledgment that names your actual technology list.
Common mistake: a generic "be careful online" video with no link to your approved tools.
5. Enrol at hire and force the 12-month cycle
Automate assignment on day one and set a 12-month recurrence with reminders and manager escalation. Collect an acknowledgment that the person received awareness of information security policies and procedures at least annually.
Expected outcome: hire-date and annual completion plus acknowledgment records for a QSA sample.
Common mistake: onboarding only, with no re-acknowledgment in year two.
6. Review the program every 12 months
Schedule a calendar-controlled review: new threats (deepfake vendor calls, QR phishing, help-desk MFA fatigue), incident lessons, policy changes, and simulation trends. Update materials and record the review date for 12.6.2.
Expected outcome: a short review minute and version-bumped content inside the last 12 months.
Common mistake: replaying the same package for three assessment cycles.
7. Package evidence the way assessors sample
Build a folder: program doc, role matrix, sample completions, acknowledgment export, simulation summary, and last annual review note. Keep it boring and complete.
Expected outcome: evidence pack ready within one business day of a request.
Common mistake: scrambling through HR inboxes during onsite fieldwork.
Troubleshooting
QSA says acknowledgments are missing. Completion is not always acknowledgment. Add an explicit policy-ack step with timestamp and version.
High turnover sites never hit 100%. Prioritise hire-date automation and 30-day cleanup reports for stores and seasonal staff.
Simulations blocked by email security. Whitelist simulation infrastructure before the campaign; document the control so it is not read as a real gap.
Service provider shares CDE duties with a customer. Clarify whose 12.6 program covers whose people in the responsibility matrix; do not assume the other party trained your staff.
Content feels generic. Inject your payment brand rules, your help-desk verification script, and one real (anonymised) near-miss from the last year.
Tools and resources
- Short PCI-aligned lessons and quizzes for hire and annual cycles
- Phishing simulations with remediation paths
- Exportable completion and acknowledgment reports
- Human risk views that combine training and simulation outcomes
- Your PCI DSS 4.0.1 ROC/SAQ template and information security policy set
- ACSC Essential Eight reading as complementary technical hygiene in Australian environments
What to do next
Once 12.6 evidence is clean, fold payment-diversion drills into the same cadence used for invoice fraud and supplier bank-detail verification. PCI awareness should not live in a silo from finance fraud controls.
FAQ
What does PCI DSS 4.0.1 require for security awareness training?
A formal documented program (12.6.1), at least annual review and update (12.6.2), training at hire and every 12 months with acknowledgments (12.6.3), plus explicit phishing/social-engineering and acceptable-use content (12.6.3.1 and 12.6.3.2).
When did the phishing training requirement become mandatory?
The phishing and social-engineering awareness requirement in 12.6.3.1 became effective 31 March 2025 as a future-dated obligation under PCI DSS v4.0/v4.0.1. 2026 assessments treat it as current.
Who must receive PCI security awareness training?
Personnel who can affect the security of account data — including roles outside pure IT, such as cashiers, contact centre, finance, and relevant contractors — according to your scoped environment.
Is a phishing simulation required by PCI DSS?
The standard requires awareness of phishing and social engineering; simulations are a widely accepted way to deliver and evidence that awareness but should sit inside a broader documented program.
How do I prove acknowledgments to a QSA?
Export timestamped records showing each in-scope person acknowledged information security policies and procedures at least every 12 months, tied to content version where possible.
Can SAQ merchants use a lighter program than ROC entities?
SAQ type affects overall validation, but 12.6 expectations still call for a real program matched to your environment. Lighter tooling is fine; missing hire/annual training and phishing content is not.
How often should we update awareness content?
At least every 12 months, and sooner when threats, policies, or payment channels change materially.
One last thing
QSAs have seen the same recycled phishing video for a decade. What changes findings is a short program document, fresh phishing content, and acknowledgments you can export without drama. Build that pack once, put the review on a calendar, and 12.6 stops being a scramble.