How Do You Achieve ISO 27001 Certification When Your Infrastructure Runs AI Agents?

Consider an illustrative scenario (not a real client). A Series B fintech company in the Nordics spent eighteen months preparing for ISO 27001 certification. Asset inventories were documented, supplier agreements were signed, and monitoring controls were running across production. Then the auditor asked a single question about their new LLM-based underwriting agent. The agent called external APIs, produced recommendations that fed into credit decisions, and wrote outputs to a cloud store that sat entirely outside the documented ISMS boundary. Certification stalled for four months while the team extended their asset register, renegotiated supplier contracts, and built the audit trail the agent had never produced.

Information security management systems were built for software that behaves predictably. AI agents that call tools and external models break that assumption.

This article covers what certification requires, where agentic infrastructure creates friction, which controls need extending, and how to organise the work when agents already run in production.

What ISO 27001 certification actually requires

ISO 27001 is the international standard for information security management systems (ISMS). Certification means demonstrating to an accredited third-party auditor that your organisation systematically identifies, manages, and reduces information security risks across people, processes, and technology, including any AI agents operating within your ISMS boundary.

The current version, ISO 27001:2022, was published in October 2022. It introduced 11 new controls in Annex A and reorganised the control set into four themes: organisational, people, physical, and technological. Go Wombat holds ISO 27001:2022 certification and applies these controls across our cybersecurity consulting engagements and client delivery environments.

The process follows five stages in sequence. Scope definition establishes which systems, data flows, and business processes fall inside the ISMS boundary. Risk assessment identifies threats and vulnerabilities across all in-scope assets. The Statement of Applicability (SoA) documents which Annex A controls apply, which don't, and why. Risk treatment implements controls to bring identified risks to an acceptable level. Finally, internal audit and management review validate the ISMS before an external auditor conducts the two-stage certification audit.

For companies deploying AI solutions, scope definition is where the process becomes noticeably more complex, and the later it is addressed, the harder it gets.

Why AI agents change the certification equation

Traditional software is deterministic: you define its inputs, it produces predictable outputs, and you can document both. AI agents are not, and that affects four parts of the certification process.

Auditors expect documented evidence of what normal system behaviour looks like. For an AI agent, that definition has to be engineered deliberately; it does not come from a spec sheet. An agent may return different results for identical inputs depending on model version, context window state and tool availability. What counts as "expected" is a question engineering teams often haven't formally answered before the audit begins.

Supplier management is where most AI integration projects hit unplanned work. Most agentic frameworks, including LangChain and LangGraph, rely on calls to third-party LLM providers such as OpenAI, Anthropic and Google. Each of those is a supplier relationship under ISO 27001, and each needs a formal agreement, a risk assessment and an exit strategy. Teams often haven't treated these providers as suppliers at all.

Then there's access control. An agent that triggers actions, writes to databases, or calls downstream APIs on its own initiative expands the attack surface in ways that conventional access control models weren't designed to handle. The agent needs its own identity, its own access review cycle, and defined boundaries on what it can initiate without a human in the loop.

Audit trail gaps close the list, though they're often the most time-consuming to fix. ISO 27001:2022 requires logs of activities, exceptions, faults and other relevant events to be produced, stored, protected and analysed (Annex A control A.8.15, Logging), and systems to be monitored for anomalous behaviour (A.8.16, Monitoring activities). Together, they must give an audit trail complete enough to support incident investigation. Most agent orchestration frameworks don't produce structured, tamper-resistant logs by default. Building that layer is typically custom work.

In July 2025, 2501.ai, a Paris-based company building autonomous AI agents for enterprise IT operations across cloud, hybrid, and on-premise infrastructure, achieved ISO/IEC 27001 certification by bringing its full agentic stack inside ISMS scope: the Command Center (covering its Engine, Planner, Evaluator, and Orchestrator), its cloud, on-prem, and hybrid deployment layers, and its agent-to-agent protocols, plugins, and gateways. As CEO Alexandre Pereira explained: "Our clients are asking AI to operate autonomously on critical systems. ISO-27001 is our answer to that trust." 

