Framework

ISO/IEC 42001
AI management system standard for enterprise teams

ISO/IEC 42001:2023 (Information technology, Artificial intelligence, Management system) is the international management system standard for AI. Published December 2023, it specifies the requirements for establishing, implementing, maintaining, and continually improving an AI management system (AIMS) inside an organisation that uses, develops, or provides AI systems. The standard is certifiable, in the same shape as ISO/IEC 27001 for information security. This page covers the seven management-system clauses, the Annex A controls (A.2 through A.10), the AI roles the standard names, the failure modes recurring across early adoptions, the relationship with adjacent regimes (NIST AI RMF, ISO/IEC 23894, EU AI Act, ISO/IEC 27001, SOC 2, OWASP AI security lists), and the audit-grade evidence the certification body reads against.

Get Started Free

No credit card required. Free plan available forever.

ISO/IEC 42001 explained for AI governance, AppSec, and GRC teams

ISO/IEC 42001:2023 (Information technology, Artificial intelligence, Management system) is the international management system standard for artificial intelligence. Published in December 2023, it specifies the requirements for establishing, implementing, maintaining, and continually improving an AI management system (AIMS) inside an organisation that uses, develops, or provides AI systems or services. The standard is certifiable in the same shape ISO/IEC 27001 is certifiable: accredited certification bodies issue ISO/IEC 42001 certifications against a documented AIMS, and the management system discipline (leadership, planning, support, operation, performance evaluation, improvement) is the same family of requirements as the other ISO management system standards.

For internal security teams, AppSec teams, GRC and compliance teams, security engineering teams, product and engineering leads operating AI features, privacy and legal teams, and CISOs accountable for AI governance, ISO/IEC 42001 is the operating reference that holds the AI policy, the AI risk and impact assessments, the AI system lifecycle evidence, the supplier discipline, the human oversight discipline, the performance evaluation, and the continual improvement loop together. The standard sits alongside the NIST AI Risk Management Framework, the OWASP Top 10 for LLM Applications, the EU AI Act, and the broader information security regime as the management system spine that the rest reads against.

This page walks through the scope of the standard, the AI roles ISO/IEC 42001 names, the seven management-system clauses, the Annex A controls (A.2 through A.10), the failure modes the standard surfaces, the relationship with adjacent regimes, the evidence the certification body reads against, and where the AIMS operating record sits alongside the secure code review for AI-generated code guide and the vulnerability acceptance and exception workflow. Programmes that adopt 42001 produce one operating record from which the audit evidence, the regulator readiness, the customer assurance, and the executive reporting all read.

What ISO/IEC 42001 covers

The standard sits at the management system layer. It does not prescribe AI tooling, model architectures, or evaluation methodologies; it specifies the governance, the planning, the operating discipline, and the improvement cycle the organisation operates around the AI systems it builds, deploys, or sources. The companion standards in the ISO/IEC AI family (ISO/IEC 23894 for AI risk management guidance, ISO/IEC 5338 for AI system lifecycle processes, ISO/IEC 22989 for AI concepts and terminology, ISO/IEC 23053 for the framework of ML systems) carry the technical and process detail.

An AI management system standard

ISO/IEC 42001:2023 is an international management system standard, in the same family as ISO/IEC 27001 for information security and ISO 9001 for quality. It specifies the requirements for establishing, implementing, maintaining, and continually improving an AI management system (AIMS) inside an organisation that uses, develops, or provides AI systems or services. The standard is certifiable; accredited certification bodies issue ISO/IEC 42001 certifications against the documented AIMS in the same shape they issue ISO/IEC 27001 certifications against an ISMS.

Management system, not a tool catalogue

ISO/IEC 42001 is the management system layer. It names the governance, the policy hierarchy, the roles, the planning, the operation, the performance evaluation, and the improvement cycle. It does not prescribe specific AI tools, model architectures, evaluation suites, or testing harnesses. The companion documents (ISO/IEC 23894 for AI risk management guidance, ISO/IEC 5338 for AI system lifecycle processes, and the broader 22989/23053 vocabulary and framework family) carry the technical and process detail the management system reads against.

