PCI DSS compliance training starts with your developers
PCI DSS names two training obligations. Security awareness training for all personnel is the obligation most vendors cover. Requirement 6.2.2 is the other: software security training for the people building your payment applications, at least once every 12 months, specific to their languages and their jobs. That second one is what your assessor checks line by line, and it is the one this page covers.
Development teams in payments and financial services train with SecureFlag
PCI DSS v4.0.1
Current standard
Every 12 months
Developer training (Req 6.2.2)
All personnel, annual
Awareness training (Req 12.6.3)
March 31, 2025
v4.0 fully mandatory since
What is PCI DSS compliance training?
PCI DSS compliance training is what the Payment Card Industry Data Security Standard requires organizations to provide. There should be security awareness training for all personnel at least once every 12 months (Requirement 12.6.3), and software security training for software development personnel at least once every 12 months, relevant to their job function and development languages (Requirement 6.2.2).
The standard is maintained by the PCI Security Standards Council, founded by the five major card brands, and enforced through the card networks and acquiring banks. Compliance is validated every year: a Report on Compliance by a Qualified Security Assessor for Level 1 merchants and most service providers, or a Self-Assessment Questionnaire for smaller merchants. Training records are evidence on both routes.
The current version is PCI DSS v4.0.1. Under the previous version of the standard, a generic annual video could pass an assessment. The v4.0 requirements that were future-dated became mandatory on March 31, 2025, and with them the language-specific, role-specific training obligation, which is why questions that used to be best-practice conversations now show up as findings.
The two training requirements in PCI DSS
Most of the confusion around PCI training, and most of the vendor noise, comes from collapsing two different obligations into one. They cover different people, different content, and different evidence.
Security awareness training
Req 12.6.3Software security training
Req 6.2.2SecureFlag covers both training requirements, 12.6.3 and 6.2.2, and helps you evidence the wider Requirement 6 controls mapped below.
What the assessor actually checks for 6.2.2
01
The check starts with a roster, not a curriculum. Assessors ask for every person who wrote or modified in-scope application code in the past twelve months, contractors included, and reconcile that list against training records. A developer who made two config changes last year is in scope. Anyone on the roster without a completion inside the last twelve months is a finding.
02
The window is rolling, per person. A batch campaign every January does not cover the engineer hired in March, or the one whose last completion is thirteen months old. And the content itself gets reviewed: "relevant to development languages" is tested literally. The same video library for every engineer produces records, but not evidence. A Java team trained on generic pseudocode fails the content review.
03
Two more things assessors expect. If your pipeline runs SAST, DAST, or software composition analysis, the 6.2.2 conditional clause applies, and developers need documented training on using those tools. And you should be able to answer in writing how you decided what training is relevant to each role, how the content covers the languages in your codebase, and what proves each developer completed it.
04
What passes are per-developer completion records with dates, curricula mapped to the languages and frameworks in your cardholder data environment, and content descriptions that an assessor can read without a meeting. Evidence you export the week before the assessment, not reconstruct during it.
Requirement 6, mapped to your development team
Requirement 6 is where PCI DSS regulates how software gets built. Most PCI guides recite the control text. This table maps the engineering-relevant controls to the capability that satisfies them, and to the evidence that answers the assessor.
Developers trained in software security, every 12 months, per language and job function
Bespoke and custom software reviewed before release
Techniques in use to prevent common software attacks
Security vulnerabilities identified and risk-ranked
Vulnerability scans and segmentation tests have tooling answers. Requirement 6.2.2 is about people, and the assessor treats it that way.
Could you evidence 6.2.2 this week?
Ten questions covering the controls above, including per-developer records, language relevance, 12-month coverage, reviewer competence, and attack-class coverage. You get a gap view by requirement, not a sales call. If an assessor already handed you a finding, the same gap view shows the shortest path to closing it.
Everyone who wrote or changed in-scope code in the last 12 months, contractors included, has a dated training record.
Training content matches the languages and frameworks each developer actually works in.
Each developer is tracked on a rolling 12-month window, so new hires and lapsed completions get caught.
Developers are trained on the security testing tools in your pipeline, such as SAST, DAST, or software composition analysis.
All bespoke and custom code is reviewed for vulnerabilities before release, and issues are fixed before it ships.
Manual code reviews are done by someone other than the author, who is trained in secure coding and code-review techniques.
Your teams use defined techniques to prevent common attacks, including injection, broken access control, weak cryptography, and business logic abuse.
You can show which attack classes each team has been trained on, tracked by team and category.
New vulnerabilities in bespoke, custom, and third-party software are identified from industry sources and given a risk ranking.
You measure how long developers take to fix vulnerabilities once they are found.
Scanners find vulnerabilities. 6.2.2 asks who is writing them.
ASV scans, SAST, and DAST cover their own requirements. None of them trains anyone, and none of them produces the evidence an assessor reads for 6.2.2. There is a reason the control exists: in Verizon's payment security research, Requirement 6 has sat among the lowest-performing requirements in the standard for years, and it is the requirement organizations most often patch over with compensating controls.
For payment teams, SecureFlag's labs mirror the failures assessors keep finding: primary account numbers written to logs, tokenization applied after validation instead of before it, authorization checks missing on account and transaction endpoints, and injection in transaction search. Developers fix them in running applications, in their own stack.
The labs map to the OWASP Top 10, which is the vocabulary most assessors reach for when they discuss the attack classes 6.2.4 names, and SecureFlag partners with OWASP to provide training for its members.
52.4%
of organizations maintained full Requirement 6 compliance, down from 58.8%, according to the Verizon 2024 Payment Security Report.
Abrantix, a Swiss payment software and card transaction testing provider, adopted SecureFlag to support PCI DSS compliance across its payment solutions, and holds PCI DSS v4.0.1 certification today.
What enterprise leaders are saying
SecureFlag helps global engineering and security teams reduce vulnerabilities and build secure software faster.
“We needed a solution that both helps developers improve their secure coding practices and meets our compliance and audit requirements, and SecureFlag delivers on both. Developers get practical, hands-on training that carries over into day-to-day work. At the same time, we have the reporting and completion tracking we needed for the auditors.”
Security Director
Verified review on G2
What is PCI compliance training?
The training PCI DSS requires is security awareness training for all personnel (Requirement 12.6.3) and software security training for software development personnel (Requirement 6.2.2). Both run on a 12-month cadence.
Is PCI DSS training mandatory?
Yes. Both requirements are tested with evidence at every assessment, and since March 31, 2025, all PCI DSS v4.0 requirements are mandatory, including the ones that were future-dated.
How much does PCI training cost?
Depends which training. The PCI Security Standards Council publishes fees for its own professional programs in the low thousands of dollars per person. Awareness and developer training are priced per platform, usually per seat per year.
Can I do PCI compliance myself?
Most merchants below Level 1 self-assess with a Self-Assessment Questionnaire. Level 1 merchants and most service providers need a QSA assessment and a Report on Compliance. The training obligations apply to both routes; the difference is who reviews your evidence.
Does PCI DSS require secure coding training for developers?
Yes, by name. Requirement 6.2.2 requires software security training for development personnel at least once every 12 months, relevant to their job function and development languages. PCI DSS is one of the few frameworks that says so explicitly.
Do we get a PCI certification from training?
No, and nobody can offer one. PCI SSC trademark rules do not allow claiming that personnel or code are "PCI certified." Completing training produces the records your assessor accepts as evidence. The formal qualifications (QSA, ISA, PCIP) are PCI SSC programs for assessors and compliance professionals, not for developers.
Walk into your next assessment with 6.2.2 answered
See how SecureFlag maps training paths to Requirement 6 in the languages your team ships, and what the exported evidence looks like to a QSA. Thirty minutes, with your stack.