AI Risk Assessment for ISO 42001: Step-by-Step for Security Teams

AI Risk Assessment for ISO 42001: What Security Teams Need First

If you had to sum up ISO 42001 in one line: set one AI risk method first, use it for every system, keep AI risk and AI impact work separate, and retain proof for audit from day one.

For security teams building an ISO 42001 programme, you need a repeatable workflow that covers five parts:

• List every AI use case in one central inventory
• Score each risk with the same 1–5 likelihood and impact scale
• Run a separate AI impact assessment for higher-risk systems that affect people directly
• Map each risk to controls, owners, and proof
• Review risks after changes, not just once a year

Do not mix these two into one form. This guide is about building an AI risk process security teams can run month after month — one scoring model, clear ownership, control mapping, and review triggers that hold up in audit.

Define your AI risk assessment method before assessing any system

Set the method before you assess anything. Many teams jump into rating individual AI systems first and only later try to agree on the method. One business unit scores harshly, another scores lightly, and the risk register turns into a patchwork that is hard to defend in an audit.

Use one scoring method across every AI system. Auditors care far more about consistency than about whether you picked one scale over another. Once the method is fixed, start the first pass: identify each AI use case and log its risks in your risk management workflow.

Define scope, roles, and the AI system inventory

Start with one intake-and-assess workflow that every AI system must go through before deployment or after any material change. A large language model inside a third-party HR platform, a custom ML model built in-house, or a generative AI feature inside a vendor tool should all go through the same intake and assessment steps. If scope is fuzzy, unsanctioned AI use slips in through the side door.

The main control here is a centralised AI inventory. Each record should include the system ID or name, purpose, AI type, build-or-buy status, data types processed, decision role, ownership, and lifecycle status. Use decision roles such as informational, assistive, recommending, semi-automated, and fully automated so higher-risk use cases get flagged early. That inventory then feeds risk scoring, control mapping, and audit evidence.

• A Business Owner who is accountable for the business outcome and for accepting risk
• A Technical Owner who is responsible for operation and security

Assign both owners to every system. This keeps accountability clear across business and technical teams.

Set risk criteria, scoring scales, and impact dimensions

Use a 1–5 scale for both likelihood and impact so teams rate the same scenario in the same way. For likelihood, a score of 1 means rare, less than once per year. A score of 5 means almost certain, weekly or more often. If these definitions stay vague, the scores may look neat on paper but will not mean the same thing across teams.

For AI, impact has to go beyond the standard CIA triad. Score each risk across privacy, legal or compliance exposure, safety, operational disruption, reputational harm, and financial loss. Line up AI thresholds with your organisation’s ERM bands so AI risk reports through existing risk-led security channels without duplication.

Build a standard AI risk taxonomy and assessment template

A reusable risk taxonomy gives assessors a starting language. Without it, people write risk descriptions from scratch and wording drifts. At a minimum, cover Bias and Fairness, Explainability, Data and Privacy, Human Oversight gaps, and Third-Party AI Risk. Add Model Misuse issues such as hallucinations and prompt injection, along with security issues like adversarial attacks and model drift.

Use the template to produce a repeatable risk register that feeds treatment decisions and audit records. Be specific when writing each risk entry. A line that says "bias risk" is too vague for a certification audit. A line that says "Bias in credit scoring for under-25s" gives the auditor something concrete to test.

This structure helps you achieve ISO 42001 compliance by providing the inventory, assessments, treatment plan, and Statement of Applicability evidence that auditors expect. Set reassessment triggers as well: retraining, changes to data sources, new user groups, vendor updates, and moves from pilot to production.

How to run an ISO 42001 AI risk assessment: step by step

Once your method, scoring scales, and taxonomy are set, the work becomes a repeatable workflow. Use the same process for any AI system in scope — whether you built it in-house, configured it, or bought it from a third party.

Identify AI use cases and log risks for each use case

In a live assessment, record the use case, affected stakeholders, intended and prohibited uses, architecture, and decision role for each system in scope. Then check each use case against AI risk categories such as:

• Bias and fairness
• Explainability
• Security issues such as prompt injection or data poisoning
• Model performance
• Behaviour drift
• Third-party dependency

Log risks across the full lifecycle: design, test, deploy, monitor, and retire. Pair this with AI risk profiling so higher-risk systems are surfaced early rather than buried in a static spreadsheet.

Score likelihood and impact, then prioritise for treatment

After you log the use-case risks, rank them with the same scale across all systems. Score the inherent risk first. Then subtract the effect of existing controls to get residual risk.

In AI settings, likelihood goes up when the system is public-facing, lacks input or output filtering, relies on historical data with known bias, has weak access controls around model APIs, or gets too little human review. Impact goes up when a system handles sensitive personal data, affects credit, employment, health, or legal decisions, or could cause physical or psychological harm.

Risk assessment should support proportionate controls, not zero-risk targets. Set acceptance thresholds in advance:

• Low: accepted by the System Owner
• Medium: by the Business Owner
• High: by the AI Governance Committee
• Critical: by the Executive Committee

