ASD ISM 1633Determine System Boundary, Criticality and Security Objectives
System owners, in consultation with the authorising officer, must define each system's boundary, business criticality, and security and resilience objectives based on an assessment of compromise impact.
Plain language
This control ensures every system has a clearly defined scope and agreed goals for how well it must be protected and how quickly it must recover. System owners work with the authorising officer to set each system's boundary, decide how important it is to the business, and agree its security and resilience objectives. These decisions are grounded in an honest assessment of the harm that would result if the system were compromised or attacked, so protection effort matches the real stakes.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Mar 2026
Control Stack last updated
10 Aug 2026
E8 maturity levels
N/A
Guideline
Guidelines for cyber security rolesSection
System ownersOfficial control statement
System owners, in consultation with each system's authorising officer, determine the system boundary, business criticality, and security and resilience objectives for each system based on an assessment of the impact if it were to be compromised or attacked.
Why it matters
Without agreed boundaries, criticality ratings and objectives, protection effort becomes misaligned with business impact, leaving high-value systems under-protected and security decisions unaccountable.
Operational notes
Revisit each system's boundary, criticality and objectives whenever the system changes materially so they stay aligned with current business impact.
Implementation tips
- System owners should document a clear system boundary that lists every component, interface and data flow that is part of the system, so its scope is unambiguous.
- Run a business impact assessment for each system that estimates the operational, financial and reputational harm of it being compromised or taken offline, and use the results to rate its business criticality.
- Hold a working session with the authorising officer to agree and formally sign off each system's security and resilience objectives before the system is authorised to operate.
- Translate the agreed objectives into measurable targets, such as required protection levels, tolerable downtime and recovery time objectives, and record them in the system security documentation.
- Re-run this boundary, criticality and objectives exercise whenever a system changes significantly or at scheduled reviews, keeping the authorising officer involved each time.
Audit / evidence tips
- AskAsk the system owner to show the documented system boundary for a selected system.GoodA current, dated boundary definition listing components, interfaces and data flows, approved by the system owner.
- AskAsk how the system's business criticality rating was determined.GoodA completed impact assessment that links the criticality rating to specific consequences of the system being compromised or attacked.
- AskAsk to see the agreed security and resilience objectives for the system.GoodDocumented objectives covering both security and resilience, formally endorsed by the authorising officer.
- AskAsk for evidence that the authorising officer was consulted in setting the boundary, criticality and objectives.GoodRecords showing the authorising officer reviewed and approved each of these decisions.
- AskAsk when the boundary, criticality and objectives were last reviewed.GoodEvidence of periodic review, with updates that reflect significant changes to the system.
Cross-framework mappings
How ISM-1633 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
handshakeSupports(4)expand_less | ||
| Annex A 5.15 | ISM-1633 requires system owners and authorising officers to determine the system boundary, business criticality and security objectives b... | |
| Annex A 5.30 | ISM-1633 requires defining system boundaries, criticality and security objectives based on impact if compromised | |
| Annex A 7.1 | ISM-1633 requires the organisation to determine the system boundary and security objectives based on compromise impact | |
| Annex A 8.22 | ISM-1633 requires determining system boundaries and security objectives in line with impact of compromise | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in Cyber security roles
See all Guidelines for cyber security roles controls, or browse the full ASD ISM library.