ISO 27001 vs ISO/IEC 42001: Which Certification Does Your Organisation Need for AI?

ISO/IEC 27001 helps an organisation manage information-security risk. ISO/IEC 42001 helps it manage the risks of designing, deploying, buying, or using AI. If your organisation uses AI only in limited, low-impact ways, strengthening an existing ISO 27001 information security management system (ISMS) may be the immediate priority. If AI affects customers, employees, operational decisions, regulated data, or core products, ISO 42001 provides the missing management-system layer for accountability, human oversight, fairness, transparency, and AI-specific risk.

The practical answer for most organisations is not “27001 or 42001?” but “what is the right sequence?” Start by understanding your AI use, data flows, and risk appetite. Build the security foundations that protect information and systems. Then add the governance processes that make AI use repeatable, reviewable, and defensible. The standards overlap in useful ways, but neither is a substitute for the other.

The difference in one sentence

ISO/IEC 27001 is an internationally recognised framework for an information security management system. It is designed to protect the confidentiality, integrity, and availability of information. ISO/IEC 42001 is an international framework for an AI management system. It is designed to help organisations govern AI responsibly across its lifecycle, from selection and design to monitoring, change, and retirement.

That difference matters because AI introduces risks that a conventional security programme does not fully address. A model can produce inaccurate or biased output, use information in ways users do not expect, drift after deployment, make recommendations that are difficult to explain, or trigger an action through an automated workflow. Those are not merely technical-security issues. They are questions of business ownership, impact, oversight, and acceptable use.

When ISO 27001 should come first

ISO 27001 is usually the more immediate priority when the organisation’s main concern is protecting information and systems. It is especially relevant if a company is responding to customer security questionnaires, preparing for enterprise procurement, handling sensitive client data, improving access control, or trying to establish repeatable risk-management and incident-management practices.

The standard helps organisations establish an ISMS: a managed set of policies, processes, records, roles, risk assessments, and controls. In practical terms, that means defining what information matters, assessing threats, choosing treatments, assigning ownership, collecting evidence, reviewing performance, and improving over time. Certification is not simply a set of documents; it requires an operating system for information security.

An organisation should not wait for a perfect technology estate before starting. However, it does need enough control over its assets, identities, suppliers, data, backups, and incident processes to make the management system real. A weak or purely paper-based ISMS will create extra work later when customers, auditors, or regulators ask for evidence that a control actually operates.

When ISO 42001 becomes the priority

ISO 42001 becomes particularly relevant when AI is material to how the organisation serves customers, manages people, makes decisions, or handles sensitive information. This includes organisations that develop AI-enabled products, embed AI features in customer-facing systems, use automated decision support in HR or finance, run agents with access to internal tools, or rely heavily on third-party generative-AI services.

The aim is not to certify that every model is perfect. The aim is to establish an AI management system that makes AI use intentional and governed. It asks the organisation to define objectives, responsibilities, AI risk processes, impact assessments, controls, monitoring, and improvement activities. It also provides a way to integrate AI governance with existing quality, security, privacy, and compliance management systems.

A useful trigger question is: could this AI system affect a person, a customer commitment, a financial outcome, a regulated process, or a business-critical decision? If the answer is yes, governance should move beyond an informal acceptable-use policy.

A simple decision guide

How the standards work together

The most efficient approach is to treat ISO 27001 as a security foundation and ISO 42001 as an AI-specific governance extension. Both standards use a management-system structure built around organisational context, leadership, planning, support, operations, performance evaluation, and continual improvement. That common structure allows shared governance routines rather than two disconnected compliance programmes.

For example, one risk-management process can include both information-security and AI risks. A single management review can examine security incidents, AI-system performance, major changes, supplier risks, and audit findings. An asset register can be extended into an AI system inventory. The organisation can re-use document-control, training, internal-audit, corrective-action, and leadership-review processes across both systems.

The work that remains distinct should stay distinct. ISO 27001 asks whether information is protected. ISO 42001 also asks whether AI use is appropriate, explainable enough for its context, fair, safe, monitored, and subject to meaningful human oversight. Treating AI as just another software asset misses that difference.

What to implement first: a 90-day preparation plan

Days 1–30: establish scope and ownership

Create an inventory of AI systems and uses. Include internally built models, third-party AI tools, embedded vendor features, copilots, chatbots, automated workflows, and AI agents. For each item, record its owner, purpose, users, data inputs, outputs, integrations, affected people, and business criticality.

At the same time, identify executive sponsorship. The organisation needs a decision-maker who can resolve trade-offs between speed, risk, cost, and customer commitments. Day-to-day ownership may sit with technology, security, data, product, compliance, or operations, but it should not be left ambiguous.

Days 31–60: assess risk and define controls

Use the inventory to prioritise systems by impact. High-priority systems generally involve sensitive data, customer-facing interactions, important decisions, financial or employment consequences, privileged system access, or external regulatory obligations. Document the risks in plain language before selecting controls.

Typical controls include approved-use rules, data-classification boundaries, identity and access controls, supplier due diligence, human approval points, prompt and output testing, monitoring, logging, incident escalation, model-change review, and user disclosure where relevant. The right controls are proportional to the use case; a meeting-summary tool does not need the same safeguards as an agent that can alter customer records.

Days 61–90: produce evidence and test the operating model

Create the records that show the programme works: risk assessments, approvals, training records, supplier reviews, access reviews, test results, incident logs, meeting minutes, and management-review actions. Run a tabletop exercise around an AI failure scenario, such as inaccurate customer advice, confidential-data exposure, or an agent acting outside its intended authority.

This is also the point to estimate the certification effort. Cost is driven less by the number of policies and more by scope, current maturity, number of sites and systems, supplier complexity, employee awareness, internal capability, and the time needed to collect evidence. A narrow, well-defined scope is usually faster and more affordable than attempting to certify every business process at once.

What practitioners need to document

A practitioner implementing the programme should expect to build and maintain the following working artefacts:

• An AI system inventory, with system owners, data inputs, intended use, users, integrations, risk level, and status.
• A documented AI governance policy and a clear role-and-responsibility model.
• AI risk and impact assessments that are reviewed when a system, model, data source, or use case changes.
• Supplier and third-party AI assessments covering security, privacy, contract terms, data handling, support, and service changes.
• Testing and acceptance criteria for AI outputs, including human review where required.
• Monitoring, logging, incident management, and corrective-action records.
• Training and communications appropriate to employees, managers, builders, reviewers, and end users.
• Internal-audit and management-review evidence showing the programme is evaluated and improved.

The point is not administrative volume. Each artefact should enable a better decision, prove a control operates, or make a future review easier. If a document has no owner, no review date, and no operational use, it is unlikely to help during an audit or incident.

Certification is a milestone, not the operating model

Certification can improve trust with customers, investors, partners, and procurement teams. It can also bring focus to work that should exist regardless of certification: knowing how AI is used, protecting data, assigning accountability, testing meaningful risks, and keeping evidence of decisions.

But certification alone does not make an AI system lawful, accurate, unbiased, or appropriate for every context. Organisations still need to consider their contracts, industry rules, privacy obligations, and the specific harms that an AI system could create. Treat the standard as a disciplined management framework, not a shortcut around sound judgement.

Need help turning AI governance or ISO readiness into a practical operating programme? Managed Company can help map your current environment, define a proportionate scope, build the evidence and controls that matter, and integrate AI governance with your wider security and compliance work. Explore Growth & Compliance support.