Escalate at once if the risk involves possible physical harm, unlawful discrimination, or an inability to provide meaningful human oversight. High-impact use cases should move into a deeper impact assessment.

Run AI impact assessments for high-risk systems

Run a deeper impact assessment when a system makes automated decisions that affect credit, employment, health, or legal status; involves children or other vulnerable groups; processes sensitive personal data; operates with limited human oversight; or is used in healthcare, finance, or public services. For Clause 6.1.4 cases, document stakeholder impact, rights impact, and severity.

Map controls, assign ownership, and prepare audit evidence

Once you know the residual risk, the next move is simple in theory and messy in practice: tie each risk to a control, a clear owner, and proof that the control works. Turn the risk register and impact assessment into something your team can run day to day — and something an auditor can follow without guesswork.

Select controls and map them across ISO 42001, ISO 27001, and SOC 2

Start by reusing what already works. If your ISO 27001 and SOC 2 controls, evidence, or workflows already deal with part of the AI risk, use them instead of building a parallel system from scratch. Keep the AI risk register linked to, but separate from, the ISO 27001 register. Information security risks stay in the ISO 27001 register. AI-specific risks such as bias, explainability, and drift belong in the AI risk register, with cross-references connecting the two.

Build a Control Applicability Matrix that maps each AI risk to a control, the Annex A reference, and any ISO 27001 or SOC 2 overlap. This matrix becomes the backbone of your Statement of Applicability.

Build the risk treatment plan and Statement of Applicability inputs

Clause 6.1.3 requires both the Statement of Applicability and the Risk Treatment Plan. The SoA must justify why every Annex A control is included or excluded. If you exclude a control, document the risk reason clearly. Blanket "not relevant" statements are one of the most common causes of audit findings.

• Business Owner: accountable for the business process and outcome
• Technical Owner: responsible for model-level controls
• Risk/Control Owner: handles specific treatment actions

Each treatment action needs a named owner, a target completion date, and a defined residual risk target. Then track those actions through your normal governance workflow. If the AI system depends on a third-party model or API, add contractual controls, usage constraints, and supplier due diligence records to the same treatment plan. Do not leave vendor risk sitting off to the side.

• Risk identified

• Control selected

• Control implemented

• Evidence retained

• Residual risk evaluated

• Named approval recorded

Maintain an evidence pack that stays audit-ready

Once controls are assigned, collect proof that they work. Common audit gaps include missing AI impact assessments under Clause 6.1.4, SoA exclusions with no risk justification under Clause 6.1.3, and missing AI-specific competence records under Clause 7.2.

• Completed risk assessments and impact assessments
• Control test evidence: configuration screenshots, red-team results, bias testing logs
• Vendor due diligence records and model monitoring dashboards
• AI Governance Committee minutes and formal risk acceptance memos

Use a consistent date format across logs and review records — for example, 23 Jun 2026. These artefacts should feed day-to-day governance, not a folder opened only for audit week. Evidence collection agents and integrations can automate artefact capture so the pack stays current between assessments.

Move from one-time assessment to continuous AI governance

AI risk does not stay still after go-live. It shifts as models change, data changes, users change, and rules change. ISO 42001 needs a standing review cycle, not a one-time report. Once the risk register and treatment plan are in place, governance has to continue after deployment.

Set review triggers, checkpoints, and monitoring cycles

Do not treat AI risk assessment as an annual-only task. Spell out the events that require a new review: model updates, data drift, expansion to new users or geographies, incidents, regulatory change, and supplier term changes. Calendar dates help, but reviews should also be triggered by continuous monitoring signals: model performance, data drift, incidents and near misses, control effectiveness, and external context such as new regulations or threat patterns.

These reviews should update the same risk register. They should not drift into a separate governance lane.

Extend the process to AI vendors and enterprise GRC workflows

The same review discipline should apply to third-party AI. If a provider changes its model, updates service terms, or shifts how data is handled, your risk posture can change with it. Supplier change notifications should feed straight into change management, incident response, and vendor risk management.

In practice, AI risk should sit inside workflows your team already uses. Model updates should be flagged automatically. AI-related incidents should trigger reassessments. Supplier reviews should include AI-specific due diligence. That keeps AI risk tied to the rest of your enterprise GRC process instead of turning it into a side project.

Conclusion: an ISO 42001 workflow security teams can sustain

That is what turns ISO 42001 from a document into an operating process. For security and compliance teams managing ISO 42001 alongside ISO 27001 and SOC 2 compliance, CISOGenie centralises risk registers, control mappings, vendor oversight, and evidence collection in one place — with automated monitoring and evidence updates that keep the programme current.

1. 1

   Fix one scoring method

   Before assessing any system.

2. 2

   Inventory every AI use case

   With dual ownership and decision roles.

3. 3

   Separate risk and impact assessments

   Clause 6.1.2 for all systems; Clause 6.1.4 for high-risk.

4. 4

   Map controls and keep evidence current

   Reuse ISO 27001 and SOC 2 where they fit; retain AI-specific proof separately.
5. 5

   Review on triggers, not only on calendars

   Model, data, vendor, and incident changes drive reassessment.

See CISOGenie Run This Exact Workflow

Frequently Asked Questions