ASD ISM 0041 Maintain a system security plan with overview and controls annex
What it says
Systems have a system security plan that includes an overview of the system (covering the system's purpose, the system boundary and how the system is managed) as well as an annex that covers applicable security controls from this document and any additional security controls that have been identified and implemented.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEvery system needs a written security plan describing what it is for, where it starts and ends, who runs it, and an annex listing the ISM controls and any extra controls in place.
This control requires each system to have a system security plan (SSP). The plan has two parts. The first is an overview of the system: what the system is for, where its boundary sits (which components, networks, data and interfaces are inside it and which are outside) and how the system is managed (who owns it, who operates it and how it is administered). The second is an annex that lists the security controls from the ISM that apply to the system, together with any additional security controls the organisation has identified and put in place beyond the ISM. It matters because without a plan nobody can say with confidence what a system actually consists of or what protects it. Assessors, system owners and authorising officers all rely on the SSP to understand scope and to check that the right controls exist. A system without a clear boundary tends to accumulate undocumented components and connections, and a system without a controls annex tends to have gaps that nobody notices until an incident or an assessment exposes them.
Free. Save your status, tasks and notes.
Why it matters
Without a system security plan, the organisation cannot demonstrate what the system is, where it ends or which controls protect it. Authorisation decisions are made on incomplete information, security assessments become guesswork, applicable ISM controls are missed or assumed to be in place when they are not, and undocumented components or connections drift outside anyone's oversight, leaving exploitable gaps.
How to implement
The system owner assigns an author for the SSP and adopts a standard template with two mandatory parts: a system overview and a security controls annex.
The system owner and architect write the overview section, stating the system's purpose, defining the system boundary (components, networks, data flows and interfaces in and out of scope, ideally with a boundary diagram) and describing how the system is managed, including ownership, operational roles and administration arrangements.
The security team builds the controls annex by working through the current ISM and recording each applicable control, its identifier and how it is implemented in this system.
The security team and system owner identify any additional security controls that have been implemented beyond the ISM (for example from a risk assessment or contractual requirement) and record them in the annex alongside the ISM controls.
The system owner places the SSP under document control with a version number, review schedule and change log, and updates it whenever the system's purpose, boundary, management arrangements or implemented controls change or a new ISM release is published.
Keep it running
In practice the SSP is a living document owned by the system owner and maintained by the people who run the system. The overview section is usually short and stable, but it must be revisited whenever the system's purpose changes, its boundary shifts (new components, interconnections or hosting arrangements) or management responsibilities move between teams or suppliers.
The controls annex takes more ongoing effort. It should be built from the current ISM release, listing each applicable control and how it is implemented, and it should also capture any additional controls the organisation has identified and implemented for that particular system. When the ISM is updated, the annex needs a review so that new, changed or withdrawn controls are reflected. Many organisations manage the annex as a structured register or spreadsheet referenced from the SSP so it can be updated without rewriting the whole plan.
Keep the SSP under version control with a clear owner, review date and change history, and make sure the version used for assessment and authorisation is the same one the operational team is working from.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the current, approved system security plan for the system in scope.
Look at
Check that the document exists, is version-controlled, names an owner and covers the system being assessed rather than a generic template.
Good evidence
A dated, approved SSP specific to the system, with a version history and a named system owner.
- Check 2 of 5What an auditor asks for
Ask for
Ask where the plan describes the system's purpose.
Look at
Read the overview section for a clear statement of what the system does and what business function it supports.
Good evidence
A concise purpose statement that matches how the system is actually used.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the system boundary definition.
Look at
Look for a description or diagram showing which components, networks, data and interconnections are inside the boundary and which are outside, and compare it with the deployed environment.
Good evidence
A boundary that is unambiguous and consistent with the real architecture, with external connections clearly identified.
- Check 4 of 5What an auditor asks for
Ask for
Ask how the plan describes the way the system is managed.
Look at
Check the overview for ownership, operational and administrative roles and any outsourced or shared management arrangements.
Good evidence
Named roles or teams responsible for owning, operating and administering the system, matching the organisation's actual arrangements.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the security controls annex.
Look at
Confirm the annex lists the applicable ISM controls with their implementation, references the current ISM release, and also records any additional controls the organisation has identified and implemented.
Good evidence
A complete annex that maps each applicable ISM control to its implementation and includes any extra controls, with evidence it was reviewed after the latest ISM update.
Mappings
Closest match in ISO/IEC 42001: A.6.2.2, AI system requirements and specification, which partially overlaps with this control.
ISO/IEC 42001: 2 mappings
This control partially overlaps A.6.2.2.
Annex A 6.2.2 requires documented requirements/specifications for new or materially enhanced AI systems. ISM-0041 requires a system security plan describing the system purpose, boundaries, management approach, and applicable controls. They overlap because AI system specifications inform the system security plan, particularly for security, boundaries, and control selection. ISM-0041 covers security planning for any system, while Annex A 6.2.2 focuses on broader AI system requirements.
This control partially overlaps A.6.2.3.
Annex A 6.2.3 requires the organisation to document AI system design and development based on organisational objectives, documented requirements and specification criteria. ISM-0041 requires a system security plan that documents the system's purpose, boundary, management approach and the set of applicable controls, which for AI-enabled systems will rely on or reference key AI design artefacts (e.g. architecture, data flows, component boundaries) to define the security boundary and control applicability. The overlap is limited to system description/architecture documentation used for security planning; Annex A 6.2.3 is broader because it requires design and development documentation beyond security planning (e.g. model design choices, training approach, evaluation criteria).
ASD Essentials for enterprise IT: 1 mapping
- IT.PRO-01.1Design systems with telemetry, least privilege, data protection and minimal attack surfacePartially overlaps
This control partially overlaps IT.PRO-01.1.
IT.PRO-01.1 requires secure system design that enforces authorised access, protects data, minimises privileges and limits exposed services; ISM-0041 documents it, requiring a system security plan covering each system's purpose, boundary, management and applicable security controls.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.