PCI DSS security awareness training

PCI DSS v4.0.1 breaks Requirement 12.6 into five testable parts, and two of them, phishing awareness and acceptable use, became mandatory on 31 March 2025.

Five-to-ten-minute 3D exercises mapped to each PCI DSS duty, with completion evidence your auditor can export.

Book a Demo See the exercises

At a glance

In scope: Merchants and service providers that store, process or transmit card data
Requirement: 12.6.1 to 12.6.3.2 security awareness program
Mandatory since 31 Mar 2025: 12.6.3.1 phishing and 12.6.3.2 acceptable use
Who tests: Your QSA, or you through a Self-Assessment Questionnaire

Trusted by teams at

Founded by the creator of Kontra Application Security Training.

Play the exercises behind your PCI DSS program

Each one is a 3D scenario your staff finish in 5 to 10 minutes. Pick one and play it here, with no sign-up.

Exercises run in interactive 3D environments.

Requirement 12.6 runs on a 12-month loop

A QSA tests each step on its own, so each step needs its own evidence.

1 12.6.1 Program A formal awareness program for all personnel.
2 12.6.2 Annual review Review and update the content at least every 12 months.
3 12.6.3 Training At hire and at least every 12 months, with a policy acknowledgment.
4 12.6.3.1 Phishing Recognise phishing and social engineering. Mandatory since 31 March 2025.
5 12.6.3.2 Acceptable use Use of end-user technologies under 12.2.1. Mandatory since 31 March 2025.

Requirement 12.6, mapped to exercises

Each 12.6 sub-requirement, mapped to exercises a QSA can sample.

Requirement Exercises that cover it

12.6 Security Awareness Program

Employee Security Responsibilities ISMS Policy Awareness

12.6.3 Threat Awareness Updates

Phishing Callback Phishing Double Barrel Phishing Whaling With A Deepfake Business Email Compromise Smishing +7

9.4 Media Protection

PII Document Redaction USB Drop Attack

8.3 Authentication Management

MFA Setup & Best Practices MFA Fatigue Attack Credential Stuffing Awareness

12.10 Incident Response

General Incident Reporting Reporting Culture

6.2 Secure Software Development (AI Systems)

Unsafe AI Output Handling AI Agent Code Injection RAG Pipeline Exploitation SQL Injection Stored XSS Server-Side Request Forgery +6

3.x Protection of Stored Account Data

Public Storage Buckets Secrets in Git History Committed Secret Files Secrets in Image Layers PII in URL Token Exposure in URL

10.2 Audit Logs

Audit Logging Gaps Insufficient Logging & Monitoring Missing MCP Audit Trail

Compare every framework on one page

Requirement 12.6 as seven courses

The PCI DSS path covers cardholder data handling, threat updates, authentication, media protection and incident response.

12.6.1 to 12.6.3: Awareness, phishing and social engineering each have their own step.
Cardholder data: Protecting sensitive information sits alongside password and access hygiene.
A dated record: Each completion is dated, which is what a QSA samples.

The PCI DSS Security Awareness Training learning path in RansomLeak for PCI DSS v4.0 Requirement 12.6, with seven course steps and progress per person

Recommended exercises

Front desk, call centre and AP scenarios for anyone near cardholder data.

Requirement 12.6 in v4.0.1, part by part

What changed from v3.2.1, and how a QSA tests each part.

01 Scope: cardholder data environment, connected systems, and people with access

PCI DSS scope is the cardholder data environment (CDE) plus any system that stores, processes or transmits card data, or could affect its security. The people in scope follow the data: every employee, contractor and third party with access to the CDE or to systems connected to it.

Segmentation, tokenization, P2PE and hosted payment pages shrink the technical footprint. They do not remove the awareness duty for whoever still handles PAN.

The first thing a QSA asks when sampling 12.6 is exactly who is in scope. Your program has to name them.

02 Requirement 12.6: the formal security awareness program

Requirement 12.6 calls for a formal security awareness program so all personnel know the cardholder data security policy and procedures. It has three parts:

12.6.1: the program is formal and implemented. An undocumented program fails.
12.6.2: it is reviewed at least once a year and updated for new threats, with evidence of the review (sign-off, date, what changed).
12.6.3: what people actually get: acknowledgment, targeted training and ongoing reinforcement.

03 Targeted training topics named in 12.6.3

12.6.3 names the topics people must be trained on:

phishing and other social engineering
acceptable use of end-user technology
choosing and protecting passwords
protecting mobile devices and working remotely

QSAs sample against this list. A 30-minute generic video that does not cover each topic on its own will be flagged.

Version 4.0 added the phishing and the mobile and remote-work items, both in response to attacks the v3.2.1 wording did not cover.

