GMD AutomationVisit Website →
← Back to blog

Audit Ready AI: ISO 27001 for Practical ISMS Controls

September 7, 2026
Audit Ready AI: ISO 27001 for Practical ISMS Controls

Yes, ISO 27001 applies to AI, and if your information security management system doesn't yet treat models, training data, and inference pipelines as information assets, that's the gap to close first. Bring every AI component into scope, add AI-specific entries to your risk register, and start logging model inputs and outputs continuously. The mapping and step-by-step sections below show exactly how.

TL;DR:

  • Most AI assets, including models, data, and credentials, should be incorporated into existing ISO 27001 asset registers with clear ownership and classification.
  • Six AI-specific risks such as model poisoning, prompt injection, and data leakage must be added to the risk register and addressed with targeted controls and evidence.
  • Mapping AI risks to ISO controls requires focusing on change management, access control, and privacy, supported by technical standards like OWASP AISVS and ETSI EN 304 223 for verification.
  • Incorporating AI into the ISMS should follow a step-by-step approach, starting with mapping data flows, assigning owners, and establishing continuous logging and version tagging practices.
  • Combining ISO 27001 with ISO 42001 enhances governance by focusing on explainability, human oversight, and lifecycle management, especially in regulated sectors or customer-demand scenarios.
Gmdautomation
Build AI Systems With Security In Mind
GMD Automation helps UK businesses deploy scalable AI systems designed for security, compliance, performance, and ongoing support.
Explore GMD Automation

Table of Contents

ISO 27001 for AI: what the ISMS already covers, and where it stops

ISO 27001 was never written with large language models in mind, but its structure doesn't care what kind of asset it's protecting. ISO/IEC 27001:2022 defines requirements for building, running, and improving an information security management system, and that system is asset-agnostic by design. A trained model, its weights, the datasets feeding it, the API keys guarding its endpoints, and even the prompts users send it all qualify as information assets the moment you decide to treat them that way.

The practical challenge isn't whether ISO 27001 applies to AI. It's whether your existing asset register has actually caught up with what your organisation is running in production.

Start by listing what counts as an AI asset in your context:

  • Trained models and their versioned weights
  • Training, validation, and fine-tuning datasets
  • Inference endpoints and the infrastructure serving them
  • API keys, service accounts, and credentials tied to AI services
  • Prompts, system instructions, and any retrieval-augmented content stores
  • Logs of inputs, outputs, and user interactions with the model

Several Annex A control families map directly onto this list without much translation. Asset management (A.5.9 to A.5.14 in the 2022 revision) handles inventory and classification of models and data. Access control (A.5.15 to A.5.18) governs who can query, retrain, or deploy a model. Change management (A.8.32) applies neatly to model updates and retraining events. Supplier management (A.5.19 to A.5.23) covers the third-party AI vendors most organisations now depend on. Incident response (A.5.24 to A.5.28) extends to model misuse, data leakage, and adversarial exploitation.

Where the standard runs out of road is evidence of behaviour, not just configuration. ISO 27001 tells you to manage access to a dataset. It doesn't tell you how to prove a model wasn't trained on data it shouldn't have seen, or how to document why an output changed after a retraining run. Data provenance, explainability, and model lifecycle tracking sit outside what Annex A was ever designed to measure.

This is where technical standards earn their place. OWASP AISVS gives you testable security requirements for model integrity and adversarial resilience, and ETSI EN 304 223 provides conformance assessment criteria you can point an auditor to. Neither replaces ISO 27001. Both fill the measurement gap it leaves behind. If your organisation is still working out who owns this coordination between security and product teams, IT governance for AI is worth reading before you assign responsibilities.

AI security risks to add to your ISMS risk register

Most risk registers built before generative AI arrived simply don't account for how models fail. Six categories belong on every register that includes AI systems, and each maps to a familiar confidentiality, integrity, or availability concern your ISMS already tracks.

  1. Model poisoning and tampering. An attacker manipulates training data or weights to corrupt outputs, an integrity risk that traditional data validation controls rarely catch because the corruption looks statistically plausible.
  2. Adversarial attacks and prompt injection. Crafted inputs manipulate a model into ignoring instructions, leaking system prompts, or producing outputs it was explicitly designed to refuse. This is now the most common attack vector against deployed language models.
  3. Data leakage. Models can memorise and regurgitate training data, or an unguarded output can expose confidential information from a retrieval store, both confidentiality failures.
  4. Bias and unsafe outputs. Discriminatory or harmful outputs create regulatory exposure well beyond information security, touching equality law and consumer protection alongside your ISMS obligations.
  5. Drift and degradation. Model performance changes over time as real-world data shifts away from training distributions, an availability and integrity risk that's easy to miss without active monitoring.
  6. Over-reliance and misuse. Staff treating model output as fact without verification is a human factor risk, and one that scales badly the more AI gets embedded into decision-making.

