One Risk Language, Two Lenses: How to Integrate AI Risk Into an Existing ISMS

By now, the full shape of the problem should be visible. AI risk is not just another ISMS topic. AI risk and ISMS risk differ in object, failure mode, evidence, and ownership. Cybersecurity and AI governance collide. Hidden AI-specific harms remain even in strong security environments. Governance works only when accountability becomes concrete.

Now comes the practical question every serious organisation eventually asks: how do we actually integrate this into the systems we already have?

Some teams talk as if AI governance requires a completely separate universe of controls, committees, and frameworks. Others insist the existing ISMS should simply absorb it with minor language changes. Both instincts are flawed.

Mature organisations do not replace their ISMS for AI. They extend it. The ISMS remains the control spine, while AI governance adds the behaviour, decision, and accountability layers the old model does not capture by itself.

Start with the right objective

The objective is not build an AI governance programme. The better objective is this: extend existing enterprise risk and control processes so AI use cases are governed proportionately, consistently, and with the right additional evidence.

This avoids underreaction because it acknowledges AI-specific harms. It avoids overreaction because it builds on structures the organisation already knows how to operate.

What should stay inside the existing ISMS

A surprising amount should remain exactly where it already lives. The ISMS should continue to govern asset and system identification, access management, vendor review, incident response structure, logging and monitoring baselines, change management discipline, data protection controls, resilience, and baseline control lifecycle management.

If an AI system is poorly inventoried, badly access-controlled, weakly monitored, or connected to insecure suppliers, then the organisation already has a serious governance problem before any model-specific review begins. The ISMS should remain the operational backbone.

What needs to be extended, not merely inherited

The ISMS backbone is necessary, but it does not answer all the questions AI creates. So the organisation needs explicit extensions for use-case risk classification, output reliability and validation evidence, explainability and contestability requirements, fairness review where relevant, drift monitoring, acceptable use boundaries, human review requirements, decision-accountability mapping, and model-specific incident triggers.

These are not replacements for security controls. They are additional control dimensions.

The integration model should feel operational, not ceremonial

1. Extend the risk register, do not reinvent it

Adapt the register so it can capture hallucination risk, bias or disparate performance risk, explainability gaps, overreliance risk, drift risk, unsafe automation risk, and supplier behaviour-change risk.

2. Extend existing approval workflows

If the organisation already has change approval, new technology review, vendor onboarding, or risk acceptance flows, use them — but add AI-specific review questions where needed.

3. Extend incident taxonomies

Add categories now for harmful AI outputs, repeated hallucination in sensitive workflows, prompt injection attempts, retrieval leakage, drift beyond threshold, and biased or unsafe response patterns.

4. Extend evidence expectations

For AI, the review should also ask whether the use case has validation evidence, defined limitations, monitoring logic, review boundaries, a named owner, and fallback conditions.

Build an AI risk taxonomy people can actually use

One of the most useful implementation steps is creating a simple AI risk taxonomy that fits inside the organisation’s existing governance language.

• Security and control risks: unauthorised access, data leakage, insecure integration, supplier compromise, insufficient logging.
• Model and output risks: hallucination, reliability limits, weak explainability, drift, inconsistent performance.
• Human and workflow risks: overreliance, weak review discipline, misuse outside intended scope, automation without sufficient challenge.
• Legal and accountability risks: unfair treatment, inability to defend decisions, non-compliant use of data or outputs, unclear ownership of consequences.

Define proportional governance, not maximal governance

Another integration mistake is treating every AI system like a board-level crisis. That creates friction, slows adoption, and eventually causes people to bypass governance.

The better principle is proportionality.

• Tier 1: convenience or low-impact internal use — light controls, clear usage boundaries, baseline security, basic owner assignment.
• Tier 2: operational influence — stronger validation, clearer review rules, periodic monitoring, cross-functional signoff.
• Tier 3: high-impact or rights-affecting use — formal approval, thick evidence, explainability standards, strict monitoring, executive visibility.

The internal AI assistant becomes the integration test case

The fictional company’s internal assistant is now enough to do something useful. Instead of debating AI governance in the abstract, it can use the assistant as the first integration case.

That means registering the assistant in the same inventory and control environment as other critical systems, classifying the use cases separately, defining what the assistant may and may not be used for, adding AI-specific validation evidence, defining which outputs require human review, logging enough context to support both security investigation and governance accountability, and assigning named owners.

What metrics should leadership actually see?

If AI governance is integrated properly, leadership reporting should evolve. Leadership should be able to see the number of active AI use cases by risk tier, the percentage with named business owners, the percentage with current validation evidence, the number of AI-related incidents or escalations, unresolved supplier or control gaps, and cases paused or redesigned based on governance findings.

A practical 90-day integration roadmap

Days 1–30: map and classify

Identify current AI use cases, assign provisional business owners, place each use case into an impact tier, map where existing ISMS controls already apply, and identify the biggest gaps in validation, ownership, and monitoring.

Days 31–60: extend core processes

Update the risk register taxonomy, add AI-specific questions to approval and vendor review flows, define minimum evidence by risk tier, define incident triggers for harmful AI behaviour, and confirm cross-functional role expectations.

Days 61–90: operationalise and test

Run one or two real use cases through the updated model, test whether ownership and evidence actually work, refine thresholds and templates, start leadership reporting with a usable AI risk dashboard, and decide which use cases need redesign, tighter controls, or executive review.

The final executive takeaway

AI risk does not invalidate the ISMS. It reveals its boundaries.

The ISMS remains critical because it protects the environment in which AI operates. AI governance becomes necessary because it protects the decisions, behaviours, and harms AI can create.

Mature organisations need both — not as competing frameworks, but as one integrated control system with two lenses.

Conclusion

The real question was never whether AI risk should replace ISMS risk. The real question was whether organisations could expand an existing control discipline without losing clarity, proportionality, or operational usefulness.

The answer is yes — if they resist both extremes. Do not build a disconnected AI governance empire. Do not pretend classical security frameworks already solve the whole problem. Extend what works. Add what is missing. Keep ownership explicit. Use one risk language where possible, and two lenses where necessary.

That is how AI governance stops being a slogan and becomes an operating capability.