AI Risk Assessment for ISO 42001: A Step-by-Step Implementation Guide for Security Teams
-
Shankar Jayaraman - 25 Jul, 2026
If I had to sum up ISO 42001 in one line, I’d say this: 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.
Here’s the short version of what this article says in plain English. If you’re a security team working on ISO 42001, 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
The article also makes one point very clear: AI risk is not the same as ISO 27001 risk. ISO 27001 leans on confidentiality, integrity, and availability. AI adds other problem areas like bias, hallucinations, prompt injection, data poisoning, drift, weak human review, and third-party model risk. That means I should not squeeze AI into a plain infosec risk sheet and hope it fits.
A few direct takeaways stand out:
- Use one intake process for all AI systems, whether built in-house or bought from a vendor
- Assign two owners to each system: a business owner and a technical owner
- Define escalation triggers upfront for issues like physical harm, unlawful discrimination, or poor human oversight
- Keep an AI risk register separate from the ISO 27001 register, but link them where needed
- Build the risk treatment plan and Statement of Applicability from the same assessment trail
- Keep an evidence pack ready with logs, test results, approvals, vendor checks, and review records dated like 23 Jun 2026
The article also draws a sharp line between two ISO 42001 tasks:
| Item | AI Risk Assessment | AI Impact Assessment |
|---|---|---|
| Main focus | What can go wrong for the organisation | Who may be affected and how badly |
| ISO 42001 clause | 6.1.2 | 6.1.4 |
| Applies to | All AI systems in scope | Higher-risk systems |
| Main output | Risk register and risk scores | Stakeholder and rights analysis |
In other words: don’t mix these two into one form.
I’d read this article as a practical guide for building an AI risk process that a security team can run month after month without confusion. It’s less about theory and more about putting in place a single scoring model, clear ownership, control mapping, and review triggers that hold up in audit.
That’s the core idea of the full article below.
Define your AI risk assessment method before assessing any system
Set the method before you assess anything. A lot of teams do the opposite: they jump into rating individual AI systems first and only later try to agree on the method. That usually ends badly. One business unit scores harshly, another scores lightly, and the risk register turns into a patchwork that’s hard to defend in an audit. Then comes the clean-up work.
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.
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.
Assign two owners to every system:
- a Business Owner who is accountable for the business outcome and for accepting risk
- a Technical Owner who is responsible for operation and security
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 won’t 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. Use your organisation’s own monetary bands from the ERM scale, and line up AI thresholds with those same ERM bands. That cuts duplication and makes AI risk easier to report through existing channels.
Also set mandatory escalation triggers in advance. These are cases that must be escalated right away, no matter what the numerical score says. Potential physical harm, unlawful discrimination, and systemic rights impacts should not sit in a queue waiting for the next routine review.
Build a standard AI risk taxonomy and assessment template
A reusable risk taxonomy gives assessors a starting language. Without it, people end up writing risk descriptions from scratch, and the wording drifts all over the place. At a minimum, your taxonomy should cover Bias and Fairness, Explainability, Data and Privacy, Human Oversight gaps, and Third-Party AI Risk. You can also 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 and won’t hold up in a certification audit. A line that says “Bias in credit scoring for under-25s” gives the auditor something concrete to test.
| Risk Register Field | Description | How it helps |
|---|---|---|
| Risk Scenario | ”Because of [cause], the AI may [event], causing [impact].” | Forces concrete, repeatable risk statements |
| Impact Dimensions | Privacy, Compliance, Safety, Operations, Reputation, Financial | Keeps AI risks aligned to business impact |
| Inherent Risk | Likelihood × Impact (1–5 scale) before controls | Supports consistent prioritisation |
| Controls / Treatment | Selected Annex A controls and treatment actions | Feeds the Risk Treatment Plan |
| Residual Risk | Risk level remaining after treatment is applied | Shows what remains after controls |
| Risk Acceptor | Named individual with authority to accept residual risk | Creates a clear decision record |
| Evidence Link | Validation results, monitoring logs, or approval minutes | Keeps the assessment audit-ready |
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. Common ones include retraining, changes to data sources, new user groups, vendor updates, and moves from pilot to production. Once the method is fixed, assess each use case and score likelihood and impact.
How to run an ISO 42001 AI risk assessment: step by step
ISO 42001 AI Risk Assessment: 5-Step Implementation Workflow
Once your method, scoring scales, and taxonomy are set, the work becomes a repeatable workflow. You can 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. These risks then feed into likelihood, impact, and residual-risk scoring.
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. A practical authority ladder looks like this:
- 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
Use the split below for scoping and evidence.
| Aspect | AI Risk Assessment (Clause 6.1.2) | AI Impact Assessment (Clause 6.1.4) |
|---|---|---|
| Trigger | All AI systems in scope | High-risk systems or those affecting individuals directly |
| Key question | What could go wrong for the business? | Who is affected, and how severely are their rights impacted? |
| Outputs | Risk register, likelihood/impact scores | Stakeholder mapping, rights analysis, severity evaluation |
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.
Use both outputs to build the risk treatment plan and Statement of Applicability in the next step.
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.
That means turning 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. At the same time, 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.
A single matrix helps keep treatment, framework mapping, and evidence in sync. 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.
| AI Risk Category | Practical Control | ISO 42001 Annex A Ref | Framework Reuse |
|---|---|---|---|
| Bias & Fairness | Subgroup testing; human-in-the-loop review | A.6.2.2, A.7.4 | Privacy Impact Assessment (DPIA) |
| Security | Prompt injection filtering; rate limiting | A.8.4 | ISO 27001 (A.8.7), SOC 2 (CC6.1) |
| Explainability | Model cards; transparency disclosures | A.7.2, A.7.3 | Privacy (Transparency/Notice) |
| Model Drift | Automated performance monitoring alerts | A.6.2.6 | Operational Monitoring (SOC 2) |
| Supply Chain | Contractual audit rights; model cards | A.10.2 | Vendor Risk Management |
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.
Ownership should be split by role so there’s no confusion later:
- 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. Don’t leave vendor risk sitting off to the side. If it affects the system, it belongs in the treatment trail.
For accepted risks, document the full chain:
- 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. That’s where many ISO 42001 programmes stumble. 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.
Your evidence pack should include completed risk assessments, impact assessments, control test evidence such as configuration screenshots, red-team test results, and bias testing logs, vendor due diligence records, model monitoring dashboards, AI Governance Committee minutes, and formal risk acceptance memos. Use the en-IN date format across logs and review records - for example, 23 Jun 2026 - so documentation stays consistent. These artefacts shouldn’t be treated like paperwork shoved into a folder for audit week. They should feed day-to-day governance.
Platforms like CISOGenie can automate evidence collection and centralise audit artefacts, which cuts manual work.
Those artefacts also become the base for review triggers, monitoring, and vendor oversight.
Move from one-time assessment to continuous AI governance
AI risk doesn’t stay still after go-live. It shifts as models change, data changes, users change, and rules change. That’s why 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
Don’t 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 they’re not enough on their own. Reviews should also be triggered by monitoring signals. Five signals should feed reviews on a continuous basis: model performance, data drift, incidents and near misses, control effectiveness, and external context such as new regulations or threat patterns.
| Review Cadence | Activity | Key Stakeholders |
|---|---|---|
| Monthly | Review AI inventory changes and new use cases | AI Governance Team, IT |
| Quarterly | Review high/medium risks, monitoring metrics, and incidents | CISO, Risk Owners, AI Committee |
| Ad-hoc | Reassess after material changes (model, data, or vendor) | Technical Owner, Business Owner |
| Annually | Review risk methodology, appetite, and control effectiveness | Executive Leadership, Internal Audit |
One point matters here: these reviews should update the same risk register. They shouldn’t drift into a separate governance lane.
Extend the process to AI vendors and enterprise GRC workflows
This same review discipline should apply to third-party AI too. 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, that means 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’s 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.
FAQs
How does AI risk assessment differ from ISO 27001 risk assessment?
ISO 27001 centres on the confidentiality, integrity and availability of information assets.
ISO 42001 goes a step further. It looks at AI-specific risks like model bias, weak explainability, data drift, and harm to people and society.
It also covers the full AI lifecycle - from design and development to retirement. And it brings in impact checks on individuals and society, not just risks to the organisation itself.
When is a separate AI impact assessment needed under ISO 42001?
Under ISO 42001, you need a standard AI risk assessment for every AI system that falls within scope. That’s part of Clause 6.1.2.
But that’s not always enough.
For high-risk use cases, a separate and stricter AI impact assessment is also needed. This applies when an AI system could cause serious negative effects for individuals, groups, or society.
In practice, that usually includes AI used in regulated sectors like finance or healthcare, customer-facing tools tied to major outcomes, systems that handle sensitive personal data, or AI that makes consequential decisions about people.
What evidence should we keep to stay audit-ready for ISO 42001?
Keep a clear, documented audit trail so anyone reviewing your AI governance can see that the risk assessment process is defined, recorded, and used the same way across the full AI lifecycle.
That trail should show how you assess risk, which AI systems you track, what risks you’ve logged, how you plan to handle them, and what remains after controls are in place.
Include records such as:
- Your methodology
- AI inventory
- Risk registers
- Risk treatment plans
- Residual risk acceptance records
- Ongoing monitoring evidence, such as drift checks, incident triggers, and periodic reassessments
Think of it as the paper trail behind each AI decision. If a model changes, a control fails, or a new issue turns up, the records should make it easy to see what was reviewed, what action was taken, and who signed it off.