Mapping AI risk to your existing control framework

You probably already have the controls you need. The gap is knowing which ones apply to AI, and where the coverage holes are.

Organisations approaching ISO 42001, or any structured AI governance framework, often assume they need an entirely new control set. The assumption is reinforced by consultants who arrive with proprietary control libraries and by vendors who sell dedicated AI GRC platforms. The reality is more boring and more useful. In most cases, the organisation already has the controls it needs. The gap is knowing which existing controls already cover AI systems, which need a small scope adjustment, and which are genuinely missing.

The work, in other words, is mapping rather than invention. Done well, the mapping takes a few weeks and produces a control framework that the organisation can actually operate. Done badly, or skipped in favour of standing up a parallel AI control set, the work takes months and produces a framework that runs alongside, and competes with, the controls the organisation has already invested in.

The 70-20-10 pattern

Across a wide range of organisations, the mapping exercise produces a consistent split. Roughly seventy percent of existing controls cover AI systems already, with at most a scope adjustment. Roughly twenty percent need a new procedure or a meaningful extension to cover AI properly. Roughly ten percent represent genuine gaps that need a net new control.

Knowing this split in advance changes how the work is framed. The conversation with control owners is no longer about whether their controls apply to AI, which produces defensive answers. It is about how their controls apply to AI, which produces collaborative answers. The conversation with executives is no longer about a multi-million pound investment in new controls, which produces resistance. It is about extending existing investments by perhaps twenty percent of their original cost, which produces support.

What is already covered

Change management. The process that governs how code moves to production almost always covers AI model deployments already, even if the process documentation does not mention AI explicitly. A model update is a deployment. It goes through the same pipeline, the same review, the same approval. The control covers it. The work is to add AI-specific items to the deployment checklist, not to invent a new change management process.

Risk assessment. Most organisations have a risk assessment process for new technology projects. The process covers data flows, security implications, third party dependencies, business continuity. All of these apply equally to AI systems. The work is to extend the assessment template with AI-specific questions, not to build a separate assessment process.

Supplier management. The procurement and supplier review process covers contractual commitments, security posture, data handling. These cover AI suppliers as well as any other technology supplier. The work is to add AI-specific questions to the supplier assessment, not to stand up a parallel AI supplier review.

Incident management. The incident response process covers detection, triage, escalation, communication, post-incident review. All of these apply to AI incidents. The work is to define what counts as an AI incident, to add AI-specific tags and severity criteria, and to extend the post-incident review template, not to invent a parallel AI incident process.

Access control. The identity and access management framework covers who can access what systems and what data. AI systems are systems. The framework covers them. The work is to make sure that AI-specific roles, such as model trainer, model approver, model deployer, are defined within the existing framework, not to build a parallel access control system.

What needs extension

About twenty percent of controls need more substantial work. These tend to cluster in a few areas.

Architecture review. The existing process probably reviews scalability, security, and operational concerns. It does not, in most organisations, review model behaviour, training data lineage, or failure modes. Extending the architecture review to cover these adds perhaps thirty percent to its length and significantly increases its protective value.

Testing and validation. The existing testing process covers functional and non-functional requirements. It does not, in most cases, cover model performance against held-out data, bias and fairness metrics, or behaviour under adversarial input. These need to be added as a new category of testing that runs through the existing test infrastructure, rather than as a separate quality assurance function.

Monitoring and observability. The existing monitoring stack covers system health, latency, error rates. It does not, in most cases, cover model drift, prediction distribution shift, or input distribution shift. These need to be added as new metrics in the existing dashboard, with the same alerting and on-call coverage as other production metrics.

Documentation. The existing documentation process covers system architecture and runbooks. It does not, in most cases, cover model cards, training data documentation, or evaluation results. These need to be added as documentation requirements, ideally in the same repository as the rest of the system documentation, owned by the same teams.

What is genuinely missing

About ten percent of what AI governance requires is genuinely new. The most common gaps are:

AI risk register. Most organisations have a general risk register that does not have the granularity to capture AI-specific risks. A separate AI risk register, ideally linked to the system inventory, fills this gap. We have written about how to build one that gets used.

Model inventory. The system inventory covers applications and services. It does not usually capture models as first-class entities, with their own lifecycle, ownership, and metadata. A model registry, even a simple spreadsheet, fills this gap.

Continuous evaluation pipeline. The testing process tests at the point of change. It does not, in most cases, continuously evaluate deployed models against ongoing performance criteria. A scheduled evaluation pipeline, owned by the model team, fills this gap.

Human oversight design. The general access control framework does not specify how humans should oversee model outputs in workflows that include both. A documented oversight pattern, with measured latency and clear override authority, fills this gap.

Disclosure to affected users. Most organisations do not have a process for informing users that they are interacting with an AI system, or that a decision affecting them was influenced by one. The EU AI Act and several sector regulations require this. A standard disclosure pattern, tied to the system inventory, fills the gap.

How to run the mapping exercise

The mapping exercise is best run as a workshop, not a desk study. Get the owners of the existing controls in a room with someone who knows AI governance well. Walk the existing control framework, control by control, and ask three questions of each: does this control already cover AI systems, even if not by name; could it cover AI systems with a small scope adjustment, and if so what; or is there a gap that needs a new control entirely, and if so what is the simplest control that would close it.

The exercise typically takes two to three days for an organisation with a mature control framework. It produces three outputs: a list of controls that need a scope clarification, ideally with the exact wording change; a list of controls that need extension, with the proposed extension described concretely; and a list of new controls needed, with a draft of each.

The output is then reviewed with the AI risk owner and the head of compliance or audit, refined, and adopted as the AI control framework. There is no separate AI controls document. There is the existing controls document, with AI-specific extensions integrated into each relevant control, and a small appendix of new AI-specific controls.

What this saves you

Done this way, the work of standing up an AI control framework is a few weeks of senior time and modest changes to existing processes. Done the other way, by standing up a parallel AI controls function with its own owners, its own tooling, and its own audit calendar, it is six to twelve months of work and ongoing operational cost that the organisation will struggle to justify after the first audit cycle.

More importantly, the integrated framework actually operates. The same teams that run the existing controls also run the AI controls, because they are the same controls with extensions. The same evidence pipeline serves both. The same auditor walks both. The framework that was supposed to be expensive and disruptive turns out, on inspection, to be a modest extension of the framework that was already there. That is what good governance design looks like.