Conduct Vulnerability Assessments and Penetration Tests Annually
Conduct vulnerability assessments and penetration tests on systems before they are deployed, before significant changes go live, and at least once every year afterwards.
Plain language
Before a new system goes live, and before any major change to an existing one, you must have it security tested in two ways: a vulnerability assessment that scans for known weaknesses, and a penetration test where a tester actively tries to exploit them. You also repeat both at least once a year for systems already in production. This catches exploitable flaws while you can still fix them before an attacker finds them first.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
June 2026
Control Stack last updated
19 June 2026
E8 maturity levels
N/A
Guideline
Guidelines for security assuranceSection
Security AssessmentsOfficial control statement
Vulnerability assessments and penetration tests are conducted for systems prior to their deployment, including prior to the deployment of significant changes, and at least annually thereafter.
Why it matters
Systems can be put into production, or have significant changes pushed live, carrying exploitable weaknesses that no one has actively probed for, and production systems can run for years without any adversarial testing. An attacker then finds and exploits those flaws before the organisation does, because one or more of the three required test triggers (pre-deployment, pre-significant-change, and annual) was never run.
Operational notes
Tie the pre-deployment and pre-significant-change tests to your change and release process so that no system reaches production, and no significant change is approved, without a completed vulnerability assessment and penetration test against it. Define in advance what counts as a "significant change" (for example a new internet-facing service, a major version upgrade, an authentication or network-segmentation change) so testing triggers are unambiguous. Track the annual cycle per system with a due date and run the next test before that date lapses, even when no change has occurred. Feed every finding into a tracked remediation backlog with severity ratings, and retest or revalidate fixed high and critical issues rather than closing them on assertion alone.
Implementation tips
- Add a mandatory gate to your release/go-live checklist that blocks deployment until a vulnerability assessment and a penetration test have been completed against the system, and record the scan date and test report reference against the deployment.
- Define and document criteria for a "significant change" (for example major version upgrades, new internet-facing exposure, authentication or network-segmentation changes) and wire those criteria into the change process so they automatically trigger a vulnerability assessment and penetration test before approval.
- Maintain a per-system register that records each system's deployment-test date and calculates the next annual due date, and schedule the next vulnerability assessment and penetration test to run before that date regardless of whether a change occurred.
- Run both test types for each trigger: use an authenticated vulnerability scanner to enumerate known weaknesses, and commission a penetration test that actively attempts to exploit them, so coverage is not limited to automated scanning.
- Scope each test against the real deployed configuration (production-equivalent build, exposed interfaces and integrations) so results reflect what actually goes live rather than a stripped-down test instance.
- Log every finding into a remediation tracker with a severity rating and owner, fix high and critical findings before go-live or within an agreed window for in-production systems, and retest or revalidate those fixes to confirm closure.
Audit / evidence tips
- For a system deployed since the last assessment, request the vulnerability assessment and penetration test records and confirm both were completed and dated before the system's production go-live date.
- Pick a significant change from the change register (such as a major upgrade or a new internet-facing service) and confirm a vulnerability assessment and penetration test were run against it before it was approved and pushed to production.
- Take a sample of in-production systems and confirm the most recent penetration test and vulnerability assessment for each are dated within the last 12 months, evidencing the at-least-annual requirement.
- Confirm both activity types are present for each trigger: a vulnerability assessment (scan-based weakness identification) and a penetration test (active exploitation attempt), not just one substituting for the other.
- Check the scope of each report covers the actual deployed system (hosts, interfaces, application) rather than a narrower or stale scope, so the test reflects what is in production.
Cross-framework mappings
How ISM-2118 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.8 | ISM-2118 requires vulnerability assessments and penetration tests prior to deployment/significant change and at least annually thereafter | |
E8
| Control | Notes | Details |
|---|---|---|
| sync_alt Partially overlaps (1) expand_less | ||
| E8-PA-ML2.1 | ISM-2118 requires vulnerability assessments and penetration tests to be performed prior to deployment (including significant changes) and... | |
| handshake Supports (2) expand_less | ||
| E8-PO-ML1.1 | ISM-2118 requires vulnerability assessments and penetration tests to be performed prior to deployment/significant change and at least ann... | |
| E8-PA-ML3.1 | ISM-2118 requires vulnerability assessments and penetration tests prior to deployment/significant change and at least annually thereafter | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.