ASD ISM 1203 Risk assessment for system security
What it says
System owners, in consultation with each system's authorising officer, conduct a threat and risk assessment for each system.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSystem owners work with authorising officers to assess threats and risks for each system.
System owners need to collaborate with the person responsible for authorising each system to assess what might go wrong and how to protect each specific system. This matters because if you don't understand the unique risks each system faces, you could expose your organisation to data breaches, financial losses, or damage to your reputation.
Free. Save your status, tasks and notes.
Why it matters
Without a system-specific threat and risk assessment, owners may miss key threats and weaknesses, increasing likelihood of breach and disruption.
How to implement
System owners should consult with their authorising officer to define potential threats to each system.
They can do this by listing what valuable information the system holds and who might want access to it. This helps in considering various scenarios like data breaches or system failures.
System owners should organise a meeting with the authorising officer and relevant IT staff to discuss potential risks.
Begin by identifying any cases where similar systems have faced issues or breaches. Taking these examples can guide the conversation on possible weaknesses.
The IT team should assist system owners in documenting each identified risk.
Use a simple table or spreadsheet to categorise the types of risks, their potential impact, and how likely they are to happen. This documentation guides future security strategies.
Authorising officers should approve any decisions about risk mitigation strategies.
They can review the documented threats and proposed solutions, providing any additional insights or approvals needed before changes are implemented.
System owners must review the threat and risk assessment regularly, especially when there are changes like new software updates or shifts in how the system is used.
Scheduling these reviews twice a year ensures that the system remains protected against evolving threats.
Keep it running
Review the system threat and risk assessment with the authorising officer at least annually and after major changes; record risks, treatments and residual risk.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The system risk assessment report: Request to see the document that describes the potential threats for the system and the agreed plans to address them.
Look at
Specific entries regarding various risks, their likelihood, and mitigation strategies.
Good evidence
Includes a detailed table, endorsed by the authorising officer, showing thoughtful assessment and current risk status.
- Check 2 of 5What an auditor asks for
Ask for
Meeting notes from risk assessment sessions: Request notes or minutes from the meetings held to discuss system risks.
Look at
A list of attendees, discussion points, and completed actions. Good meeting notes will clearly show that the authorising officer and system owner have considered and recorded a varied range of risks.
- Check 3 of 5What an auditor asks for
Ask for
To see the schedule or log that tracks the regular review of risks.
Look at
Evidence of bi-annual or triggered reviews due to system changes. A robust log shows consistent and timely reviews with updates and changes to the risk management plan.
- Check 4 of 5What an auditor asks for
Ask for
Communication records between system owners and the authorising officer: Request emails or memos that show regular communication about system risks and their management.
Look at
Ongoing dialogue that indicates active risk monitoring and relationship maintenance. Good communication records will demonstrate proactive risk assessment culture.
- Check 5 of 5What an auditor asks for
Ask for
A copy of any changes made to systems post-risk assessment: Request change logs that document any modifications made to address identified risks.
Look at
Clear alignment between identified risks and implemented changes.
Good evidence
Change log will match risk assessment findings and actions taken, authorised by relevant parties.
Mappings
Closest match in ISO/IEC 27001: A.5.8, Information security in project management, which partially overlaps with this control.
ISO/IEC 27001: 2 mappings
This control partially overlaps A.5.8.
ISM-1203 requires system owners and authorising officers to conduct a threat and risk assessment for each system. Annex A 5.8 (Information security in project management) supports ISM-1203 by ensuring risk assessment activities are embedded into project delivery (e.g. new systems, major changes) so that threats/risks are assessed at appropriate points. Annex A 5.8 is broader across project governance, while ISM-1203 is specifically about conducting the system threat and risk assessment.
This control supports A.5.7.
ISM-1203 requires system owners, in consultation with the system's authorising officer, to conduct a threat and risk assessment for each system. Annex A 5.7 (Threat Intelligence Collection and Analysis) supports ISM-1203 by providing the threat information inputs needed to identify credible threat actors, attack methods, and likelihoods during the assessment. Annex A 5.7 focuses on collecting/analysing threat information, whereas ISM-1203 focuses on performing the system-specific risk assessment and documenting risk decisions.
ISO/IEC 42001: 2 mappings
This control partially overlaps A.5.4.
Annex A 5.4 (ISO/IEC 42001:2023) requires the organisation to assess and document potential impacts of AI systems on individuals and groups across the AI system life cycle. ISM-1203 requires system owners to conduct a threat and risk assessment for each system, which can include considering harms to people where those harms arise from cyber threats or security weaknesses in an AI-enabled system. The primary control is broader in impact type (including non-security and socio-technical impacts such as fairness, discrimination, autonomy, and wellbeing), while ISM-1203 is primarily focused on security threat/risk to the system and organisation.
This control partially overlaps A.5.5.
Annex A 5.5 requires the organisation to assess and document potential societal impacts of AI systems across the full AI system life cycle. ISM-1203 requires system owners to conduct a threat and risk assessment for each system, which can include consideration of harms arising from system use and misuse (including AI-enabled systems). The overlap is in structured assessment and documentation of impacts/risks, but ISM-1203 is focused on security threats and risks rather than broader societal impacts (e.g., fairness, human rights, social harm) required by Annex A 5.5.
ASD Essentials for enterprise IT: 3 mappings
- 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-1203 applies the assessment part, with system owners conducting a threat and risk assessment for each system in consultation with its authorising officer.
- IT.GOV-14.1Identify, assess and treat legacy system risks until removal or replacementPartially overlaps
This control partially overlaps IT.GOV-14.1.
IT.GOV-14.1 requires a process to identify, assess and treat cyber security risks from legacy systems and unsupported technologies; ISM-1203 supports the assessment step more broadly, with system owners conducting a threat and risk assessment for each system, legacy ones included.
- IT.IDE-04.1Feed continuously reviewed threat intelligence and weaknesses into risk assessmentsPartially overlaps
This control partially overlaps IT.IDE-04.1.
IT.IDE-04.1 requires risk assessments to consider relevant weaknesses, malicious actor techniques and threat behaviours, reviewed continuously; ISM-1203 requires the assessment those inputs feed, with system owners conducting a threat and risk assessment for each system.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.