Statistic callout: MITRE ATLAS catalogues a growing library of documented adversarial techniques against deployed AI systems, mapped specifically to help security teams identify attack surfaces that standard threat models miss entirely.

None of these risks are hypothetical additions to keep auditors happy. They're the operational reality of running AI in production, and a risk register that doesn't name them isn't actually assessing your AI exposure. Model risk management practices built for regulators go into more depth on structuring this properly.

Mapping AI risks to Annex A controls and picking the right technical standard

Turning a risk into an auditable control requires a concrete link between the two, plus evidence you can hand an assessor without scrambling. Three example mappings show the pattern:

  • Model poisoning maps to Annex A.8.32 (change management) and A.5.9 (asset inventory). Evidence: version-controlled training pipelines, data provenance logs, and signed model artefacts.
  • Prompt injection maps to A.5.15 (access control) and A.8.9 (configuration management). Evidence: input validation logs, prompt filtering test results, and incident records for detected attempts.
  • Data leakage via outputs maps to A.5.12 (classification) and A.5.34 (privacy). Evidence: output filtering logs, retrieval-store access controls, and data loss prevention test results.

Deciding which technical standard to bring in depends on what you're trying to prove. OWASP AISVS works well when you need a graded assurance target. Its three levels run from baseline hygiene up to safety-critical verification, so a customer-facing chatbot might sit at Level 1 while a model influencing credit decisions needs Level 3 rigour. ETSI EN 304 223 suits organisations that need formal conformance testing, particularly where a customer or regulator wants third-party assurance rather than a self-assessment.

MITRE ATLAS and the NIST AI RMF do a different job. Neither is a certification standard. Both are threat modelling and prioritisation frameworks, useful for working out which of the risks in your register actually deserve budget this quarter versus next year.

Pro Tip: Don't try to map every AI risk to Annex A in one sitting. Start with the three or four risks that would cause the most damage if realised, get those mappings audit-ready, then expand the register incrementally. A shallow mapping across everything looks weaker at audit than a deep mapping across a few genuine priorities.

How ISO 42001 fits alongside ISO 27001

ISO 42001 isn't a replacement for ISO 27001, and it isn't a competitor either. It's an AI management system standard that adds structure around explainability, human oversight, fairness, and lifecycle governance, areas ISO 27001 was never built to address directly. Where ISO 27001 asks whether you're protecting an asset, ISO 42001 asks whether you understand what the asset is doing and whether a human can meaningfully oversee it.

For most organisations, the sequencing question answers itself. If your ISMS doesn't yet include AI assets at all, ISO/IEC 27001:2022 comes first. It gives you the asset inventory, risk assessment process, and control framework that ISO 42001 assumes already exists. Trying to build AI-specific governance without that foundation tends to produce parallel documentation that never quite talks to your main ISMS.

Where it makes sense to run both together from the start:

  • Your customers or procurement contracts explicitly demand ISO 42001 certification
  • You're deploying AI in a regulated sector where explainability is a legal requirement, not a nice-to-have
  • You already have a mature ISMS and the incremental effort of adding ISO 42001 scope is genuinely small

Practitioner guidance on integrating the two standards generally agrees that most Annex A controls transfer directly, so the extra work sits in extending evidence collection and lifecycle documentation rather than rebuilding your governance from scratch. Operationally, expect ISO 42001 to demand more from you around documented human oversight checkpoints, fairness testing records, and lifecycle change logs than ISO 27001 ever asked for on its own.

A step-by-step checklist for extending your ISMS to cover AI

Getting AI properly inside your ISMS scope is a sequencing problem more than a technical one. Follow this order and you avoid the common failure mode of writing controls before you've actually worked out what needs controlling.

  1. Enumerate every AI use case in the business. Not just the ones IT deployed deliberately. Shadow AI, where teams have quietly adopted tools without security sign-off, is where most exposure hides.
  2. Map data flows for each use case. Where does training data come from, where does inference data go, and which third parties touch either?
  3. Assign asset owners. Every model, dataset, and endpoint needs a named owner accountable for its risk posture, the same way you'd assign ownership to a database or server.
  4. Run a materiality-based risk assessment. Not every AI use case deserves the same scrutiny. A model summarising internal meeting notes carries different stakes than one making lending decisions.
  5. Define risk acceptance criteria before you need them. Decide in advance what level of hallucination rate, bias score, or drift threshold triggers escalation, rather than deciding reactively after an incident.
  6. Adapt existing controls rather than inventing new ones. Access control, change management, and logging processes you already run can usually extend to AI assets with modest adjustment.
  7. Build continuous logging of inputs and outputs. This is the single most valuable piece of evidence you can produce at audit, and the one most organisations skip until it's too late.
  8. Tag every model version and tie retraining events to your change log. An auditor will ask which model version produced a given output six months ago. Make sure you can answer.
  9. Schedule internal audits and management reviews with AI-specific agenda items. Don't let AI governance get buried as a footnote in a broader ISMS review.

