Develop, Implement and Maintain a Security Monitoring Policy
A security monitoring policy must be developed (written down), implemented (actually put into practice), and maintained (kept current over time). The policy sets out how your organisation watches its systems, networks and accounts for signs of security problems, such as unauthorised access, malicious software, or unusual activity. The Information Security Manual (ISM) is the Australian Signals Directorate (ASD) cyber security guidance this control comes from. A monitoring policy turns ad hoc, occasional checking into a deliberate, documented practice so that suspicious events are noticed, recorded and acted on rather than slipping past unseen.
Plain language
Think of a security monitoring policy as the written instructions for keeping a constant watch over your computer systems. It is not enough to simply say "we keep an eye on things". This control asks for three connected things. First, the policy must be **developed**: written down as a clear document that says what gets monitored, why, and who is responsible. Second, it must be **implemented**: the monitoring described in the policy must actually happen in real life, not just exist on paper. Third, it must be **maintained**: the policy must be reviewed and kept up to date as your systems, staff and threats change, so it does not become stale and inaccurate. If any one of these three is missing, the control is not met. A polished document that nobody follows fails just as surely as good monitoring that was never written down.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
June 2026
Control Stack last updated
18 June 2026
E8 maturity levels
N/A
Official control statement
A security monitoring policy is developed, implemented and maintained.
Why it matters
Without a developed, implemented and maintained monitoring policy, suspicious activity goes unnoticed and inconsistently handled, letting breaches spread undetected.
Operational notes
Treat the policy as a living document: review it at least yearly and after major system changes so what is written still matches what is actually monitored.
Implementation tips
- Senior management or the security manager owns the security monitoring policy and signs it off, so it has clear authority and a named owner who is accountable for keeping it current.
- The policy author writes the document so it states exactly what is monitored (for example systems, networks, user accounts and security events), why each is monitored, who performs the monitoring, and how often, using plain language anyone can follow.
- The IT or security team implements the policy by setting up the actual monitoring described in it, then keeps records showing the monitoring is genuinely running and not just described on paper.
- Assign a regular review cycle, for example every twelve months or after any major system change, and have the owner update the policy so it stays accurate as systems and threats evolve.
- Store the approved policy in a central, accessible location and record each version with its approval date and reviewer, so anyone can confirm it is the current, maintained version.
Audit / evidence tips
- AskCan you show me your documented security monitoring policy?Look atA formally written and approved document, not informal notes or a verbal descriptionGoodAn approved policy with a named owner, an approval date, and a clear scope of what is monitored
- AskHow is the policy actually put into practice day to day?Look atEvidence that the monitoring described in the policy is genuinely happeningGoodMonitoring records, logs or dashboards that match what the policy says should be monitored
- AskWhen was the policy last reviewed and updated?Look atA version history or revision date showing recent reviewGoodA documented review within the last twelve months, or after the most recent significant system change
- AskWho is responsible for developing, implementing and maintaining this policy?Look atA clearly named role or person, not 'everyone' or 'no one in particular'GoodA specific owner such as the security manager who can describe their responsibilities
- AskHow do you make sure the policy stays accurate as systems change?Look atA defined review trigger or scheduleGoodA scheduled review cycle plus a rule to update the policy after major changes, with evidence it has been followed
Cross-framework mappings
How ISM-0580 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(2)expand_less | ||
| Annex A 5.28 | ISM-0580 requires an organisation to develop, implement and maintain an event logging policy to ensure events are recorded and monitored | |
| Annex A 8.15 | ISM-0580 requires an organisation to develop, implement and maintain an event logging policy to ensure events are recorded and monitored | |
E8
| Control | Notes | Details |
|---|---|---|
handshakeSupports(10)expand_less | ||
extensionDepends on(4)expand_less | ||
ISO 42001
| Control | Notes | Details |
|---|---|---|
handshakeSupports(1)expand_less | ||
| Annex A 6.2.8 | Annex A 6.2.8 requires the organisation to decide during which AI system life cycle phases event logging is enabled (at minimum during use) | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in Security assurance
See all Guidelines for security assurance controls, or browse the full ASD ISM library.