ASD ISM 0009 System owners identify supplementary controls with authorising officer
What it says
System owners, in consultation with each system's authorising officer, identify any supplementary security controls required based upon the unique nature of each system, its operating environment and the organisation's risk tolerances.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSystem owners, consulting the authorising officer, work out which extra security controls each system needs given its nature, its environment and how much risk the organisation will accept.
The baseline set of security controls in the ISM is written for systems in general. It cannot anticipate everything about a particular system: what it does, what data it holds, where it runs, who connects to it, and how much risk the organisation is prepared to carry for it. This control closes that gap. The system owner, who knows the system best, is responsible for identifying any supplementary security controls that the baseline does not already provide. They do this in consultation with the system's authorising officer, so that the person who will ultimately accept the system's residual risk has a say in what additional protection is needed. The statement names three inputs that should drive that identification: - **The unique nature of the system**, such as its purpose, the sensitivity of the information it handles, and its architecture or technology. - **Its operating environment**, such as physical location, network connectivity, exposure to external parties, and the wider systems it depends on. - **The organisation's risk tolerances**, meaning how much residual risk the organisation is willing to accept for a system of this kind. Why it matters: without this step, a system is protected only by generic controls and any threat specific to that system goes unaddressed. Involving the authorising officer early also means the eventual authorisation decision is informed by controls that were chosen deliberately rather than discovered as gaps at the end.
Free. Save your status, tasks and notes.
Why it matters
If system owners do not identify supplementary controls, systems are protected only by the generic baseline and threats specific to a particular system, its environment or its data go unmitigated. Residual risk can then exceed what the organisation is prepared to accept without anyone realising it. Where the authorising officer is not consulted, gaps tend to surface late, during authorisation, causing delays, rework or a system being authorised on an incomplete picture of its risk. In the worst case, a system-specific weakness that a tailored control would have addressed is exploited, leading to compromise of sensitive information or disruption of the service the system provides.
How to implement
System owners: assign yourself, or a named delegate with security expertise, responsibility for identifying supplementary controls for each system you own, and make it a standing step in the system's security assessment and authorisation process.
System owners: for each system, write a short profile covering the three inputs in the statement (the system's purpose, data sensitivity and technology; its operating environment including location, connectivity and external exposure; and the organisation's risk tolerance for that kind of system) and use it as the starting point for identifying supplementary controls.
System owners: compare the system profile against the baseline ISM controls already applied and, for any system-specific risk the baseline does not address, draft a supplementary control that would mitigate it, recording which of the three inputs drove the decision.
System owners: consult the authorising officer on the draft list of supplementary controls before finalising it, walk them through the reasoning for each control, and capture any changes or concerns raised so the final list reflects that consultation.
System owners: when a system or its operating environment changes materially, or at the system's next scheduled security review, revisit the supplementary controls with the authorising officer to confirm they remain appropriate.
Keep it running
In practice, identifying supplementary controls fits naturally into the system's security assessment and authorisation activities. The system owner (or a delegate with security expertise acting on their behalf) reviews the system against the three inputs in the statement, considers whether the baseline controls leave any system-specific risk unaddressed, and drafts the supplementary controls that would close those gaps. The system owner then consults the authorising officer on that draft, so the authorising officer understands the reasoning and can raise any concerns or expectations before the controls are settled.
Keeping a record of the identified supplementary controls, and the reasoning that connects each one to the system's nature, environment or the organisation's risk tolerances, makes the consultation easier and gives the authorising officer something concrete to review. It is good practice, though not required by the statement, to also note any candidate controls that were considered but not adopted, so the reasoning is not lost.
Because the inputs can change over time (for example, a system moving to a new hosting environment, being connected to a new external party, or starting to process more sensitive data), it is sensible to repeat the exercise when the system or its environment changes materially, and to revisit it as part of the system's normal life-cycle security reviews. Treat this as guidance on keeping the identified controls current rather than as a separate audited obligation.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask the system owner to walk through how supplementary security controls were identified for a sample system and who was involved.
Look at
Look for a documented list of supplementary controls for the system and for the system owner (or their delegate) as the person who identified them.
Good evidence
The system owner can explain the identified supplementary controls for the system and can point to a record of them.
- Check 2 of 5What an auditor asks for
Ask for
Ask for evidence that the authorising officer was consulted when the supplementary controls were identified.
Look at
Look for meeting notes, emails, review comments or sign-off showing the authorising officer saw the proposed supplementary controls and had the opportunity to comment.
Good evidence
There is a record showing the authorising officer was consulted on the supplementary controls before they were finalised.
- Check 3 of 5What an auditor asks for
Ask for
Ask how the unique nature of the system informed the supplementary controls that were identified.
Look at
Look for a description of the system's purpose, data sensitivity and technology, and for supplementary controls that respond to those characteristics.
Good evidence
The identified supplementary controls can be traced back to specific characteristics of the system rather than being generic.
- Check 4 of 5What an auditor asks for
Ask for
Ask how the system's operating environment was taken into account.
Look at
Look for consideration of factors such as physical location, network connectivity, external exposure and dependencies on other systems.
Good evidence
The supplementary controls reflect the actual environment the system operates in and address environment-specific risks.
- Check 5 of 5What an auditor asks for
Ask for
Ask how the organisation's risk tolerances influenced which supplementary controls were identified.
Look at
Look for an explanation, from the system owner or authorising officer, of how the organisation's appetite for residual risk on this system shaped the controls chosen.
Good evidence
The system owner and authorising officer can describe how risk tolerance informed the supplementary controls, and the controls are consistent with that account.
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: 1 mapping
This control partially overlaps A.6.2.2.
ISM-0009 requires system owners, with the authorising officer, to identify supplementary security controls based on the system's nature, operating environment and organisational risk tolerance. ISO/IEC 42001 Annex A 6.2.2 relates because specifying and documenting AI system requirements commonly includes identifying additional security controls needed for the AI system's context and risk profile. The overlap is that both drive context-specific control selection/definition, but Annex A 6.2.2 is AI-system requirements-focused while ISM-0009 is broader to any system and explicitly anchored to authorising officer consultation for supplementary controls.
ASD Essentials for enterprise IT: 1 mapping
- IT.GOV-03.1Assess and treat cyber security risks using an approved methodology and planPartially overlaps
This control partially overlaps IT.GOV-03.1.
IT.GOV-03.1 requires an approved risk management methodology and plan used to assess and treat cyber security risks; ISM-0009 is one treatment step, with system owners identifying supplementary controls for each system based on its nature, environment and organisational risk tolerances.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.