ISO/IEC 27001:2022 introduced A.8.28 Secure Coding as a new control. Train your developers against it, evidence it cleanly for internal and external auditors, and close the 27001:2013 to 27001:2022 transition gap before your next surveillance visit.
The 27001:2022 revision restructured Annex A and added secure coding as an explicit control. Our platform was architected around the new control set — A.8.28, A.6.3, A.8.29, and A.5.7 — not retrofitted onto a generic LMS.
A.8.28 is what auditors will be looking for first this cycle. We map directly: language-specific secure coding curriculum across 15+ stacks, OWASP-aligned vulnerability category coverage, and demonstrated proof of competence per developer — not attendance.
A.6.3 covers staff awareness more broadly, and engineering teams need a developer-specific track to satisfy it credibly. Role-mapped paths for backend, frontend, and mobile engineers — distinct from generic security awareness — close that gap with auditable records.
A.8.29 expects security testing inside the SDLC. Training covers what developers must run before merge — SAST, DAST, IAST integration patterns, dependency scanning, and how to triage findings — so the control is operationalized, not just documented.
A.5.7 is a 27001:2022 addition that auditors are still figuring out how to evidence. Our quarterly curriculum refresh tracks emerging vulnerability classes — zero-day patterns, dependency confusion, recent CVEs — so threat intelligence is a living input to training, not a stale slide.
An internal auditor or certification body assessor walking into an A.8.28 review is looking for a specific set of artifacts. Our platform produces all seven — automatically, continuously, and in the formats ISMS auditors expect.
Each transcript mapped to A.8.28 and A.6.3 controls with timestamps, scores, and attempt history. The exact per-learner record an auditor traces back from a sampled developer.
Curriculum description tied to the in-scope languages, frameworks, and OWASP categories of your ISMS — version-controlled with a changelog the auditor can inspect.
Scoring on demonstrated capability — classify vulnerable code, write fixes, review pull requests with planted flaws — not seat-time. The form of competence A.6.3 actually asks for.
Training output tied to the A.8.29 hook: developers trained on running SAST, DAST, IAST, and code review checks before merge, with module completion linked to those activities.
Refresh records tied to threat intelligence inputs (A.5.7) — emerging vulnerability classes, dependency-chain risks, recent CVEs — with documented rationale for each curriculum change.
CSV and JSON exports with control references inline — A.8.28, A.6.3, A.8.29, A.5.7 — so the auditor reads control alignment without translating from your LMS taxonomy.
Drop-in SoA wording for in-scope Annex A controls citing this training as the primary mitigation, with the evidence references your assessor will sample against.
A thirty-minute call is usually all it takes to know if we are the right fit for your ISMS. We walk your team through the A.8.28 bar, map our program to your stack and SoA, and show you the evidence package internal and external auditors have already accepted.