Software Development Training

PCI DSS 4.0.1 requires you to train software development personnel who work on bespoke and custom software at least annually on software security topics tied to their job role and programming languages, including secure design, secure coding, and (where applicable) how to use security testing tools to find vulnerabilities. Your fastest path to compliance is a role-based training standard, a complete in-scope roster, and tight evidence of completion and coverage. (PCI DSS v4.0.1 Requirement 6.2.2)

Key takeaways:

• Scope to “software development personnel” working on bespoke/custom software, not all engineers by default. (PCI DSS v4.0.1 Requirement 6.2.2)
• Training must be role- and language-relevant and cover secure design, secure coding, and security tool use if those tools are used. (PCI DSS v4.0.1 Requirement 6.2.2)
• Auditors look for proof of coverage, frequency, and relevance: rosters, content, and completion evidence mapped to roles/languages. (PCI DSS v4.0.1 Requirement 6.2.2)

“Software development training requirement” under PCI DSS 4.0.1 Requirement 6.2.2 is a control with a simple headline (annual training), but it fails in practice for predictable reasons: unclear scope, generic training content that doesn’t match the tech stack, and weak evidence that doesn’t survive an assessment. PCI DSS is explicit that training must be relevant to the developer’s job function and development languages and must include secure software design and secure coding techniques. If your teams use security testing tools, training must also cover how to use those tools to detect vulnerabilities in software. (PCI DSS v4.0.1 Requirement 6.2.2)

Operationalizing this requirement is about building a repeatable system: define who is “software development personnel,” define what “bespoke and custom software” means in your environment, assign training by role/language/tooling, and retain artifacts that prove training happened within the required cadence. The outcome you want is defensible: you can show a complete population, assigned training that matches that population, and completion records that tie back to the right people and content.

Regulatory text

Requirement (verbatim): “Software development personnel working on bespoke and custom software are trained at least once every 12 months on software security relevant to their job function and development languages, including secure software design and secure coding techniques, and if security testing tools are used, how to use the tools for detecting vulnerabilities in software.” (PCI DSS v4.0.1 Requirement 6.2.2)

What the operator must do:
You must run an annual training program for in-scope developers (and developer-adjacent staff who code) that is tailored to (1) their role, (2) their languages and frameworks, and (3) the security tools they are expected to use. Then you must retain evidence that training was assigned and completed and that the content matches the requirement elements. (PCI DSS v4.0.1 Requirement 6.2.2)

Plain-English interpretation

This requirement is not “everyone takes a generic secure coding video once a year.” It is:

• Annual cadence for in-scope software development personnel. (PCI DSS v4.0.1 Requirement 6.2.2)
• Role- and language-relevant content, so a Java team and a JavaScript team can take different modules. (PCI DSS v4.0.1 Requirement 6.2.2)
• Two mandatory content domains: secure software design and secure coding techniques. (PCI DSS v4.0.1 Requirement 6.2.2)
• A conditional content domain: if you use security testing tools (SAST/DAST/SCA, CI scanning, IDE plugins), train people on how to use them to detect vulnerabilities in software. (PCI DSS v4.0.1 Requirement 6.2.2)

Who it applies to (entity and operational context)

Entity types: Merchants, service providers, and payment processors in PCI DSS scope. (PCI DSS v4.0.1 Requirement 6.2.2)

Operational scope trigger: Any personnel who work on bespoke and custom software that is in scope for your cardholder data environment (CDE) and connected systems, or that could affect the security of payment flows. PCI DSS 6.2.2 is tied to your SDLC control environment; if custom code can touch authentication, authorization, payment pages, tokenization, logging, encryption, secrets, APIs, or data handling, assume it is in scope until you can justify exclusion. (PCI DSS v4.0.1 Requirement 6.2.2)

Typical in-scope roles (adjust to your org):

• Application developers and software engineers building or maintaining custom apps
• Mobile developers if the app affects payment flows or CDE-connected services
• DevOps/Platform engineers who write custom deployment scripts, infrastructure code, or build pipeline logic that impacts application security controls
• QA/Automation engineers who write test harnesses that interact with security testing tools
• Contractors who commit code to your repositories or deliver custom components

Common scoping decision:
If a person only configures commercial off-the-shelf software with no code changes, they may fall outside “bespoke and custom software.” Document that rationale, because auditors will ask why the role was excluded.

What you actually need to do (step-by-step)