04 Annual personnel acknowledgment and the QSA evidence sample

Personnel must confirm at least once a year that they have read and understood the security policy and procedures. QSAs sample the acknowledgment more than anything else in Requirement 12.

The QSA asks for your staff list, then checks names against the acknowledgment register, the completion register and the role matrix. Missing or backdated acknowledgments are the quickest way to fail 12.6.3.

Collect acknowledgments electronically, timestamp them, record which policy version was signed, and keep the log for the assessment retention period.

05 Refresh cadence: annual minimum, after material CDE changes, after incidents

Once a year is the minimum. Under 12.6.2 the program must be updated for new threats, and people need refreshed training when the CDE changes materially, such as a new payment channel, processor or tokenization vendor, or after an incident that exposed an awareness gap.

If your incident log shows a phishing incident and there was no training update or staff message afterwards, the QSA will write it up.

The strongest programs run monthly short training on the 12.6.3 topics plus the annual policy acknowledgment.

06 PCI DSS v4.0 changes versus v3.2.1 for security awareness

The v3.2.1 text of 12.6 was brief: run a formal program, train people at hire and yearly, collect an annual acknowledgment.

Version 4.0 added the topic list in 12.6.3, the explicit phishing item, the mobile and remote-work item, and the yearly review and update in 12.6.2.

These became mandatory on 31 March 2025, and assessments since then are scored against the longer text. A program last updated under v3.2.1 will not pass a v4.0.1 sample.

07 A program your QSA can sample in one sitting

12.6.3.1 asks people to recognise phishing, so the training should show them phishing. Learners work through a simulated inbox, call, SMS thread or video meeting and decide for themselves.

A QSA will accept a video completion for the phishing topic. But since v4.0 the expectation is targeted training that builds the habit of checking, not passive viewing.

Scenario completions give the QSA the same timestamps and learner IDs to sample, with better proof behind them.

How much training someone gets depends on their access to the CDE:

Anyone who handles card data, such as cashiers, AP, customer service with stored cards and CDE operations: the full 12.6.3 set on phishing, mobile devices and acceptable use.
IT and help desk: vishing, MFA resets and MFA fatigue, the techniques behind Scattered Spider in 2023 and 0ktapus.
Developers whose code touches PAN: secure development and AI output handling, mapped to 6.2.
Executives and finance leaders: BEC and deepfake wire fraud, the pattern behind the Pepco and Arup cases.

Every assignment logs the learner ID, exercise, completion time and the policy version acknowledged.

The export is what makes the program ready for a QSA. You get:

a completion register per learner
each exercise mapped to its 12.6.3 topic
the acknowledgment register tied to the policy version
the dated release log proving the 12.6.2 review happened

Exports come as CSV and JSON for the QSA workbook, and as SCORM 1.2 and 2004 packages for Cornerstone, Workday Learning, Docebo, SAP SuccessFactors or any standards-based LMS. The program owner walks into the Level 1 ROC interview with evidence already organised by 12.6 sub-requirement.

Card breaches that began with a person, not a firewall

Each started with a phish, a call or a password, not a technical flaw.

2013 Target breach, 40M cards, $202M total cost

Attackers got into Fazio Mechanical, an HVAC vendor with remote access to Target, through a phishing email carrying Citadel malware. They used the vendor’s credentials to move into Target’s network and put card-scraping malware on point-of-sale terminals during the holiday season.

Forty million card records were stolen, plus personal details of another 70 million customers. Target paid an $18.5 million multistate settlement and $39.4 million to banks, and total costs were reported above $202 million.

The PCI follow-up pointed to third-party access and vendor training. Target tightened vendor onboarding and segmentation in the years after.

2014 Home Depot breach, 56M cards, $179M settlement

Attackers used credentials stolen from a third-party HVAC vendor to get into Home Depot’s network. They installed custom card-scraping malware that ran for five months on self-checkout terminals in US and Canadian stores.

Fifty-six million card numbers and 53 million email addresses were taken. Home Depot settled for $179 million covering consumer claims and bank losses, on top of internal costs reported above $200 million.

The assessment fallout centred on vendor access, segmentation, and training for third-party staff holding credentials inside the CDE. It is one of the most cited examples of how 12.6 awareness and 12.8 third-party management connect.

2008 Heartland Payment Systems breach, 130M cards, $140M+ losses

Attackers used SQL injection on a public web application to plant a sniffer on Heartland’s processing network and took about 130 million card records, the largest known card breach at the time. Fines and settlements with Visa, MasterCard, American Express, Discover and banks passed $140 million.

Heartland had been certified compliant by its QSA before the breach. Later assessments cited weak application security training, secure coding and developer awareness.

