When PCI DSS 4.0.1 took effect on March 31, 2025, Requirement 12.6 stopped being the easiest line item in the entire standard. For years it asked almost nothing of security teams: run an annual training video, log a completion percentage, move on. Now it asks for a documented program, reviewed at least every 12 months, role-based content that covers phishing and social engineering, and, for the first time, explicit coverage of acceptable use of end-user technologies. That last piece is the one most programs are least ready for.
If your environment touches cardholder data, retail, hospitality, financial services, this is worth ten minutes of your attention before your next assessment, not after it.
What actually changed
Four things moved at once inside 12.6. The program itself has to be formal and documented, not a folder of slides someone assembled the week before the audit. It has to run on a real cadence: training at hire, again at least every 12 months, with a record of who completed it and when. The content has to name the social engineering patterns an organization’s own environment actually faces, not a generic definition of phishing. And under 4.0.1, it has to explicitly cover acceptable use of end-user technology, which in 2026 means the AI tools employees are already using, sanctioned or not.
None of that is exotic on its own. Taken together, it is considerably more than a video and a quiz, and most programs were built for the version of the requirement that no longer exists.
The other trigger in 12.6.2
Most summaries of 12.6.2 stop at the twelve-month cadence, because that is the part that fits neatly into a compliance checklist. The requirement actually has two triggers. The program must be reviewed and updated at least once every twelve months, and separately, whenever new threats or vulnerabilities emerge that could affect the environment. Those are not the same obligation, and the second one is the harder problem to solve.
A twelve-month cadence is a scheduling problem. Put it on the calendar, assign an owner, done. Addressing new threats as they emerge is a production problem, and legacy awareness programs were never built to solve that quickly. Writing a new module, routing it through legal for exact wording, getting sign-off from HR and GRC, and pushing it into an LMS typically takes weeks. A new vishing script aimed at help desks, or a deepfake-voice fraud pattern, can spread across an industry in days.
That gap is why the second trigger in 12.6.2 sits mostly unaddressed, even in programs that pass their assessment. A completion report proves the twelve-month box got checked. It says nothing about whether the training a call center agent received in March still reflects how attackers are calling in September.
The two-metric trap
Most awareness programs were built around two numbers: who completed the training, and who clicked the phishing test. Neither number says much about whether a cashier is actually less likely to hand a stranger cardholder data over the phone. Activity happened. Risk may not have moved at all.
Picture the QSA interview. The completion report says 98 percent. The auditor asks a call center lead to explain how they would handle a caller who already knows the last four digits of a card number. If the honest answer is “I finished the training in March,” that 98 percent just became a finding, not evidence.
That is roughly the direction QSAs are already moving. Role-based content mapped to actual policy. Personnel who can explain, in their own words, what they are responsible for protecting. Documented handling for the person who missed training and nobody followed up on. A spreadsheet of green checkmarks does not survive that conversation, and it was never designed to.
Compliance is the floor, not the ceiling
Here is the distinction worth sitting with: passing an assessment and reducing actual risk are two different jobs. An organization can satisfy 12.6 on paper, documentation tidy and current, and still have a help desk team that resets a multi-factor token for anyone who sounds urgent enough on the phone.
That is not hypothetical. MGM Resorts lost more than 100 million dollars because one social engineering call talked its way past identity verification at the help desk. No annual video would have stopped that call. The distance between trained in January and would have caught it in October is exactly where 4.0.1 is now pointing, and exactly where most programs still have nothing to show.
The part nobody puts in the audit narrative
Every security leader who has run one of these programs knows the harder problem is not the training content. It is the coordination. HR wants to know what happens to someone who fails a simulation three times. Legal wants to see the exact wording before a vishing test goes out. GRC wants evidence that survives a regulator, not a vendor demo. A lean team is doing all of that while also trying to keep the content current against threats that changed since the last content review cycle closed.
That is the real reason most programs default to an annual video. Not because security teams do not know better, but because building anything more specific, at hire, per role, updated as threats shift, has historically required headcount most teams do not have.
What closing the gap actually requires
Training that reflects the requirement in spirit, not just the letter, looks different from what most organizations run today. It is role-based in practice, not just in a slide that claims it is tailored by department, because a cashier and an accounts payable clerk face different attackers and need different preparation. It moves at the speed the second trigger in 12.6.2 actually demands, not the speed a content calendar allows. And it produces evidence that a person’s behavior changed, not just a log of who clicked play.
That is the specific problem I spend my time on at Fable: closing the distance between what someone was taught in January and what they would actually do under pressure in October, using the security signals an organization already has instead of adding another portal nobody opens.
We put the specifics behind that claim into a requirement-by-requirement mapping of 12.6 against this approach, for anyone who wants the detail rather than the argument.
The floor moved
None of this means a well-run program suddenly fails PCI DSS. It means the bar for what counts as evidence just moved, and the distance between technically compliant and actually less likely to lose cardholder data to a phone call has not gotten any smaller. Security teams have known that distance was real for years. Their auditors are only now starting to ask about it too.