1) Define “bespoke/custom software” in your environment

Write a short definition that matches how your teams work:

• Custom applications you build
• Internal services and APIs
• Custom scripts and infrastructure-as-code that can change security behavior
• Custom integrations (webhooks, middleware, payment routing)

Keep it practical. Your goal is to define the boundary for who must be trained. (PCI DSS v4.0.1 Requirement 6.2.2)

2) Build and maintain the in-scope roster

Create an authoritative list of “software development personnel working on bespoke and custom software.” Use system sources, not spreadsheets alone:

• HRIS job codes + manager attestation
• Source control org/team membership
• SDLC tool access (issue tracker, CI/CD permissions)
• Contractor onboarding lists

Minimum fields that make the roster audit-ready:

• Name, team, role
• Employment type (employee/contractor)
• Primary languages/frameworks
• Security tools they are expected to use (if any)
• Training assignment and completion status

3) Create a role-and-language training standard

Draft a one-page standard that states:

• Training frequency: at least annually. (PCI DSS v4.0.1 Requirement 6.2.2)
• Training must be relevant to job function and development languages. (PCI DSS v4.0.1 Requirement 6.2.2)
• Training includes secure software design and secure coding techniques. (PCI DSS v4.0.1 Requirement 6.2.2)
• If security testing tools are used, training includes how to use them to detect vulnerabilities. (PCI DSS v4.0.1 Requirement 6.2.2)
• Completion expectations (e.g., required for access to production repos/pipelines, if that fits your governance model)

This standard becomes your “control statement” assessors map against.

4) Map training content to the requirement elements (and your stack)

Create a simple coverage matrix:

Requirement element	How you cover it	Evidence you retain
Annual training	Recurring assignment in LMS	LMS assignment + completion report
Relevant to job function	Role-based learning paths	Role-to-path mapping document
Relevant to languages	Language-specific modules (e.g., Java, .NET, JS)	Module outlines/syllabi
Secure software design	Threat modeling, secure architecture patterns	Course content + attendance
Secure coding techniques	Input validation, authz, error handling, secrets	Course content + assessment results
Tool training if used	SAST/DAST/SCA/CI scanner usage	Tool training deck + lab completion

Keep it opinionated: you are proving coverage, not building a university.

5) Assign training automatically, then close gaps

Operational moves that work:

• Assign learning paths based on the roster fields (role, language, toolset)
• Add onboarding triggers for new hires and contractors
• Add a manager escalation workflow for overdue completions
• For teams with multiple languages, require the module that matches what they actively ship

If you use Daydream to manage evidence and audit readiness, treat the roster, coverage matrix, and completion exports as a single “requirement packet” you refresh on a schedule so your assessor request is a pull, not a scramble.

6) Add a lightweight knowledge check (strongly recommended)

PCI DSS 6.2.2 does not prescribe test format, but a short quiz or hands-on lab is valuable because it proves engagement and reinforces tool use. Keep questions aligned to your secure coding standards and common defects in your environment.

7) Run a quarterly control self-check

Even though training is annual, your compliance exposure is continuous because people join, change teams, and start using new tools. Do a periodic check to confirm:

• roster completeness
• new tool adoption triggers training updates
• contractors are captured
• training content still matches current languages and frameworks

Required evidence and artifacts to retain

Aim to produce the following on request:

• Training standard / procedure describing scope, cadence, and required topics. (PCI DSS v4.0.1 Requirement 6.2.2)
• In-scope roster of software development personnel working on bespoke/custom software. (PCI DSS v4.0.1 Requirement 6.2.2)
• Role/language/tool mapping (who takes what, and why). (PCI DSS v4.0.1 Requirement 6.2.2)
• Training content outlines showing secure design + secure coding coverage, plus tool modules if tools are used. (PCI DSS v4.0.1 Requirement 6.2.2)
• Completion records (LMS exports, certificates, attendance logs) tied to individuals and dates. (PCI DSS v4.0.1 Requirement 6.2.2)
• Exceptions and remediations (late completions, temporary access decisions, contractor offboarding clean-up) with approvals.

Common exam/audit questions and hangups

Expect these lines of questioning:

1. “Who is in scope, and how do you know the list is complete?” Be ready to show your roster methodology and sources.
2. “Show me that training is relevant to the languages used.” Provide your mapping and examples (e.g., Java secure coding module for Java teams).
3. “Do you use security testing tools? If yes, show tool training.” Auditors often spot this gap when teams claim they run SAST/DAST but have no enablement artifacts. (PCI DSS v4.0.1 Requirement 6.2.2)
4. “Prove the annual cadence for a sample set of developers.” Pull dated completion evidence for the sample population.

