The Australian Signals Directorate's Information Security Manual (ISM) is the control catalogue behind Australian Government system authorisations, IRAP assessments and the Essential Eight, yet many teams treat it as a static checklist rather than a risk framework that changes every quarter. This guide explains what the ISM is, who it binds and who merely uses it, how its applicability markings and six-step risk management framework work, and which controls matter most for identity, including the new AI agent, OAuth and workload credential controls in the September 2026 release. It is written for CISOs, system owners, IRAP-bound cloud and managed service providers and GRC teams. It goes deeper than the Australia IRAP Guide on the manual itself. Status line: checked on 27 October 2026 against the ISM September 2026 release (OSCAL catalogue version 2026.09.4, published 3 September 2026). This guide is not legal advice.
Key takeaways
- Advice, not law, unless something compels it: the ISM states that an organisation is not required as a matter of law to comply with it unless legislation, or a direction given under legislation or by another lawful authority, compels them.
- Two layers: 49 cyber security principles grouped into govern, identify, protect, detect, respond and recover, supported by roughly 1,140 security controls in 23 guideline chapters.
- Applicability markings drive scope: each control carries NC, OS, P, S and or TS markings, and ASD publishes baseline profiles for each, plus Essential Eight Maturity Level One to Three profiles.
- The risk framework is the real requirement: define, select, implement, assess, authorise and monitor, drawing from NIST SP 800-37 Rev. 2, ending in an authorisation to operate granted by the authorising officer.
- Non-human identity is now explicit: the identity controls apply to services, applications, workloads and AI agents, and September 2026 added an AI agent register, unique agent identities, OAuth consent controls and short-lived workload credentials.
Scope: who and what is covered
The ISM describes its purpose as outlining a cyber security framework that an organisation can apply, using its risk management framework, to protect IT and operational technology systems. Its intended audience is CISOs, CIOs, cyber security professionals and IT and OT managers. It represents the considered advice of ASD, provided under ASD's functions in the Intelligence Services Act 2001.
| Who | How the ISM reaches them | What to check |
|---|---|---|
| Australian Government entities | Through government protective security policy (the ISM refers readers to the Department of Home Affairs Protective Security Policy Framework) and system authorisation practice | Your entity's PSPF obligations and which ISM release it assesses against |
| Cloud service providers serving government | Control ISM-1570: outsourced cloud service providers and their NC, OS, P and S cloud services undergo an IRAP assessment at least every 24 months | IRAP assessment date and the ISM release used |
| Managed service providers | Control ISM-1793: MSPs and their managed services undergo an IRAP assessment at least every 24 months | Same as above, per managed service |
| Gateway operators | Control ISM-0100: NC, OS, P and S gateways undergo an IRAP assessment at least every 24 months | Gateway assessment cycle |
| Private sector and critical infrastructure | Voluntary use, contracts, or where a law or direction compels it; the ISM points to laws such as the Privacy Act 1988 and the Security of Critical Infrastructure Act 2018 as relevant context | Contract clauses that cite the ISM or Essential Eight |
The ISM also states that it does not override obligations imposed by legislation and that law takes precedence where they conflict. For the statutory regimes see the Australia SOCI Act Guide and the Australia Cyber Security Act 2024 Guide.
Applicability markings and baselines
| Marking | Meaning in the ISM | Baseline profile size (Sept 2026, principles plus controls) |
|---|---|---|
| NC | Non-classified systems, government and non-government | 1,066 |
| OS | OFFICIAL: Sensitive systems | 1,077 |
| P | PROTECTED systems | 1,077 |
| S | SECRET systems | 1,141 |
| TS | TOP SECRET systems | 1,150 |
| ML1, ML2, ML3 | Essential Eight maturity level tags on individual controls | ML2 profile: 87 controls |
Counts come from the ASD OSCAL profiles for the September 2026 release and will change with each release.
Key obligations
The ISM frames its principles as something an organisation "should be able to demonstrate" it adheres to, and its guidelines as practical support. In an authorisation or IRAP context the following are the obligations assessors look for first.
The six-step risk management framework
- Define the system: determine the system boundary, business criticality and security and resilience objectives from an impact assessment (ISM-1633), and record them in the system security plan (ISM-0041).
- Select security controls: select and tailor controls using the applicability markings (ISM-1634), document inherited controls, and have the selection approved by the authorising officer. The ISM says its controls are a baseline, not an exhaustive list, so you still do your own risk analysis.
- Implement: record any difference between planned and actual implementation in the system security plan annex.
- Assess: agree scope with the assessor, system owner and authorising officer; NC, OS, P and S systems may be assessed by the organisation's own assessors or IRAP assessors (ISM-1636), TOP SECRET by ASD assessors or delegates. Produce a security assessment report.
- Authorise: the authorising officer reviews the authorisation package (system security plan, incident response plan, change and configuration management plan, continuous monitoring plan, security assessment report, plan of action and milestones) and grants, constrains or refuses an authorisation to operate (ISM-0027). For NC to S systems the authorising officer is the organisation's CISO or delegate; for commercial providers it is the CISO of the supported organisation.
- Monitor: continuously monitor threats, risks and controls, and reassess after events such as major incidents, new threats or major architectural changes.
Governance principles that change behaviour
- GOV-01: the board of directors or executive committee is accountable for cyber security.
- GOV-08: the board or executive committee is accountable for ensuring artificial intelligence is secure, controllable, human-supervised and used ethically and accountably.
- GOV-02: a CISO provides leadership and regular risk-based reporting to the board.
- GOV-11: systems are delivered and supported by trustworthy suppliers whose practices are regularly independently verified or risk-assessed.
Incident reporting controls
ISM-0123 requires incidents to be reported to the CISO or a delegate as soon as possible, and ISM-0140 requires reporting to ASD as soon as possible after they occur or are discovered. The ISM's list of incident types to report includes suspicious privileged account lockouts, suspicious remote access authentication events and service accounts suspiciously communicating with internet-based infrastructure. ISM-1880 and ISM-1881 cover timely reporting to customers and the public.
Timeline and current status
| Item | Status at 27 October 2026 |
|---|---|
| Current release | ISM September 2026 (OSCAL catalogue version 2026.09.4, published 3 September 2026) |
| Release pattern | Control revision dates in the catalogue fall in March, June, September and December, consistent with quarterly updates |
| Machine-readable form | ASD publishes the ISM as an OSCAL catalogue with profiles for each applicability marking and for Essential Eight ML1 to ML3; a mirror is maintained on GitHub |
| IRAP assessments | Use the latest ISM release available before the assessment begins, or a subsequent release (ISM-1570, ISM-1793, ISM-0100) |
| New in September 2026 (identity) | ISM-2133 to ISM-2144, including AI agent identity and register, risk-based access, OAuth consent and device code controls, and application and workload credentials |
Track the release in your GRC tooling by importing the OSCAL catalogue rather than re-keying PDFs. See the OSCAL Guide.
Enforcement and penalties
The ISM itself carries no penalties. Consequences flow through other mechanisms:
- Authorisation: an authorising officer can grant an authorisation to operate with constraints, such as limited functionality or an expiry date, or revoke it if risks are no longer acceptable.
- IRAP outcomes: assessment reports record weaknesses and recommended remediation, which drive the plan of action and milestones and influence government buyers.
- Contracts and law: where a contract, legislation or a lawful direction requires the ISM, the penalty is whatever that instrument sets. Check those instruments directly.
What it means for AI agents and non-human identities
The ISM's identity and access management chapter now says plainly that controls for identifying, authenticating, authorising and monitoring users also apply to non-human users, such as services, applications, workloads and AI agents. The September 2026 release turned that into specific controls.
| Control | Requirement (paraphrased from the ISM) | Practical evidence |
|---|---|---|
| ISM-2133 | Each AI agent has a unique identity distinct from personnel accounts and from other agents | Directory or IdP objects per agent; no agents running as a human user |
| ISM-2134 | An AI agent register is developed, implemented, maintained and regularly verified | Register with last-verified date |
| ISM-2135 | The register records each agent's unique identifier, owner and business purpose, identities, user accounts and credentials, and the tools, permissions and data repositories it can access | Register fields populated for 100% of agents |
| ISM-2136 | Risk-based access decisions, informed by contextual signals, are enforced | Conditional access policies |
| ISM-2137, 2138 | Only authorised administrators grant consent to third-party OAuth applications; consents reviewed at least every six months | Consent settings, review records, revocations |
| ISM-2139, 2140 | OAuth consent, token issuance and use centrally logged; device code flow disabled unless required | SIEM data source, policy screenshot |
| ISM-2141 to 2143 | Workloads prefer short-lived dynamically issued credentials; static credentials centrally managed in a secrets solution; credentials unique per workload and environment | Secrets manager inventory, federation configuration |
| ISM-2144 | Static workload credentials changed if compromised, suspected compromised, or found stored or transmitted in the clear | Rotation runbook, secret-scanning alerts |
The ISM also says identities assigned to AI agents should be managed like service accounts, including being disabled or removed when no longer required, and that all identities of an agent across environments should be recorded in the register. Older controls still apply to machine accounts: ISM-1940 keeps service accounts out of Domain Admins, Enterprise Admins and other highly privileged groups, ISM-1932 minimises service accounts with an SPN, and ISM-1955 changes computer account credentials at least every 30 days. See the Agent Identity and Access Guide and the Secrets Management Guide.
Human identity controls assessors test first
- MFA: ISM-1504 and ISM-1679 require MFA for human users of the organisation's and third-party online services holding sensitive data; ISM-1173 and ISM-0974 cover privileged and unprivileged users of systems; ISM-1872 requires phishing-resistant MFA for online services. See the Phishing-Resistant MFA Guide.
- Privileged accounts: ISM-0445 dedicated privileged accounts, ISM-1175 no internet, email or web access, ISM-1648 disable after 45 days inactivity, ISM-1647 disable after 12 months unless revalidated, ISM-1898 Secure Admin Workstations (ML3).
- Leavers: ISM-0430 removes or suspends access the same day it is no longer needed.
Compliance steps
- Classify each system and pick the matching baseline (NC, OS, P, S or TS) plus your Essential Eight target level.
- Import the OSCAL catalogue and profile for the current release into your GRC tool so control IDs and revision dates stay accurate.
- Tailor: mark each control as implemented, inherited (for example from an IRAP-assessed cloud provider), not applicable with reasons, or risk-accepted.
- Build the authorisation package listed in step 5 of the framework.
- Assess with internal assessors or an IRAP assessor; for IRAP-bound services, schedule within the 24-month cycle.
- Diff each new release: filter for controls with the latest revision date and route new ones, such as ISM-2133 to ISM-2144, to owners within the quarter.
- Monitor continuously and reassess on the trigger events the ISM lists.
Small versus large organisations: a small supplier can start from the NC baseline and Essential Eight ML2 profile and inherit heavily from assessed cloud services. A large agency needs per-system security plans, a release-diff process and named authorising officer delegates. See the Essential Eight Guide.
Mapping to other frameworks
| ISM element | Closest equivalent |
|---|---|
| Six principle functions (govern to recover) | NIST CSF 2.0 functions GV, ID, PR, DE, RS, RC |
| Risk management framework steps | NIST SP 800-37 Rev. 2 RMF, which the ISM says it draws from |
| MFA and privileged access controls | NIST SP 800-53 IA-2 and AC-6 |
| Workload credential controls | NIST SP 800-53 IA-5 |
Measuring it
- Percentage of applicable controls with current evidence per system.
- Days from a new ISM release to triage of new controls.
- AI agents in the register versus agents discovered in IdP and platform logs.
- Share of workload credentials that are short-lived or federated.
- OAuth consent reviews completed on the six-month cycle.
Common failure patterns
- Assessing against a stale release: IRAP controls require the latest release available before the assessment starts.
- Treating the baseline as the ceiling: the ISM says its controls are not exhaustive and you must still analyse your own risks.
- Agents running on borrowed identities: agents using a developer's account break ISM-2133 and make actions unattributable.
- Unreviewed OAuth grants: the ISM notes that consented tokens can survive credential resets; stolen integration tokens drove the Salesloft Drift breach.
- Inheritance without evidence: claiming cloud controls as inherited without the provider's IRAP report scope.
Practitioner checklist
- Record the ISM release and baseline used for each system.
- Import the September 2026 OSCAL catalogue and profiles into GRC tooling.
- Stand up an AI agent register meeting ISM-2135 fields and verify it regularly.
- Give every agent and workload its own identity; remove agents running under human accounts.
- Restrict OAuth consent to administrators and review grants every six months.
- Move workloads to short-lived credentials and vault the remaining static secrets.
- Confirm phishing-resistant MFA for online services and privileged users.
- Check IRAP dates for every cloud, MSP and gateway dependency against the 24-month cycle.
- Build a quarterly release-diff routine with named control owners.
Standards and references
- Australian Signals Directorate: ISM OSCAL (Information security manual in OSCAL)
- Australian Signals Directorate: Information security manual catalogue, September 2026
- Australian Signals Directorate: ISM PROTECTED baseline profile
- Australian Signals Directorate: ISM Essential Eight Maturity Level Two baseline profile
- NIST: SP 800-37 Rev. 2 Risk Management Framework for Information Systems and Organizations
Related NHI Mgmt Group resources: Australia IRAP Guide · Essential Eight Guide · Agent Identity and Access Guide · OSCAL Guide. This guide summarises the Australian Information Security Manual and is not legal advice.