12.6 Security awareness education: requirements and evidence

What 12.6 security awareness education requires and why assessments fail on it

Requirement 12.6 asks for a security awareness program that is alive, not a slide deck filed once a year. The compliance lead facing a QSA review or an SAQ D needs to show that awareness is a formal program with its own review cycle, that personnel receive training through more than one communication method, that people acknowledge the security policy at least every 12 months, and that the training covers phishing, social engineering and acceptable use. The five sub-requirements, 12.6.1 through 12.6.3.2, describe that program in layers: the program exists and is reviewed yearly, the content and delivery are ongoing, and each person's acknowledgment is recorded individually. The risk behind them is practical. Staff are a common route into payment environments through convincing emails, phone calls and pretexts, and an untrained employee can hand over credentials that no firewall rule would have stopped.

The most frequent failure is missing evidence of ongoing delivery and per-person acknowledgment. Assessors do not grade a deck for its quality. They ask who was trained, when, on which topics, and whether the record shows it, and they sample individuals to check. An organization that holds one annual session with no attendance record, or that gathers a single signed policy PDF from a manager, will struggle to show that every person with access to the cardholder data environment acknowledged the policy in the last 12 months. The same gap appears when new joiners and contractors are missed, or when the review of the program itself is never documented. Before the assessment, confirm with your QSA which artifacts they will sample, and list every person who touches the environment, including third-party staff where the policy applies to them.

Three points deserve attention now. Requirements 12.6.2, 12.6.3.1 and 12.6.3.2 were best practices until 31 March 2025 and are now assessed in full, so an SAQ or ROC completed without them will not pass. Most evidence can be produced from a learning management system or a wiki that keeps version history, provided the completion data is exported and retained with dates. Your team should decide who owns the program, how completion is tracked, and how gaps are chased before the next review. The PCI SSC Document Library hosts the current standard and the official SAQ templates for checking the exact wording against your environment.

Who must complete security awareness training under 12.6

Requirement 12.6 does not list job titles, so the population is set by your own scoping decisions. The cards below separate the groups an assessor will ask about and the training implication for each, from people who touch the cardholder data environment to third parties who never receive a company login.

Personnel with CDE access

Administrators, developers, support engineers and operators who log into systems in the cardholder data environment are the core population. Their training should cover phishing, social engineering and the acceptable use rules that apply to their privileged tools. Check that your access reviews and your training roster come from the same list, so an assessor can see that no one with access was left out. Ask whether training content names the systems they actually use, not generic examples.

Staff who handle payment processes

Customer service agents, refund approvers, finance staff and anyone who takes card details by phone or in person may never touch a server but still face social engineering aimed at card data. Their training should include scenarios such as a caller asking for a card number to be read back or a fake supplier changing payment instructions. Confirm whether these roles sit inside your CDE scope or outside it, because that decision determines how you document their training.

Contractors and temporary staff

Contractors and temporary workers who receive company accounts or work on in-scope systems are personnel for training purposes, even when their contract is short. They should complete the same program and acknowledge the security policy before access is granted, not after the first yearly cycle. Track their end dates so the acknowledgment record matches the access record. Missing this group is a common gap when training is managed only through the HR system.

Entity-wide or CDE-only program

The most consequential scoping decision is whether the awareness program covers every employee or only roles tied to the CDE. An entity-wide program is simpler to defend and avoids arguments about who counts as in scope, while a CDE-only program lowers the number of people trained but requires a documented, current list of roles. Ask your assessor early which model they expect to see for your organization, and document the reasoning in your policy.

Third-party staff through 12.8

Staff of service providers who can affect account data are handled through Requirement 12.8, which covers the written agreement, due diligence and monitoring of the provider. Your contract should state whether the provider trains its own people and how you will see evidence of that training. If a provider's staff use your systems directly, they fall under your program instead. Confirm which path applies to each provider before you ask for their training records.

How an assessor tests 12.6 and what passes

This table lists each 12.6 sub-requirement with what the assessor examines, the evidence usually requested and the findings seen most often. The patterns describe common outcomes, not guarantees, and the QSA or SAQ reviewer makes the final determination for your environment.

