ASD ISM 2122 Use suitable AI models to augment software security testing
What it says
Suitable AI models are used to augment software security testing.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishWhere your organisation builds software, use appropriate artificial intelligence tools to strengthen, not replace, your existing security testing of that software.
If your organisation writes its own software (whether a website, an app, or an internal system), it should test that software for security weaknesses before and after release. This control says you can use suitable artificial intelligence (AI) tools to help do that testing better, for example by spotting coding flaws faster or covering more of the code. The AI is meant to add to your normal security testing, not be your only safety check, and you need to choose AI tools that are genuinely fit for the job.
Free. Save your status, tasks and notes.
Why it matters
If AI security testing is poorly chosen or relied on alone, real coding flaws can slip through into released software, exposing it to attackers and putting customer data and reputation at risk.
How to implement
The development team lead decides which parts of your security testing AI can help with (for example scanning code for known flaws or generating extra test cases) and writes this into your testing checklist so it is done consistently on every release.
The person responsible for tool selection trials two or three AI security testing tools against a sample of your own code, then chooses one based on how accurately it finds real flaws rather than on marketing claims.
The development team runs the AI security testing alongside your existing manual and automated tests, treating AI findings as one input to review rather than as the final word, so a human still confirms each result before it is fixed or dismissed.
The team lead sets a rule that no AI security tool is given access to sensitive source code or customer data unless the vendor's terms confirm that data is not stored or used to train their models, and records this check before adopting any tool.
The quality or security reviewer keeps a short record for each release listing which AI tools were used, what they checked, and what was found, so there is proof the AI testing actually happened and was acted on.
Keep it running
Reassess the chosen AI tools periodically as both the tools and your software change, and keep confirming that AI findings are still reviewed by a person rather than accepted automatically.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
the development team to show their security testing process for a recent software release.
Look at
where AI tools fit into that process and confirm they sit alongside other testing.
Good evidence
shows AI is one documented step among several, not the only check.
- Check 2 of 5What an auditor asks for
Ask for
how they chose the AI security testing tool they use.
Look at
evidence of a trial or comparison against their own code and clear selection reasons.
Good evidence
describes testing the tool's accuracy on real examples, not just picking the cheapest or best-known product.
- Check 3 of 5What an auditor asks for
Ask for
the output or findings from the AI security testing on a recent release.
Look at
a record of what flaws the AI raised and what the team did about each one.
Good evidence
shows findings were reviewed by a person and either fixed or justifiably dismissed.
- Check 4 of 5What an auditor asks for
Ask for
whether sensitive code or data is exposed to the AI tool and how that is controlled.
Look at
the vendor's data handling terms and an internal check confirming code is not retained or used for training.
Good evidence
points to a documented review of those terms before the tool was adopted.
- Check 5 of 5What an auditor asks for
Ask for
how they confirm the AI testing is genuinely improving results rather than just adding noise.
Look at
comparison of flaws found with and without the AI, or feedback on false alarms.
Good evidence
shows the team monitors the tool's usefulness and adjusts how they use it.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.25.
ISM-2122 requires organisations to use suitable AI models to strengthen their software security testing. ISO/IEC 27001:2022 Annex A 8.25 mandates rules for secure software and system development, where ISM-2122 acts as one tactical approach among broader secure development practices.
This control partially meets A.8.29.
ISM-2122 requires the use of suitable AI models to augment security testing for organisational software. ISO/IEC 27001:2022 Annex A 8.29 requires defining and implementing security testing processes across the development lifecycle, allowing for AI-assisted testing approaches, making ISM-2122 a specific technique within this broader requirement.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.