AI and ISO 27001: Bringing AI Into an ISMS

AI systems fit an established information security management system more easily than teams expect. The structure already exists; what needs adding is a handful of risk types and a supplier relationship nobody has assessed yet. This guide covers both, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

What changes when AI enters the ISMS?

Less than expected structurally, more than expected in the risk register.

Area	What changes
Scope	AI systems named explicitly, not assumed
Risk assessment	New failure modes beyond confidentiality
Supplier controls	Model providers assessed as suppliers
Access control	Model outputs treated as data
Logging	Prompts and outputs, with retention decided
Incident management	AI events routed through the same process

How should model providers be handled?

As suppliers, within the controls you already have: assessment before onboarding, contractual requirements, ongoing monitoring, and periodic review.

The specific questions are data retention, sub-processing, where processing occurs, what happens to prompts and outputs, and what notice you get before a model changes. Organisations that onboard a model provider without any of this have an unassessed third party inside a certified environment.

What new risks should be assessed?

Output quality degradation, behaviour changes when a provider updates a model, prompt injection through untrusted content, data leakage through prompts, and over-reliance by staff who assume outputs were verified.

The last one is under-assessed everywhere. A system that is right most of the time trains people to stop checking, which converts an occasional error into an unnoticed one. See what is tool poisoning.

Where does the AI management standard fit?

Alongside rather than instead. A dedicated AI management system standard covers governance aspects that an information security management system does not — impact on individuals, intended use, and lifecycle management of AI specifically.

Organisations with a mature ISMS generally find the additional work modest, because the management system machinery is already in place and much of the evidence is shared.

What evidence do you need?

Scope statements covering AI systems explicitly, risk assessments including AI-specific risks, supplier assessments for model providers, control evidence around prompt and output handling, and incident records showing AI events were handled through the ISMS.

If that evidence exists as a by-product of how systems are built and operated, you are in good shape. If it exists only as documents written for a review, you are not, and the difference is visible to anyone who looks carefully.

How does this change engineering practice?

It pushes prompt and output handling into the control set. Deciding what is logged, for how long, and who can see it is an access control and retention question rather than a debugging convenience.

It also makes model version pinning a configuration management concern: a system whose behaviour can change without a change record has a control gap, and that framing usually gets the change made faster than a quality argument would.

How does it interact with other regimes?

Usually more than expected. The same system can attract questions from a data protection authority, a sector supervisor, and a general AI regulator, each starting from a different premise and arriving at overlapping requirements.

One evidence base mapped to several requirements answers all of them. Separate programmes produce separate documents describing the same systems, and inconsistencies between them are themselves a finding.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into a project, the incremental cost is modest and much of it is work the system needed anyway.

Retrofitted onto a live system it becomes a project, performed under a deadline you did not choose, on something people already depend on. See AI compliance audit cost.

What are the common mistakes?

Leaving AI systems out of scope by omission. Onboarding a model provider without supplier assessment. Assessing only breach risks. And allowing model versions to change without a change record.

Who owns this internally?

The function that owns the systems, with legal and compliance support. Ownership by compliance alone produces documents describing systems nobody changed; ownership by engineering alone produces good practice with no one accountable for the interpretation.

Name a person per system rather than a committee. Committees review; people decide.

What should you ask a supplier?

What documentation they provide about capabilities and limitations, what evaluation evidence they share, how they handle personal data, where processing happens, and what happens to your prompts and outputs.

Suppliers who have prepared answer those quickly. Suppliers who have not take weeks, and that delay is itself information about how the relationship will run.

How do you keep this current?

Assign someone to watch the sources that actually bind you rather than general commentary. Record what was checked and when, so the next review starts from a known point.

Rules in this area change, and a position taken eighteen months ago and never revisited is a risk in itself.

How do you avoid duplicating effort across frameworks?

By maintaining one evidence base and mapping it. The same supplier assessment, risk register, control evidence, and incident records serve an ISMS, an AI management system, and most regulatory regimes.

Organisations that run separate programmes produce separate documents describing the same systems, and the inconsistencies between them are themselves an audit finding.

What should you do first?

Check whether your ISMS scope statement mentions AI systems at all, and whether any model provider has been through supplier assessment. Both gaps are common and both are quick to close.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: model providers assessed as suppliers before onboarding, model versions pinned and change-controlled so behaviour cannot shift silently, evaluation results dated and versioned, oversight designed structurally rather than asserted in policy, and documentation produced during the build rather than reconstructed afterwards. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To align a system with these requirements, message FISTA on WhatsApp, or read AI and SOC 2 Type 2.