Sub-requirement	What the assessor examines	Evidence requested	Common findings
12.6.1 Formal awareness program	Whether a written awareness program exists, who owns it, and whether it reaches all personnel who access systems or data in scope	Written program document, named owner, distribution list or audience definition, and a current copy of the training plan	Program exists only as informal onboarding notes, or the audience omits contractors and temporary staff
12.6.2 Yearly program review	Whether the awareness program is reviewed at least once every 12 months and whether changes follow from the review	Dated review record, meeting minutes or sign-off, and a change log showing updates made after the review	Review is documented once and never repeated, or the review does not reflect new threats or changed systems
12.6.3 Training with multiple methods and policy acknowledgment	Whether training is delivered through more than one communication method and whether personnel acknowledge the security policy at least every 12 months	Training materials in each format used, delivery schedule, and signed or electronically recorded policy acknowledgments with dates	Only one channel is used, such as a single annual slide deck, or acknowledgments are collected once at hire and not refreshed
12.6.3.1 Phishing and social engineering content	Whether training covers how personnel recognize and report phishing and social engineering attempts, including how the organization tests this	Phishing and social engineering module content, simulation campaign records if used, and reporting procedure shown to staff	Training mentions phishing in general terms with no reporting step, or the content has not been updated for current lures
12.6.3.2 Acceptable use content	Whether training explains the acceptable use policies that apply to end-user technologies and whether staff demonstrate understanding	Acceptable use module content, mapping to the acceptable use policies in force, and completion records for in-scope personnel	Training refers to a policy version that has since changed, or it does not address the technologies staff use in the cardholder data environment
Sampling of personnel	Whether the assessor can trace individual personnel to completed training and a current policy acknowledgment	Roster of in-scope personnel, completion records for a sample chosen by the assessor, and the dates behind each record	Completion is recorded at program level only, or records cannot be linked to named individuals
Completion tracking in the learning system	Whether completion is recorded reliably, for example through activity completion settings that mark a learner complete only after the required action	Export of completion status by person and date, and the completion conditions configured for each training activity	Completion is marked when a page is opened rather than when the learner finishes, or exports cannot be produced on request
Change history for awareness content	Whether the program documents, versions and approves changes to training and policy text over time	Version history of training and policy pages showing what changed, when and by whom	Content is overwritten without history, so the assessor cannot see which version applied on a given date

How to build a 12.6 program that produces evidence

This sequence turns Requirement 12.6 from a training intention into a documented program with defined ownership, approved content, tracked delivery, recorded policy acknowledgments and a yearly review. Each step ends with a record an assessor can sample.

