There is a moment in many ISO 27001 audits where the conversation shifts from what the policy says to what the business actually does. AI is now one of those moments. (Don’t believe us, take a look at this recent blog where we explain in detail.)
A policy that says “staff must not enter sensitive information into public AI tools” is fine as a starting point. It is also the kind of statement auditors have seen before. The next question is usually where things get more interesting.
How do you know?
That is the question organisations need to prepare for. How do you know which AI tools are being used? How do you know what information is being entered? How do you know whether outputs are being checked before they influence a decision, a customer response, a piece of code, or a report?
The annual audit is unlikely to become a deep technical inspection of every AI tool in the business. Most auditors are more practical than that. They are looking for evidence that AI use has been considered inside the information security management system, rather than treated as a side issue owned by IT, legal, or whoever happened to write the AI policy.
The first piece of evidence is usually a register. This should be a current record of approved AI tools and AI-enabled features, with enough detail to show the organisation understands how they are used. The register should explain the business purpose, the owner, the type of information processed, supplier details, access arrangements, and any restrictions on use.
This matters because AI has a habit of hiding inside tools the business already uses. Meeting summaries, CRM assistants, document drafting tools, help desk automation, security products, developer assistants and search features can all involve AI. Some are switched on deliberately. Some arrive as product updates.
Auditors may also ask to see risk assessments. These should be useful enough to support decisions, not generic enough to satisfy a template. A good AI risk assessment asks what data is involved, where it goes, whether it is retained, who can access it, how outputs are used, and what could go wrong if the tool is unavailable or inaccurate.
Data classification is another area that comes under pressure. Many organisations have a classification scheme in their ISMS, but staff do not always connect it to AI use. If confidential customer information cannot be entered into a public tool, does everyone know what that means in practice? Are meeting transcripts covered? What about contracts, source code, screenshots, complaint notes, incident details, financial forecasts, board papers, tender responses, and supplier reports?
This is where evidence becomes more than a paper exercise. Training records may help, but auditors will also look for signs that the business has given people practical guidance. Plain language rules are usually more convincing than legalistic acceptable use wording that nobody can remember.
Supplier evidence still matters. If an AI tool is approved, the organisation should be able to show how the supplier was assessed. That might include security certifications, contractual terms, data processing arrangements, hosting locations, subprocessor information, retention settings, access controls, incident notification terms and whether customer data is used to train models.
But a supplier review only answers part of the question. It tells you something about the vendor. It does not prove the organisation is using the tool safely.
That is why auditors may ask for evidence of approved use cases. This can be as simple as a documented record showing what the tool is approved for, what it must not be used for, and what controls apply. For example, an AI meeting assistant might be approved for internal project meetings but not for sensitive customer discussions. A code assistant might be approved for use in a development environment but subject to peer review and testing before release.
Output review is becoming a bigger part of the conversation. AI does not only create confidentiality risk. It can affect the integrity of information. If AI is used to draft customer communications, summarise documents, assess risks, classify tickets, generate code, or prepare reporting, the business needs a position on human review.
Auditors may ask who checks the output and when. They may ask whether the approval process changes when AI has contributed to the work. They may ask whether errors are recorded and reviewed. The organisation does not need to treat every AI-generated sentence as a major risk, but it should know where accuracy matters and where judgement is required.
Access control is another practical evidence area. Who can use the tool? Is access limited to approved users? Is single sign-on enabled? Are accounts removed when people leave? Are admin roles controlled? Are logs available? Are prompts and outputs visible to other users inside the tenant?
These questions are familiar ISO 27001 territory. AI simply gives them a new setting.
Then there is monitoring. This is where many organisations struggle. They may have rules, but no way of knowing whether people follow them. Technical monitoring is not always easy, especially where public AI tools are concerned. Still, auditors may expect some reasonable effort. This could include approved tool lists, browser or CASB controls, expense reviews, staff attestations, periodic access reviews, supplier reviews, management reporting, or internal assurance checks.
None of this needs to be over-engineered. A small organisation does not need the same machinery as a bank. But it does need a story that holds together.
The best evidence is connected. The AI register links to supplier reviews. Supplier reviews link to risks. Risks link to controls. Controls link to policies, training, access decisions, and review activities. If an auditor asks why a tool was approved, the answer should not depend on someone searching their inbox for a half-remembered conversation.
ISO 27001 audits have always been about confidence. Organisations are expected to demonstrate that they understand and can manage their risks, with controls that operate beyond audit week. You need to be able explain decisions in a way that stands up to scrutiny. AI hasn’t changed any of this. It’s just made the gaps easier to see.
For organisations preparing for their next annual audit, the practical question is simple enough. Can you show what AI you use, what data it touches, what decisions you made, and what evidence proves those decisions are still valid? That’s where your auditor is likely to start.
Book a demo to see how de.iterate can help.