The case led to explicit secure development expectations in PCI DSS. It shows why 12.6 training has to include developers whose code touches PAN.

The 12.6 topics, and the requirements next to them

Neighbouring requirements that only work with trained staff.

12.6.1: Formal documented security awareness program

RansomLeak gives you a written program with a named owner, a defined scope, a role-based training matrix and a refresh schedule. That document is what your QSA samples to confirm 12.6.1 exists in writing, not just in practice.

There is a template, so your program owner does not start from a blank page.

12.6.2: Annual review and update for new threats and vulnerabilities

New exercises ship monthly and existing ones are refreshed to follow current attacks, each listed in the release notes.

That dated release log is your 12.6.2 evidence. It shows the QSA the annual review happened and changed real content, not just the date on a cover page.

12.6.3: Targeted training on phishing and social engineering

Phishing, callback phishing, double-barrel phishing, smishing, QR code phishing, deepfake audio, BEC, calendar invite scams and typosquatting cover the 12.6.3 social engineering topic in depth.

Each exercise ends with feedback naming the cues the learner missed and the check that would have stopped the attack. The per-learner record satisfies the 12.6.3 sample.

12.6.3: Acceptable use, password choice, mobile and teleworking topics

Each 12.6.3 topic has its own exercises, so the QSA can trace every assignment back to the standard:

Mobile and remote working: Mobile Device Security.
Passwords: MFA Setup Best Practices and Credential Stuffing Awareness.
Acceptable use and the policy acknowledgment: Employee Security Responsibilities and ISMS Policy Awareness.

12.10: Incident response training and rehearsal

General Incident Reporting and Reporting Culture cover the people side of Requirement 12.10. Staff learn to recognise an incident and report it straight away through the published channel, because the delay between noticing and reporting is the attacker’s window.

They also reinforce no-blame reporting. Punishing people who report kills the culture 12.10 depends on.

8.3: Authentication and MFA hygiene

MFA Setup Best Practices and MFA Fatigue Attack cover the people side of 8.3 and 8.4: MFA for CDE access and for all admin access.

Staff learn how push bombing works and that approving an unexpected prompt is the same as handing over a password. They also learn why FIDO2 and passkeys stop the adversary-in-the-middle kits that get past SMS, push and TOTP.

9.4: Media protection and physical access

USB Drop Attack covers the people side of 9.4: the stick in the car park, the unexpected parcel, the conference freebie.

Staff learn that dropped media is a way to deliver malware, and that the only safe move is to hand it, unopened, to security or IT. It complements the physical controls 9.4 already requires.

6.2: Secure development training for developers in CDE scope

Safe GenAI Usage and Unsafe AI Output Handling are for developers writing code that touches PAN, under the 6.2 secure development expectations expanded in v4.0. Engineers learn prompt injection and the unsafe output handling that creates the next wave of application flaws, the kind Heartland warned about.

The Secure AI-Assisted Development course applies 6.2 to code written with an AI assistant: untested security fixes, tests that check nothing, and AI-built tools that skipped review.

Pass 12.6.3.1 on the first sample

Phishing, social engineering and acceptable-use scenarios with a QSA-ready register.

Book a Demo Play a free exercise

Frequently asked questions

What is PCI DSS security awareness training?

PCI DSS Requirement 12.6 makes a formal security awareness program mandatory for every person with access to the cardholder data environment. This page covers the v4.0.1 transition, the targeted training topics 12.6.3 names, and the evidence pattern Qualified Security Assessors sample during a Report on Compliance.

What is PCI DSS Requirement 12.6?

Requirement 12.6 of PCI DSS v4.0.1 says the entity must implement a formal security awareness program to make all personnel aware of the cardholder data security policy and procedures. It is the anchor requirement for security awareness inside PCI DSS and applies to every merchant or service provider in scope of the standard.

Three sub-requirements sit beneath it. 12.6.1 requires the program to be formal and implemented in writing. 12.6.2 requires annual review and update for new threats and vulnerabilities. 12.6.3 requires personnel to acknowledge the policy at least annually and to receive targeted training on phishing and social engineering, acceptable use, password choice, and mobile or teleworking technologies.

Does PCI DSS require annual security awareness training?

Yes. Sub-requirement 12.6.3 requires personnel to acknowledge at least annually that they have read and understood the security policy and procedures, and to receive targeted training on the topics named in the standard. Annual is the floor, not the ceiling. Sub-requirement 12.6.2 separately requires the program itself to be reviewed and updated annually for new threats and vulnerabilities.

