# ISM-2121: Security Skills for Software Developers

ISM-2121 says software developers who lack the cyber security knowledge and skills their project or task needs are not used for that work. In practice an organisation decides what security knowledge each kind of development work requires, checks everyone who writes its code against that, contractors and AI coding tools included, and closes any gap before the work starts rather than after the code ships. The control is new in the June 2026 ISM and works with ISM-2037, which asks for training or upskilling, and ISM-2038, a register of developers' security knowledge and skills.

## What does ISM-2121 require?

Read on its own, the control can sound like a ban. Read with the controls around it, it is a matching rule: the security skills a developer brings have to be enough for the work they are given. Three points carry the meaning.

- **The bar moves with the work.** ASD says "required for their projects or tasks", not skills in general. A developer adjusting a report layout needs less security knowledge than one building a sign-in flow, handling payments, parsing files that arrive from the internet or deploying cloud infrastructure from code. The same person can be the right choice for one task and the wrong one for the next.
- **Every developer counts.** The statement does not distinguish employees from contractors or a development partner, and ASD's guidance for the section is explicit about AI. It "applies to human, artificial intelligence (AI)-assisted, AI-powered and AI-driven software development activities", and "Where references are made to software developers, they apply to humans and AI."
- **What "are not used" means.** The answer to a gap is not to sideline people for good. ISM-2037 says developers who lack the skills "undertake suitable training or upskilling on secure software development and programming practices", so the practical reading is: train or pair first, give the work to someone who has the skills in the meantime, and assign it once the gap is closed.

The control applies at every classification ASD marks, from non-classified systems to TOP SECRET, wherever an organisation develops software. It is not part of the Essential Eight.

## Why does it matter?

Many software vulnerabilities start as an ordinary coding decision: a database query built from user input, a permission check left off one page, a password written into a configuration file, a library added without a look at its history. Security testing catches some of these. A developer who knows the safe pattern does not write them in the first place, and is better placed to notice what testing misses.

ASD's Secure by Design guidance puts the responsibility on the organisation: "All organisations must invest in the skills and knowledge of their employees, whilst supporting them through the implementation of technical controls, safety nets and guard rails" ([ASD](https://www.cyber.gov.au/business-government/secure-design/secure-by-design/secure-by-design-foundations)). NIST's Secure Software Development Framework, which the ISM points to for this section, makes the same point in its practice on roles and responsibilities: "Ensure that everyone inside and outside of the organization involved in the SDLC is prepared to perform their SDLC-related roles and responsibilities throughout the SDLC" ([NIST SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final)).

AI coding assistants make the control more pressing, not less. They produce plausible code quickly, and the person who accepts it is often the last check before it ships. GitHub's documentation for its own assistant says: "You should be careful when using Copilot to generate code for security-sensitive applications and always review and test the generated code thoroughly" ([GitHub](https://docs.github.com/en/copilot/responsible-use/inline-suggestions)). That review is only as good as the reviewer's security knowledge. And because ASD counts AI as a software developer, the tool itself has to be suitable for the task it is given, as well as the people directing and checking it.

## How does it fit with the other controls?

ISM-2121 is one step in a short sequence within ASD's secure software development controls:

- **ISM-2035** identifies and documents the security roles, responsibilities and knowledge the software development life cycle needs. This is what "sufficient" is measured against.
- **ISM-2036** documents the security responsibilities of software developers themselves.
- **ISM-2038** keeps a register of developers' cyber security knowledge and skills, so the comparison can actually be made.
- **ISM-2037** closes the gaps with training or upskilling on secure development and programming practices.
- **ISM-2121** makes the match binding: work goes to developers who have the skills it needs.
- **ISM-2120** sets all of this in a secure software development policy that is developed, implemented and maintained.

The controls that follow in the same section describe the skills themselves: Secure by Design principles (ISM-0401), threat modelling (ISM-1238), secure programming practices for the language in use (ISM-2040) and memory-safe programming languages (ISM-2041). Together they are a sensible first list of what "cyber security knowledge and skills" means in practice.

## How do you meet ISM-2121?

1. **Decide who counts as a developer.** List everyone who writes, changes or generates code for your systems: in-house teams, contractors, development partners and the AI coding tools in use. Decide whether people who build scripts and automations outside the development team are in scope.
2. **Write down what each kind of work needs.** A short skills matrix is enough to start: a baseline for anyone who writes code (secure programming practices for the language, handling secrets, validating input, the common weaknesses of your stack), plus additions for higher-risk work such as authentication, cryptography, payments, infrastructure as code and AI features. This is the knowledge ISM-2035 asks you to identify.
3. **Assess people against it and record the result.** Use evidence rather than self-belief: training completed, a practical exercise, and findings from recent code reviews and security testing. The record is the register ISM-2038 asks for.
4. **Close gaps before the work.** Training or upskilling (ISM-2037), pairing with a developer who has the skills, or giving the task to someone else while the gap closes.
5. **Make allocation depend on the register.** Whoever assigns work, usually a technical lead, checks it for higher-risk tasks. For contractors and development partners, write the skills requirement into the contract and ask for the evidence.
6. **Set rules for AI coding tools.** Which tools are approved, what they may be used for, and who reviews what they produce. The reviewer needs the skills the task needs; accepting generated code without them is exactly the gap ISM-2121 describes.
7. **Keep it current.** Revisit the matrix and the register when people join or leave, when you adopt a new language, framework or tool, when testing or an incident shows a recurring weakness, and at least once a year. NIST's framework asks organisations to "Periodically review personnel proficiency and role-based training, and update the training as needed."
8. **Put it in the policy** (ISM-2120), so the rule outlives the people who set it up.