When AI agents are involved, the ISMS scope has to expand. The only choice is whether you plan for it before the audit or discover it during.

The Annex A controls most affected by AI agents

The ISO 27001:2022 Annex A contains 93 controls. These are the ones that need the most attention when agentic infrastructure is in scope.

A.5.19 — Information security in supplier relationships

Every third-party AI API your agents call is a supplier relationship. Agreements with OpenAI, Anthropic, Google and any other LLM provider in the chain must address data classification, processing limits, incident notification timelines and audit rights. If the GDPR consulting work your organisation has done already includes data processing agreements with these providers, that work feeds directly into A.5.19. It's rarely wasted effort; it just needs to be pulled into the ISMS formally.

A.5.23 — Information security for use of cloud services

Agents running on cloud infrastructure or calling cloud-hosted models require documented security requirements for each service: data residency, encryption standards, access restrictions. Vague references to "cloud infrastructure" don't satisfy an auditor reviewing this control.

A.8.15 and A.8.16 — Logging and monitoring activities

Monitoring only works if agents produce logs (A.8.15) that are complete, structured, and retained long enough to support investigation. In practice, this means configuring the orchestration layer to write time-stamped, tamper-resistant records of every action the agent takes, every tool it calls and every output it generates. That logging layer is typically custom-built; it doesn't come out of the box.

A.8.24 — Use of cryptography

Data that agents process or transmit must be protected in transit and at rest, with particular care for agents handling personal or financial data where encryption requirements also need to align with regulatory obligations outside the ISMS.

A.5.30 — ICT readiness for business continuity

If an AI agent fails mid-process, the ISMS must show how the affected business process continues without it, including manual fallback procedures that don't assume the agent is available.

A.5.37 — Documented operating procedures

Every significant operational process needs documented procedures. For AI agents, this includes deployment, updates, access reviews, and decommissioning, each of which tends to happen more frequently than with conventional software.

In May 2026, the UK's National Cyber Security Centre (NCSC), the US Cybersecurity and Infrastructure Security Agency (CISA), the NSA and their Five Eyes partners published joint guidance on the careful adoption of agentic AI services. Introducing it, the NCSC put the principle bluntly: "If you cannot understand, monitor or contain an agent's actions, it is not ready for deployment." That standard is now what auditors increasingly expect organisations to demonstrate.

Where ISO 42001 fits in — and where it doesn't

ISO/IEC 42001:2023, published in December 2023, is the world's first AI management system standard. It covers territory that ISO 27001 was never built for: algorithmic fairness, model bias, AI-specific transparency obligations, and the governance structures needed to oversee AI responsibly across an organisation.

The two standards address different layers of the same problem and complement each other.

For most organisations, ISO 27001 is the right first step. It establishes the ISMS foundation, the risk assessment process, and the supplier management structure that AI governance builds on top of. Organisations that already hold ISO 27001 certification tend to align with ISO 42001 significantly faster because the management system disciplines transfer; Protecht Group reports, from its client work, that ISO 27001-certified organisations reach ISO 42001 compliance 30 to 40 per cent faster than those starting from scratch.

This matters in fintech and healthcare, where the EU AI Act's Article 9 risk management requirements overlap strongly with ISO 42001's control set. Following the Digital Omnibus on AI (Regulation (EU) 2026/1744), those requirements apply to high-risk AI systems listed in Annex III from 2 December 2027. Aligning with both in a single workstream is considerably more efficient than retrofitting them separately. Our approach to responsible AI governance covers this dual-standard alignment for teams starting that planning now.

Practical steps to certify with AI agents in scope

The ISO 27001 implementation path changes when AI agents are part of your infrastructure. The six steps below address the points where teams most often run into delays.

Step 1. Extend your asset inventory to include agents as assets