Distinct from regional regulation and from voluntary risk frameworks

ISO/IEC 42001 is international, voluntary, and management-system shaped. The EU AI Act is a regulation that creates legal obligations for providers and deployers of AI systems placed on the EU market. The NIST AI Risk Management Framework (AI RMF 1.0) is a US voluntary risk framework that names trustworthy AI characteristics and the four core functions (GOVERN, MAP, MEASURE, MANAGE). The three publications are complementary: 42001 is the operating spine, the AI Act is the regulatory consequence in the EU, and the NIST AI RMF is the risk-management vocabulary US federal customers and many enterprises read against.

AI roles the standard names

ISO/IEC 42001 distinguishes the roles an organisation plays in the AI value chain. The roles inform the scope decision in clause 4, the policy posture in clause 5, the planning in clause 6, and the operational controls in clause 8 and Annex A. Most organisations play more than one role: a SaaS company that builds AI features for customers is a provider and often also a deployer of third-party AI services inside its own operations.

  • AI provider: the organisation that develops or provides an AI system, an AI service, or an AI product. The AIMS for a provider focuses on the design, development, validation, documentation, and supply-chain disclosures of the AI systems shipped to customers.
  • AI developer: the organisation or team that designs and builds AI systems, often inside a larger provider or deployer. The AIMS evidence for a developer covers the lifecycle processes, the data management, the model evaluation, and the technical documentation.
  • AI deployer: the organisation that uses an AI system in its own business context, frequently sourced from an external provider. The AIMS for a deployer focuses on the intended-use compliance, the operating context monitoring, the human oversight, the affected-party communication, and the feedback to the provider when the deployment context exposes gaps.
  • AI user: the individual or organisation that interacts with an AI system, often inside a deployer. The AIMS for a user-heavy organisation covers user training, user-facing disclosures, the feedback mechanism, and the user-side incident reporting.
  • AI subject: the individual or community affected by an AI system. The AIMS does not require the affected party to operate the AIMS, but it does require the deployer and the provider to consider the affected party in the impact assessment, the disclosures, and the redress mechanism.

The seven management-system clauses

Clauses 4 through 10 form the management-system spine. They follow the harmonised high-level structure shared with ISO/IEC 27001, ISO 9001, ISO 14001, and the other ISO management system standards. Organisations already certified to ISO/IEC 27001 typically recognise the structure immediately and reuse the management review, the internal audit programme, and the documented information discipline already in place.

  1. 4

    Clause 4: Context of the organisation

    The organisation determines the internal and external issues relevant to the AI management system, the interested parties (regulators, customers, employees, affected communities, suppliers, civil society), the scope of the AIMS (which AI systems, business units, geographies, and intended uses are in scope), and the AI roles the organisation plays (AI provider, AI developer, AI deployer, AI user, affected party, and combinations). The scope and the role determination are anchor decisions; everything in clauses 5 through 10 reads against them.

  2. 5

    Clause 5: Leadership

    Top leadership demonstrates leadership and commitment to the AI management system, establishes and communicates the AI policy, assigns AI-related roles and responsibilities, and is accountable for the effectiveness of the AIMS. The AI policy is the public commitment the rest of the AIMS reads against. The roles and responsibilities are named (AI governance owner, AI risk owner, AI security owner, technical owners, business owners) rather than implied.

  3. 6

    Clause 6: Planning

    The organisation plans actions to address risks and opportunities to AI systems, sets AI objectives and the plans to achieve them, and plans changes to the AIMS. Planning includes the AI risk assessment (informed by ISO/IEC 23894 risk management guidance), the AI impact assessment, the AI objectives that the AIMS commits to, and the planned changes to the management system as the organisation scales, ships new AI systems, or moves into new jurisdictions.

  4. 7

    Clause 7: Support

    The organisation provides the resources, competence, awareness, communication, and documented information the AIMS needs. The competence requirement names AI literacy and AI-specific roles. The documented information requirement covers the policy, the scope, the risk and impact assessments, the operational records, the performance evaluation evidence, and the management review minutes.

  5. 8

    Clause 8: Operation

    The organisation operates the planned controls, the AI risk treatment, and the AI impact treatment. Clause 8 is where the AI system lifecycle processes (data collection and preparation, model development, validation, deployment, monitoring, decommissioning) run against the policy, the role responsibilities, and the documented controls from Annex A. Operation also covers AI system change management, the operational records the AIMS expects, and the supplier and third-party AI risk management discipline.

  6. 9

    Clause 9: Performance evaluation

    The organisation monitors, measures, analyses, and evaluates the performance of the AIMS, conducts internal audits on the planned cadence, and runs the management review with top leadership. Performance evaluation is the gate that turns the AIMS from a documented set of intentions into evidence of an operating system. The internal audit and the management review are the two recurring management-system activities the certification body reads against most directly.

  7. 10

    Clause 10: Improvement

    The organisation acts on nonconformities, takes corrective action, and continually improves the AIMS. Improvement is the closed-loop discipline that takes the findings from performance evaluation, internal audit, and external review back into the planning iteration. Nonconformity management is structured rather than informal; corrective actions are tracked through to closure with named owners and due dates.

