Why your existing controls show green while failing to protect your AI estate

Why Your Existing Controls Can Pass While Failing To Protect Your AI Estate

A common angle for an article like this is that “AI changes everything and your existing controls are obsolete.”

Guess what? That messaging sells consulting engagements…

…It’s also wrong.

Most of your control library transfers just fine. The parts that don’t, don’t fail loudly.

They pass.

A control that’s quietly stopped covering the thing it was written for still shows green on a dashboard. Still gets signed off in an audit. Still gets reported to a risk committee as effective.

And that’s a much worse failure mode than a gap you can see.

Using the 9-layer map from yesterday: layers 1 through 5 are in reasonable shape. Layers 7 through 9 are where controls pass while covering nothing.

What actually transfers

If you hold ISO 27001, you already own the machinery.

ISO/IEC 42001 and ISO/IEC 27001 share the Harmonized Structure. So clauses 4 through 10 – context, leadership, planning, support, operation, performance evaluation, improvement – are the same management system in both.

An existing ISMS is real leverage here. Not a starting point you have to throw away.

Where they separate is the control sets.

ISO/IEC 27001:2022 carries 93 Annex A controls across 4 themes. ISO/IEC 42001:2023 carries 38 controls across 9 objectives, numbered A.2 to A.10 – AI policy, internal organisation, resources, impact assessment, the AI system lifecycle, data, transparency, responsible use, and third-party relationships.

(Quick aside: if you see “114 controls in 14 categories” quoted anywhere for 27001, that’s the superseded 2013 edition. It still circulates a lot.)

Notice what 42001 has that 27001 has no equivalent for at all. Impact assessment. Intended use and foreseeable misuse. Responsibilities allocated across a value chain.

And notice that 42001 is the smaller set. It isn’t a replacement. It’s the part your library was missing.

At layers 1 through 5 – compute, data pipeline, training environment, model artifacts, deployment infrastructure — extension works. Encryption, segmentation, secrets management, vulnerability management, supply chain controls. All of it applies to AI workloads with adjustments rather than rewrites.

Anyone telling you those layers need a brand new control framework is selling you something.

Three controls that pass while covering nothing

CChange management.

Your standard reads something like: changes to production systems require documented approval.

Your model provider ships an update.

Your change advisory board never meets. No ticket gets raised. And the control isn’t breached… because you didn’t change anything.

Someone else did. To a component sitting inside your critical operation. On their schedule.

The control was written on an assumption so basic nobody bothered writing it down – that changes to your production estate originate from inside your organisation.

That assumption is now false. And nothing in the control text tells you so.

Asset management.

Try registering a model in your CMDB. Go on, have a crack.

What’s the configuration item type? “Thing”?

And what’s the version – given that a deployed model is a base model, plus a fine-tuning checkpoint, plus an adapter, plus a system prompt, plus a handful of inference parameters… and changing any one of those changes how it behaves?

Your CMDB can hold one of those. And it will confidently call it the version.

You cannot patch, recertify, or decommission an asset class you have no schema for. So every downstream control that depends on the asset register inherits the gap. Silently.

Access control.

Your IAM governs two populations. Humans, and service accounts.

An agent is a service account that makes decisions. Which is a third thing.

Joiner-mover-leaver has no agent equivalent. Access recertification works by asking a manager whether a person still needs an entitlement – and an agent has no manager. (The engineer who deployed it has changed teams.) Least privilege assumes a stable, enumerable set of actions, and an agent’s action set is whatever tools it can currently reach.

Every one of those controls will pass its next audit.

Where extension genuinely stops working

Three things at layers 7 through 9 have no ancestor in your library. These are the ones you build, not extend.

Behavioural baselining. Every detection control you own assumes deterministic expected behaviour. Establishing “normal” for a system that produces different outputs from identical inputs is a genuinely different problem – and it’s the hard technical work of the next few years.

Output inspection. You inspect traffic, files and code. You’ve never had to inspect the semantic content of a system’s output to decide whether the system should be allowed to act on it.

Tool invocation authorisation. Authorising a request is solved. Authorising an action that a non-deterministic system decided to take, in context, against a tool it selected itself… is not the same control, and you can’t build it from the same parts.

The clause worth reading tonight

ISO 42001’s A.10 objective covers third-party relationships. And its contractual controls ask for things your existing vendor clauses probably don’t – an obligation on the supplier to notify you of significant changes, incident reporting procedures, and provisions for you to conduct or commission audits.

Now read that back against the change management failure above.

Your change control broke because a third party can alter a production component without telling you.

Which means it broke as a contract gap. And the fix is a clause, not a technical control.

This is the pattern more often than security teams expect at the upper layers. The control you need already exists somewhere in the organisation. Filed under procurement.

What to do this quarter

Don’t rebuild the library.

Take four controls – change management, asset management, access recertification, vendor management – and re-read each one asking a single question:

What did the author assume, that AI has made false?

  1. For change management, the assumption was that changes originate internally.
  2. For asset management, that an asset has one version.
  3. For access recertification, that every principal has a human manager.
  4. For vendor management, that a supplier’s product stays the same between contract renewals.

Four assumptions. Four response sentences. And you’ll likely surface more real exposure than a framework gap analysis produces in a month.

Because a gap analysis tells you which controls are missing.

This tells you which of the ones you already have are lying to you.

About Satheeshan Siva

Continue the conversation.

I write about what emerging technology makes possible and what it takes to make it work inside a real organisation. If you disagree with something here, or want to discuss what it means for yours, get in touch.