ISM Guide

The Information Security Manual (ISM) is the Australian Government's comprehensive record of everything you must do to your systems before ASD will consider trusting you near government information. It is published by the Australian Signals Directorate (ASD), a statutory agency established under the Australian Signals Directorate Act 2018, responsible for signals intelligence, offensive and defensive cyber operations, and periodically reminding the rest of the public sector that patching is still important.

The ISM defines over 1,000 security controls — specific requirements that Commonwealth agencies and their ICT suppliers must implement. Each control represents a concrete security measure, derived from either genuine threat intelligence or the accumulated scar tissue of a decade of incidents. In practice, both.

Who it applies to: Commonwealth entities under the PGPA Act must use the ISM as the foundation of their Information Security program. It also extends to contractors and cloud providers handling government information — on the basis that if the government is going to trust you with its data, it would like confirmation that you have enabled multi-factor authentication first. State governments and critical infrastructure operators increasingly reference it as well.

Update cadence: Approximately quarterly. Each release carries a version string such as ISM-2025-01. Controls are added, modified, and occasionally withdrawn. The important ones are usually modified. The compliance work is, by design, never finished.

The authoritative source is asd.gov.au/ism. This site republishes the data for convenience — always verify against ASD for anything that matters.

The ISM is organised into a three-level hierarchy:

• Guidelines — broad chapter headings covering topics like networking, cryptography, and personnel security. Note: "guideline" does not mean optional. These are mandatory requirements. The name is doing significant work. There are approximately 20 guidelines, and none of them are more what you'd call guidelines than actual rules.
• Sections — sub-topics within each guideline. Each section includes a brief overview that explains what the section covers, which is useful the first time you read it.
• Controls — the actual requirements. Over 1,000 of them, each with a permanent numeric ID that is never reused, an applicability marking, and a statement specifying what must be done.

Anatomy of a control: Each control has:

• ID — e.g. ISM-1173. Permanent. Never recycled. This level of numbering discipline is, in context, noteworthy.
• Statement — what must be implemented. The language is consistently "…is implemented" or "…are used." Not "is considered" or "should be explored." Implemented.
• Applicability — classification levels the control applies to. Higher levels accumulate requirements from lower levels.
• Revision history — recorded when a control's statement or applicability changes. This site tracks every revision back to 2010, for those who enjoy watching requirements evolve over a decade.

Control lifecycle: Controls are introduced as new, updated as modified, or removed as withdrawn. Withdrawn controls remain in the catalog because somewhere, someone will need to explain to an auditor why the 2015 version said something different.

Each control specifies which classification levels it applies to. The current Australian Government protective security scheme has five levels — think of them as a ladder where each rung adds more controls and removes more suppliers:

Controls are cumulative: PROTECTED systems must meet NC and OFFICIAL:Sensitive controls in addition to their own. The higher you go, the more you inherit. This is the information security equivalent of not being allowed to skip levels.

The ISM contains over 1,000 controls. The Essential Eight is ASD's acknowledgement that this is a lot, and that most organisations are better served by doing eight things well than a thousand things approximately. It is a prioritised set of mitigation strategies selected because the evidence says they stop the most common attacks.

The fact that strategy three is "Configure Microsoft Office Macro Settings" is a data point about the Australian threat landscape. That data point is not flattering. Macro-based malware has been a viable vector for a very long time. It continues to work.

Maturity levels: ML1, ML2, and ML3 — representing progressively stronger implementation. ML1 is the minimum. ML3 is what you aim for once you have time, budget, and executive support, ideally in that order. ASD recommends at least ML2, which translates roughly to "please do more than the bare minimum."

Maturity levels are defined in ASD's Essential Eight Maturity Model and map to specific ISM controls. The mappings are shown in the Explorer's right panel — the maturity grid and E8 strategy pills on each control detail.

Finding E8 controls on this site: Use the ML1 / ML2 / ML3 filter pills in the Explorer sidebar. The right panel on any selected control shows its maturity level mapping and which strategy it belongs to.

IRAP — the Information Security Registered Assessors Program — is an ASD-administered scheme for assessing ICT systems against the ISM. IRAP assessors are independent security professionals who have been vetted, trained, and endorsed by ASD. They have read the ISM. Professionally. This is how they make their living, and they have chosen to continue doing it.

Why IRAP matters: Systems handling OFFICIAL:Sensitive and above information require an IRAP assessment as part of obtaining an Authority to Operate (ATO) — the document that authorises a system to operate. The ATO is signed by the Authorising Officer, who accepts residual risk on behalf of the agency. The Authorising Officer is the person who has been persuaded that the benefits of the system outweigh the documented risks. Cloud providers seeking to host government workloads must also hold a current IRAP assessment, because the government would like to know you have done the work before it hands you its data.

Assessment types:

• Informal / advisory assessment — a gap analysis. Identifies where you stand relative to where you need to be. Useful for remediation planning. Does not produce an ATO-ready artifact. Think of it as a practice run where the examiner tells you your answers.
• Formal / compliance assessment — a full evidence-based evaluation against a defined ISM control set. Produces a Security Assessment Report (SAR) that informs the ATO decision. At no stage in this process does anyone claim it is enjoyable.

What an assessment covers:

• System boundary definition — agreeing on what is in scope. This sounds straightforward and reliably takes longer than expected.
• Threat modelling — identifying who might attack the system, how, and what they are after. The honest answer is usually "most actors, many vectors, all data."
• Security documentation review — the SSP, SRMP, Incident Response Plan, and related artifacts. The documentation describes what you claim the system does. The rest of the assessment verifies whether this is accurate.
• Control evaluation — testing and evidence review for each applicable ISM control. Each control is assessed as implemented, partially implemented, or not implemented. "Partially implemented" is the most common outcome and the one that generates the most remediation actions and follow-up meetings.
• Residual risk statement — risks that remain after controls are applied. This is the part the Authorising Officer reads most carefully, because they are the ones signing off on it.

ASD publishes the IRAP Common Assessment Framework (April 2025) to ensure consistency across assessors and engagements — because when everyone is reading the same document, it helps if they agree on what it means.