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

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 automatically produced (this is an illustrative scenario, not a real client).

Most engineering teams don't hit this problem because they're careless. They hit it because information security management systems were built for software that behaves predictably. AI agents don't.

What follows is a practical account of what the certification process actually requires, where agentic infrastructure creates friction, which controls need extending, and how to organise the work when agents are already running 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 services and solutions, the scope definition stage is where the process becomes materially more complex. And the complexity compounds the further along the process you get before addressing it.

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 don't work that way. That single difference reshapes four parts of the certification process.

Auditors expect documented evidence of what normal system behaviour looks like. For an AI agent, that definition doesn't emerge from a spec sheet. It has to be deliberately engineered. 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.

The supplier question is where most AI integration services projects run into friction they didn't anticipate. Most agentic frameworks, including LangChain and LangGraph, rely on calls to third-party LLM providers: OpenAI, Anthropic, Google DeepMind. Each of those is a supplier relationship under ISO 27001. Each needs a formal agreement, a risk assessment, and an exit strategy. On a typical project, there are three to six of these to address, and most teams haven't treated them 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 that monitoring activities (Annex A control A.8.16) generate logs 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 Centre, Planner, Evaluator, Orchestrator, and all agent-to-agent communication protocols. As CEO Alexandre Pereira explained: "Our clients are asking AI to operate autonomously on critical systems. ISO-27001 is our answer to that trust." 

Scope expansion when AI agents are involved is not optional. The question is whether you plan for it before the audit begins or discover it during.

The Annex A controls most affected by AI agents

The ISO 27001:2022 Annex A contains 93 controls. Six of them consistently require 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 must address data classification, processing limits, incident notification timelines, and audit rights, for OpenAI, Anthropic, Google DeepMind, and any other LLM provider in the chain. 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.16 — Monitoring activities

Agents must produce logs 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, 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

What happens when an AI agent fails mid-process? The ISMS must document 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 April 2026, the UK's National Cyber Security Centre (NCSC), the US Cybersecurity and Infrastructure Security Agency (CISA), and their Five Eyes partners published joint guidance on agentic AI security. Their position was unambiguous: "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. They're complementary, not competing.

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, analysis from Protech Group suggests the efficiency gain runs to 30 to 40 per cent.

This matters practically for companies in fintech software development and healthcare software development, where the EU AI Act's Article 9 risk management requirements, applying to high-risk AI systems from August 2026, overlap strongly with ISO 42001's control set. 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. Six steps address the points where teams consistently 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. For organisations running machine learning services or custom-built agents across multiple environments, every deployment instance needs to be tracked separately, along with its associated 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 April 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, not treated as 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 reflect all Annex A controls now applicable because of your AI agents, particularly A.5.19, A.5.23, A.8.16, A.8.24, A.5.30, and A.5.37. It must also 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 satisfies both the NCSC guidance and the EU AI Act's human oversight requirements for high-risk systems.

A discovery phase workshop can map agent dependencies before a formal ISMS scoping exercise begins. Getting scope right at the start costs a fraction of what it costs to correct it under audit pressure.

What auditors will look for — and where teams stumble

So what does an auditor actually examine when your infrastructure runs agentic systems?

Most teams preparing for AI infrastructure security certification focus on technical controls and underestimate the documentation requirements. On paper, this seems backwards. In practice, it's consistently where 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 the most common failure mode, and it's almost always fixable with two to four weeks of focused effort before the audit.

AI agent infrastructure tends to evolve faster than the governance artefacts meant to track it. Quarterly reviews of agent-related ISMS documentation, rather than annual ones, are becoming the practical standard for maintaining audit readiness. Business process automation tooling can sustain that cadence without placing an ongoing manual burden on the security team.

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 six Annex A controls most directly affected by AI agents (A.5.19, A.5.23, 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.

The organisations that achieve AI governance compliance without delays share one habit: they address agent scope, supplier agreements, and monitoring architecture before the auditor arrives.