ASD ISM 1633Determine System Boundary, Criticality and Security Objectives
Official 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.
Quoted as published. Everything else on this page is written by Control Stack.
In plain English
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.
What this means in practice
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 (Control Stack)
Proactive
Classifications
NC, OS, P, S, TS
ISM last updated
Mar 2026
Control Stack last updated
29 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for cyber security rolesSection
System ownersTopic
Protecting systems and their resources
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.Look atSystem security documentation, architecture diagrams and component or asset inventories.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.Look atBusiness impact assessment records and the recorded criticality rating.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.Look atSecurity objectives documentation and system authorisation records.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.Look atMeeting minutes, sign-off records or the system authorisation package.GoodRecords showing the authorising officer reviewed and approved each of these decisions.
- AskAsk when the boundary, criticality and objectives were last reviewed.Look atVersion history and review logs in the system security documentation.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(1)expand_less | ||
| Annex A 5.30 | ISM-1633 requires defining system boundaries, criticality and security objectives based on impact if compromised | |
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.