## What evidence shows ISM-2121 is met?

| Ask | Look at | Good looks like |
|---|---|---|
| What security knowledge does each kind of work need? | Documented roles, responsibilities and knowledge (ISM-2035, ISM-2036) | Written for each role or type of work, not one generic sentence |
| Who has it? | The developer knowledge and skills register (ISM-2038) | Every developer listed, contractors included, with when and how they were assessed |
| What happens when someone falls short? | Training and upskilling records (ISM-2037) | Gaps closed, or the work reassigned, before the work starts |
| Does the register decide who does what? | A sample of recent higher-risk changes, compared with the register | Each one done or reviewed by someone with the skills the task needed |
| How is AI-assisted development governed? | The secure software development policy (ISM-2120) and review records | Approved tools, defined uses, and review by a developer with the right skills |
| What about contractors and partners? | Contracts and the evidence they supplied | A skills requirement in the contract, and evidence received |

## What gets in the way?

**Skills are hard to measure.** Certificates and years of experience are easy to record and say little about whether someone writes safe code in your stack. Short practical exercises and the findings of real code reviews are better evidence, and cheaper than they sound.

**A register nobody consults.** The register is only useful if someone looks at it when work is allocated. A spreadsheet that is filled in once a year and never read is evidence of a document, not of the control.

**Contractors and development partners.** Organisations that outsource development often cannot see who is writing their code. Ask the partner how it assesses and trains its developers, and ask for the evidence in the table above.

**AI changes the volume.** AI coding assistants can produce more code than a team can review well. If the reviewers lack the skills for the task, the extra speed is extra risk.

**Smaller and larger organisations.** A smaller organisation may have one or two developers or rely on an agency. Its register can be a single page; the hard part is depth, so it may need an outside security review for its riskiest work, such as authentication or payments. A larger organisation has many teams, languages and contractors, so it needs a skills framework, a training platform, security champions in each team and a way to keep the register current as people move between projects.

**The business case.** The cost is training time and a little process. What it buys is fewer vulnerabilities written in the first place, rather than found, fixed and sometimes disclosed later, and a clear answer when a customer, an auditor or a government buyer asks how you know your developers can build secure software.

## What tools and skills help?

- **Secure coding training** that is hands-on and uses the languages and frameworks your teams actually work in. Free material is a good base: the [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/) was "created to provide a concise collection of high value information on specific application security topics".
- **A maturity model for the training programme.** OWASP's Software Assurance Maturity Model has an Education and Guidance practice whose second level is to "Educate all personnel in the software lifecycle with technology and role-specific guidance on secure development" ([OWASP SAMM](https://owaspsamm.org/model/governance/education-and-guidance/)).
- **A skills register**, kept in a spreadsheet, a learning management system or an HR system, as long as it records what was assessed, how and when.
- **Security champions**: a developer in each team with deeper security knowledge who reviews higher-risk changes and helps others learn. OWASP SAMM suggests one in each development team.
- **Code review and automated checks** in the build pipeline, such as static analysis, dependency checks and secret scanning. They catch some mistakes and show where training is needed, but they support skilled developers rather than replace them. NIST's framework gives as an example: "Measure outcome performance to identify areas where changes to training may be beneficial" ([NIST SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final)).
- **Rules for AI coding tools**: an approved list, settings that keep code and secrets where they belong, and review requirements written into the policy.
- **Skills** to write the skills matrix, assess developers fairly and run the programme: usually a senior developer or security architect with application security experience.

Which of the products you already pay for help here? The [free coverage check](https://check.teresec.com.au/?utm_source=teresec.com.au&utm_medium=ism-guide&utm_campaign=ism-2121) shows which ISM and Essential Eight controls your current products can reach, in about three minutes. To see ISM-2121 among the other software development controls, open it in our [sample coverage report](/sample-report.html#ISM-2121), or read [what an ISM assessment involves](/services/ism).

## What changed in recent ISM releases?

ISM-2121 is new: ASD added it in the June 2026 release, at revision 0, together with ISM-2120, the secure software development policy. The same release changed ISM-2037 from "training" to "training or upskilling" and tidied the wording of ISM-2035. In the September 2026 release ISM-2038 changed from a register that "is implemented and maintained" to one that "is developed, implemented and maintained", the same wording ASD uses for the new policy control. Our [ISM September 2026 summary](/blog/2026-09-17-ism-september-2026-update) covers the rest of the latest release.

## Sources

- ASD, [Information security manual](https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/ism): ISM-2121, the secure software development controls, and the section guidance quoted on this page
- ASD, [Secure by Design foundations](https://www.cyber.gov.au/business-government/secure-design/secure-by-design/secure-by-design-foundations)
- NIST, [SP 800-218, Secure Software Development Framework (SSDF) Version 1.1](https://csrc.nist.gov/pubs/sp/800/218/final): practice PO.2, Implement Roles and Responsibilities
- OWASP, [SAMM: Education and Guidance](https://owaspsamm.org/model/governance/education-and-guidance/)
- OWASP, [Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- GitHub, [Application card: GitHub Copilot inline suggestions](https://docs.github.com/en/copilot/responsible-use/inline-suggestions)