An AI agent is an information asset. Document each one: name, version, purpose, data inputs, data outputs, external dependencies, and the identity or role that controls it. If you run machine learning models or custom-built agents across several environments, track every deployment instance separately, along with its data flows.

Step 2. Map every external API call as a supplier relationship

Pull the full list of third-party services your agents call: LLM providers, tool APIs, retrieval services, data sources. Each needs a formal supplier assessment under A.5.19. In practice, this means reviewing the provider's security documentation, confirming data processing terms, and deciding whether their posture sits within your risk appetite.

Step 3. Assign agent identities and access boundaries

Agents shouldn't run under shared credentials or over-privileged service accounts. Each needs its own identity, scoped to the minimum access required for its function. The NCSC's May 2026 guidance is explicit on this point: apply least privilege, constrain the agent's scope, and avoid long-lived credentials. Agent access reviews belong in the standard access management cycle rather than in a separate process.

Step 4. Build a structured monitoring and logging layer

Your agent orchestration framework needs to write structured, tamper-resistant logs capturing every action the agent takes. Whether you use LangGraph, LangChain, or a proprietary framework, this typically requires a custom callback or middleware layer, and those logs must feed into your security monitoring tooling, not sit in isolation in an agent-specific store.

Step 5. Update the Statement of Applicability

The SoA must show how your AI agents are covered by the applicable Annex A controls, particularly A.5.19, A.5.23, A.8.15, A.8.16, A.8.24, A.5.30 and A.5.37, and justify any excluded controls. Auditors examine SoA exclusions closely when AI infrastructure is in scope.

Step 6. Document human oversight and escalation paths

Every agent that takes consequential actions needs a defined escalation path: who monitors its behaviour, who can override it, and who is accountable when something goes wrong. This supports the NCSC guidance and is part of the EU AI Act's human oversight requirements for high-risk systems. Article 14 goes further: the system must be designed with oversight tools, and the people overseeing it must be able to override or reverse its output and stop it.

A discovery phase workshop can map agent dependencies before a formal ISMS scoping exercise begins. Getting scope right at the start is far cheaper than correcting it under audit pressure.

What auditors will look for — and where teams stumble

Most teams preparing for certification with AI infrastructure focus on technical controls and underestimate the documentation. Yet documentation is where many non-conformity findings originate.

Common audit flags when AI agents are in scope:

• Incomplete asset registers 

Agents are not listed, or listed without data flows and external dependencies documented

• Missing supplier agreements 

Third-party LLM API terms not formally reviewed or not aligned with the organisation's data classification policy

• Unstructured agent logs 

Monitoring in place but logs not structured or retained long enough to support incident investigation

• SoA gaps 

AI-related controls absent from the Statement of Applicability, or marked inapplicable without justification

• No agent identity access reviews 

Agents running under shared credentials with no scheduled review cycle

• Absent continuity procedures 

No documented fallback when an AI-dependent process fails

You can design a technically sound AI compliance framework and still receive a non-conformity finding because the documentation doesn't reflect what the system actually does. That gap is a common failure mode, and it is best closed before the audit begins.

AI agent infrastructure tends to evolve faster than the governance artefacts meant to track it. We recommend reviewing agent-related ISMS documentation quarterly rather than annually. Business process automation helps here: export agent inventories and access lists on a schedule, so each review starts from current data.

Key takeaways

ISO 27001 certification is achievable with AI agents in scope. The key is deliberate decisions about what enters the ISMS boundary, not just the security controls that surround it.

The Annex A controls most directly affected by AI agents (A.5.19, A.5.23, A.8.15, A.8.16, A.8.24, A.5.30 and A.5.37) are all addressable. They require documentation that most agent frameworks don't produce by default, and closing that gap needs to happen before an audit begins.

ISO 42001:2023 and ISO 27001:2022 are complementary standards. For organisations building AI agents in regulated sectors, aligning with both in a single workstream is more efficient than treating them as separate programmes.

To avoid delays, address agent scope, supplier agreements and monitoring architecture before the auditor arrives.