ISO 27001 gives you a strong foundation for AI development, but it needs AI-specific extensions to actually govern model risk. Your immediate next step is scoping AI assets into the ISMS and running an AI-focused risk assessment. Alongside that, map ISO 42001 and the NIST AI RMF against existing controls and plan a pilot for testing, evaluation, validation and verification.
How ISO 27001 maps to AI risks: control mapping and practical checklist
ISO 27001 was never written with large language models or autonomous agents in mind, yet its structure survives the translation better than most security leaders expect. The standard’s strength is that it governs risk through assets, controls and evidence rather than through named technologies. That means AI does not require a parallel system. It requires an honest extension of the one you already run.
Start with the asset register. Most organisations inventory servers, applications and data stores but miss the artefacts that actually carry AI risk: models, training datasets, fine-tuning pipelines, prompt libraries and the agents that act on their outputs. Each of these needs an owner, a classification and a change history, the same discipline you already apply to production code.
Annex A controls commonly mapped to AI environments include asset management, access control, supplier relationships and secure development lifecycle practices, and practitioner guidance on AI threats sets out how to apply each to machine learning contexts specifically. Interpreting these controls for AI means asking different questions: who can modify a model’s weights, what data a vendor’s foundation model was trained on, and whether a third-party API logs your prompts.
Supplier relationships deserve particular attention. Contracts with model providers should specify data retention, training-data provenance and the right to audit security practices, not just uptime and support terms.
For audits, collect:
- Model and dataset version records, including training data provenance and lineage.
- TEVV artefacts: test results, validation suites and red-team reports.
- Access logs showing who approved changes to models, prompts or agent permissions.
- Supplier due-diligence records for any third-party model or API in use.
Integrating ISO 42001 and NIST AI RMF with your ISMS: a phased approach
ISO/IEC 42001 was built using the same Annex SL high-level structure as ISO 27001, and ISO’s own guidance on AI and information security confirms the two standards are designed to work together rather than duplicate each other. That shared structure means your existing risk methodology, internal audit programme and management review cycle can absorb AI governance without a second bureaucracy.
A phased roadmap keeps this manageable:
- Discover (days 1 to 30): inventory AI systems, map data flows and identify which Annex A controls already touch AI assets without being labelled as such.
- Design (days 30 to 60): draft AI-specific policy clauses, extend the risk register with model-level threats, and define roles for review, red-teaming and model provenance.
- Pilot (days 60 to 90): run one agentic workflow or model deployment through the full control set, from risk assessment to TEVV, and document every gap.
- Operationalise: fold the pilot’s lessons into standard ISMS procedures and schedule recurring internal audits that include AI assets by default.
The NIST AI Risk Management Framework offers a useful translation layer here. Its functions, govern, map, measure and manage, convert naturally into ISMS processes: governance becomes policy and accountability, mapping becomes your extended asset inventory, measuring becomes TEVV, and managing becomes risk treatment. Treating AI RMF as a lens on your existing ISMS, rather than a separate framework to run in parallel, keeps auditability intact and avoids the duplicated paperwork that kills momentum on most governance initiatives.
AI-specific risk assessment and assurance: methods and artefacts
Traditional ISO 27001 risk assessments were built for infrastructure and applications with predictable behaviour. Models and agents behave differently, and your risk register needs new threat categories to reflect that.
Model-level threats worth formal assessment include:
- Data poisoning during training or fine-tuning.
- Model extraction and inversion attacks that reconstruct training data or proprietary weights.
- Prompt injection, both direct and indirect, that hijacks an agent’s instructions.
- Adversarial inputs designed to force incorrect or unsafe outputs.
Assurance evidence needs to match the threat. Red-team reports, structured validation suites and bias audits all belong in your risk treatment file, and the OWASP AI Security Verification Standard sets out testable, verifiable controls that treat evaluation and red-teaming as core security activities rather than optional extras. Reproducible TEVV logs matter as much as the test results themselves, since an auditor needs to see that the same test produces the same outcome on the same model version.
Risk acceptance criteria should map directly back to your existing risk treatment plan structure. A prompt-injection vulnerability that could expose customer data gets the same severity treatment as a web application vulnerability with equivalent impact, scored against confidentiality, integrity and availability rather than against a separate “AI risk” scale that nobody outside the AI team understands.
Pro Tip: Score AI risks by their worst-case impact on confidentiality, integrity and availability first, then layer in novelty. A familiar-looking vulnerability with high CIA impact deserves more urgency than an exotic attack with low practical consequence.
Engineering controls and processes for agentic AI in the SDLC
Policy only works when engineering practice enforces it. For agentic AI, that means specific architectural patterns, not general good intentions.
Context isolation is the starting point. The OWASP prompt injection prevention guidance recommends separating trusted system prompts from untrusted content, often through a dual-LLM or quarantined summariser pattern where untrusted text is processed by a model with no tool access before it ever reaches the privileged model that can take action. This single pattern closes most indirect prompt-injection paths that agentic systems otherwise leave open.
One compromised agent with broad tool access can touch every system that agent is connected to, which is why least-privilege scoping per agent matters more than it does for a single service account.
Engineering controls that support this in practice:
- Strict tool profiles per agent, scoped to the minimum actions that role requires.
- Human review and sign-off for any agent-generated change before it merges.
- Commit ownership rules that distinguish human-authored from agent-authored changes.
- CI policies that detect and flag agent-origin code for additional scrutiny.
- Egress controls that prevent agents from reaching systems outside their defined scope.
Repository hygiene deserves its own line item. Rules files, README content and pull request descriptions should always be treated as untrusted input rather than as blindly trusted configuration, because an agent reading a poisoned rules file risks redirection without anyone modifying its core prompt. Our guide to AI code guardrails for secure software delivery covers the CI-level controls that catch this kind of drift before it reaches production, and our breakdown of CI controls for AI governance sets out the specific pipeline checks engineering teams can enforce today.
Provenance and versioning close the loop: every model and dataset in production needs a traceable record of what version is running, when it was deployed and what changed since the last approved release.
Observability, continuous compliance and how AI can help ISO 27001 monitoring
ISO 27001 certification depends on evidence, and AI systems generate evidence differently than traditional software. Your minimum telemetry set should capture input and output logs, full tool-call trails, model and dataset identifiers for every inference, and test results tied to the specific model version that produced them.
AWS security guidance for AI systems frames this as observability-first security: monitoring agent goal states and tool-use patterns makes AI behaviour auditable in a way that opaque model outputs alone never can be.
AI itself can shoulder much of this monitoring burden. Automated evidence collection and continuous controls monitoring reduce the manual scramble before every audit cycle, and research on automating regulatory compliance in DevSecOps describes instrumented pipelines that produce near-continuous auditability for standards like ISO 27001.
Useful automated detection patterns include:
- Token-usage anomalies that signal unexpected model behaviour or runaway agent loops.
- Unexpected tool invocation chains outside an agent’s defined profile.
- Drift detection comparing current model outputs against a validated baseline.
Retain TEVV artefacts in a structured, timestamped format that an external auditor can query directly, not buried in chat logs or ticket comments. Our guide to AI incident response covers how to structure these logs so they double as incident evidence when something does go wrong.
Cleverbit’s governance-first practitioner example and implementation pattern
When we scope an AI governance engagement, we start by mapping the client’s existing ISMS against the AI systems already in use or planned, then run a contained pilot before touching anything at scale. That pilot tells us exactly where current ISO 27001 processes need to change and produces the artefacts an auditor will eventually ask for.
The teams we embed carry defined ownership from day one:
- A review owner responsible for sign-off on agent-generated changes before merge.
- A red-team function that tests agentic workflows for prompt injection and excessive agency.
- A provenance owner tracking model and dataset versions through every deployment.
Engagements deliver concrete operational artefacts: written AI usage policies aligned to the client’s existing engineering standards, CI-level review gates, telemetry dashboards covering tool-call trails and model identifiers, and handover documentation that lets an internal team take direct ownership once the pattern is proven. More detail on how this fits across the delivery pipeline sits on our AI software delivery page.
Author perspective: the case for deliberate, governance-first AI adoption
The organisations getting the most value from agentic AI are rarely the fastest movers. They are the ones who treat guardrails as the thing that protects velocity, not the thing that slows it down.
Common missteps we see: skipping the asset inventory because it feels like paperwork, letting agents run with broad tool access to save setup time, and rolling out agentic workflows organisation-wide before a single pilot has produced measurable TEVV evidence. The corrective behaviour is always the same: test narrow, measure honestly, then expand from a position of evidence rather than optimism.
— Cleverbit
How Cleverbit helps implement ISO 27001 aligned agentic AI development
We build software development teams with governance integrated from the beginning, so the controls this article describes are embedded in the delivery process rather than added later.
Our engagement begins with consultancy to understand your stack and compliance requirements, moves into a pilot through The Foundation Engagement, and scales into AI-integrated engineering teams once the pattern is proven. Clients who want to take direct ownership of their teams and the governance structures around them can do so through our Special Purpose Vehicle model, with minimal disruption because the structure is already in place.
If you are scoping AI governance against ISO 27001 and want a team that builds the controls in rather than adding them afterwards, talk to us about a pilot.
FAQ
What is ISO 27000 used for?
ISO 27001 is the certifiable standard that sets requirements for an information security management system and is widely used across industries to structure risk assessment, control selection and continuous improvement of security practices, and extending it to cover AI development follows the same logic as extending it to cover any new technology.
What is the ISO for AI governance?
ISO/IEC 42001 is the standard specifically for AI management systems, and it shares the Annex SL high-level structure with ISO 27001, which allows the two to be integrated into one governance programme rather than run as separate systems. Organisations already certified to ISO 27001 can extend their existing ISMS to cover AI governance requirements without duplicating policy and audit work.
What is the main difference between ISO 27001 and ISO 27701?
ISO 27001 governs information security broadly across any organisation, while extensions to the ISMS structure specifically cover privacy information management, addressing how personal data is processed and protected. For AI development, both matter: ISO 27001 covers the security of models, pipelines and infrastructure, while ISO 27701 addresses the privacy obligations tied to training data and personal information processed by AI systems.
How do I become ISO 27001 certified?
Certification follows a defined path: scope your ISMS, conduct a risk assessment, select and implement Annex A controls, run an internal audit and management review, then engage an accredited certification body for a two-stage external audit. For AI development specifically, that process needs AI assets folded into the scope from the start, including models, datasets and agentic tooling, so the certification body is assessing the system you actually run rather than the infrastructure you ran before AI entered the pipeline.
Sources
- ISO – AI and information security management package
- NIST AI Risk Management Framework (AI RMF)
- OWASP AISVS