When AI fails, the business shouldn't.
AI-specific security controls mapped to ISO 27001, incident playbooks for model failures, and continuity planning that assumes the model will eventually be wrong, poisoned or unavailable.
Security and continuity for a new class of asset.
AI systems fail differently from other software: they can be poisoned through training data, extracted through queries, evaded through crafted inputs — or simply drift into being confidently wrong. This practice extends your existing ISO 27001 security programme and business continuity arrangements to cover all of it.
Core deliverables
At a glance
Maps to
A new attack surface, mostly unguarded.
Attacks your SOC has never seen
Model poisoning, extraction and evasion don't trip conventional security monitoring. The controls exist — they just aren't in most ISMS scopes yet.
Incidents without playbooks
When a model starts producing harmful output, who can switch it off, what replaces it, and who tells the regulator? Most incident plans have no answer.
Continuity plans that ignore AI
Processes quietly became AI-dependent without anyone updating the business impact analysis. If the model is down, can the process still run?
No one watching the model
Models degrade silently. Without drift monitoring and alerting thresholds, the first person to notice is usually a customer.
What we secure.
ISO 27001 AI extension
AI-specific risks and controls mapped into your existing ISMS — one management system, not a parallel one. Adversarial risk taxonomy drawn from the Coalition for Secure AI (CoSAI) and ISO/IEC 27090 AI security guidance.
Adversarial risk assessment
Poisoning, evasion, extraction and inversion risk per system, rated and prioritised.
Incident response for AI
AI-specific playbooks: kill-switch authority, fallback procedures, notification duties and evidence preservation.
Tabletop exercises
Scenario-based exercises for AI failures — run with the people who would actually be in the room.
Continuity & disaster recovery
AI dependencies in the business impact analysis, with recovery objectives and manual fallbacks defined.
Monitoring & alerting
Drift, anomaly and misuse detection with thresholds, ownership and escalation built in.
A typical 8–12 week engagement.
Assess
- AI asset & dependency inventory
- Adversarial risk assessment
- ISMS gap analysis
Build
- Control implementation roadmap
- Incident playbooks
- Continuity plan updates
Prove
- Tabletop exercise
- Monitoring go-live
- Board readout
Plan for the day the model is wrong.
One workshop is enough to find out whether your incident and continuity plans would survive an AI failure.
Book a consultation