Effective Software Security through Testing
Use tests to ensure software is secure and works well, considering both good and bad scenarios.
Plain language
This control is about making sure the software your business uses is both safe and reliable by running different kinds of tests on it. If you skip these tests, the software might have hidden problems or security gaps that can let in cyber attackers, leading to data breaches or other serious issues.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
May 2025
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
Unit testing and integration testing, covering both positive and negative use cases, are used to ensure code quality and security.
Why it matters
Without unit and integration testing for positive/negative scenarios, software errors or vulnerabilities may allow data breaches and operational failures.
Operational notes
Create unit and integration tests for positive and negative paths, including edge cases; verify security assertions and regularly review/close test coverage gaps.
Implementation tips
- A developer should create tests that check both the normal functions of the software (like logging in or processing a transaction) and what happens if something goes wrong (such as entering incorrect data). These tests should be written during the development phase and updated whenever changes are made to the software.
- An IT manager should ensure there is an automated system in place to regularly run these tests. This can be done by setting up a testing schedule that automatically triggers tests at set times, like daily or weekly, using tools designed for software testing.
- Software testers should clearly document the results of each test run, including any failures or unexpected results. They can do this by preparing a detailed report that lists what tests were run, what was being tested, and what the outcomes were.
- The IT security lead should review test results to identify any security issues or weaknesses in the software. They should also work with developers to fix these issues promptly, following a documented process for prioritising and resolving security problems.
- The organisation should train all relevant staff on why software testing is important and how it protects the business. This can be a part of regular training sessions that highlight how testing keeps the software secure and reliable, and what role each staff member plays in this process.
Audit / evidence tips
- AskA copy of the software testing plan: This is the document that outlines what tests will be done, how often, and who is responsible GoodIncludes a comprehensive schedule covering all critical operations and how issues are reported
- GoodShows tests being performed regularly, with clear outcomes and resolution steps for any fails
- AskEvidence of processes followed when software updates occur. Look to see that new versions include updates to tests or indicate new tests added to address known issues GoodIncludes log entries showing test plan adjustments after software updates
- AskTraining records of staff involved in testing processes: These records should demonstrate when and what training took place GoodShows regular training sessions with content updates reflecting latest testing practices
- GoodIncludes a system overview that automates testing across all necessary scenarios
Cross-framework mappings
How ISM-2062 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (1) expand_less | ||
| Annex A 8.29 | ISM-2062 requires unit and integration testing (including positive and negative use cases) to assure code quality and security | |
| handshake Supports (1) expand_less | ||
| Annex A 8.28 | ISM-2062 requires unit and integration testing (positive and negative cases) to validate code quality and security | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.