Annex A controls (A.2 through A.10)

Annex A is the AI-specific control catalogue the AIMS reads against. It is structured similarly to ISO/IEC 27001 Annex A, but the controls are AI-specific rather than information-security-specific. The organisation produces a Statement of Applicability that records which Annex A controls are applicable, which have been implemented, and the justification for any exclusion. Each applicable control needs operating evidence the certification body can read against during the surveillance audit cycle.

A.2 Policies related to AI

The AI policy and the topic-specific AI policies (acceptable use, privacy, security, transparency, fairness, accountability) form the policy hierarchy the rest of the controls read against. The policies are documented, approved at the named level of authority, communicated, available where they are needed, and reviewed on the documented cadence.

A.3 Internal organisation

AI roles and responsibilities are assigned, the AI governance bodies and the cross-functional reporting lines are documented, segregation of duties is considered, and the contact with authorities and special interest groups is maintained. The named owners are accountable for the AIMS sub-areas; the audit pack reads against the named ownership rather than against assumed responsibility.

A.4 Resources for AI systems

The resources for the AI systems (data resources, tooling resources, system and computing resources, human resources, and the suppliers and third parties that contribute to the AI systems) are identified, documented, and managed. The resource inventory is the input clauses 6 and 8 read against when they plan and operate the AI systems.

A.5 Assessing impacts of AI systems

AI impact assessments evaluate the potential and actual impacts of the AI systems on individuals, groups, communities, society, and the organisation itself. Annex A.5 names the impact assessment as an explicit operating artefact rather than an optional review. The assessment results inform the AI risk treatment, the design and deployment decisions, the disclosure to affected parties, and the management review.

A.6 AI system lifecycle

The AI system lifecycle is documented and managed: the requirements, the design and development, the verification and validation, the deployment, the operation and monitoring, the maintenance, and the decommissioning. The lifecycle controls are the operating spine the technical AI work runs against, and they read against ISO/IEC 5338 (AI system lifecycle processes) for the underlying process model.

A.7 Data for AI systems

The data the AI systems consume is managed across acquisition, quality, provenance, preparation, and management. Annex A.7 names data quality, data provenance, and the data preparation lifecycle as explicit AIMS controls. Data quality is the input that data-driven AI systems inherit; programmes that treat data management as a separate concern outside the AIMS lose the audit thread between data and AI system behaviour.

A.8 Information for interested parties

Information about the AI systems is provided to interested parties (users, affected individuals, regulators, suppliers, and the public where applicable). The information includes the intended use, the limitations, the technical documentation, the explainability information, and the mechanisms for affected parties to raise concerns. The information is structured rather than ad hoc.

A.9 Use of AI systems

The AI systems are used inside the documented intended-use boundary, with the appropriate human oversight, and within the documented operating context. Annex A.9 names the operating discipline the deployer carries (human oversight where the impact assessment requires it, intended-use enforcement, monitoring of the deployment context against the design assumptions).

A.10 Third-party and customer relationships

