ISO/IEC 42001: What Engineering Leaders Need to Know About the AI Management System Standard

AI is embedded in your engineering organization in ways you might not fully see: coding assistants, at 91% adoption across engineering organizations, generating pull requests, SDKs calling external models, MCP servers configured in developer environments, API keys scattered across repositories. The governance question is now whether you can prove you're managing it responsibly when auditors, enterprise buyers, or regulators ask.

ISO/IEC 42001 is the first international standard for an Artificial Intelligence Management System (AIMS), published in December 2023. It provides a framework for identifying AI systems, assessing risks, applying controls, and producing the evidence that demonstrates responsible AI governance. This article covers what the standard requires, how it differs from the EU AI Act, and what engineering teams actually need to change to support ISO 42001 readiness.

In this article:

• What is ISO/IEC 42001
• What ISO 42001 actually requires from engineering teams
• How ISO 42001 differs from the EU AI Act
• Practical steps toward ISO 42001 readiness
• Common mistakes engineering teams make with AI governance
• How Codacy supports ISO 42001 evidence collection

What is ISO/IEC 42001

ISO/IEC 42001 is the first international standard for an Artificial Intelligence Management System, often abbreviated as AIMS. Published in December 2023, it gives organizations a structured framework for governing AI responsibly across the entire lifecycle, from data collection and model selection through deployment, monitoring, and eventual retirement.

If you've already been through ISO 27001 certification, the structure will feel familiar. ISO 42001 uses the same Annex SL management-system architecture and follows the Plan-Do-Check-Act methodology. The key difference is scope: ISO 27001 addresses information security, while ISO 42001 addresses how organizations develop, deploy, and use AI systems responsibly.

Here's what's important to understand upfront: ISO 42001 is a management-system standard, not a technical testing checklist. Auditors will look for evidence that your organization has defined AI governance responsibilities, identified AI systems and use cases, assessed risks and impacts, applied controls, and established processes for monitoring and improvement. The question isn't whether you have an AI policy document sitting in Confluence. The question is whether you have a repeatable system that actually operates day to day.

What ISO 42001 actually requires from engineering teams

The standard organizes requirements around several operational areas. For engineering leaders, each of these translates into specific changes in how teams identify, approve, and govern AI usage.

Leadership and accountability

Someone in the organization has to own AI governance decisions. Not informal tool approvals over Slack. Not ad-hoc conversations during sprint planning. ISO 42001 expects clear accountability for AI-related decisions, with traceability back to who approved what and when.

For engineering teams, this typically means defining:

• Who can approve AI tools, models, SDKs, and development assistants: This includes coding assistants like GitHub Copilot or Claude, as well as AI APIs embedded in product code.
• Review paths for new AI capabilities: Before teams enable new AI features or integrations, there's a defined process for evaluation.
• Escalation paths for higher-risk use cases: Some AI applications warrant deeper review than others.
  
  

AI risk management

The standard expects AI-related risks to be identified, assessed, treated, and monitored. This isn't abstract. Engineering teams encounter AI risk in concrete forms: use of unapproved LLM APIs, sensitive data sent to external AI services, AI-generated code introducing insecure patterns, and AI dependencies with unclear provenance.

Risk records for AI systems and tools become part of the evidence auditors expect. These records map risks to controls and get reviewed when AI usage changes, not only during annual audits.

AI system impact assessment

Before deploying AI systems or making material changes, organizations are expected to understand how those systems may affect users, customers, employees, or regulated processes. Impact assessment covers data sources, intended use, model behavior, affected users, and failure modes.

Engineering teams often add AI impact checkpoints to design reviews or architecture reviews. Product AI features and internal development AI may require different assessment depth, but both fall within scope.

Lifecycle management

ISO 42001 expects organizations to manage AI systems across their full lifecycle: data sourcing, model selection or training, evaluation, deployment, monitoring, change management, and retirement. AI systems need lifecycle ownership, not one-time approval.

This means tracking models, SDKs, APIs, datasets, prompts, and configurations. Model updates and AI workflow changes are treated as controlled changes with documented evaluation and approval.

Third-party supplier oversight

Many organizations consume AI through vendors, SaaS features, APIs, SDKs, and coding assistants rather than building models internally. Risk often enters through the supply chain rather than through internally trained models.

Engineering examples include Copilot or other coding assistant configurations, Claude or OpenAI SDKs in code, AI-enabled CI/CD or testing tools, and MCP servers used by developers. Maintaining an inventory of third-party AI tools and services, reviewing vendor terms and data handling, and enforcing approved and unapproved AI service lists all fall within this requirement.

Operational controls

ISO 42001 requires controls that make governance real in daily work. For engineering teams, this means moving from policy documents to enforceable controls in IDE, Git, PR, and CI/CD workflows.

Relevant controls include:

