An ISO 42001 checklist should help the board prove seven things: AI scope, leadership, risk planning, competence, operational control, management review and improvement, with Annex A controls selected from evidence rather than copied as policy text.
ISO/IEC 42001:2023 is the first international AI management-system standard and specifies requirements for establishing, implementing, maintaining and continually improving an artificial intelligence management system, or AIMS, for organisations that develop, provide or use AI systems (ISO). The board value is practical: the standard turns "we govern AI" into documents, owners, records and review cycles that can be inspected.
Key takeaways
- Use the checklist to prepare a board paper, audit committee pack or diagnostic brief, not as a promise that certification is already in reach.
- Start with scope. ISO says the standard applies to organisations that develop, provide or use AI-based products or services, so the first evidence item is a current inventory of AI systems in use (ISO).
- Treat leadership as evidence. BSI describes ISO/IEC 42001 as helping organisations establish, implement, maintain and continually improve an AI management system; for boards, that has to become scope, policy, risk, operation, monitoring and improvement evidence (BSI).
- Annex A should become a Statement of Applicability, control owners and operating records. Public control summaries list nine Annex A areas, from AI policy to third-party and customer relationships (ISMS.online).
- Use the AI Risk Register Generator to turn gaps into owned risks, then use the Board AI Scorecard or AI governance diagnostic to test whether the evidence is board-ready.
Who should use this and when
Use this checklist if a customer, regulator, investor, audit committee or procurement team has asked whether your organisation is aligned to ISO/IEC 42001. It is also useful before a formal readiness assessment, because BSI frames the route as understanding, preparing, implementing and then seeking independent assessment for certification (BSI). If the board question is budget rather than evidence, pair it with our ISO 42001 certification cost guide.
This is not a substitute for buying the standard or taking accredited certification advice. It is a board-level screen. It asks whether the organisation can show the governance artefacts that an AIMS depends on: a defined scope, policy, named accountabilities, AI risk and impact assessment, operational controls, monitoring, internal review and improvement records. For the longer explanation of how those clauses work, read ISO/IEC 42001 explained for boards.
What the board needs to decide
The board should minute four decisions before management turns this into a project plan.
- Scope: which AI systems, business units, geographies, suppliers and data flows sit inside the AIMS boundary.
- Accountability: which executive owns the AIMS, which committee reviews it, and where exceptions are escalated.
- Risk method: whether the organisation will use ISO/IEC 42001 alone, or run the NIST AI RMF's Govern, Map, Measure and Manage functions inside the AIMS. NIST describes those four functions as the core of its framework (NIST).
- Assurance route: whether the goal is internal alignment, customer assurance, or independent certification.
The decision matters because the UK does not operate through one AI Act for every use case. The government white paper sets five cross-cutting principles for regulators: safety, security and robustness; transparency and explainability; fairness; accountability and governance; and contestability and redress (GOV.UK). ISO/IEC 42001 gives the board one management-system spine, but sector law, UK GDPR and regulator expectations still decide what the controls must prove in context. Our UK AI regulation guide maps that landscape.
ISO 42001 checklist for board papers
| Area | Board question | Evidence to ask for | Owner |
|---|---|---|---|
| Scope and context | Do we know which AI systems are in scope? | AI inventory, supplier list, data-flow summary and rationale for excluded systems | AIMS owner |
| Leadership | Has the board set policy, objectives and accountability? | Approved AI policy, objectives, role descriptions and committee terms of reference | Chair, CEO or accountable executive |
| Planning and risk | Are AI risks and impacts assessed before deployment or major change? | Risk assessments, AI impact assessments, treatment plans and accepted residual risks | Risk lead and system owner |
| Support | Can the people involved evidence competence, awareness and resources? | Role-based training records, competence matrix, communications plan and resource decisions | People lead and AIMS owner |
| Operation | Are planned AI controls operating in live processes? | Change records, human review logs, test results, supplier approvals and incident procedures | Product, operations and technology leads |
| Performance evaluation | Does top management review whether the AIMS is working? | Monitoring metrics, internal audit findings, management-review minutes and action logs | Audit committee or board committee |
| Improvement | Are nonconformities corrected and lessons retained? | Corrective-action register, root-cause notes, updated controls and closure evidence | AIMS owner |
| Annex A controls | Have we selected controls because risks require them? | Statement of Applicability, control owners, evidence location and reasons for exclusions | AIMS owner and control owners |
The table follows the public standards-body description of an AIMS as a system that is established, implemented, maintained and continually improved (BSI). It also reflects how Annex A is commonly summarised: nine control areas from policies related to AI through internal organisation, resources, impact assessment, lifecycle, data, information for interested parties, use of AI systems, and third-party relationships (ISMS.online).
Evidence the board should ask for
A board paper should not say "control in place" without naming the record that proves it. If the organisation uses personal data, the ICO's AI governance and accountability audit framework asks for a documented and embedded privacy management framework endorsed by senior management for AI development, use and oversight (ICO). That is the standard of evidence to expect: endorsed, documented and embedded.
For secure AI, the NCSC-led secure AI system development guidance is organised around secure design, secure development, secure deployment, and secure operation and maintenance, with deployment and operation covering infrastructure protection, incident management, logging, monitoring and update management (NCSC). A board should therefore ask for operational records, not only policies.
For risk tracking, a static spreadsheet is weak evidence. Each open item should have a system, risk statement, owner, severity, control, evidence record, review date and next action. The working pattern is the same one we set out in making the AI risk register living evidence: the register has to change when the system changes.
Framework mapping
| Board evidence item | ISO/IEC 42001 use | NIST AI RMF use | UK regulatory use |
|---|---|---|---|
| AI inventory and scope | Defines the AIMS boundary and interested parties | Supports Map by identifying system context | Shows which sector rules and data-protection duties apply |
| AI policy and named owner | Supports leadership, objectives and accountability | Supports Govern through roles, policies and oversight | Addresses the UK principle of accountability and governance (GOV.UK) |
| Risk and impact assessment | Supports planning and Annex A control selection | Supports Map and Measure | Supports ICO accountability where personal data is involved (ICO) |
| Operational control evidence | Supports operation and selected Annex A controls | Supports Manage | Supports secure design, deployment and operation expectations (NCSC) |
| Management review minutes | Supports performance evaluation and improvement | Feeds Govern and Manage decisions | Shows the board has reviewed whether controls still match risk |
This is why ISO/IEC 42001 and the NIST AI RMF are not rivals. ISO/IEC 42001 gives the management-system evidence chain; NIST gives a working risk vocabulary. We compare the two in ISO 42001 vs NIST AI RMF, and we place both inside a wider UK AI governance framework.
Next step
Take the table above into the next board or audit committee meeting and mark each row red, amber or green. Red means no current evidence exists. Amber means evidence exists but is not owned, current or reviewable. Green means a named owner can produce the record today.
Then do one of three things. If the gap is the risk register, build a first version with the AI Risk Register Generator. If the board needs a fast baseline, complete the Board AI Scorecard. If procurement, a regulator or a customer is pressing for evidence, commission the AI governance diagnostic and map the findings against the UK AI Regulation Tracker. If certification is becoming a procurement condition, use the ISO 42001 certification cost guide before asking for audit proposals.
Sources: ISO/IEC 42001:2023 standard page; BSI ISO/IEC 42001 AI Management System; NIST AI RMF Core; ICO governance and accountability in AI; NCSC Guidelines for secure AI system development; GOV.UK pro-innovation approach to AI regulation; ISMS.online ISO 42001 Annex A controls summary.
