How AI Is Changing Information Security: What It Means for ISO/IEC 27001

4 min read

Table of Contents

“A few years ago, the biggest security worry inside most organisations was someone clicking a phishing link. Today, it’s just as likely to be an employee pasting a client’s financial details into ChatGPT to get a quick summary done.”

AI tools such as ChatGPT, Microsoft Copilot, and Gemini have quietly moved from novelty to necessity across almost every workplace. People use them to draft emails, analyse data, write code, and get through the day a little faster, and there’s nothing wrong with that. But it does mean information is now moving through systems that most ISMS frameworks were never really built with in mind.

“The real question is whether your ISMS is prepared for how employees are already using AI, rather than how it’s assumed they use it.”

Does ISO/IEC 27001 Cover AI?

There’s a common assumption that ISO/IEC 27001 doesn’t apply to AI simply because it doesn’t mention AI by name. That assumption doesn’t quite hold up. ISO/IEC 27001 was never written around specific tools or platforms to begin with. Its concern has always been information itself, and protecting it wherever it happens to travel.

So when an employee pastes confidential customer data into ChatGPT, that becomes an information security event whether or not the ISMS documentation ever mentions AI. The same applies when a developer uses an AI coding assistant with access to company code, or when a operation team uploads internal files to an AI tool just to tidy up a draft. None of this calls for a new standard. It simply means applying the one already in place to a newer way information tends to move.

The Annex A Controls That Matter More Now

None of the controls below are new or written specifically for AI. They already exist within most ISMS frameworks, but they carry noticeably more weight now that AI has entered the picture.

  • Threat intelligence used to mean keeping an eye on malware and phishing trends. Now it also involves understanding how AI tools can be manipulated and what risks certain vendors quietly carry.
  • Cloud service security matters here too, since most AI tools run on the cloud and deserve the same scrutiny as any other cloud vendor.
  • Configuration management becomes relevant because AI platforms often ship with settings, like data retention for model training, that aren’t secure by default until someone actually checks.
  • Information Deletion: We need to honestly question what happens once data enters an AI system. Does it actually get removed when requested, and more importantly, can anyone actually prove that it’s gone?
  • Data Masking: Prevention is key here. Sensitive fields ideally shouldn’t reach an AI tool in their original form to begin with. Masking that data beforehand keeps the risk low.
  • Secure Development Life Cycle (SDLC): Developers relying on AI coding assistants still need the discipline of a proper, secure development process. AI-generated code might save a lot of time, but it can introduce security vulnerabilities just as easily as a human developer.
  • Security Awareness & Training: At the end of the day, teaching people matters more than any technical lock you put in place. Most AI-related leaks don’t happen because someone is trying to do harm—they happen simply because an employee didn’t realize that what they were doing was risky.

The Risks Organisations Tend to Face

A few patterns show up again and again: confidential information being pasted into AI chatbots without much thought, “shadow AI” tools being used without IT’s knowledge, vendors processing company data under terms nobody in security has actually reviewed, little to no monitoring of what’s going where, and awareness training that was written before AI became part of daily work

On their own, these look like small oversights. Together, they tend to point to a real gap between what an ISMS says on paper and what’s actually happening on people’s screens.

Where ISO/IEC 27001 Stops

To be fair to the standard, its job has always been narrower than people assume: protecting information. It was never meant to answer whether an AI system is biased, whether its decisions are transparent, or whether there’s enough human oversight built in. Those are legitimate questions, just not ones this particular standard was designed to answer.

Where ISO/IEC 47001 Stops

That’s really where ISO/IEC 42001 comes in, the management system standard built specifically around AI governance. A simple way to think about it: ISO 27001 secures the information, while ISO 42001 governs the AI system itself, how it’s designed, monitored, and held accountable. One protects what goes in and out. The other governs the intelligence making decisions with it. They aren’t competing frameworks, and for organisations leaning heavily on AI, having both in place tends to paint a far more complete picture than either one alone.

AI was never really outside the reach of ISO/IEC 27001. It sits well within it, and what most organisations need isn’t a new framework but a closer look at how their existing controls are actually being applied to this newer way information moves.

The more useful question, in the end, isn’t whether an ISMS technically covers AI on paper. It’s whether it’s genuinely being applied that way, day to day.
This is exactly the kind of gap RACERT tends to see when reviewing ISMS implementations against real-world AI usage, and it’s often a smaller exercise to close than most teams expect, long before it turns into an actual incident.

Frequently Asked Questions

Recent Post

Table of Contents