ISO 42001
ISO 42001 (ISO/IEC 42001:2023) is the international standard for an artificial intelligence management system (AIMS): the policies, roles, risk assessments, and review processes an organization uses to develop, provide, or use AI responsibly. Applied to agentic AI, coding agents, enterprise assistants, and internal agents that call tools sit in that AIMS scope the same way any other AI system does.
ISO 42001 (ISO/IEC 42001:2023) is the international standard for an artificial intelligence management system (AIMS): the policies, roles, risk assessments, and review processes an organization uses to develop, provide, or use AI responsibly. Applied to agentic AI, coding agents, enterprise assistants, and internal agents that call tools sit in that AIMS scope the same way any other AI system does.
If your organization already uses ISO 27001, much of the structure will feel familiar, but the standards have different priorities. ISO 27001 deals with information security, while ISO 42001 deals with how an organization develops, provides, or uses AI. That distinction matters for coding agents on employee laptops and assistants connected to systems such as Salesforce.
Our ISO 27001 for agentic AI guide maps 14 information-security controls to agents and their tool calls. This guide covers the AI management side, including what auditors may ask for and how runtime records can support the work.
What is ISO 42001?
ISO published the first edition of the standard in December 2023. Its formal reference is ISO/IEC 42001:2023, and it was developed by ISO/IEC’s AI standards committee, JTC 1/SC 42. It applies to organizations of any size that develop, provide, or use AI products and services. ISO’s public FAQ says it was designed to work across different AI applications and contexts.
In practice, an AIMS brings AI governance into the organization’s regular management processes. ISO defines it as the policies, objectives, roles, and processes used to manage the responsible development, provision, or use of AI. It follows the same Plan-Do-Check-Act cycle used by management standards such as ISO 9001, ISO 14001, and ISO 27001.
ISO 42001 asks an organization to:
- Decide which AI systems and uses belong in scope.
- Assign responsibility and set an AI policy.
- Assess AI risks and potential impacts.
- Manage AI systems through operation and change.
- Review whether the program works and improve it over time.
For teams working directly from the standard, clauses 4 through 10 organize these requirements:
| Clause | What it covers |
|---|---|
| 4 | The organization’s context and the scope of its AIMS |
| 5 | Leadership, roles, and the AI policy |
| 6 | Planning, including AI risk assessment, risk treatment, and impact assessment |
| 7 | People, resources, communication, and documented information |
| 8 | Operation across the AI system life cycle |
| 9 | Monitoring, internal audit, and management review |
| 10 | Corrective action and continual improvement |
Annex A provides 38 reference controls under nine objectives, A.2 through A.10. The organization chooses the controls that fit its risks and explains those choices in a Statement of Applicability.
Certification is optional and carried out by an independent certification body, which may itself be accredited by a national accreditation body. ISO defines and publishes the standard, while the certification body audits the organization and issues the certificate.
Does ISO 42001 apply to AI agents?
The public standard uses the broader term AI systems rather than naming AI agents. Its scope can include a coding agent on an employee laptop, a ChatGPT Enterprise assistant connected to a CRM, or an internal agent that calls a production API. Organizations should assess these agents alongside other AI systems.
That does not put every agent in scope automatically. Clause 4.3 requires the organization to set the boundary of its AIMS. That decision should reflect how each agent is used, the risks it creates, and the requirements of people or groups affected by it. An agent installed directly by an employee still deserves that assessment, even if it never went through a formal procurement process. This is where shadow AI becomes an AI governance issue.
The standard also covers organizations that use AI without training their own models. A supplier’s SOC 2 or ISO 27001 report can support vendor due diligence, but the customer still needs to manage its own use of the AI system.
ISO 42001 describes what the management program should cover and leaves technology choices to the organization. It does not require Model Context Protocol (MCP), Okta, or a particular log format. Runtime records become important when an organization needs to show what an agent did and how its policies were applied.
How does ISO 42001 compare to ISO 27001?
ISO 42001 and ISO 27001 use a similar management-system structure, but they focus on different risks. ISO 27001 covers information security, while ISO 42001 covers the responsible development and use of AI. Each standard has its own certification, although ISO also sells them together as an AI and information-security management package.
| ISO/IEC 27001:2022 | ISO/IEC 42001:2023 | |
|---|---|---|
| What it manages | Information security management system (ISMS) | Artificial intelligence management system (AIMS) |
| Main question | How does the organization protect its information? | How does the organization manage AI responsibly? |
| Main risk | Confidentiality, integrity, and availability of information | Responsible development, provision, and use of AI systems |
| Reference controls | 93 controls in four themes | 38 controls under nine objectives, A.2 through A.10 |
| Focus for agents | Access, data protection, security monitoring, and incident response | Purpose, accountability, impact, oversight, and review |
| Question for an agent | Is the agent inventoried, identified, restricted, logged, and revocable? | Does the organization govern the agent through policy, impact assessment, life-cycle control, and operating evidence? |
An organization that already uses ISO 27001 will recognize processes such as document control, internal audits, management reviews, and corrective action. It may be able to reuse some of that work. ISO 42001 still requires the organization to address AI-specific topics such as impact assessments, responsible use, data, life-cycle controls, and oversight of AI suppliers.
The two standards work alongside each other. Where a runtime record supports controls in both systems, the organization can reference it in both Statements of Applicability. Our ISO 27001 for agentic AI guide explains the information-security side in more detail.
ISO 42001 audit evidence for AI agents
An ISO 42001 audit looks at how the organization manages AI in practice. A model card may form part of the evidence, but the auditor will look across the wider management system.
The exact request depends on the organization’s scope and chosen controls. Common documents include:
- The scope of the AI management system and the AI policy.
- Risk and impact assessments.
- A record of who is responsible for each part of the program.
- Internal-audit results and management-review minutes.
- The Statement of Applicability, which explains the controls the organization selected.
A GRC platform can hold much of this documented package.
Written policies set expectations, while operating records show whether those expectations were followed. For agents, an auditor may look for evidence in these areas:
-
Event logs (A.6.2.8). The organization decides when logs are needed and what they should contain. For agents, useful evidence often covers two surfaces:
- Conversation records show what the model received and produced.
- Action records show the tool, its arguments, the target system, the caller’s identity, the response, and the time of the call.
Together, these records can help reconstruct behavior, investigate an incident, and detect activity outside intended conditions. The agent compliance guide explains what vendor compliance APIs may capture.
-
Responsible use (A.9). The organization documents what an agent is for, who may use it, and when its use should pause or stop. An acceptable-use policy in Confluence cannot show whether a specific user was allowed to call
delete_repositoryat 14:03. Tool-level policies can apply the rule at the time of the request and record the decision. -
Ownership and suppliers (A.3.2 and A.10). Accountability should cover the agent and the external models, MCP servers, and data sources it depends on. A.10.2 covers the allocation of responsibility, while A.10.3 covers suppliers. An externally supplied MCP server may therefore need a named owner and a supplier review. An internal MCP server is not automatically a third party.
-
Impact assessments (A.5). The organization considers how an agent could affect individuals, groups, and society, including foreseeable misuse, and retains the assessment. An agent that can access customer records or change production systems may need closer review.
-
Operation and monitoring (A.6.2.6). The organization defines how the agent runs day to day, who owns failures and updates, and what happens when it behaves outside its intended conditions. Tool-call monitoring can cover actions against internal systems that a chat product’s admin console may not see.
GRC integrations can help collect policies, vendor details, and user records. If Vanta or Drata connects to an OpenAI or Anthropic account, verify exactly what that connector imports. A synced user roster is different from a conversation record or tool-call log. Any missing runtime evidence must come from another system.
How runtime evidence supports ISO 42001 for AI agents
The organization owns its AI management system and decides which controls it needs. Speakeasy’s narrower role is to enforce rules while agents are running and record what happened.
The Speakeasy AI Control Plane sits between agents and the tools they call. Agents can connect through Speakeasy-hosted MCP endpoints. Agent hooks can apply the same controls to coding agents before a tool call runs on an employee’s machine.
Identity. The platform connects to the organization’s identity provider through single sign-on (SSO). Supported providers include Okta, Microsoft Entra ID, Auth0, WorkOS, Google Workspace, and Ping Identity, along with any SAML or OIDC provider. Each session can then be tied to a named user instead of an anonymous or shared credential. Every MCP server behind the MCP gateway inherits that authentication. The gateway can add OAuth 2.1, Dynamic Client Registration, and PKCE when the upstream server does not provide them.
Policy. Role-based access can be set for an MCP server, a group of tools, or one specific tool. The platform evaluates those rules on the request path before the tool runs, rather than relying on a laptop configuration. Disallowed actions are denied, while judgment calls can pause for human acknowledgement. The audit record captures the denial or acknowledgement with the request.
Audit. Every tool call, access event, and permission change is logged and searchable. A tool-call record includes the user, server, tool, arguments, target system, response, and time. Speakeasy uses the same record format across Claude, ChatGPT, Cursor, Copilot, and internal agents, and the logs can be exported to the organization’s SIEM.
These capabilities can support the controls an organization selects for its AIMS. The organization still needs to write the AI policy, complete its assessments, review the program, and work with its auditor. For related information-security controls, see ISO 27001 for agentic AI. The agent compliance guide covers the records available from AI vendors.
ISO 42001 can help an organization manage its compliance work, but it does not replace laws or regulations. The EU AI Act, for example, is a separate legal regime with its own risk classifications, conformity-assessment requirements, and penalties.
To see how identity, policy, and audit records work across an agent’s tool calls, talk to us.