Third-party AI suppliers, customer-facing AI services, and the relationships across the AI value chain are managed. The supplier discipline covers due diligence, contract clauses, monitoring, and incident handling. The customer-facing discipline covers the disclosures, the support model, and the feedback loop. Annex A.10 reads against ISO/IEC 27036 for the general supplier relationship discipline and against the EU AI Act for the regulated value-chain expectations when applicable.

Failure modes the standard surfaces

ISO/IEC 42001 is forgiving on the choice of tooling, the wording of the policy, the formatting of the risk register, and the cadence of the management review (so long as it is documented and held). It is unforgiving about a small number of patterns that turn the AIMS cosmetic rather than operational. The patterns below recur across early AIMS adoptions and are the ones that erode certification confidence most reliably.

  • Treating ISO/IEC 42001 as a one-off implementation project. The AIMS is a management system, not a documentation deliverable. Programmes that produce the policy hierarchy, the risk assessment, and the impact assessment as a project deliverable then return to business as usual lose the management review, the internal audit cadence, and the continual improvement loop the standard expects. Certification bodies read the recurring management activities (review, audit, corrective action closure) at least as carefully as the foundational artefacts.
  • AI risk and impact assessments without traceability to AI system inventory. Programmes that run a high-level AI risk assessment but cannot trace each material AI system to the assessment that informed its design and deployment decisions produce an audit pack that auditors and certification bodies read as decorative. The traceability between AI system, risk assessment, impact assessment, and operating control evidence is the readable spine of the AIMS.
  • Annex A controls treated as applicability statement only. Some programmes treat Annex A.2 through A.10 as a Statement of Applicability exercise in the shape of ISO 27001 Annex A, then never reread the controls during operation. ISO/IEC 42001 Annex A is structured similarly but the operational controls (A.5 impact assessments, A.6 lifecycle, A.7 data, A.8 information to interested parties, A.10 third-party relationships) need recurring evidence. The SoA is the entry point, not the destination.
  • AI risk register parallel to enterprise risk register. Programmes that maintain an AI-specific risk register without reconciling it with the enterprise risk register and the information security risk register produce three parallel risk views that drift apart. The integration with enterprise risk management is an explicit ISO/IEC 42001 requirement; the AI risk record needs to reconcile with the wider risk operating record.
  • Third-party AI suppliers treated as black boxes. Programmes that procure foundation models, AI-enabled SaaS services, or AI-component-bearing software libraries without applying Annex A.10 supplier discipline (due diligence, contract clauses, monitoring, incident handling) inherit the supplier risk without the operating record. ISO/IEC 42001 expects the supplier discipline to apply with AI-specific extensions (model lineage, training data provenance where available, evaluation results, intended-use boundaries, support and incident commitments).
  • No structured feedback loop from deployment monitoring back into design. Programmes that monitor AI systems in production but do not feed the monitoring signals back into the impact assessment, the risk treatment, or the design of subsequent AI systems lose the continual improvement loop the standard expects. The improvement cycle is part of the AIMS, not an aspirational endnote.
  • Operational records held in chat and shared drives. Programmes that hold the AI risk and impact assessments, the supplier reviews, the deployment monitoring evidence, the incident records, and the corrective action ledger in shared drives, ticketing systems, and chat channels produce reconstruction work at audit time. The AIMS expects structured records; reconstruction across email threads is the failure mode the standard surfaces most often.

How ISO/IEC 42001 relates to adjacent regimes

ISO/IEC 42001 sits in a busy regulatory and assurance neighbourhood. The relationships below are the ones programmes encounter most often when they read 42001 against the rest of the operating regime. Programmes operating across regions, sectors, and customer assurance demands use 42001 as the management system spine and read the NIST AI RMF, the EU AI Act, ISO/IEC 23894, ISO/IEC 27001, SOC 2, and the OWASP AI security lists as the contextual layers around it.

ISO/IEC 42001 vs ISO/IEC 27001

