ISO/IEC 42001 Guide: Complete AI Governance Framework
What Every Senior Leader Should Be Able to Answer About AI Governance
Most conversations about AI risk end up circling the same few worries — people quietly using tools IT never approved, company data ending up inside a public model, or a vendor who can’t tell you how their AI actually makes decisions. Those concerns are real. But there’s a bigger question sitting underneath all of them that fewer leaders can answer: can you actually prove, in a structured and repeatable way, that AI risk is being managed properly in your organisation? ISO/IEC 42001:2023 exists to answer exactly that question.
The easiest way to explain it to your board: if ISO 27001 is how you prove you manage information security well, ISO 42001 is the same idea applied to AI. It’s the first internationally certifiable standard for an AI Management System (AIMS), and it applies whether you build AI models, buy them from a vendor, or simply use AI tools inside the business.
This guide walks through the standard in the order it’s actually written — Clauses 4 through 10, then the Annex A controls and Annex B guidance — with the kind of plain explanations you’d want on hand before an audit, a board update, or a vendor conversation.
What This Standard Actually Gives You, Beyond a Certificate
Before getting into clauses and controls, it’s worth being honest about what this standard is actually for. It’s not a certificate for the lobby wall — it changes how AI decisions get made and defended inside the business.
- It gives you proof, not just a promise. Saying “we use AI responsibly” is easy. The Statement of Applicability backs that claim with documented, justified controls you can actually show someone.
- It pulls everything into one place. Instead of an AI ethics slide deck here and a model card there, risk, impact on people, data sourcing, and human oversight all sit under one system.
- It shortens the sales cycle. Enterprise customers now routinely ask “how do you govern your AI?” as part of procurement. A certificate answers that faster than a bespoke questionnaire response every time.
- It builds the record you’ll need if something goes wrong. If an AI system ever causes harm, regulators and courts will ask for impact assessments, oversight logs, and incident communications. This is where those get created before you need them, not after.
- It doesn’t force you to start over. If you’re already ISO 27001 certified, several clauses share the same skeleton. You extend what you have rather than building a parallel system from scratch.
Worth remembering: regulators and enterprise buyers are increasingly asking AI providers and adopters for evidence, not intentions. This standard is the mechanism that produces that evidence whenever it’s asked for.
Clauses 1–3: The Groundwork Most People Skip Past
The first three clauses don’t contain any hard requirements — they set the scope and define the vocabulary. It’s tempting to skim them. Don’t. An auditor will still check that you’ve applied them correctly, because every clause after this one depends on getting these right.
Clause 1 — Scope
This clause simply says the standard applies to any organisation, of any size, in any industry, that provides or uses AI-powered products or services. Its purpose is to help you develop, provide, or use AI responsibly, and to meet the obligations you owe to the people affected by it.
For leaders: you don’t need to call yourself an “AI company” to be in scope. Using an AI tool internally — say, for screening job applicants — is enough on its own.
Clause 2 — Normative References
This clause points to ISO/IEC 22989:2022 (AI Concepts and Terminology) as the companion document that defines the language used throughout 42001.
For leaders: if your team ever disagrees on what “AI system” or “AI lifecycle” technically means, ISO/IEC 22989 settles it. It’s the reference, not whoever argues loudest in the meeting.
Clause 3 — Terms and Definitions
This clause defines the vocabulary the rest of the standard is built on. A handful of these terms matter more than the rest when you’re the one making governance calls:
| Term | What it means, in plain terms | Why it matters to you |
|---|---|---|
| Risk | The effect of uncertainty — which can work in your favour or against you | Risk isn’t only about bad outcomes. AI opportunities count as risk too, under this definition |
| Control | A measure that keeps risk in check or changes its shape | This is the building block for everything in Annex A |
| AI system impact assessment | A formal, written process to identify and address how an AI system affects individuals, groups, and society | This is a separate exercise from a risk assessment — don’t merge them |
| Statement of Applicability | A document that records every control you’re using or excluding, and why | This is the single document your auditor will care about most |
| Governing body | The person or group accountable for how the organisation performs and conforms | Not automatically the same as “top management” — relevant if your board is expected to oversee AI |
| Data quality | How well data meets your requirements for a specific use | Quality depends on context — there’s no universal bar to clear |
For leaders: an “AI system impact assessment” and a “risk assessment” are two different things, procedurally. A lot of organisations combine them into a single document without realising that’s a mistake the standard doesn’t allow.
So What’s Actually Mandatory?
This is the question we get asked most often, and it’s genuinely confusing on a first read. Here’s the honest breakdown.
| Clause / Annex | Mandatory? | Why |
|---|---|---|
| Clauses 1–3 | Foundational, not “shall” requirements | They set scope and vocabulary. You won’t be audited against them directly, but everything downstream is interpreted through them |
| Clauses 4–10 | Fully mandatory | Every “shall” statement here is a certification requirement. There’s no exemption based on your own risk appetite |
| Annex A (Controls) | Selectively mandatory | You’re not required to adopt every control, but you are required to run the comparison exercise in Clause 6.1.3(b) and record a reason for every inclusion or exclusion. Skipping that comparison is itself a finding, even if you end up excluding most of the controls |
| Annex B (Implementation Guidance) | Not mandatory | Explains how to satisfy Annex A well. Auditors will lean on it, but they won’t cite it as a requirement on its own |
| Annex C (Objectives & Risk Sources) | Informative only | A useful prompt list — not a checklist you’re required to work through |
| Annex D (Sector/Domain Integration) | Informative only | Guidance for lining this up with ISO 27001, ISO 9001, and similar standards |
Bottom line: Clauses 4 through 10 aren’t optional, full stop. Annex A is risk-based, but the process of working through it is not optional — even when you decide most of the controls don’t apply.
Clause 4 — Context of the Organization
Before anything else in the standard will make sense, leadership needs to establish a few basics in writing.
| Requirement | What it looks like in practice |
|---|---|
| 4.1 Understand your context | Work out which role or roles you play — provider, producer, customer, partner, or subject of AI — and document the internal and external issues that affect how you manage it, including whether something like climate impact is relevant to your AIMS |
| 4.2 Understand who’s affected | Identify the regulators, customers, employees, and data subjects your AI touches, and note what each of them expects from you |
| 4.3 Set the boundary | Write down, in specific terms, which AI systems, teams, and processes are actually inside scope |
| 4.4 Stand up the system | Formally establish the management system itself, along with the processes it needs and how they connect |
Clause 5 — Leadership
Clause 5 has three parts, and each one gets checked separately during an audit. The single most common mistake we see is leadership treating this whole clause as “we wrote an AI Policy, done.” It isn’t.
5.1 — Leadership and Commitment
This is what top management is personally responsible for. It can’t be handed off to a working group:
- Making sure the AI Policy and objectives actually connect to business strategy
- Building AIMS requirements into how the business already works, rather than bolting them on the side
- Making sure resources are genuinely available, not just approved in a budget meeting
- Explaining why AI governance matters, and doing it more than once
- Directing and supporting people so the AIMS actually works day to day
- Pushing for continual improvement rather than treating certification as the finish line
- Backing other managers so they can show leadership on AI within their own areas
For leaders: auditors test this clause through conversation, not paperwork. If you can’t explain, in your own words, why the AIMS exists and what it does for the business, this sub-clause fails no matter how polished the documentation is.
5.2 — AI Policy
The policy document itself needs to be:
- Genuinely fit for how your organisation actually operates
- A framework you use to set AI objectives, not a standalone statement
- A commitment to meeting the requirements that apply to you
- A commitment to keep improving the AIMS over time
- Written down, shared internally, and available to anyone outside the business who asks for it
For leaders: if you can’t summarise the AI Policy in one sentence during an audit interview, it isn’t embedded in the business. It’s decoration.
5.3 — Organisational Roles, Responsibilities and Authorities
Top management needs to assign, and clearly communicate, who is responsible for:
- Making sure the AIMS actually conforms to ISO/IEC 42001
- Reporting on how the AIMS is performing, back up to top management
- Owning specific duties — impact assessment, risk treatment, human oversight, incident handling — assigned to named individuals, not left with “the security team” in general
For leaders: this is exactly where a RACI matrix earns its keep. Auditors want named accountability. “Who owns AI impact assessments” needs to be answered with a person’s name or job title, not a department.
Clause 6 — Planning
This clause is the engine room of the whole standard. Four things have to happen here, and roughly in this order.
6.1.1 Actions to address risks and opportunities — decide what counts as acceptable risk before you start assessing anything. Set the yardstick first.
6.1.2 AI risk assessment — a repeatable process that:
- Identifies risks that either help or work against your AI objectives
- Looks at the consequences for the organisation, for individuals, and for society
- Assesses likelihood where that’s actually possible to do
- Weighs everything against your risk criteria and ranks what needs treating first
6.1.3 AI risk treatment — which means you:
- Choose how each risk will be treated
- Cross-check the choice against Annex A, to confirm nothing necessary got left out
- Produce a Statement of Applicability that justifies every control you’ve included or excluded
- Put together a treatment plan and get management sign-off on whatever risk is left over
6.1.4 AI system impact assessment — a separate exercise from the risk assessment above. This one looks at what the system does to individuals, groups, and society, not just to the organisation. It has to happen before deployment, and then again at intervals you define.
6.2 AI objectives need to line up with the policy, be measurable wherever that’s realistic, actually get monitored, and be written down and communicated — not just set once and forgotten.
For leaders: the Statement of Applicability is the single most important document you’ll produce under this standard. Every excluded control needs a reason that would hold up if someone challenged it.
Clause 7 — Support
| Element | What’s expected |
|---|---|
| 7.1 Resources | Work out what’s needed to build, run, and improve the AIMS, then actually provide it |
| 7.2 Competence | Make sure people working on AI systems are properly qualified, and keep evidence — training records, hiring criteria, relevant experience |
| 7.3 Awareness | Everyone under your control should know the AI Policy exists, and understand what happens if it’s ignored |
| 7.4 Communication | Decide what gets communicated, to whom, when, and how — both inside and outside the business |
| 7.5 Documented information | Control how AIMS documentation gets created, reviewed, approved, accessed, stored, versioned, and eventually retired |
For leaders: this is where audits actually fail most often — not because the controls don’t exist, but because competence and awareness were never properly evidenced.
Clause 8 — Operation
This is where the planning from Clause 6 turns into day-to-day practice:
- 8.1 Put the operational controls from 6.1.3 into place, including how AI systems are actually developed and used day to day
- 8.2 Re-run AI risk assessments on a schedule you set, and again whenever something significant changes
- 8.3 Carry out the risk treatment plan, verify it worked, and re-treat when new risks turn up
- 8.4 Do the same for impact assessments — on a schedule, and after major change
For leaders: “planned intervals” is deliberately left undefined by the standard. It’s on you to decide and document your own cadence — quarterly, per release, whatever genuinely fits how your business ships AI.
Clause 9 — Performance Evaluation
| Requirement | What it looks like |
|---|---|
| 9.1 Monitoring & measurement | Decide what gets measured, how often, and how the results get analysed |
| 9.2 Internal audit | Run planned, independent audits against both the standard itself and your own internal AIMS requirements |
| 9.3 Management review | Top management reviews whether the AIMS is still fit for purpose, using real inputs — nonconformity trends, audit results, and changes in what interested parties expect from you |
For leaders: management review isn’t a box-tick meeting once a year. The standard specifically requires trend data on nonconformities and audit outcomes as inputs, not just a status update.
Clause 10 — Improvement
- 10.1 Keep improving how suitable, adequate, and effective the AIMS is — on an ongoing basis, not as a one-off project
- 10.2 When something goes wrong: fix the immediate problem → find the actual root cause → check whether it’s happening anywhere else → put a corrective action in place → confirm it worked → update the AIMS if that’s what’s needed
For leaders: fixing the symptom without finding the root cause is just firefighting. Auditors will ask for the “why,” not only the “it’s fixed now.”
Annex A — The Controls, Defined Properly
Not all 38 controls will apply to you — you work out what’s relevant through the risk assessment and record the exclusions in your Statement of Applicability. What follows is the full set, defined in plain terms, alongside what an auditor will actually expect to see as proof.
A.2 — Policies Related to AI
| Control | What it means / evidence to keep |
|---|---|
| A.2.2 AI Policy | Have an approved, signed policy with a version history, plus proof it was actually shared with staff — an intranet post date or a staff email works |
| A.2.3 Alignment with other policies | A simple cross-reference showing where the AI Policy connects to security, privacy, HR, or procurement policy — it shouldn’t sit in isolation |
| A.2.4 Policy review | Meeting minutes or a change log showing the policy actually gets reviewed on a schedule, with real outcomes recorded |
A.3 — Internal Organization
| Control | What it means / evidence to keep |
|---|---|
| A.3.2 Roles & responsibilities | A RACI matrix or org chart specific to AI governance — your general company org chart won’t satisfy this |
| A.3.3 Reporting of concerns | A working channel for raising AI concerns — email, tool, or hotline — plus at least one example showing it’s actually been used |
A.4 — Resources for AI Systems
| Control | What it means / evidence to keep |
|---|---|
| A.4.2 Resource documentation | An inventory of what AI systems exist, what stage each is at, and what resources sit behind them |
| A.4.3 Data resources | A register of your data sources — origin, category, how often it’s refreshed, and any known bias concerns |
| A.4.4 Tooling resources | A list of the frameworks, algorithms, and dev tools each system relies on |
| A.4.5 System/computing resources | A map of infrastructure — on-prem, cloud, edge — and how compute is allocated |
| A.4.6 Human resources | A skills matrix showing who has AI-relevant expertise and which systems they support |
A.5 — Assessing Impacts of AI Systems
| Control | What it means / evidence to keep |
|---|---|
| A.5.2 Impact assessment process | A documented method or template for carrying out an AI impact assessment |
| A.5.3 Documentation of results | Completed impact assessment reports for every system in scope, kept for as long as your retention policy requires |
| A.5.4 Impact on individuals/groups | A section covering fairness, legal exposure, and physical or psychological wellbeing |
| A.5.5 Societal impact | A section covering wider environmental, economic, or governmental effects |
A.6 — AI System Life Cycle
| Control | What it means / evidence to keep |
|---|---|
| A.6.1.2 Objectives for responsible development | Dev-time goals — like fairness thresholds — written down and tied to the actual design spec |
| A.6.1.3 Responsible design/development processes | An SDLC that shows bias testing and human checkpoints, not just standard code review |
| A.6.2.2 Requirements & specification | A requirements document for each new AI system, or any material change to one |
| A.6.2.3 Design & development documentation | Architecture diagrams and the reasoning behind why a particular model was chosen |
| A.6.2.4 Verification & validation | Test plans, how test data was chosen, and clear pass/fail criteria with actual results |
| A.6.2.5 Deployment | A deployment plan plus sign-off confirming the release criteria were genuinely met |
| A.6.2.6 Operation & monitoring | Monitoring configuration, alert thresholds, and a support/maintenance schedule |
| A.6.2.7 Technical documentation | The actual documentation set, tailored for whichever audience needs to read it |
| A.6.2.8 Event logging | Log retention settings and a sample extract showing what fields actually get captured |
A.7 — Data for AI Systems
| Control | What it means / evidence to keep |
|---|---|
| A.7.2 Data management processes | A documented process covering data from the moment it’s acquired to the moment it’s disposed of |
| A.7.3 Data acquisition | Source, licensing basis, and selection criteria recorded for every dataset |
| A.7.4 Data quality | Quality metrics you actually use, measured against thresholds you’ve defined |
| A.7.5 Data provenance | A log tracking how each dataset was created, transformed, and moved over time |
| A.7.6 Data preparation | The cleaning and preparation methods used, along with the reasoning behind them |
A.8 — Information for Interested Parties
| Control | What it means / evidence to keep |
|---|---|
| A.8.2 System documentation for users | Published, user-facing documentation — kept separate from your internal technical docs |
| A.8.3 External reporting | A visible, working way for users to report harm caused by the system |
| A.8.4 Incident communication plan | A plan that exists and has actually been tested or run through, not just filed away |
| A.8.5 Info for interested parties | A record of what’s been shared with regulators or customers, and when |
A.9 — Use of AI Systems
| Control | What it means / evidence to keep |
|---|---|
| A.9.2 Responsible use processes | Internal guidelines telling staff how the system should and shouldn’t be used |
| A.9.3 Objectives for responsible use | Documented targets — like human-oversight thresholds — tied to specific systems |
| A.9.4 Intended use conformance | Monitoring evidence showing the system is actually being used the way it was designed for |
A.10 — Third-Party and Customer Relationships
| Control | What it means / evidence to keep |
|---|---|
| A.10.2 Allocating responsibilities | Contracts or a RACI showing who owns what across everyone involved in supplying or building the system |
| A.10.3 Suppliers | Due-diligence records for any AI components you’ve sourced from outside vendors |
| A.10.4 Customers | Proof that customer needs and expectations were actually captured somewhere — contracts or requirements docs |
Annex B — What Actually Convinces an Auditor
You don’t have to justify Annex B the way you do Annex A, but it tells you how to satisfy each control in a way that actually holds up.
- AI Policy (B.2): Should be shaped by business strategy, risk appetite, legal obligations, and the impact on the people affected — not written by security or legal on their own.
- Roles & Responsibilities (B.3): Make sure coverage spans risk management, impact assessment, security, safety, privacy, development, and suppliers.
- Resources (B.4): Document data, tooling, compute, and people per lifecycle stage — this documentation is what your impact assessments will draw on directly.
- Impact Assessment (B.5): Needs to weigh legal exposure, wellbeing, human rights, and societal effects, not just the technical risk.
- Lifecycle Management (B.6): Testing rules, human oversight points, training-data rules, release criteria, and change control all need to be settled before development starts, not retrofitted afterward.
- Data (B.7): Quality, provenance, and preparation all need to be defined and evidenced — this is one of the more common gaps we see in real audits.
- Interested Party Communication (B.8): People should know they’re interacting with AI, how to override it, and how to flag harm.
- Responsible Use (B.9): Human oversight isn’t a nice-to-have anywhere AI affects people. Define who can step in and when.
- Third Parties (B.10): Supplier and customer responsibilities need to be written down explicitly, especially who’s acting as controller versus processor when personal data is involved.
ISO 42001 and ISO 27001 — Do You Need Both?
Yes, you need both. Neither one substitutes for the other, but they’re built to work together rather than run as two separate systems that never talk to each other.
Why They’re Different Standards
- ISO 27001 is about information security in general — the confidentiality, integrity, and availability of information.
- ISO 42001 is about AI-specific risk and lifecycle management — bias, explainability, the effect an AI system has on people and society, where training data actually comes from, and human oversight of automated decisions.
An AI system can be entirely secure under ISO 27001 and still be unfair, opaque, or harmful — 27001 has no way to catch that. Annex A of 42001 exists specifically to cover what 27001 never touches.
Where They Overlap and Can Share Evidence
| Shared element | Can you reuse it? |
|---|---|
| Context of the organization (Cl. 4) | Mostly — extend your existing 27001 context work with AI-specific roles |
| Leadership commitment (Cl. 5) | The structure carries over, but the AI Policy stays a separate document from your Information Security Policy |
| Roles & responsibilities (Cl. 5.3 / A.3.2) | Partly — AI-specific roles like impact assessors and oversight owners are new additions |
| Competence, awareness, documented info control (Cl. 7) | The process carries over, but the content — training material, doc registers — needs AI-specific additions |
| Internal audit & management review (Cl. 9) | Process and cadence carry over, but audit criteria and review inputs need to explicitly include AI risk data |
| Nonconformity/corrective action (Cl. 10) | Fully reusable — the same log just needs to accept AI-related findings too |
Where You’ll Need to Start Fresh for 42001
- AI risk assessment and treatment (Cl. 6.1.2 / 6.1.3) — a different exercise from information security risk assessment
- AI system impact assessment (Cl. 6.1.4, A.5) — there’s no 27001 equivalent to lean on
- Data provenance and quality for training and test data (A.7) — this goes well beyond 27001’s data classification controls
- AI lifecycle controls — model validation, bias testing, explainability (A.6)
- Human oversight requirements for automated decisions (A.9)
A practical way to run this: treat it as one integrated management system, not two silos. If you’re already ISO 27001 certified, use your Clause 4/5/7/9/10 documentation as your starting point and extend it with AI-specific content. Keep the AI Policy and the Statement of Applicability as their own named documents — 42001 auditors will ask for them specifically. If it’s practical, run one combined risk register but tag each entry clearly as either an “information security risk” or an “AI risk,” so nothing gets lost between the two. If your AI systems also process personal data, bring ISO/IEC 27701 into the picture too (Annex D.2 covers this).
A Few Things Worth Keeping Handy
Clauses 4–10, in order
Context → Leadership → Planning → Support → Operation → Performance evaluation → Improvement.
An easy way to hold onto the order: “Confident Leaders Plan Support, Operate, Perform, Improve.” The first letters — C, L, P, S, O, P, I — line up exactly with Clauses 4 through 10. It’s also the same skeleton ISO 27001 uses, so if your team already knows one, they’re most of the way to knowing the other.
Numbers worth remembering
- 38 Annex A controls, spread across 9 control families (A.2 through A.10)
- 2 mandatory assessments — AI risk assessment (6.1.2) and AI system impact assessment (6.1.4) — always kept separate
- 1 normative reference — ISO/IEC 22989 defines the vocabulary the whole standard runs on
- 7 fully mandatory clauses — every “shall” in Clauses 4 through 10 is a certification requirement
- 3 sub-clauses inside Clause 5 — leadership commitment (5.1), the AI Policy itself (5.2), and roles & responsibilities (5.3)
Where organisations tend to lose points
- Merging risk assessment and impact assessment into one document — they’re procedurally distinct (6.1.2 vs. 6.1.4), and combining them is one of the most common mistakes we see.
- Treating Annex A as fully optional. Individual controls can be excluded, but the comparison process behind that decision (6.1.3b) can’t be skipped.
- Mixing up “governing body” with “top management.” The standard deliberately uses both terms — governing body is the accountable oversight layer, often your board.
- Assuming good hiring proves competence. The standard asks for evidence — training records, communication logs, sign-off trails — not just a strong team.
- Writing the AI Policy in a silo. Annex B expects input from business strategy, legal, and the people the AI affects — not just security or legal working alone.
- Treating Clause 5 as one requirement. It’s three, checked independently — commitment, the policy itself, and named roles and authority.
- Forgetting “planned intervals” is left undefined on purpose. You’re expected to set and document your own cadence for risk assessments, impact assessments, and reviews.
Questions Worth Being Able to Answer Without Notes
Q: What’s the difference between an AI risk assessment and an AI system impact assessment?
A: The risk assessment (6.1.2) looks at what could help or hurt your AI objectives, from the organisation’s point of view. The impact assessment (6.1.4 / Annex A.5) looks at the consequences for individuals, groups, and society — a genuinely different lens. Both are required, and combining them into one document is a mistake worth avoiding.
Q: Do we need ISO 42001 if we only use third-party AI tools and don’t build our own?
A: Yes. Clause 1’s scope covers anyone who provides or uses AI systems. Being a customer in the AI value chain is enough on its own to bring you into scope.
Q: What is the Statement of Applicability, and why does it get so much attention?
A: It’s the document, produced under Clause 6.1.3, that justifies including or excluding every Annex A control. Most practitioners would call it the single most audit-critical artifact in the entire standard.
Q: Can you legitimately exclude most of the Annex A controls?
A: Yes — the controls are selectively mandatory based on your own risk profile. But running the comparison itself (6.1.3b) isn’t optional. Skipping that step is a finding, even if the resulting document excludes nearly everything.
Q: How does ISO 42001 relate to ISO 27001 — do we actually need both?
A: Both are needed, and neither replaces the other. They share a common structure across several clauses, but the AI-specific risk and impact assessment, data provenance, lifecycle controls, and human oversight requirements all need to be built from scratch.
Q: What’s the most common reason organisations fail an ISO 42001 audit?
A: Usually it isn’t that the controls don’t exist — it’s that competence and awareness (Clause 7) were never properly evidenced. No training records, no documented awareness effort, no proof the AI Policy was actually communicated to anyone.
Q: What has to happen after a nonconformity, under Clause 10.2?
A: Fix the immediate issue, find the actual root cause, check whether the same problem exists anywhere else, put a corrective action in place, confirm it worked, and update the AIMS if that’s what’s needed.
Q: What’s a “governing body,” and how does it differ from “top management”?
A: The governing body is the person or group accountable for organisational performance and conformance — often the board. It’s a deliberately distinct term from top management, the executive team, and it matters when questions come up about board-level AI oversight.
Q: What are the three parts of Clause 5, and why does the split matter?
A: 5.1 Leadership and commitment, 5.2 the AI Policy, and 5.3 Roles, responsibilities, and authorities. Each is checked differently — 5.1 through interview, to see whether leadership can explain the “why”; 5.2 through the policy document itself; and 5.3 through named accountability records like a RACI matrix.
If You Only Remember Five Things
- Know your AI role before you write policy — provider, producer, customer, partner, or subject (Clause 4).
- Risk assessment and impact assessment are separate, and both mandatory (Clause 6).
- The Statement of Applicability is your audit lifeline — document every inclusion and exclusion, with reasons.
- Competence and awareness need to be evidenced, not assumed (Clause 7).
- Corrective action needs a root cause, not just a fix (Clause 10).
This is a plain-language reference based on ISO/IEC 42001:2023(E), written for internal use and revisiting before reviews or audits. For anything that will actually bind the organisation, work from the full standard alongside a qualified AIMS or ISMS advisor.
Before You Get Started
AI isn’t the risk here. Using it without a plan is. These tools are already inside your business, whether IT approved them or not — the only real question is whether you can prove you’re managing that responsibly when someone asks.
Knowing the standard is one thing. Operationalizing it is another entirely. The policy, the risk register, the impact assessments, the Statement of Applicability, the audit trail regulators and customers will eventually demand — that’s not a weekend project, and it’s not something to squeeze in between everything else your team is already carrying.
That’s the gap Access0day closes. We don’t hand you a template and wish you luck — we build the AI Management System with you: assess where you actually stand, design controls that match how your business really runs, and get you audit-ready instead of audit-anxious. Talk to Access0day before governance becomes the thing that slows your AI roadmap down instead of the thing that protects it.
