ISO 42001 Risk Assessment: A Practical Guide
AI adoption creates responsibilities for AI governance that extend beyond protecting information and maintaining system availability. An ISO 42001 risk assessment helps your organisation identify potential failures, assess their consequences and agree proportionate controls.
The priority is traceable decision-making: understanding what could go wrong, who could be affected and why a treatment is appropriate. Assessment methods and risk criteria should reflect your organisation's role, objectives and operating context.
Start by distinguishing the different assessments within your artificial intelligence management system (AIMS).
Key Takeaways
An ISO 42001 risk assessment should connect AI system risks with wider organisational risks, while keeping the separate AI system impact assessment focused on effects on individuals, groups and society.
Define your AIMS scope, your organisation’s role and responsibilities, and a usable inventory of AI systems before assessing risks across the full lifecycle.
Set risk criteria that reflect your context, record evidence and uncertainty, and link each risk to an accountable treatment, selected controls and approval of residual risk.
Keep assessments traceable and current by retaining supporting evidence and reassessing when systems, suppliers, data, users or operating conditions change.
What an ISO 42001 risk assessment covers
ISO/IEC 42001:2023 provides a framework for establishing, maintaining, and improving an AIMS. Its planning structure distinguishes AI risk assessment, risk treatment, and assessment of AI system impacts.
Organisational risks and AI system risks
Clause 6.1.2 covers ISO 42001 risk assessment. System-level risks include unreliable outputs, inappropriate data, security weaknesses, and ineffective human oversight.
Broader organisational risks include unclear accountability, insufficient competence, supplier dependency, and failure to meet contractual or legal obligations. These can affect several systems simultaneously.
Connect both levels. A model's unreliable output might expose an operational process to failure, whilst weak approval arrangements could allow unsuitable models into production.
AI system impact assessment
Clause 6.1.4 covers a separate, documented AI system impact assessment of effects on individuals, groups, and society. Consider discrimination, bias and fairness, privacy intrusion, barriers to accessing services, and other foreseeable consequences.
These assessments inform one another, but serve different purposes. Advisera's ISO 42001 overview also distinguishes risk assessment, treatment, and impact assessment.
An adverse impact can matter even when the organisation faces little financial loss. Record affected stakeholders rather than assessing consequences solely through business exposure.
Define your AI role and assessment scope
A useful assessment starts with a clear boundary. Define the scope of assessment by identifying the activities, teams, systems, and business processes covered by your AIMS.
Establish your responsibilities
Determine whether your organisation develops, provides, integrates, or uses AI, including third-party AI. Your AI governance responsibilities depend on your role and degree of control.
A developer can examine training data and model development directly. A user may rely on supplier documentation, configuration choices, contractual commitments, and operational monitoring.
Using third-party AI doesn't remove responsibility for its application within your business. Document what your organisation controls and where supplier assurance is necessary.
Check legal obligations separately. Whether the EU AI Act applies depends on your organisation and the system, not on ISO/IEC 42001.
Build a usable system inventory
Record each system's purpose, owner, deployment status, users, data sources, dependencies, and intended operating conditions. Include material supplier components and interfaces.
Assess the surrounding process as well as the model. Data collection, user instructions, escalation routes, and retirement arrangements can introduce risk.
The scope and certification guidance from Modulos connects scope with assessment and control applicability. Document scope decisions and explain exclusions.
Use this inventory to populate your risk register and prioritise assessment effort according to potential harm, operational importance, and uncertainty.
Identify AI risk scenarios across the lifecycle
Risk identification should cover every stage of the AI lifecycle: development, validation, deployment, operation, change and retirement. Bring together technical staff, business owners, security, privacy, legal and relevant stakeholder representatives.
Examine data and model behaviour
Review data provenance, representativeness, permitted uses, quality and access as part of data governance. Assess bias and fairness in relation to the system's purpose and affected populations.
Examine unreliable outputs, limited explainability and transparency, model drift, and performance outside tested conditions. For generative AI, consider prompt injection, sensitive information disclosure and unsupported answers. Evaluate safety and reliability against the system's intended use.
Record each scenario in the risk register, linking its cause to a potential failure and its consequences. Add an owner and practical control, as broad entries such as "AI bias" don't give control owners enough information to act.
Examine organisational and human factors
Check whether users understand system limitations, can challenge outputs and have authority to intervene. Human oversight needs workable procedures, training and escalation routes.
Review ownership, supplier changes, incident reporting, regulatory obligations and commercial dependency. Assess whether service interruption or model withdrawal would disrupt essential processes.
Existing ISO 27001 risk management support can strengthen security foundations. However, confidentiality, integrity and availability assessments alone won't capture every fairness, safety or societal concern.
A technically secure system can still produce unsuitable decisions.
Use STRIDE to examine technical threats
STRIDE is an optional threat modeling method, not an ISO/IEC 42001 requirement. It covers spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. It can complement guidance such as the NIST AI RMF, but ISO/IEC 42001 doesn’t require either.
Apply it to a data-flow diagram covering inputs, model services, retrieval sources, APIs, users, and downstream actions. Identify trust boundaries before discussing threats.
Link findings to treatment decisions and relevant entries in your risk register:
Examine tampering with training data or retrieval content, then consider provenance checks, access restrictions, and change approvals.
Assess information disclosure through prompts, outputs, and logs, with data minimisation and output testing as possible treatments.
Review excessive permissions for AI-enabled tools, then restrict service identities and require approval for sensitive actions.
These are implementation examples, not prescribed controls. Select measures according to the assessed scenario and operating environment.
STRIDE won’t provide a complete assessment of discrimination, explainability and transparency, or societal impact. Combine technical threat modelling with stakeholder analysis and system impact assessment.
Retain the diagram, assumptions, identified threats, and associated risk references so reviewers can understand the assessment boundary.
Set risk criteria appropriate to your organisation
An ISO 42001 risk assessment needs consistent evaluation, but consistency doesn't require a universal scoring formula. Define risk criteria to suit your systems, sector, obligations, and available evidence.
Consider financial, operational, legal, safety, privacy, and stakeholder consequences. Explain how likelihood and consequence will be evaluated when incident history is limited.
This illustrative scale can support discussion, but isn't a requirement of the standard.
Rating | Likelihood description | Impact description |
|---|---|---|
1 | Unlikely under assessed conditions | Limited, readily recoverable effects |
2 | Possible under unusual conditions | Contained disruption or harm |
3 | Plausible during normal operation | Material disruption or stakeholder harm |
4 | Likely without stronger controls | Serious harm or major business disruption |
5 | Expected or already recurring | Severe harm or sustained disruption |
Define these descriptions more precisely for your context. A healthcare deployment and an internal drafting assistant need different consequence criteria.
You can multiply likelihood and impact to support prioritisation. Set acceptance and escalation thresholds separately, including overrides for severe harm or prohibited activity.
A low likelihood estimate shouldn't conceal a severe consequence. Escalate such scenarios separately when your criteria require it.
Record uncertainty, assumptions, evidence quality, and ratings in the risk register. Missing supplier information should prompt further investigation, restricted use, or escalation rather than an unsupported low rating.
Distinguish inherent risk before treatment from residual risk after controls. Explain which existing controls have already influenced each rating.
Select treatments and justify control choices
Risk treatment should produce accountable actions and measurable outcomes. Clause 6.1.3 addresses treatment within the AIMS planning framework.
Choose an appropriate response
Options include avoiding an activity, reducing risk, sharing exposure through contracts or insurance, and accepting justified residual risk.
Sharing financial exposure doesn't remove obligations towards affected people. Accept residual risk only in line with your organisation's criteria and designated approval arrangements.
Record each risk treatment with an owner, target date, intended outcome and verification method. For example, human review needs defined criteria and evidence that reviewers can identify unsuitable outputs.
Prioritise treatments according to harm, obligations, dependencies and implementation feasibility. Where necessary, restrict deployment while significant uncertainty or unacceptable exposure remains.
Connect treatments with Annex A
Annex A contains normative reference control objectives and controls. Use Annex A controls to check proposed treatments against assessed risks and organisational context.
Record control-selection decisions in a Statement of Applicability. Explain inclusions, exclusions and implementation status in relation to your assessment results and context.
Don't assume every control applies identically to every organisation. The standard's requirements are distinct from implementation examples, and difficulty alone isn't a reason to exclude a control.
The ISO 42001 Clause 6.1 guidance connects assessment, treatment, applicability and impact assessment. Confirm clause-level requirements against the full standard.
Use the risk register to link each treatment decision to its assessment finding. Keep the full chain visible: finding, treatment decision, selected control, implementation evidence and residual-risk approval.
Maintain evidence and review operational changes
A completed risk register is useful only when it reflects operational reality. Maintain assessment records alongside implementation evidence and monitoring results.
Build a traceable evidence set
Auditors need to understand whether your approach is defined, consistently applied and effective. A practical evidence set includes scope decisions, assessment methodology, risk criteria, assessment results, impact assessments and treatment records.
For each risk register entry, capture the system and lifecycle stage, cause, consequence, affected stakeholders, owner, rating rationale, existing controls, treatment, residual risk and review trigger.
Link supporting evidence rather than duplicating it. Relevant records may include validation results, access reviews, supplier assessments, user training, approvals and incident investigations.
AKRUP's ISO 42001 consultancy supports gap assessment, AIMS implementation and internal audit preparation. Evidence review can identify weaknesses before certification assessment.
Reassess when conditions change
Set a planned review frequency that suits the risk and context, then add event-driven reviews. ISO/IEC 42001 doesn't prescribe one universal interval.
Reassessment triggers can include new data, model updates, changed users, expanded purposes, supplier or third-party AI changes, incidents, complaints or deteriorating performance.
Cloud audit logs, model-version records, evaluation reports and continuous monitoring alerts can support review. Connect each signal to an accountable owner and a defined response.
Check whether earlier assumptions still hold. Update treatment decisions, impact assessments and control applicability when material changes affect them.
Feed recurring findings into training, policy updates, management review and continual improvement. This keeps assessment connected to everyday governance rather than a certification timetable.
Frequently Asked Questions
Is an ISO 42001 risk assessment the same as an AI system impact assessment?
No. Risk assessment considers risks to the organisation and its AI systems, while the impact assessment examines effects on individuals, groups and society. The assessments inform one another but serve different purposes.
Does ISO/IEC 42001 require a particular risk scoring method?
No. Organisations should define consistent risk criteria suited to their systems, sector, obligations and available evidence. Record the rationale, assumptions and uncertainty behind ratings.
Does using third-party AI remove my organisation’s responsibilities?
No. Your responsibilities depend on your role and degree of control, including how the AI is applied in your business. Document what you control and where supplier assurance is needed.
When should an AI risk assessment be reviewed?
Set a planned review frequency that suits the risk and context, and reassess when material conditions change. Triggers may include model updates, new data or users, supplier changes, incidents, complaints or deteriorating performance.
Build confidence through proportionate AI risk management
An effective ISO 42001 risk assessment connects system behaviour, organisational responsibilities, and impacts on people. Its value depends on clear criteria, justified controls, and evidence that treatments work.
Start with an accurate inventory and accountable owners. Maintain traceability as systems, suppliers, and operating conditions change.
If you would like to find out more information or require any of our services please Contact Us and complete the contact form.
Comments