The calendar alert triggers. Your client has a PCI DSS Report on Compliance (RoC) assessment starting in 60 days. The Qualified Security Assessor (QSA) sends the initial document request list. Right at the top: a demand for complete documentation of the security awareness training program for the trailing twelve months.

You know the client's staff completed the modules. Proving it to an assessor is another story. You are facing hours of manual data extraction just to build a cohesive timeline. The stakes are real. An incomplete training roster or missing policy acknowledgement leads directly to a failed assessment, steep compliance fines, and the potential loss of the client's merchant account.

This post covers what PCI DSS requires for security awareness training documentation, what auditors look for when they ask for it, and what most SAT platforms don't give you by default.

What PCI DSS requires for security awareness training

The Payment Card Industry Data Security Standard (PCI DSS) is explicit about training expectations. In PCI DSS v4.0, these obligations live in Requirement 12.6. The regulation states that "Security awareness education is an ongoing activity."

Specifically, Requirement 12.6.1 mandates a formal security awareness program for all personnel. Requirement 12.6.2 dictates that this training must be completed upon hire and at least annually thereafter. PCI DSS does not allow ambiguity on who must be trained. "Personnel" includes full-time employees, part-time employees, temporary employees, contractors, and consultants who have access to the Cardholder Data Environment (CDE). If they can interact with the network where card data lives, they must be trained.

Content requirements are similarly specific. Under Requirement 12.6.3.1, the training program must explicitly cover threats that could impact the security of the CDE. This includes mandatory modules on phishing and social engineering. Furthermore, Requirement 12.6.3.2 demands that personnel acknowledge, at least annually, that they have read and understood the information security policy.

For documentation retention, QSAs require evidence spanning the entire 12-month compliance cycle. You must prove the training occurred, that the exact required topics were covered in the curriculum, and that every individual in scope completed it. The framework requires tangible proof. A simple memo stating training occurred is not compliant. You must retain granular completion logs, timestamps, and signed policy acknowledgements for the entirety of the audit window.

What auditors actually look for

When a Qualified Security Assessor (QSA) evaluates your training program, they are testing operational controls. They do not want assurances. They want evidence. They execute a formal audit protocol designed to expose gaps in your compliance posture.

First, they look for program evidence. This means reviewing the written security policy and the training curriculum. They cross-reference the curriculum to ensure it directly addresses the secure handling of cardholder data. They look for specific modules covering phishing and related social engineering tactics.

Next, they demand per-person records. The QSA will pull an active directory roster of everyone with access to the CDE. They will sample this roster and demand corresponding training records for those specific individuals. They look for strict scope coverage. If a contractor was granted access in May, the QSA wants the exact date their initial training was completed to verify it happened upon hire.

They also demand cadence evidence. A single certificate from last year is insufficient. PCI DSS v4.0 emphasizes ongoing education. Assessors want to see a timeline of continuous engagement, such as periodic phishing simulations distributed consistently across the audit period.

Finally, auditors look at the response to identified issues. If an employee consistently falls for simulated phishing, the auditor wants the documented follow-up. Recording the click isn't enough. They want evidence of the specific intervention or remedial training triggered by that failure. The documentation must prove the system responds to human risk.

What most SAT platforms give you by default

The security awareness training category has a standard output model. It just happens to be the wrong model for a QSA.

Most SAT platforms function as massive data generators. They produce raw completion reports. They output per-campaign phishing results showing exactly who clicked a simulated threat on a specific Wednesday. They generate aggregate percentages showing high-level organizational risk.

For an MSP operator trying to satisfy an auditor, this is raw data. It is not evidence.

What these platforms typically do not produce in audit-ready format are framework-mapped reports specific to PCI DSS. They lack evidence bundles that neatly combine initial training, ongoing phishing results, and policy acknowledgements into a single timeline for each user. They struggle with date-range-scoped exports that perfectly match the client's 12-month PCI audit window.

Instead, you get manual reconciliation. You export a CSV from the directory. You export another CSV from the SAT platform. You run VLOOKUPs to identify missing users. You manually filter out activity that occurred outside the audit period. You reconcile the workforce roster against the completion logs by hand just to prove no one slipped through the cracks.

The final output is a fragile spreadsheet. It lacks the integrity-hashed PDF artifacts auditors prefer to verify the data hasn't been modified post-export. The platform logs the clicks, but it leaves the actual work of proving compliance to you.

Your PCI DSS training documentation checklist

To get through a PCI DSS assessment without wasting days on manual data formatting, your evidence needs to be precise and organized. Build your documentation bundle using this scannable checklist.

Per-person records:

• Full legal name and employee ID

• Organizational role or title

• Official hire date or CDE access date

• Training completions with exact dates and timestamps

• Content mapping (showing modules cover phishing, social engineering, and cardholder data handling)

• Information security policy acknowledgements with signature dates

• Refresher evidence (timestamps for ongoing phishing and awareness touches)

• Response to identified needs (remedial training dates triggered by simulation failures)

• Program-level artifacts:

• 
  

• Written information security policy

• Scope statement defining the in-scope workforce (all personnel with CDE access)

• Complete curriculum overview mapping back to PCI DSS Requirement 12.6

• Audit protocol compliance evidence showing training occurred within the 12-month window

• Retention:

• 
  

• Maintain all listed records for a minimum of 12 months to cover the annual assessment cycle, securely stored and readily accessible for the QSA.

Retention:

• Maintain all listed records for a minimum of 12 months to cover the annual assessment cycle, securely stored and readily accessible for the QSA.

Modern managed SAT platforms can generate this documentation automatically. Kinds, for example, produces PCI DSS-mapped PDF reports scoped by date range and workforce selection, with SHA-256 integrity hashes embedded in the footer so auditors can verify the report hasn't been modified. But whatever platform you use, the checklist above is what your documentation should include. If your current platform can't produce this without manual reconciliation, you have a documentation problem, not a training problem.

Related frameworks

Organizations subject to PCI DSS often also deal with SOC 2 and the GLBA/FTC Safeguards Rule. For related guidance, see our posts on those frameworks.

This post describes general patterns in PCI DSS training documentation. It is not legal or compliance advice. Confirm specific obligations with your compliance advisor, assessor, or relevant regulator.