Define program scope and owner
Decide who the program covers, which personnel and contractors are included, and which executive or security leader owns it. Scope should match the people with access to the cardholder data environment and the people who support it, drawn from the scope documentation already maintained under Requirement 12.5. The owner is named in writing and has authority to require completion. The output is a short scope statement with a named owner and a current roster of people in scope that you can compare against HR and access records.
Write the awareness program document
Document the program's purpose, audiences, topics, delivery methods, completion rules, acknowledgment process and review cycle. The document is the formal awareness program that Requirement 12.6.1 expects, so it should be approved by the owner and stored where the assessor can retrieve the current version. Note the version date and the approver. The output is an approved program document that a reader can follow without asking the security team what happens next.
Select training content for key topics
Build or license course content covering phishing, social engineering and acceptable use, the three topics the requirement names. Map each module to the acceptable use and security policy expectations already set under Requirements 12.1 and 12.2, so trainees are taught the rules they will be asked to acknowledge. Have the content reviewed by someone who can confirm it matches your environment, such as your email platform, remote access tools and reporting path. The output is a content inventory with each module's topic, version and reviewer.
Set delivery through multiple channels
Requirement 12.6.3 expects training delivered through more than one method of communication. Combine a learning platform course with periodic reminders such as email notices, short internal bulletins, posters or intranet pages, and simulated phishing exercises if your team runs them. Record which channel carried which message. An ongoing rhythm matters more than a single annual session. The output is a delivery plan that lists each channel, its purpose and its owner, plus the records each channel generates.
Track completion and collect policy acknowledgments
Assign the training to every person in scope, set completion criteria, and collect a written acknowledgment that each person has read and understood the security policy at least once every 12 months. Learning platforms can record completion automatically when a learner views an activity, receives a grade or ticks it off, depending on how the activity is configured, so confirm which trigger your course uses. Follow up on people who have not completed the course or acknowledgment and record the escalation. The output is a per-person completion and acknowledgment register with dates, which assessors sample against the current roster.
Run the yearly program review
Review the program at least once every 12 months. Check the content against current threats and policy changes, review completion and acknowledgment gaps, look at incidents such as reported phishing or social engineering attempts, and decide what changes are needed. Record the reviewer, date, findings and approved changes, and update the program document and content inventory where needed. The output is a signed review record that links to the revised documents and shows what changed since the last cycle.
Store version-controlled evidence for assessors
Keep the program document, content versions, delivery records, acknowledgments and review records in one controlled location with change history. Wiki platforms can record each page change, who made it and when, and allow comparison and rollback between versions, which helps show that the program was current at each point in the assessment period. Confirm with your platform vendor which versioning and access controls it supports before relying on it. The output is an evidence folder an assessor can navigate in one sitting, with the most recent version of each record clearly identified.

Evidence that satisfies 12.6 and how to keep it current

Requirement 12.6 is tested through records, not intentions. An assessor will look for a written program, a dated review, training content, per-person completion and signed acknowledgments, and will ask whether each record still reflects the environment. The cards below cover each artifact and the habit that keeps it current between assessments.

Written security awareness program

This is the formal program document that defines who is trained, on what topics, how often, and through which channels. Assessors check that it exists, that it is approved, and that it covers phishing, social engineering and acceptable use. Confirm that the document names an owner and that every training element traces back to it. A program that exists only in a slide deck is hard to defend.

Yearly program review record

The review record shows that the program was assessed at least once a year and changed where needed. It should list the date of review, the reviewer, the findings, and every change made, such as new phishing scenarios or updated acceptable use topics. A review with no recorded changes is hard to justify when threats or staff have shifted. Keep the record in the same place as the program document.

Training materials with version history

Assessors expect the actual content delivered to personnel, not only a description of it. Keep each module, quiz and phishing lesson under version control so you can show which edition a person saw on a given date. Wiki platforms such as XWiki record what changed, when and by whom, and let you compare or restore earlier versions. Record the approver for each revision, not only the author.

Per-person completion records

Completion records prove that each person with access to the cardholder data environment completed training within the required period. Moodle's activity completion can mark a module complete when a learner views it, receives a grade, or ticks it manually, depending on how the activity is configured. Check that the completion condition matches what you claim. Export records regularly so they survive a platform change.

Dated policy acknowledgments

Each person must acknowledge in writing or electronically, at least once every 12 months, that they have read and understood the security policy. Store the signed or recorded acknowledgment with its date and the policy version acknowledged. Ask whether contractors and temporary staff are included, since they often fall outside HR systems. A missing acknowledgment for one person in scope is a finding.

Phishing and social engineering exercise records

If you run simulated phishing or social engineering exercises, keep the scenario, the target group, the date sent, the results, and the follow-up training assigned to those who failed. Results matter as much as the exercise itself, because they show whether training changed behavior. Record any change to the exercise design and who approved it. Confirm with your assessor how they want exercise evidence presented if you run them.

How self-hosted open-source platforms produce 12.6 evidence

An assessor testing 12.6 wants dated records showing the program exists, runs, is reviewed and reaches every person with access to the cardholder data environment. Learning management, wiki and access control tools can each hold part of that record, provided the organization configures them to keep it. The cards below cover what each tool produces and what to confirm before relying on it.

Moodle completion records

