What ISO 27001 Auditors Are Starting to Ask About AI

A few years ago, AI didn’t take up much time in an ISO 27001 audit. Maybe someone asked whether the business used machine learning somewhere in the product. Maybe there was a brief discussion about automation in the security stack. Then everyone moved on to access control, supplier reviews, incident records and the usual evidence hunt.

Now, AI is sitting in browser tabs, meeting tools, CRMs, help desk platforms, development environments and document workflows. Some of it has been approved. Some of it has slipped in quietly because it was useful, cheap or already bundled into a product the business was using anyway. As a result, auditors are starting to ask better questions.

An auditor’s first question is not: “Do you use AI?” (Because most organisations, if not all, do use AI in one form or another).

More and more, I’m seeing that the auditor’s first question is: “What data is going into your AI tools, where is that data going, and who has decided that this is acceptable?”

It’s little wonder that a lot of organisations feel uncomfortable giving an honest answer.

Supplier Security Assessments

A supplier security assessment is a sensible place to start. It can tell you whether the vendor has a decent security posture, whether data is encrypted, where hosting happens, what certifications exist and whether the contract gives you enough protection.

A vendor can look fine on paper while your internal use of the tool is a mess. Someone may be pasting client information into a public AI tool to save time. A sales team may be recording and summarising calls without thinking about retention. A developer may be using an assistant with access to source code. A team may be relying on an AI feature inside a platform without anyone checking whether the data is retained or used to improve the service.

The security assessment says something about the supplier. It says much less about your behaviour, which is what ISO 27001 auditors are really interested in.

Confidentiality, Integrity and Availability

Underneath the AI noise, the audit conversation still comes back to confidentiality, integrity and availability. The same old audit and compliance principles are doing plenty of work here.

Confidentiality

Confidentiality is the obvious starting point. If staff are using AI tools, the business needs to know what information can be shared and what cannot. That sounds simple until you look at real workflows. Meeting transcripts may contain customer names, commercial details, complaints, legal comments or internal decisions. Support tickets may include screenshots, account data or sensitive business context. Contracts, board papers, risk registers and incident notes all have a habit of finding their way into tools when people are under pressure.

Nobody needs to be reckless for this to happen. Convenience is usually enough.

For an audit, a generic acceptable use policy will not carry the whole argument. The business needs some evidence that AI use is understood, approved and reviewed. That might mean an AI register. It might mean use case approvals. It might mean data classification rules that people actually understand. It should mean supplier reviews that look at AI-specific issues, not just standard cyber questions copied from last year’s questionnaire.

Integrity

Integrity is the part many teams underestimate. AI output can be wrong in a very tidy way. That is what makes it dangerous. A rough answer tends to raise suspicion. A polished answer can sneak through.

If AI is being used to draft customer responses, summarise contracts, generate code, triage support issues, analyse risk data or prepare reports, the auditor may ask how the organisation checks the output before it becomes part of a business process.

This does not require panic. It requires ownership. Who reviews the output? When is human approval required? How are errors handled? If AI-generated code is used, does it go through the same review and testing as everything else? If an AI summary influences a decision, is the original source still checked?

That is a normal management system conversation. It belongs with change control, document approval, software development, incident management and risk treatment. AI does not need a mystical parallel universe. It needs to be pulled into the controls the business already claims to operate.

Availability

Availability gets less attention, mostly because it feels less exciting. It should still be on the table. If a team uses an AI tool every day, the business may have created a dependency whether anyone has written it down or not. What happens if the tool is unavailable? What happens if the supplier changes the feature, changes the model, changes the licence, moves data processing somewhere else, or removes functionality your team has built into its workflow?

This matters most when AI is supporting customer service, security operations, software delivery, compliance activity or management reporting. A tool does not need to be officially classified as critical to become operationally important. It only needs enough people to rely on it.

For ISO 27001, the practical answer is to stop treating AI as a side topic and start treating it as part of the information environment.

Start with your data. What do you hold? Who uses it? Which systems process it? Which suppliers touch it? Which AI tools can access it? What leaves the business? What comes back? What is stored, logged, retained or reused?

Once you can answer those questions, the AI conversation becomes much less theatrical and much more useful. Security assessments still matter. They are part of the picture. But if the compliance program stops there, it misses the thing auditors are beginning to care about most.

Book a demo to see how de.iterate can help.