Cyber Warrior came to AI from security. This page is written as a working reference for the controls an AI system actually needs, and you are welcome to use it whether or not you ever engage us.
The accountability chain
AI governance establishes who is accountable for each AI system, what it may access, and how its outputs are logged and reviewed. Controls map to ISO 27001, the DPDP Act 2023 and the EU AI Act risk tiers, covering prompt injection, data residency and model change management.
Each of these has surfaced during a real security review. None of them are difficult to answer if they were asked before launch.
Nobody knows, because the answer includes a departmental subscription, a spreadsheet plugin and something a contractor built last year. Shadow AI is normal rather than shameful, and the first useful governance output is simply a complete list.
The build team assumed the business owner had; the business owner assumed compliance had. This gap becomes visible during an incident, which is the worst moment to discover it. A named individual, recorded, before launch.
Under the DPDP Act 2023 and the DPDP Rules 2025 this needs a documented answer rather than an assumption. Most systems can answer it; very few have written it down, and reconstructing it after the fact from code is slow work.
The provider shipped three model versions, someone edited a prompt, and the document corpus grew. All of those change behaviour, and none of them went through change control because change control was written for code. This is the most common AI-specific gap we find.
Five questions about consequence rather than technology. The EU AI Act groups systems into four risk bands, and the band determines how much control the system needs regardless of how simple it looked in the demo.
Does it influence decisions about individuals, such as credit, employment, insurance or care?
Can it act on its own, or does a person approve every consequential output?
Does it interact directly with customers or the public?
Does it process personal data?
Is it offered to, or does its output reach, users in the EU?
Indicative band
Internal, supervised, no personal data and no decisions about people. Standard application security and a register entry are proportionate. Most first pilots belong here deliberately, and starting here is a governance strategy rather than a limitation.
Obligations to plan for
This is an orientation tool, not legal advice. Classification under the EU AI Act, the DPDP Act or any sectoral regulation is a legal determination. We prepare the technical evidence and work alongside your counsel, who should confirm the classification itself.
Delivered by the team that runs our VAPT and zero-trust engagements, not by a separate compliance function reading a checklist.
We review the system the way an attacker would approach it: every place untrusted text enters, every tool the model can reach, what the service identity is permitted to do, and what happens to output before it reaches a browser. Standard application security still applies in full and is assessed alongside.
Findings come with a fix and a severity, and we re-test rather than closing on a description. The architectural patterns are set out under generative AI development.
Every AI system, with owner, purpose, data categories, model and version, classification, evaluation results and review date. Unglamorous, and it is the artefact that turns governance from an intention into something checkable.
Prompt edits, index rebuilds and provider version changes all alter behaviour. They go through change control with evaluation evidence attached, which is the gap most existing ISMS processes have.
Which fields leave the network, to which processor, in which region, retained for how long. Produced as a diagram and a table, and kept current as part of the same change process. Self-hosted orchestration shortens this considerably.
What to do when a system produces harmful output. Written, assigned and walked through, because the first time you read a runbook should not be during the incident.
Five steps that work whether you have one AI system or twenty, and whether they are already live. Part of the wider AI and automation practice.
Including the ones nobody registered. A departmental subscription, a plugin someone enabled, a script a contractor left behind. We treat shadow AI as expected rather than as a finding, because a register built on blame is a register that stays incomplete.
A model recommending stock levels and a model scoring loan applications may share an architecture and need entirely different controls. Risk follows what the output affects and who it affects, which is why the classifier above asks about people rather than about models.
If you hold ISO 27001, most of the required controls already exist: access control, logging, supplier management, change management, incident response. We extend them to cover AI rather than standing up a parallel regime that competes for the same people's attention.
Model change management, evaluation evidence, prompt injection containment, output filtering and data residency documentation. These five have no pre-AI equivalent, and they are consistently where the findings are. Applies equally to robot identities and model service accounts.
A register entry with a review date and an accountable individual, and an incident runbook that has been walked through. Governance that happens once is a project; governance that recurs is a control.
The same underlying controls, expressed in the vocabulary each framework uses. Select a framework to see what an AI system specifically has to satisfy.
| Control area | What it means for an AI system | What we implement |
|---|---|---|
| Access control | The model and its tools are identities that need permissions | A scoped service identity per tool, least privilege, no shared human accounts |
| Logging and monitoring | Runs must be reconstructable months later | Per-step logging of input, tool call, result and decision, with replay |
| Supplier management | Model providers are processors in your supply chain | Provider register, retention settings evidenced, region documented |
| Change management | Prompts, indexes and model versions change behaviour | All three under change control with evaluation evidence attached |
| Incident response | Harmful output is an incident class the plan may not cover | An AI incident runbook with severity criteria and a kill switch |
A support assistant has told a customer something that is not true. Step through what happens in an organisation that prepared for this, and notice how much of the response depends on decisions made before launch.
Incident
ai-2026-014 · step 1 of 6
T+0 · Detection
An agent flags a conversation where the assistant stated a refund window that does not exist. Detection came from a person, which is normal — the useful question is whether there is a route for them to report it, and here there is a button in the agent console.
T+10 min · Containment decision
The named owner decides whether to disable the assistant or restrict it to escalation only. Because a kill switch exists and has been tested, this is a decision rather than an engineering task. Restricted mode is chosen; the assistant now routes everything to a person.
T+40 min · Reconstruction
The run trace shows what was retrieved and what score it cleared. The cited source turns out to be a superseded policy document that was re-indexed last week. The model behaved correctly on bad input, which changes the fix entirely.
T+2 h · Blast radius
A query across conversation logs finds every other exchange that cited the same document. Eleven customers received the same wrong answer. Without retained logs and citations this step is not possible at all, and the honest answer to how many were affected becomes "we cannot tell".
T+4 h · Fix and verify
The superseded document is removed and the index rebuilt. The case is added to the evaluation set so any future regression fails a build. The suite is re-run before the assistant returns to normal operation, and the result is recorded against the change.
T+1 day · Process change
The real finding is not the wrong answer, it is that a superseded document could enter the corpus without review. Ingestion now requires a document owner and an effective date. That control did not exist because nobody had imagined this failure until it happened.
Five of these six steps were only possible because of decisions made before launch: a reporting route, a tested kill switch, retained run traces, citations on every answer, and an evaluation set to add the case to. Governance is what makes an incident survivable rather than what prevents it.
Whether by an auditor, an enterprise customer's security questionnaire, or your own board. All four are short if written early.
Four patterns we see repeatedly. Profiles are anonymised.
Anything touching a credit decision sits in the highest band, and the useful early work is drawing a hard line between systems that assemble a case and systems that influence the outcome. The first can ship quickly; the second needs formal treatment.
Banking and insuranceThe line between administrative help and clinical advice cannot depend on a prompt. Topic classification runs before the model, refusals are logged, and we sign Business Associate Agreements where the engagement requires it.
Healthcare engagementsGovernance often arrives because an enterprise customer sent a security questionnaire with AI questions on it. The data flow record and the model register answer most of it, which turns a two-week scramble into an afternoon.
Logistics engagementsClient material under engagement terms may not be permitted to reach a third-party processor at all. That constraint usually decides the deployment shape before any other requirement does, and it is better established in week one.
Consulting providersConventional application security still applies in full. These five rows are what is genuinely different, and they are where reviews find gaps.
| Area | Conventional software | AI system |
|---|---|---|
| Testing | Deterministic: it passes or it fails | Statistical: a score against a fixed evaluation set, with a threshold |
| Untrusted input | Validated at defined entry points | Any text the system reads is an instruction channel |
| Change control | Triggered by a code deployment | Also by prompt edits, index rebuilds and provider model updates |
| Supply chain | Libraries and hosting providers | Also model providers, which are processors with their own regions |
| Failure mode | An error, usually loud | A fluent, confident, wrong answer that nobody flags |
The last row is the one that changes review practice most. Conventional monitoring watches for errors, and an AI system in its worst state produces none. Monitoring has to watch quality and refusal rates rather than exceptions. The wider security programme context sits under the security challenge.
Every delivery line in the AI and automation practice is built against the controls on this page.
The highest-governance system type, because it acts rather than answers.
Where the containment patterns referenced here are implemented in detail.
Public-facing systems, where transparency and refusal design carry the risk.
Where the incident walkthrough above most often plays out in practice.
Where the governance dimension gets scored before anything is built.
The organisation-wide framing, for boards rather than build teams.
Penetration testing and zero-trust work sits with our cyber security practice, and programme-level policy design with IT consulting and advisory. To start, tell us what you already run or read the help centre.
The ten that come up in almost every review. None of these are legal advice.
Even an incomplete one. The inventory is the first deliverable and it is usually the one that changes the conversation. We reply in under 3 minutes.