ISO/IEC 27001 is the information security management system standard; ISO/IEC 42001 is the AI management system standard. The two are designed to read together. An organisation already certified to ISO/IEC 27001 inherits the management system discipline (leadership, planning, support, operation, evaluation, improvement, internal audit, management review) and adopts the AI-specific scope, the AI policy hierarchy, the Annex A controls A.2 through A.10, and the AI risk and impact assessments. The two AIMS and ISMS records are typically operated against the same management review cycle, the same internal audit programme, and overlapping policy hierarchies.

ISO/IEC 42001 vs the NIST AI Risk Management Framework

NIST AI RMF 1.0 (NIST AI 100-1, with the GenAI Profile NIST AI 600-1) is a voluntary, sector-agnostic risk-management framework that names the four core functions (GOVERN, MAP, MEASURE, MANAGE) and the seven trustworthy AI characteristics. ISO/IEC 42001 is the international management system standard. The two are complementary: ISO/IEC 42001 provides the management system spine and the certifiable artefact; NIST AI RMF provides the risk-management vocabulary and the trustworthy AI characteristics that the AIMS risk and impact assessments read against. Organisations operating in both ISO and US federal contexts adopt 42001 as the management system reference and read NIST AI RMF as the technical and risk-management companion.

ISO/IEC 42001 vs ISO/IEC 23894

ISO/IEC 23894:2023 is the guidance standard for AI risk management. It supports the risk-management requirements ISO/IEC 42001 names in clause 6 (planning) and the operational risk treatment in clause 8 (operation). The two read together: 42001 names the requirement to manage AI risk, 23894 names the method. Programmes adopt 23894 as the underlying risk-management discipline (informed by ISO 31000 for the general risk management vocabulary) and use 42001 as the management system anchor.

ISO/IEC 42001 vs the EU AI Act

The EU AI Act is a regulation that creates legal obligations for providers and deployers of AI systems placed on the EU market. ISO/IEC 42001 is an international management system standard. The two are distinct in nature (regulation vs voluntary standard) but operationally reconcilable. Providers and deployers in scope for the AI Act use an ISO/IEC 42001 AIMS as the operating record from which the conformity assessment evidence, the technical documentation, the post-market monitoring, and the serious-incident reporting are produced. Harmonised standards under the AI Act will likely refer to the AIMS family; programmes adopt 42001 in advance of harmonisation to reduce the rework when harmonised standards are published.

ISO/IEC 42001 vs SOC 2

SOC 2 is a US assurance attestation framework using the AICPA trust services criteria (security, availability, processing integrity, confidentiality, privacy). It is not a management system standard and does not have an AI-specific scope. Service organisations operating AI-enabled services often hold both: a SOC 2 attestation that reads against the trust services criteria, and an ISO/IEC 42001 certification that reads against the AIMS. The two coexist because they answer different questions: SOC 2 asserts the controls operated effectively over a period; 42001 certifies that an AI management system exists and is maintained.

ISO/IEC 42001 vs the OWASP LLM and AI Top 10s

The OWASP Top 10 for LLM Applications and adjacent AI security top-10 lists are technical risk taxonomies for the application layer (prompt injection, training data poisoning, model denial of service, supply chain attacks against AI components, sensitive information disclosure, insecure plugin design, excessive agency, overreliance, model theft, and model output validation). ISO/IEC 42001 does not enumerate technical risks at that level; it requires the organisation to run an AI risk assessment that identifies them and an AI impact assessment that evaluates their potential consequences. The OWASP lists are useful inputs to the AIMS risk and impact assessments rather than substitutes for the management system.

Where SecPortal fits in an ISO/IEC 42001 programme