Moodle's activity completion can mark a training module complete when a learner views it, when they receive a grade, or when they tick it manually, depending on the conditions set for that activity. For 12.6.3 training records, choose the condition deliberately. Viewing a page proves little about understanding, so a graded quiz or a manual attestation paired with a quiz is usually the stronger record. Confirm which completion condition each course uses and export completion reports for the assessment period. Moodle is licensed under GPL-3.0-or-later.

XWiki version-controlled program documents

Program documents such as the awareness plan, annual review minutes and training content can sit in XWiki, which keeps every change under version control and records what changed, when and by whom. Assessors reviewing 12.6.2 yearly program review can compare versions to see that the review happened and that content was updated afterward. Rollback protects against an unreviewed edit replacing approved material. XWiki is licensed under LGPL-2.1-or-later.

BookStack role-based permissions

BookStack assigns abilities through roles and can override permissions per role at the shelf, book, chapter or page level. For 12.6, use this to separate who maintains the awareness program from who reads it, so training owners can edit content while general personnel have read access only. Review role assignments at each program review and record who holds editing rights. BookStack is licensed under MIT.

Acknowledgment and phishing features to confirm

Yearly policy acknowledgment under 12.6.3.1 and phishing or social engineering exercises under 12.6.3.2 are not covered by the supplied capability facts for these tools. Before naming any of them as evidence sources, confirm with the vendor or in a test instance whether acknowledgment capture with timestamps and signed records exists, and whether simulated phishing campaigns and their reporting are available or need a separate product. Record the answer in your own configuration notes.

What meeting 12.6 costs in money and effort

This table lists the cost components of a 12.6 awareness program, who is paid for each, whether it is one-time or recurring, what drives it up, and how to reduce it. Read it as a checklist for a written quote: each row names what to ask the vendor, your staff, or your assessor to price or estimate. No figures are given because none were supplied, so the main takeaway is that open-source platforms remove license spend but not staff time.

Cost component	One-time or recurring	What drives it up	How to reduce it
Training content development or licensing	Mostly one-time build, with recurring updates	Number of roles needing tailored modules, frequency of policy changes, and whether content must cover multiple languages	Reuse one core module for all personnel and add short role-specific sections; ask whether content licenses are per user or per course
Learning platform hosting and administration	Recurring, plus one-time setup	Headcount in scope, number of integrations with HR or identity systems, and in-house versus hosted operation	Self-hosted open-source learning platforms remove license fees, but hosting, patching and backups still need an owner; confirm who holds that role
Staff time for delivery and tracking	Recurring every cycle	Number of personnel with CDE access, manual tracking of completions, and chasing overdue learners	Use automated completion tracking tied to course activity, and set reminders before the 12-month acknowledgment window closes
Phishing and social engineering exercises	Recurring	Number of simulated campaigns per year, need for custom pretexts, and whether results must be analyzed and documented by hand	Standardize templates, schedule campaigns in advance, and record each result against the training record for evidence
Yearly program review effort	Recurring, once a year	Number of policies and training modules to review, changes in threats or systems, and how much evidence must be gathered from several teams	Keep a single change log for content and policy versions, and review against the current policy rather than rebuilding the program each year
Policy acknowledgment collection	Recurring, at least every 12 months	Number of personnel, new joiners and contractors, and whether acknowledgments are collected on paper or in a system	Collect electronic acknowledgments at onboarding and at each annual cycle, with dates and names retained
QSA or internal assessor time for sampling	Recurring at each assessment	Number of personnel sampled, quality of training and acknowledgment records, and gaps the assessor must follow up	Prepare a sample-ready evidence folder with completion records, content versions and acknowledgments mapped to each person
Consulting or implementation support (if used)	One-time setup, optional recurring review	Scope of platform configuration, content customization, and support for the yearly review	Set a fixed-scope written agreement with defined deliverables, and confirm which parts your own team will run after handover

Who owns the 12.6 program and what a partner can prepare

Your organization owns its controls, and that includes the security awareness program required by Requirement 12.6. Someone inside the company must be accountable for the program, decide what the training covers, and make the yearly review decision that assessors look for. Policy approval and acknowledgment follow-up also stay with your staff, because a partner cannot accept risk or decide what personnel must read.

