Loading
Loading
3366 Members
Join Permit's SlackQuick answer: ISO 42001 certification means an external certification body has audited your AI management system against ISO/IEC 42001:2023. Use this guide when customers or regulators want third-party proof of AI governance. Don't expect ISO or any tool to certify you: it takes a documented management system and a two-stage audit, and it may be more than a team with a few low-risk AI features needs.
ISO 42001 certification means a certification body, ideally an accredited one, has audited your AI management system (AIMS) against ISO/IEC 42001:2023 and found that it conforms. ISO publishes the standard but does not certify anyone. Certification bodies do the audits, in two stages, and then keep auditing the system for the life of the certificate. For teams running AI agents, much of the audit is about proof: who could do what, what the agent actually did, and who approved it.
This guide explains what the certification involves, what the standard asks for, how the audits run, and where agent authorization and logging records fit in. The standard text is paywalled, so everything about clauses and controls below is our paraphrase, not a quotation. It is not legal or audit advice. Your certification body decides what it accepts.
ISO/IEC 42001:2023 ("Information technology, Artificial intelligence, Management system") was published in December 2023. ISO calls it the world's first AI management system standard. It specifies requirements for establishing, implementing, maintaining and continually improving an AIMS, and it applies to organizations that develop, provide or use AI-based products or services.
Certification is a third-party judgment. ISO states that it does not perform certification or issue certificates. External certification bodies do. Accreditation is how you check a certification body: an accreditation body formally recognizes that the certification body operates according to international standards. ISO notes that accreditation isn't compulsory, but it recommends checking for it. You can look up accredited bodies and certificates in the IAF CertSearch database or through your national accreditation body.
ISO's certification page states the division of roles directly:
ISO does not perform certification or issue certificates, and it does not permit anyone to use the ISO logo in connection with certification. Certification is performed by external certification bodies, thus a company or organization cannot be certified by ISO.
Source: ISO, Certification
For AI management systems there is now a dedicated rulebook for the auditors. ISO/IEC 42006:2025, published in July 2025, adds requirements for bodies that audit and certify AIMS against ISO/IEC 42001. It builds on ISO/IEC 17021-1, the general standard for bodies that certify management systems.
Accreditation bodies have started running programs on that basis. In the US, ANAB's ISO/IEC 42001 program lists ISO/IEC 42001:2023 and ISO/IEC 42006:2025 as requirements for certification bodies, alongside accreditation to ISO/IEC 17021-1. In the UK, UKAS granted its first ISO/IEC 42001 accreditation to BSI on 15 January 2026.
One practical distinction: "ISO 42001 compliant" or "aligned" is a claim an organization makes about itself. "ISO 42001 certified" means a certification body audited the AIMS and issued a certificate. That certificate should be traceable to a certification body you can look up.
ISO describes an AIMS as a set of interrelated elements of an organization that set policies, objectives and processes for the responsible development, provision or use of AI systems. It is a management system standard, run on Plan-Do-Check-Act, in the same family as ISO/IEC 27001. It is not a technical specification for any particular model.
In practice, an AIMS is not a model inventory, a risk register or a policy PDF on its own. It is the operating loop that connects them: scope, leadership, roles, risk and impact assessment, operational controls, monitoring, internal audit, management review, and improvement.
AI agents make that loop harder to close. An agent calls tools, reads data, opens tickets, changes records and talks to third-party systems, often acting on behalf of a person. An AIMS that covers agents has to show how those actions are scoped, controlled, recorded and reviewed, and it has to show that with records, not intentions. That is also the core of broader AI identity governance.
The requirements you are audited against sit in clauses 4 to 10. They follow the harmonized structure used by other ISO management system standards. Our paraphrase:
Clause 4, context of the organization. You determine your role in relation to AI (for example, developer, provider or user) and set the scope of the AIMS. Scope is where you name the AI systems, teams, environments and agent workflows that are in and out.
Clause 5, leadership. Top management sets the AI policy and assigns roles, responsibilities and authority. Auditors look for leadership that runs the system, not only for a signed policy.
Clause 6, planning. This clause holds most of the AI-specific work:
Clause 7, support. Resources, competence, awareness, communication and documented information.
Clause 8, operation. You run the processes you planned. That includes performing risk assessment (8.2), risk treatment (8.3) and impact assessment (8.4) and retaining the results.
Clause 9, performance evaluation. Monitoring and measurement, internal audit and management review. Evidence quality matters most here: can you show what happened, who reviewed it and what changed as a result?
Clause 10, improvement. Nonconformities, corrective action and continual improvement.
Annex A of ISO/IEC 42001 lists 38 reference controls grouped under nine control objectives, numbered A.2 to A.10. You don't have to implement all of them. Under clause 6.1.3, your risk treatment decides which controls you need, and the Statement of Applicability records the decision for each one. Annex B gives implementation guidance for the controls.
| Annex A | Control objective (paraphrased) | Examples relevant to AI agents |
|---|---|---|
| A.2 | Policies related to AI | AI policy, alignment with other policies |
| A.3 | Internal organization | A.3.2 AI roles and responsibilities, A.3.3 reporting of concerns |
| A.4 | Resources for AI systems | Data, tooling, compute and human resources |
| A.5 | Assessing impacts of AI systems | Impact assessment process and documentation |
| A.6 | AI system life cycle | A.6.2.6 operation and monitoring, A.6.2.7 technical documentation, A.6.2.8 recording of event logs |
| A.7 | Data for AI systems | A.7.5 data provenance |
| A.8 | Information for interested parties | A.8.4 communication of incidents |
| A.9 | Use of AI systems | A.9.2 processes for responsible use, A.9.4 intended use |
| A.10 | Third-party and customer relationships | A.10.2 allocating responsibilities, A.10.3 suppliers, A.10.4 customers |
A.6.2.8, AI system recording of event logs, is the control agent teams ask about most. In paraphrase, you decide at which life cycle phases event logging is enabled, and it has to be on at least while the AI system is in use. For an agent, "in use" is when it calls tools. So the useful log is the record of each tool call: which agent, acting for which person, requested which action on which resource, and whether the call was allowed or denied.
A.9, use of AI systems, is the other one worth planning early. Responsible use and intended use are easy to write down and hard to prove. If a support agent may read tickets but must not export customer records, that boundary is far easier to evidence when it is enforced as access policy and logged on every call than when it lives only in a policy document.
The audit process comes from ISO/IEC 17021-1, with ISO/IEC 42006 adding AIMS-specific requirements for the certification body. Both are paywalled, so this is a paraphrase of the model rather than of your certification body's contract. Expect your auditor to explain their own procedure.
Stage 1 reviews your documented information and your readiness. The auditor looks at the scope, the AIMS documentation, the Statement of Applicability, and whether you are ready for stage 2, and then plans stage 2. Weak scoping tends to show up here. If the scope doesn't say which AI systems, agent workflows, data flows, suppliers and customers are covered, the stage 2 plan has nothing firm to test.
Stage 2 evaluates whether the AIMS is implemented and effective. The auditor tests controls against real operation: risk and impact assessments that were actually performed, controls that are actually running, internal audits and management reviews that actually happened, and corrective actions that were actually closed. This is where operating records matter more than documents.
After certification, the certificate runs on a three-year cycle. Surveillance audits happen in the first and second years, and a recertification audit happens before the certificate expires. Evidence has to keep being produced for the life of the certificate, not assembled once for the initial audit.
This is where Permit comes in, and the scope is narrow on purpose. Permit does not make anyone ISO 42001 certified or compliant, and Permit.io is not ISO 42001 certified itself. Only a certification body can issue a certificate, and ISO recommends choosing an accredited one. What Permit provides is a set of authorization controls and records that can serve as evidence inside your AIMS, where your scope and Statement of Applicability include them. Our AI compliance hub maps the same evidence to other frameworks.
For agents, authorization is where intended use turns into runtime behavior. When an agent asks to call a tool or touch a resource, a policy decision allows or denies it based on the person, the agent, the resource, the action and the context. Each decision, and the record it leaves, is the kind of artifact an auditor can sample.
Decision logs. The Permit PDP records permit.check() decisions in the audit log with the timestamp, user, action, resource type, tenant and decision. It also keeps a decision log that explains why the request was allowed or denied. You can filter by user, date, decision and tenant, or pull entries through the List audit logs API. The logs forwarder can ship PDP decision logs to Elasticsearch so they sit with the rest of your telemetry. Where agents are in scope, these records can support A.6.2.8 event logging and give internal audit (clause 9.2) something concrete to sample. For log design, see authorization audit logs.
Tool-call records for agents. Permit MCP Gateway sits between MCP clients and MCP servers. It authenticates the person behind the agent, checks every tool call against policy in Permit, confirms the person consented to the agent's trust level (capped by a maximum the admin sets), and denies by default. Its audit logs record each allowed or denied call with the person, the agent, the tool, the MCP server and the time, plus the reason for denials. That record can support A.3.2 (each agent action tied to an accountable human), A.9.4 (intended use enforced, not only documented) and A.6.2.6 (denied calls as an operation and monitoring signal). See the MCP gateway page for the product view.
Approvals and intent. On Enterprise plans, human-in-the-loop approvals pause a sensitive tool call until an admin approves or rejects it. Agent Interrogation, available by contacting Permit, records the intent an agent declares and a fingerprint used to detect drift from its baseline. Approval and rejection records are evidence that a human oversaw high-risk actions. For the design side, see human-in-the-loop for AI agents.
Policy change history. With Permit GitOps, Permit writes the generated OPA Rego policy to a Git repository you own, one branch per environment. Policy changes then go through pull request review, tests and history. The Permit CLI's permit test run audit replays logged checks against a PDP and lists the decisions that would change. Together these show that access controls listed in your Statement of Applicability are versioned, reviewed and tested before they change. For access-review angles, see least-privilege evidence and explainable deny decisions.
Start the mapping from your side, not ours: AIMS scope, then risks, then Statement of Applicability, then which records prove each selected control. Authorization records fill some of those rows. They don't fill all of them.
Authorization evidence is one input to an AIMS, not the AIMS itself. It doesn't write or approve your AI policy (clause 5 and A.2). It doesn't show leadership commitment, competence or awareness, and it doesn't run a management review.
It doesn't replace the AI system impact assessment (6.1.4 and 8.4). A log shows what an agent did or tried to do. It doesn't assess consequences for individuals, groups or society, and it doesn't analyze foreseeable misuse.
It doesn't cover data quality or provenance (A.7). It can show that an agent was allowed to read a dataset, not that the dataset was fit for purpose or traceable. It doesn't validate a model or complete technical documentation (A.6.2.4, A.6.2.7).
And it doesn't conduct the internal audit, the stage 1 and stage 2 audits, or surveillance. The certification body decides whether your AIMS conforms. Tools produce controls and records, and people and auditors do the rest.
An external certification body, not ISO. ISO states that it does not issue certificates and recommends choosing an accredited certification body. Accreditation bodies such as ANAB and UKAS accredit certification bodies for ISO/IEC 42001. You can check a body or a certificate in IAF CertSearch.
ISO/IEC 42001 is a voluntary international standard. ISO itself doesn't make certification a legal requirement. In practice, whether you need it depends on customer contracts, procurement requirements and the regulators you answer to. This is not legal advice, so check the requirements that apply to you.
Annex A control A.6.2.8 covers event logging. In paraphrase, you decide at which life cycle phases event logs are recorded, and at minimum while the AI system is in use. The standard doesn't give a field list. For AI agents, the records auditors can use usually include tool calls, allowed and denied authorization decisions, the person each agent acted for, consent and approval records, and policy changes. What you log should follow your risk assessment and Statement of Applicability.
It covers what your AIMS scope covers. ISO/IEC 42001 applies to organizations that develop, provide or use AI systems, so agents are covered if they fall inside the scope you define under clause 4. Once they are in scope, risk assessment, impact assessment and the relevant Annex A controls apply to them.
Management system certificates run on a three-year cycle under ISO/IEC 17021-1 (paraphrased). Surveillance audits happen in the first and second years, and a recertification audit happens before expiry. You have to keep the AIMS running and improving throughout.
No. Only a certification body can certify your AIMS, after auditing it, and ISO recommends using an accredited one. Tools, including Permit, can implement controls and produce records that serve as evidence. They can't grant certification or make an organization compliant.
Co-Founder / CEO at Permit.io