Frequent implementation mistakes and how to avoid them

• Mistake: Counting general security awareness training as developer training. Fix: maintain a distinct secure development curriculum mapped to languages and tools. (PCI DSS v4.0.1 Requirement 6.2.2)
• Mistake: Missing contractors and embedded third parties. Fix: make training a contractual onboarding requirement and tie it to repo access.
• Mistake: Training content is generic and not job-function relevant. Fix: create learning paths by role (backend, frontend, mobile, DevOps) and by language. (PCI DSS v4.0.1 Requirement 6.2.2)
• Mistake: Tools are “used” but nobody is trained on them. Fix: if scans run in CI, train developers on interpreting results, triage, and fix validation. (PCI DSS v4.0.1 Requirement 6.2.2)
• Mistake: Evidence is scattered across HR, LMS, and engineering tooling. Fix: maintain a single audit packet per requirement, refreshed on a schedule; Daydream can help centralize and version that packet.

Risk implications (why assessors care)

This requirement exists because bespoke code is a primary way vulnerabilities enter the environment that stores, processes, or transmits card data. If developers do not understand secure design patterns, secure coding techniques, and how to use testing tools your program relies on, your preventive and detective SDLC controls degrade even if policies look good on paper. (PCI DSS v4.0.1 Requirement 6.2.2)

Practical 30/60/90-day execution plan

Use phases rather than fixed-day promises; adjust to your organization size and training platform maturity.

Immediate (stabilize scope and evidence)

• Publish a short training standard aligned to PCI DSS 6.2.2 topics and cadence. (PCI DSS v4.0.1 Requirement 6.2.2)
• Build the initial in-scope roster from HR + source control + manager attestations.
• Inventory languages/frameworks in use for bespoke/custom software and list security testing tools in use.

Near-term (implement role-based training paths)

• Create role/language learning paths that explicitly include secure design and secure coding. (PCI DSS v4.0.1 Requirement 6.2.2)
• Add tool-specific modules where security testing tools are used. (PCI DSS v4.0.1 Requirement 6.2.2)
• Configure automated assignments and escalations in your LMS (or equivalent workflow).
• Produce your coverage matrix and store it with training content outlines.

Ongoing (make it resilient)

• Add onboarding/offboarding hooks for employees and third-party contractors.
• Run periodic roster reconciliation and remediate drift (team moves, new languages, new tools).
• Refresh training content when languages/frameworks or toolchains change.
• Maintain an assessment-ready export package (roster + mapping + completions + content) in a single place, such as Daydream, with version history.

Frequently Asked Questions

Does PCI DSS require annual training for every engineer in the company?

No. The text targets “software development personnel working on bespoke and custom software.” Scope it to people who actually build or maintain custom code that can impact the security of payment flows or in-scope systems. (PCI DSS v4.0.1 Requirement 6.2.2)

What counts as “bespoke and custom software” for this requirement?

Treat it as any code your teams create or materially modify, including internal services, custom integrations, and custom pipeline logic that affects security. Document your definition and use it consistently for roster scope. (PCI DSS v4.0.1 Requirement 6.2.2)

Our teams use multiple languages. Do they need multiple trainings?

They need training relevant to their job function and development languages. In practice, assign modules that match what each person actively ships, and document your assignment logic in a role/language mapping. (PCI DSS v4.0.1 Requirement 6.2.2)

If scans run automatically in CI/CD, do we still need tool training?

Yes if those security testing tools are used as part of your program. Developers must know how to use the tools for detecting vulnerabilities in software, which usually means understanding findings, triage, and verification workflows. (PCI DSS v4.0.1 Requirement 6.2.2)

What evidence is usually missing during an assessment?

The two common gaps are an incomplete roster (especially contractors) and training content that is not clearly tied to the languages/tools in use. Fix both with a coverage matrix and auditable completion exports. (PCI DSS v4.0.1 Requirement 6.2.2)

Can we meet this requirement with internal training rather than a third-party course?

Yes. PCI DSS specifies the topics, relevance, and frequency, not the training vendor. Keep detailed materials and attendance/completion records so the training is defensible in an assessment. (PCI DSS v4.0.1 Requirement 6.2.2)