Skip to content
arrow_back
policyASD Information Security Manual (ISM)

ASD ISM 0009System Owners Identify Supplementary Controls With Authorising Officer

Official control statement

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.
policyASD Information Security Manual (ISM)ISM-0009

Quoted as published. Everything else on this page is written by Control Stack.

In plain English

System 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.

NCOSPASD Information Security ManualGuidelines for cyber security roles
record_voice_over

What this means in practice

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.

Framework

ASD Information Security Manual (ISM)

Control effect (Control Stack)

Proactive

Classifications

NC, OS, P, S, TS

ISM last updated

Sept 2026

Control Stack last updated

29 Sept 2026

E8 maturity levels

N/A

Topic

Protecting systems and their resources

priority_high

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.

settings

Operational notes

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.

build

Implementation tips

  • 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.
fact_check

Audit / evidence tips

  • AskAsk the system owner to walk through how supplementary security controls were identified for a sample system and who was involved.Look atLook for a documented list of supplementary controls for the system and for the system owner (or their delegate) as the person who identified them.GoodThe system owner can explain the identified supplementary controls for the system and can point to a record of them.
  • AskAsk for evidence that the authorising officer was consulted when the supplementary controls were identified.Look atLook for meeting notes, emails, review comments or sign-off showing the authorising officer saw the proposed supplementary controls and had the opportunity to comment.GoodThere is a record showing the authorising officer was consulted on the supplementary controls before they were finalised.
  • AskAsk how the unique nature of the system informed the supplementary controls that were identified.Look atLook for a description of the system's purpose, data sensitivity and technology, and for supplementary controls that respond to those characteristics.GoodThe identified supplementary controls can be traced back to specific characteristics of the system rather than being generic.
  • AskAsk how the system's operating environment was taken into account.Look atLook for consideration of factors such as physical location, network connectivity, external exposure and dependencies on other systems.GoodThe supplementary controls reflect the actual environment the system operates in and address environment-specific risks.
  • AskAsk how the organisation's risk tolerances influenced which supplementary controls were identified.Look atLook 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.GoodThe system owner and authorising officer can describe how risk tolerance informed the supplementary controls, and the controls are consistent with that account.
link

Cross-framework mappings

How ISM-0009 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.

ISO 42001

ControlNotesDetails
sync_altPartially overlaps(1)expand_less
Annex A 6.2.2ISM-0009 requires system owners, with the authorising officer, to identify supplementary security controls based on the system's nature, ...

These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.

See all Guidelines for cyber security roles controls, or browse the full ASD ISM library.

Mapping detail

Mapping

Direction

Controls