SecPortal is the operating layer for the security-relevant slice of the AIMS, not a replacement for the AI governance committee, the AI policy hierarchy, the model development tooling, or the model evaluation harness. The platform handles the AI-system security review record, the AI-related findings backlog, the AI supplier review evidence, the AI policy and impact-assessment artefacts, the management review pack assembly, the activity log that captures every change to the AIMS record, and the cross-framework evidence reconciliation so the artefacts the AIMS commits to are produced as structured records rather than reconstructed across drives at audit time.

  • Findings management with CVSS 3.1 scoring, CWE tagging, and 300+ structured templates so the security-relevant AI risks (prompt injection, insecure plugin design, supply chain compromise of model artefacts, sensitive information disclosure, output validation gaps) are tracked against the AI system in the same shape the wider security backlog is tracked. The AIMS risk register reads against the same finding catalogue rather than a parallel AI-only register.
  • Engagement management dedicated to AI system reviews, AI risk and impact assessments, third-party AI supplier reviews, and AI system go-live readiness, with one engagement record per assessment cycle so the AI system review trail walks alongside the broader security and audit programme rather than living in a side channel.
  • Document management for the AI policy, the AI topic-specific policies (acceptable use, privacy, security, transparency, fairness, accountability), the AI risk assessments, the AI impact assessments, the AI system technical documentation, the supplier review evidence, the internal audit reports, and the management review minutes, with version history per artefact so the policy refresh cadence and the continual improvement loop produce a defensible audit trail.
  • AI report generation that turns the structured AIMS record into the management review pack, the internal audit pack, the executive briefing on AI risk posture, the regulator-readable documentation, and the customer-facing AI transparency disclosure, working against the structured record rather than against unstructured policy drafts and emails. The reports inherit the calibrated risk levels, the affected-AI-system references, the timestamps, and the corrective action history from the AIMS record.
  • Activity log with CSV export that captures every state change on the AI system record, the AI risk record, the impact assessment, the supplier review, and the corrective action ledger, so an internal auditor, an accredited certification body, a customer reviewer, or a regulator can reconstruct the AIMS history without a multi-team excavation.
  • Compliance tracking that reads the same evidence pack across ISO/IEC 42001, ISO/IEC 27001 Annex A (where the security controls overlap), the NIST AI RMF (where the trustworthy AI characteristics inform the risk and impact assessments), SOC 2 (where AI-enabled services need trust services criteria evidence), and the EU AI Act (where the AI Act applies), so cross-regime reads are reconcilable rather than reconciled per audit.
  • Team management with role-based access (owner, admin, member, viewer, billing) that keeps the AI governance owner, the AI risk owner, the AppSec team, the GRC team, the product and engineering leads, the legal and privacy teams, and the supplier review owners on the same workspace with appropriate scoping per role, plus MFA enforcement on accounts that touch the AIMS record so the audit trail is identity-grounded.
  • Code scanning (Semgrep SAST plus dependency analysis) and repository connections via GitHub, GitLab, or Bitbucket OAuth on the same workspace as the AIMS record, so the AI system code and dependency review evidence (supply-chain risks for AI libraries, secret leaks in AI-related repositories, AI-component package metadata) walks alongside the AIMS supplier review rather than living in a separate tool.
  • Authenticated DAST (cookie, bearer, basic, form) and external scanning where the AI system is exposed as a service so the security review evidence for the AI deployment context is captured against the same operating record as the AIMS impact assessment.
  • Continuous monitoring schedules (daily, weekly, biweekly, monthly) so the post-deployment AI system monitoring evidence is produced against a documented cadence rather than ad hoc, supporting Annex A.6 lifecycle controls and the clause 9 performance evaluation discipline.
  • Encrypted credential storage (AES-256-GCM) for any privileged credentials needed during AI system review, scanner execution against AI-system targets, or post-incident verification, so the assessment activities are reproducible without leaving credentials in shared documents or chat channels.

For internal security teams operating ISO/IEC 42001 as part of the wider security operating baseline alongside ISO/IEC 27001 and the existing vulnerability and incident management programmes, the internal security teams workspace bundles the platform with the engagement structure the AI system review cadence reads against. For AppSec teams owning the technical review of AI-enabled features, the AppSec teams workspace covers the per-application review record AIMS clause 8 (operation) reads against. For GRC and compliance teams running the AIMS audit cycle and reconciling the evidence across ISO 42001, ISO 27001, SOC 2, NIST AI RMF, and the EU AI Act, the GRC and compliance teams workspace covers the policy hierarchy, the evidence pack, and the audit cadence the standard expects.