• Approved AI tooling policies: Clear definitions of which AI tools and models are permitted.
• Repository scanning for AI-related artifacts: Automated detection of AI SDKs, model references, and configuration files.
• No-merge rules for unapproved AI models or tools: Blocking PRs that introduce prohibited AI dependencies.
• Secrets detection for AI API keys: Catching hardcoded credentials before they reach the repository.
• Workflow checks for AI-related configuration files: Validating that AI agent configs follow organizational standards.

The goal is to make violations visible at the point of change and standardize controls across repositories rather than relying on team-by-team interpretation.

Performance evaluation

The organization has to measure whether its AI management system is working. Dashboards showing policy compliance, detected AI issues, inventory completeness, and unresolved risk support both internal governance and external audits.

Engineering teams typically track AI policy exceptions, review unapproved tool usage trends, measure remediation time for AI-related issues, and feed findings back into policies and controls.

How ISO 42001 differs from the EU AI Act

These two frameworks solve different problems, and it's worth being precise about the distinction.

The EU AI Act is an external regulatory obligation with defined dates, duties, and penalties. It's law. ISO/IEC 42001 is a voluntary management-system framework for governing AI responsibly. It's a standard you can choose to adopt and certify against.

ISO 42001 is not currently a harmonized standard for EU AI Act conformity. However, it helps organizations build the operating model needed to respond to multiple external demands: EU AI Act expectations, DORA, NIS2, customer security reviews, enterprise procurement questionnaires, and internal risk committee requirements.

Think of it this way: regulations define what organizations may be accountable for. ISO 42001 helps define how the organization manages that accountability in practice.

Practical steps toward ISO 42001 readiness

Engineering teams can approach readiness in stages rather than attempting a comprehensive overhaul all at once.

1. Identify where AI is already used

Scan repositories for AI SDKs, model references, configuration files, workflow files, AI API keys, and developer-tool signals. Include product code, internal tooling, and development workflows.

Manual spreadsheets typically fail here because AI usage changes too quickly and repository-level evidence is fragmented across teams.

2. Define ownership

Assign owners for AI governance policy, AI tool approval, repository-level enforcement, risk assessment, third-party review, and audit evidence. Without clear ownership, governance becomes a documentation exercise rather than an operating system.

3. Classify AI use cases by risk

Separate developer productivity tooling from internal operational AI, customer-facing AI features, and AI used in regulated or high-impact decisions. Different risk levels warrant different assessment depth and control rigor.

4. Create enforceable policies

Define approved providers, models, SDKs, tools, and workflows. Define prohibited uses and escalation paths. Then implement controls in PR and CI/CD workflows so policies are enforced at the point of change rather than discovered during audits.

5. Build evidence continuously

Maintain your AI inventory and exportable AI Bill of Materials (AIBOM). Track exceptions and approvals. Review policy compliance regularly. Use findings to improve controls over time.

Common mistakes engineering teams make with AI governance

Several patterns consistently undermine ISO 42001 readiness:

• Treating the standard as a documentation exercise: Auditors look for evidence that 38 distinct controls operate, not just that policies exist.
• Relying on annual surveys to discover AI usage: AI adoption moves faster than survey cycles. By the time you ask, the tools are already in production.
• Assuming approved coding assistants are the only AI risk surface: AI SDKs, API keys, workflow files, MCP servers, and third-party AI-enabled services all introduce risk.
• Letting each team interpret AI policy differently: Inconsistent enforcement across repositories creates gaps that auditors and enterprise buyers will notice.
• Waiting for EU AI Act deadlines before building internal governance: The organizations that handle ISO 42001 well are the ones that build the operating model before the August 2026 deadline forces it.
  
  

How Codacy supports ISO 42001 evidence collection

ISO 42001 requires consistent operational evidence: what AI is used, where it appears, who approved it, what risks were assessed, and which controls are enforced. For engineering teams, this evidence lives in repositories, configuration files, commits, and workflows.

Codacy's AI Inventory scans connected repositories to detect AI-related artifacts: AI tool configurations, SDKs and libraries, model references, AI API keys, MCP server usage, and workflow indicators. This provides a continuously updated view of AI usage across the codebase rather than point-in-time surveys.

The AI Risk Hub centralizes visibility into AI policy compliance, detected AI issues, and inventory completeness across repositories. Engineering and governance stakeholders share a single dashboard for AIMS evidence.

For teams using AI coding assistants, AgentLinter scans AI agent configuration files (CLAUDE.md, AGENTS.md, .cursorrules, copilot-instructions.md) for quality, consistency, and risk. It detects exposed secrets, vague or conflicting instructions, and injection attack vectors in the files that govern how AI assistants behave in your codebase.

Policy enforcement capabilities allow teams to define no-merge rules for unapproved AI models or tools, surface AI policy violations in engineering workflows, and standardize AI controls across repositories. This converts policy into operational control and helps close the gap between defined rules and enforced rules.