Program owner: Name a role, usually in security or compliance, that is accountable for the awareness program and its records.
Policy approval: Your leadership approves the security policy that personnel acknowledge each year.
Acknowledgment follow-up: Your team chases overdue acknowledgments and decides how exceptions such as leave or contractors are handled.
Yearly review decision: Your team records the annual review of the program, its content and its effectiveness, and signs off on changes.
Content on phishing and acceptable use: Your staff confirms the training reflects your real threats and acceptable use rules.

Confirm with your assessor which records they expect to see for the yearly review and who must sign them.

Common 12.6 gaps and how to close them

Most 12.6 findings are not missing training content. They come from awareness programs that run once, skip contractors and new hires, or leave evidence spread across systems that an assessor cannot easily trace. Each card below names a gap, the fix, and the artifact that shows the fix works.

Training runs once a year only

A single annual course is often the only awareness activity. Requirement 12.6.3 expects training that uses multiple methods of communication, so an organization that relies on one annual module has difficulty showing that the program stays current. Add short reminders, posters, team briefings and phishing simulations between the yearly course. The artifact is a communication calendar with dated entries for each channel, plus a record of who received each message.

No acknowledgment record for contractors

Employees usually sign the policy at onboarding, but contractors, temporary staff and new hires who start mid-cycle often have no dated acknowledgment at all. Under 12.6.3.1, personnel must acknowledge the security policy at least once every 12 months. Set the acknowledgment as a required step in onboarding and in contractor access provisioning, then track each person's most recent date against a 12-month window. The artifact is an exported acknowledgment roster with names, roles, and dates.

Phishing content that is generic

Generic slides about suspicious email rarely prepare staff for targeted attacks against payment operations, such as fake invoice changes or calls impersonating a processor's support team. Under 12.6.2, training must cover phishing and social engineering as threats that personnel actually face. Build examples from the organization's own payment workflows and refresh them when new attack patterns appear. The artifact is the training material with its revision history and a list of scenarios tied to real roles.

No yearly review record

Requirement 12.6.1 expects the awareness program to be reviewed at least once every 12 months, and many teams update content without recording why. An assessor will ask who reviewed the program, what changed, and what incidents or test results drove the change. Hold a yearly review meeting with a written agenda, minutes, and approved changes. The artifact is signed review minutes that list findings and the resulting content updates.

Acceptable use training not tied to 12.2

Training on acceptable use often repeats general good practice and drifts from the acceptable use policy that Requirement 12.2 requires. When the two documents disagree on approved devices, remote access, or removable media, staff receive conflicting instructions. Map each training topic to a clause in the current acceptable use policy and update both together. The artifact is a cross-reference table linking each training module to the policy section it teaches.

Evidence scattered across tools

Completion data may sit in a learning platform, acknowledgments in an HR system, policy versions in a shared drive, and phishing results in a separate tool. An assessor asking for one year of evidence then receives a set of partial exports with no clear link between them. Pick one system of record for the awareness program, keep policy versions under version control, and export a consolidated report at each assessment. The artifact is a single evidence index that points to each source and its owner.

Questions buyers ask about 12.6 cost, effort and outsourcing

How much effort does requirement 12.6 take for a small team?

The effort depends mainly on how many people handle payment environments, how many training formats you already run, and how much of the records trail exists today. Requirement 12.6 asks for a formal awareness program, a yearly review of that program, training on phishing, social engineering and acceptable use, and a yearly acknowledgment of the security policy by all personnel. For a small team, the recurring work is a short annual training cycle, a yearly review, and collecting acknowledgments. The one-time work is building the course content, choosing a learning platform and setting up completion records. No researched figure supports a specific number of hours, so ask any provider to break its quote into setup hours and recurring hours per year, and to name who produces the training content.

Can we run the security awareness program ourselves?

