PCI DSS 6.2.2: Software development personnel working on bespoke and custom software are trained at least once
PCI DSS v4.0.1 control 6.2.2: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 6.2.
Requirement 6: Develop and Maintain Secure Systems and Software › Section 6.2
Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows:
- On software security relevant to their job function and development languages.
- Including secure software design and secure coding techniques.
- Including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software.
Summary
Developers of your own software are trained yearly on secure design and coding for the languages they actually use.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 6.2.2.a | Examine software development procedures to verify that processes are defined for training of software development personnel developing bespoke and custom software that includes all elements specified in this requirement. |
| 6.2.2.b | Examine training records and interview personnel to verify that software development personnel working on bespoke and custom software received software security training that is relevant to their job function and development languages in accordance with all elements specified in this requirement. |
The training that makes 6.2.4 achievable: that control expects named techniques against named attack classes, and this is where the people learn them. Three elements, and the specificity is the point: training must be relevant to their job function and development languages, so a generic secure-coding course for a team writing in a language it never mentions is weak evidence. Where security testing tools are used, training on those tools is explicitly included. Two procedures: the policy, then the records.
What to prepare
- Training records for every developer of bespoke and custom software, dated within twelve months.
- The syllabus, showing it covers the languages and frameworks in use.
- Tool training where static analysis or similar is part of the process.
How to implement it
1. Match the content to the stack. A course on memory safety for a team writing TypeScript satisfies the letter and teaches nothing; the requirement asks for relevance to their development languages.
2. Include contractors who write your code. They are software development personnel working on your bespoke software, whoever employs them.
3. Train on the tools you actually run. If a scanner is in the pipeline, developers being able to interpret and act on its output is a named part of this control.
4. Keep the records outside the training platform. Same reasoning as 12.6.1: the evidence should survive the vendor.
Where this commonly fails
- One generic course for every engineer regardless of language.
- Contractors excluded because they are not employees.
- Annual in policy, on joining in practice.
- Tool training omitted where tools are in use, which is a named element.
Related controls
Others in section 6.2:
| Control | What it requires |
|---|---|
| 6.2.1 | Bespoke and custom software are developed securely… |
| 6.2.3 | Bespoke and custom software is reviewed prior to being released into production… |
| 6.2.3.1 | If manual code reviews are performed for bespoke and custom software prior to release… |
| 6.2.4 | Software engineering techniques or other methods are defined and in use by software development… |
← 6.2.1 · All controls · 6.2.3 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.