The strongest programs run monthly micro-training on the 12.6.3 topics with annual policy acknowledgment, because attacker tradecraft shifts inside a 12-month window faster than a single annual session can keep up with. Cadence above the annual floor also generates the dated release log a QSA samples to confirm 12.6.2 review actually happened.

Who needs PCI DSS training (employees, contractors, third parties)?

The standard uses the word personnel, which covers full-time employees, part-time employees, contractors, and any third party with access to the cardholder data environment. The 2013 Target breach and the 2014 Home Depot breach both started with credentials stolen from third-party vendors with CDE-connected access; both PCI assessment fallouts cited the awareness obligations for that third-party workforce.

Scope reduction (segmentation, tokenization, P2PE, hosted payment pages) shrinks the technical footprint but does not remove the training requirement for whoever still touches PAN. The first question a QSA asks during 12.6 sampling is who, exactly, sits in scope; the awareness program has to name them and show training records for each.

What evidence do QSAs look for during a PCI DSS assessment?

QSAs sample four artifacts during 12.6 review. The documented program (12.6.1), with named owner, scope, role-based training matrix, and refresh cadence. The dated review log (12.6.2), proving the program was reviewed and updated at least annually for new threats. The acknowledgment register (12.6.3), tying personnel to the version of the policy they signed and the date. The training completion register (12.6.3), tying personnel to the targeted topics they received.

The personnel roster is then sampled against each register. Missing or backdated entries are the fastest way to fail 12.6.3. Modern programs collect electronic timestamped acknowledgments, log per-learner per-exercise completion with the policy version, and retain the records for the assessment window the entity is operating under.

What changed in PCI DSS v4.0 for security awareness?

PCI DSS v4.0 was published in March 2022 and v4.0.1 followed in June 2024, current as of today. The v3.2.1 wording for Requirement 12.6 was thin: implement a program, educate annually, require acknowledgment annually. The v4.0 rewrite materially expanded the language. 12.6.2 added the explicit annual review and update requirement. 12.6.3 added the explicit list of targeted topics: phishing and other social engineering, acceptable use, password choice and protection, and the protection of mobile devices and use of teleworking technologies.

The transition from v3.2.1 became mandatory on 31 March 2024, and a second tranche of new v4.0 requirements (originally listed as best practice) became enforceable on 31 March 2025. Programs that have not refreshed against the expanded 12.6 language since the v3.2.1 era will not pass a v4.0.1 sample.

What targeted training topics are required under 12.6.3?

Sub-requirement 12.6.3 explicitly names four topics personnel must receive targeted training on. Phishing and other social engineering. Acceptable use of end-user technologies. Password choice and protection. The protection of mobile devices and the use of teleworking technologies. Each topic is sampled separately by the QSA; a single generic video that mentions none of them by name will not satisfy 12.6.3.

The strongest programs ship a separate exercise per topic, log completion per learner per exercise, and keep a topic-to-sub-requirement mapping document so the QSA can trace each completion record back to the standard. The v4.0 rewrite added the explicit phishing call-out and the mobile or teleworking call-out, both responses to threat patterns that the older v3.2.1 wording missed.

How is PCI DSS training different from SOC 2 or ISO 27001 awareness?

SOC 2 and ISO 27001 both require security awareness training (CC1.4 in SOC 2, A.7.2.2 in ISO 27001), but the wording is principle-based and gives the entity wide latitude on topics, cadence, and evidence format. PCI DSS Requirement 12.6 is prescriptive: it names the topics, names the cadence (annual minimum), names the audience (personnel with CDE access including third parties), and the QSA samples to a published expectation rather than to the entity's own definition.

In practice, programs running PCI DSS comfortably are also running SOC 2 and ISO 27001 comfortably; the inverse is not always true. A SOC 2 program scoped to a single annual all-hands video can pass the SOC 2 audit and still fail the PCI 12.6.3 topic sample. The two-way map matters when the same workforce is in scope for both standards.

Does e-commerce code-only access to PAN still trigger 12.6?

Yes. Requirement 6.2 covers secure software development, and any developer writing code that processes, stores, or transmits cardholder data is in scope of both 6.2 and 12.6. The 2008 Heartland Payment Systems breach (130M cards, $140M plus losses) started with a SQL injection vulnerability in a public-facing web application; the subsequent PCI assessment cited application security training and secure coding practices in the developer workforce among the deficiencies.

Hosted payment pages, redirect flows, and iframe integrations reduce the application surface but do not remove the awareness requirement for the engineering teams that still write the surrounding code. The strongest programs include a developer-scoped track inside the 12.6.3 program covering secure coding, OWASP categories, and (since v4.0.1) the AI coding assistant and prompt-injection patterns the older standard wording did not anticipate.

Simulations

Catalogue

Features

Company

Legal