Yes, most organizations can run 12.6 in-house, provided someone owns the program and keeps the records. The organization owns its controls, so the program owner must approve the content, schedule training, track completion, collect yearly policy acknowledgments and document the annual review. Self-hosted learning and documentation tools can carry much of this work. Moodle can track activity completion for each learner, XWiki keeps version history of policy pages with who changed what and when, and BookStack lets you restrict who can edit or view each page. The gap usually lies in content quality and in proving that the program is reviewed, not in the tooling itself. Confirm with your assessor which records they expect before you decide to run it alone.

What work does 12.6 need from our own staff?

Your staff must supply the policy, the people list, and the subject matter that makes training relevant. Expect these tasks from internal teams: the security policy owner confirms what personnel must read, HR or the people function keeps the roster of personnel and their start and leave dates, and security staff review phishing and social engineering scenarios against real threats your organization faces. Managers should confirm that their teams finish training and sign acknowledgments. An internal reviewer must also document the yearly review of the program, including what changed and why. A partner can draft materials, but staff must be able to explain the program to an assessor, because the assessor will ask staff what they were trained on.

How long does setting up a 12.6 program usually take?

No researched fact supports a standard setup duration, so treat any timeline as a quote item rather than an assumption. Setup length depends on whether a formal awareness program already exists, how many personnel groups need different content, whether a learning platform is already in place, and how quickly your leadership approves the policy and training materials. Ask any provider for a written schedule with milestones for content approval, platform configuration, pilot training, first full rollout and the first documented program review. Ask your assessor when they expect to see the first full cycle of acknowledgments, since the program must show evidence that it runs over time, not only that it was launched.

What should a partner deliver for 12.6, and what stays with us?

A partner should deliver a defined set of outputs in a written, fixed-scope engagement: a program design, training content covering phishing, social engineering and acceptable use, configured learning and records tooling, a repeatable acknowledgment process, and a review template with an evidence checklist. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports or attestations. Your organization keeps ownership of the policy, approves the content, runs the program each year, signs off the review, and gives the assessor the records. Independent assessors, such as a Qualified Security Assessor for a Report on Compliance, decide whether the evidence meets the requirement. Ask any provider to list each deliverable, the owner of each, and what remains your responsibility after handover.

Does training alone satisfy 12.6 without acknowledgment and review records?

No. Training alone does not satisfy 12.6 because the requirement also expects a yearly review of the awareness program and a yearly acknowledgment by personnel that they have read and understood the security policy. Assessors look for the full evidence chain: the program document, the training content and delivery method, completion records for each person, signed or electronically recorded acknowledgments dated within the last 12 months, and a documented review. A learning platform can show who completed a course, but the acknowledgment and review must be kept as separate records. Confirm with your assessor which format they accept for acknowledgments and whether each training method you use must be evidenced.

How DeployOpen prepares 12.6 evidence for your assessment

DeployOpen helps organizations build the training platform, awareness content and acknowledgment records that 12.6 asks for, inside the client's own infrastructure. The organization owns its awareness program and policy acknowledgments, and an independent QSA decides whether the evidence meets the requirement.

How we scope

Agree in writing which personnel groups, systems and training topics fall under the 12.6 program.
Define how phishing, social engineering and acceptable use training will be delivered and recorded.
Confirm the yearly review owner, the policy acknowledgment cycle and the evidence each one produces.

How we build

Deploy a self-hosted learning platform, such as Moodle, with activity completion set to record each learner's training.
Configure a version-controlled knowledge base, such as XWiki, so awareness content and review history stay traceable.
Set role-based access in a documentation platform such as BookStack so acknowledgment and content owners hold the right permissions.

How we hand over

Document the awareness program, review procedure and acknowledgment workflow in a form your assessor can test.
Provide sample completion reports and version histories that show training and policy reads over the 12-month cycle.
Walk your team through running the program so it continues after the engagement ends, with written handover materials.

How we support

Offer ongoing support and content updates as a retainer after the fixed-scope work is delivered.
Help your team prepare the yearly program review and refresh phishing and social engineering material when needed.
Confirm with your QSA which evidence they will request before the assessment, and adjust records accordingly.