For deeper reading on the disciplines this standard reads against, the NIST AI Risk Management Framework page covers the voluntary US risk-management vocabulary the AIMS risk and impact assessments read against. The ISO/IEC 27001 page covers the information security management system the AIMS most commonly pairs with. The SOC 2 framework page covers the trust services criteria the AI-enabled service organisation also reports against. The OWASP Top 10 for LLM Applications guide covers the application-layer LLM risk taxonomy the AIMS risk assessment reads as an input. The secure code review for AI-generated code guide covers the per-PR review discipline the AIMS lifecycle controls operate against when developers ship AI-assisted code. The audit evidence retention and disposal workflow covers the records-management discipline the AIMS evidence pack walks against.

Key control areas

SecPortal helps you track and manage compliance across these domains.

Clause 4: Context of the organisation

The organisation determines the internal and external issues relevant to the AIMS, the interested parties, the scope of the AIMS (which AI systems, business units, geographies, and intended uses are in scope), and the AI roles played (provider, developer, deployer, user, affected party). Scope and role determination are the anchor decisions; the rest of clauses 5 through 10 read against them.

Clause 5: Leadership

Top leadership demonstrates commitment to the AIMS, establishes and communicates the AI policy, assigns named roles and responsibilities (AI governance owner, AI risk owner, AI security owner, technical owners, business owners), and is accountable for the effectiveness of the AIMS. The AI policy is the public commitment the rest of the AIMS reads against.

Clause 6: Planning

The organisation plans actions to address AI risks and opportunities, sets AI objectives, and plans changes to the AIMS. Planning includes the AI risk assessment (informed by ISO/IEC 23894), the AI impact assessment, and the documented AI objectives. Changes to the AIMS as the organisation ships new AI systems or enters new jurisdictions are planned rather than improvised.

Clause 7: Support

The organisation provides the resources, competence (including AI literacy), awareness, communication, and documented information the AIMS needs. The documented information requirement covers the policy hierarchy, the scope, the risk and impact assessments, the operational records, the performance evaluation evidence, and the management review minutes.

Clause 8: Operation

The organisation operates the planned controls, the AI risk treatment, and the AI impact treatment. Clause 8 is where the AI system lifecycle processes (data, model development, validation, deployment, monitoring, decommissioning) run against the policy and the Annex A controls. Operation also covers AI system change management, operational records, and supplier and third-party AI risk management.

Clause 9: Performance evaluation

The organisation monitors, measures, analyses, and evaluates the performance of the AIMS, conducts internal audits on the planned cadence, and runs the management review with top leadership. Internal audit and management review are the two recurring activities the certification body reads against most directly.

Clause 10: Improvement

The organisation acts on nonconformities, takes corrective action, and continually improves the AIMS. Improvement closes the loop from performance evaluation and audit back into the planning iteration. Nonconformity management is structured rather than informal; corrective actions are tracked through to closure with named owners and due dates.

Annex A: AI-specific controls (A.2 through A.10)

Annex A is the AI-specific control catalogue. A.2 policies related to AI, A.3 internal organisation, A.4 resources for AI systems, A.5 assessing impacts of AI systems, A.6 AI system lifecycle, A.7 data for AI systems, A.8 information for interested parties, A.9 use of AI systems, A.10 third-party and customer relationships. The Statement of Applicability records which controls are applicable, which are implemented, and the justification for any exclusion. Each applicable control needs operating evidence the certification body reads at surveillance audit.

Related features

Vulnerability management software that tracks every finding

Orchestrate every security engagement from start to finish

Compliance tracking without a full GRC platform

Document management for every security engagement

AI-powered reports in seconds, not days

Every action recorded across the workspace

Collaborate across your entire team

Find vulnerabilities before they ship

Run a defensible ISO/IEC 42001 AIMS on one operating record

Hold the AI policy hierarchy, the AI risk and impact assessments, the AI system review record, the supplier discipline, the lifecycle evidence, the activity log, and the management review pack on one workspace, then read the same record across ISO/IEC 42001, ISO/IEC 27001, NIST AI RMF, SOC 2, and the EU AI Act. Start free.

Get Started Free

No credit card required. Free plan available forever.