Pro Tip: Treat your model version tag the same way you'd treat a software release number. If you can't tell an auditor which exact model version generated a specific output on a specific date, you don't have an audit trail, you have a guess.

The AI governance guide covers scoping and ownership questions in more depth if your organisation is still deciding who holds accountability for each AI use case.

Monitoring and testing that actually produces evidence

Auditors don't take your word for it. Every control you claim needs a test result, a log, or a record behind it, and AI systems need a slightly different monitoring stack to produce that evidence than traditional IT infrastructure does.

  • AI-specific penetration testing and red-teaming probe for prompt injection vulnerabilities and jailbreak attempts that standard network penetration tests never touch.
  • Bias and fairness testing should run against defined test suites before deployment and periodically afterwards, not as a one-off pre-launch check.
  • Drift detection flags when live performance diverges from validation benchmarks, catching degradation before users notice it themselves.
  • Logging strategy needs to capture inputs, outputs, model version, and any human approval step in the loop, retained long enough to satisfy both your incident response needs and any regulatory retention requirement.

Statistic callout: OWASP AISVS structures its three assurance levels specifically so teams can calibrate testing depth to consequence. A low-stakes internal tool doesn't need the same verification rigour as a system making decisions about customers.

Enterprise deployments benefit from architecture that builds monitoring in from the start rather than bolting it on afterwards, which is where a structured security architecture approach tends to outperform ad hoc monitoring added after a model is already live.

Vendor and supply-chain governance for third-party AI providers

Most organisations don't train their own foundation models. They consume AI through third-party APIs, and that dependency needs the same supplier governance rigour ISO 27001 already demands for any other critical vendor, just pointed at a new category of risk.

Assess suppliers against a handful of concrete dimensions before you sign anything: what data practices govern your inputs once they leave your systems, whether the provider can evidence training data provenance, what access controls protect your API keys and account, and whether the vendor commits to any explainability or output documentation in their service level agreement.

Four dimensions for assessing AI suppliers

Contract clauses worth insisting on include audit rights, guaranteed data deletion on termination, disclosure of any subprocessors handling your data, and defined incident notification timelines if the vendor suffers a breach affecting your usage.

Operationally, a handful of low-effort controls do a lot of the heavy lifting: network segmentation isolating AI traffic, rate limiting to contain the blast radius of a compromised key, and scoped API keys issued on a least-privilege basis rather than one master credential shared across teams.

Network segmentation rate limiting and scoped access

If a supplier can't evidence basic data provenance or refuses audit rights outright, that's the signal to escalate internally or start evaluating a replacement, before a contract renewal forces the decision under time pressure.

How this looks in practice: tagging assets and closing the evidence gap

The mechanics of bringing AI into an ISMS are less abstract than they sound. Tagging a model as an information asset means giving it an entry in the same register that already holds your databases and servers, with a classification, an owner, and a review date. Tying a retraining event to your existing change log means the same change ticket that would track a firewall rule update now tracks a model version bump, with the same approval chain behind it.

AI asset registration and change control workflow

The controls that matter most in practice are the ones that generate evidence without extra manual effort: continuous logging that runs automatically rather than depending on someone remembering to export it, version tagging built into the deployment pipeline rather than a spreadsheet someone updates occasionally, and lifecycle management that treats a model update the same way it treats any other production change.

Organisations working through this shift often lean on managed deployment approaches precisely because building continuous evidence collection from scratch is slower and more error-prone than extending infrastructure designed for it. Some managed AI system deployments build these evidence trails in from the outset, which can serve as useful reference points regardless of which provider a security team ultimately chooses. For teams working through explainability requirements specifically, AI system transparency breaks down what auditors typically expect to see documented.

Author perspective: ISO 27001 first, everything else second

The mistake I see most often is organisations treating AI governance as a separate project from information security, when it should be an extension of it. ISO 27001 first preserves something valuable: an existing audit trail and a procurement story that buyers already understand. Bolting on a parallel AI governance framework that doesn't map back to your ISMS just creates two systems of record that eventually disagree with each other.

The real trade-off isn't control rigour versus innovation, whatever the conventional framing suggests. It's whether you build evidence collection into your AI deployment pipeline now, while it's cheap, or retrofit it later under audit pressure, when it's expensive and rushed. CISOs who get this right treat model versioning and logging as deployment requirements, not compliance afterthoughts bolted on before a certification visit.

— Ravi

Standards and resources worth consulting next

For UK businesses ready to put this into practice rather than just plan for it, GMD Automation deploys managed AI systems with compliance-focused evidence trails built in from day one, covering the logging, versioning, and lifecycle controls this article has walked through, without the upfront capital cost of building that infrastructure internally. Security teams evaluating document handling and disclosure practices alongside their AI deployment will find the two areas overlap more than most governance frameworks acknowledge.

Sources