ASD ISM 2038 Maintain a software developer cyber security knowledge and skills register
What it says
A software developer cyber security knowledge and skills register is developed, implemented and maintained.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishKeep a living record of what each software developer knows and can do in cyber security, so gaps are visible and can be closed before they reach production code.
This control asks you to build, put into use and keep current a register of the cyber security knowledge and skills held by your software developers. In practice it is a structured record, per developer, of what they know (for example secure design principles, common vulnerability classes, secure handling of secrets) and what they can actually do (for example write code that resists injection, review a pull request for security defects, use the organisation's static analysis tooling). It matters because secure software depends on the people writing it. A team can have secure coding standards, code review gates and scanning tools, yet still ship weak code if the developers involved were never taught what those controls are looking for. Without a register, nobody can say with confidence which developers are equipped for security-sensitive work, where the knowledge gaps sit, or whether training is reaching the people who need it. The register turns an assumption ("our developers know security") into something you can check, plan against and improve. The statement has three parts, and all three are required: the register must be developed (designed and populated), implemented (actually used in the organisation's processes) and maintained (kept accurate as people, roles and skills change).
Free. Save your status, tasks and notes.
Why it matters
If no register exists, or it exists but is stale or unused, developers with limited security knowledge can be assigned to authentication, cryptography, input handling or other high-risk code without anyone noticing. Skill gaps stay invisible until they surface as vulnerabilities in released software, a failed penetration test, or a breach. Training budgets get spent on the wrong people or the wrong topics, and the organisation cannot demonstrate to assessors that its secure development practices are backed by a capable workforce.
How to implement
The application security lead defines the register's structure by listing the cyber security knowledge and skill areas relevant to the organisation's development work (for example secure design, common vulnerability classes, secure use of frameworks and libraries, secrets handling, security testing tools) and a simple proficiency scale for each, then documents this as the register template.
The development manager populates the register for every current software developer by combining existing training records, certifications and a short self-assessment, then confirms each entry with the developer's team lead before it is marked as verified.
The register owner embeds the register in existing processes by adding it to developer onboarding and offboarding checklists, requiring a register update when a course or certification is completed, and having managers consult it when assigning security-sensitive work.
The register owner schedules a recurring review (for example every six months) in the team calendar, at which each developer's entries are re-confirmed, stale evidence is refreshed, departed staff are archived and identified gaps are handed to the training program as priorities.
The register owner stores the register in a controlled location with restricted edit access and a change history, so updates are attributable and the register can be shown as current and maintained rather than a one-off document.
Keep it running
Day to day, the register is owned by a named person (commonly a development manager, security champion lead or application security function) and lives somewhere developers and their managers can reach it, such as an HR learning system, a spreadsheet under change control, or a skills module in the organisation's people platform.
Entries are updated on defined triggers rather than by memory: a new developer joins, a developer changes team or role, a training course or certification is completed, a security assessment reveals a knowledge gap, or a periodic review falls due. Each entry records the developer, the knowledge and skill areas assessed, the level held, the evidence relied on (course record, certification, assessment result, manager attestation) and the date it was last confirmed.
The register should feed real decisions. Managers consult it when staffing security-sensitive work, the training program draws its priorities from the gaps it shows, and reviews confirm that entries still reflect reality. Old entries for departed staff are archived so the register only describes current developers.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask to see the software developer cyber security knowledge and skills register itself.
Look at
Check that it covers each current software developer, records specific knowledge and skill areas with a proficiency level, and shows the evidence and date behind each entry.
Good evidence
Every current developer appears with recent, evidenced entries across defined security knowledge and skill areas, and there are no placeholder or blank rows.
- Check 2 of 5What an auditor asks for
Ask for
Ask who owns the register and how it was developed.
Look at
Look for a named owner, a documented template or structure, and a record of when the register was first established and approved.
Good evidence
A specific role owns the register and can explain how the skill areas and proficiency scale were chosen for the organisation's development work.
- Check 3 of 5What an auditor asks for
Ask for
Ask how the register is used in practice, not just kept.
Look at
Look for references to the register in onboarding checklists, work allocation decisions, or training planning documents.
Good evidence
Managers can point to concrete cases where the register informed who was assigned security-sensitive work or which training was scheduled.
- Check 4 of 5What an auditor asks for
Ask for
Ask what triggers an update and when the last review took place.
Look at
Check the change history or version log for updates following new starters, leavers, completed training and the scheduled review.
Good evidence
Updates are dated and attributable, recent joiners and course completions appear promptly, and the last full review is within the defined interval.
- Check 5 of 5What an auditor asks for
Ask for
Pick two or three developers and ask for the evidence behind their register entries.
Look at
Compare the register entries to the underlying training records, certifications or assessment results.
Good evidence
The evidence matches the entries, and the developers' current roles and teams are correctly reflected.
Mappings
Closest match in ISO/IEC 42001: A.4.6, Document the people and skills running your AI system, which partially overlaps with this control.
ISO/IEC 27001: 1 mapping
This control supports A.6.3.
ISM-2038 requires a developed, implemented and maintained register of each software developer's cyber security knowledge and skills to make gaps visible and manageable. ISO/IEC 27001:2022 Annex A 6.3 requires an organisation-wide information security awareness, education and training program aligned to job functions, which is directly informed and strengthened by having the ISM-2038 register to target training to developer-specific gaps. Annex A 6.3 is broader (all personnel and program delivery), while ISM-2038 is a developer-focused competency recording mechanism rather than the training program itself.
ISO/IEC 42001: 1 mapping
This control partially overlaps A.4.6.
ISM-2038 requires maintaining a living register of software developers' cyber security knowledge and skills. ISO/IEC 42001:2023 Annex A 4.6 requires documenting the human resources and competences used across the AI system life cycle (development through decommissioning), which overlaps where developers contribute to AI systems and their security competence must be evidenced. Annex A 4.6 is broader in scope (all AI lifecycle roles and competences, not only cyber security), while ISM-2038 is narrower but deeper on cyber security skills for software developers regardless of whether the system is AI.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.