# The CISO's Playbook for AI Governance: Moving Beyond "We'll Figure It Out Later"

Roughly four out of five enterprises have AI tools in production somewhere in the business. Far fewer have a written policy governing them. That gap is not a documentation problem - it is an unbooked liability sitting on your risk register, and it becomes visible the moment an auditor, a regulator, or a customer's security questionnaire asks a question you cannot answer.

This is a practical playbook for CISOs and IT heads who need to close that gap without stalling the business.

## The Gap Is Not Where You Think It Is

Most security leaders assume the AI governance problem is about the models their data science team builds. It usually is not. The models your team builds are the ones you already know about, already review, and already have some control over.

The exposure sits in three places that never crossed your desk:

- **Employee-initiated use.** Someone in finance pastes a draft board deck into a public chatbot to tighten the wording. Someone in support pastes a customer email thread, including personal data, to draft a reply. No procurement, no contract, no logging.
- **Embedded AI features in SaaS you already bought.** Your CRM added an AI summarisation feature. Your ticketing tool added a suggested-reply engine. Your video conferencing tool now records, transcribes, and summarises. None of these went through a new vendor review because the vendor was already approved.
- **Departmental tooling bought on a credit card.** Marketing has a copywriting tool. HR is trialling a CV-screening service. Each is under the approval threshold that would have triggered review.

![An abstract network of nodes - the AI estate that existing security tooling cannot see](/assets/blog-images/cisos-playbook-for-ai-governance/ai-asset-inventory-classification.jpg)

The common factor is that none of these are visible from your existing security tooling. Your CASB may see the domain. Your DLP may see a large paste. Neither tells you that a specific data class went to a specific model under a specific set of terms.

## Why ISO 27001 and NIST CSF Do Not Fully Cover This

Both frameworks remain necessary. Neither is sufficient, and understanding precisely why matters more than the general observation that "AI is different."

Traditional information security frameworks are built around protecting a system whose behaviour is specified. You define the intended behaviour, you control access to it, you monitor for deviation, and you treat deviation as an incident. That model holds for a database, an application server, or a network segment.

An AI system's behaviour is learned rather than specified, which breaks several assumptions:

| Assumption in classic InfoSec | How AI systems break it |
|---|---|
| System behaviour is deterministic and specified | Model output varies across identical inputs; correct behaviour is statistical, not binary |
| The trust boundary is the network or API perimeter | Untrusted input arrives inside the prompt, which is also the instruction channel |
| Data at rest and in transit is the asset to protect | The trained model itself encodes training data and can leak it |
| Configuration drift is the change to detect | Model drift and data drift degrade performance with no configuration change at all |
| A vulnerability is a defect to be patched | Bias and hallucination are properties of the approach, mitigated rather than fixed |
| Supply chain risk ends at the software vendor | Risk extends through model provider, fine-tuning data, and inference host |

ISO 27001 Annex A gives you access control, supplier relationships, and logging - all of which apply. What it does not give you is a control for training-data provenance, a control for model drift monitoring, or a control that says the same untrusted channel carries both the data and the instructions. NIST CSF's Identify function assumes you can enumerate assets; enumerate is precisely the verb that fails when the asset was bought on a credit card.

The practical answer is not to discard what you have. It is to extend it, and to use frameworks built for the purpose alongside it: **NIST AI RMF 1.0** for the risk management function and **ISO/IEC 42001:2023** for a certifiable AI management system that sits alongside your 27001 certificate.

## A Five-Pillar AI Governance Framework

The framework below is deliberately sequential. Each pillar depends on the one before it, and attempting a later pillar without the earlier one is the most common reason AI governance programmes stall.

### Pillar 1: Inventory

You cannot govern what you cannot list. The inventory is a register of every AI system touching company or customer data, whether you built it, bought it, or inherited it inside another product.

Minimum fields per entry: system name, business owner, technical owner, model provider, hosting location, data classes consumed, data classes produced, whether output influences a decision about a person, and date of last review.

Populate it from four sources, not one:

- SaaS spend analysis and expense reports (catches credit-card purchases)
- Identity provider application logs (catches OAuth grants to AI services)
- Network egress and DNS logs (catches direct API use)
- A structured amnesty survey to department heads (catches everything else)

The amnesty framing matters. If the first message about AI governance is a threat, the inventory will be incomplete and you will have taught people to hide things.

### Pillar 2: Classification

Not every AI system deserves the same scrutiny. Classify by consequence, not by technology.

| Tier | Definition | Governance response |
|---|---|---|
| Tier 1 - Critical | Output materially affects a person's rights, money, health, or employment | Full assessment, named accountable owner, documented human review, board visibility |
| Tier 2 - Elevated | Processes personal or confidential data, but output is advisory to a human | Assessment, access control, logging, periodic review |
| Tier 3 - Standard | Internal productivity use on non-sensitive data | Acceptable use policy, approved-tool catalogue, spot checks |
| Tier 4 - Embedded | AI feature inside an already-approved SaaS product | Vendor addendum review, feature-level enable/disable decision |

The tier drives the effort. Attempting Tier 1 rigour on every internal writing assistant guarantees the programme collapses under its own weight within a quarter.

### Pillar 3: Access Control

Access control for AI systems has two dimensions that classic RBAC does not address.

The first is **data-class binding**: an approved model should be permitted to receive specific classes of data and no others. This is enforced through a gateway or proxy that inspects outbound payloads, not through policy documents alone.

The second is **purpose binding**: the same model approved for drafting marketing copy is not thereby approved for screening job applicants. Approvals attach to a use case, not to a tool.

Practical controls: route AI traffic through a managed gateway, maintain an approved-model catalogue with per-model data-class permissions, disable direct API key issuance outside that gateway, and use tenant-isolated or private endpoints for anything above Tier 3.

### Pillar 4: Monitoring

Monitoring an AI system means watching for three failure classes that no traditional monitor detects:

- **Drift** - the statistical distribution of inputs or outputs moves away from the baseline the system was validated against. Set a baseline at deployment and alert on deviation.
- **Anomalous interaction** - a spike in prompt length, unusual token patterns, or repeated near-identical queries that suggest extraction attempts.
- **Outcome disparity** - differential outcome rates across groups for any system making or informing decisions about people.

All three require that you log prompts and outputs in the first place, subject to the same retention and access controls as any other sensitive log. Many organisations discover during their first AI incident that no such log exists.

### Pillar 5: Decommission

The pillar everyone forgets. An AI system that is no longer used but still deployed is an unmonitored, unpatched, credential-holding surface with access to production data.

A decommission procedure should cover: revoking API credentials, deleting fine-tuned model artefacts, confirming deletion with the vendor in writing, archiving the audit trail for the required retention period, removing the entry from the active inventory, and confirming that any data pipeline feeding the system has been stopped.

Set a mandatory review date on every inventory entry. Anything unused for two consecutive review cycles enters decommission by default.

## Talking to the Board in Money, Not in Models

Boards do not act on technical descriptions of risk. They act on quantified exposure and on comparison to peers. Translate accordingly.

![A leadership team reviewing findings around a conference table, illustrating AI risk reported in financial terms](/assets/blog-images/cisos-playbook-for-ai-governance/presenting-ai-risk-to-the-board.jpg)

Four numbers do most of the work:

**Regulatory exposure.** Under India's DPDP Act, the Schedule sets penalties up to ₹250 crore for failure to take reasonable security safeguards. Under the EU AI Act, penalties for prohibited practices reach the higher of EUR 35 million or 7 percent of worldwide annual turnover. State the applicable ceiling and your assessed likelihood, not the ceiling alone - a ceiling with no probability attached reads as scaremongering and gets discounted.

**Contractual exposure.** Count the customer contracts containing security or data-processing warranties that your current AI usage may breach. This number is usually more persuasive than the regulatory one because it is closer, more certain, and denominated in revenue at risk.

**Cost of the gap.** The engineering and legal effort to reach a defensible position, stated as a one-time figure and a run rate.

**Cost of delay.** What the first two numbers become in twelve months at the current rate of unmanaged AI adoption.

Present these as a single slide with a trend line, not as a report. The detail belongs in the appendix for the one director who asks.

## Map to Existing Controls Before Creating New Ones

The instinct on encountering a new risk domain is to write a new control set. Resist it. Every net-new control is a new thing to test, evidence, and defend at audit, and most AI risks are addressed by an existing control with its scope widened.

Work through this decision in order:

1. **Does an existing control already cover this if I extend its scope?** Supplier security assessment extends to model providers. Access control extends to model endpoints. Change management extends to model retraining. Logging extends to prompts and completions. This handles the majority of cases.
2. **Does an existing control cover it with an added test step?** Your secure development lifecycle already has a security review gate; add adversarial prompt testing to the test plan rather than creating a separate AI testing control.
3. **Is this genuinely novel?** A small set is. Training-data provenance, model drift monitoring, and output-bias assessment have no analogue in a classic control set. Create these as net-new, and keep the number small enough that you can genuinely operate them.

A useful sequencing rule: extend first, add test steps second, and create new controls only for what survives. Teams that invert this order routinely produce a forty-control AI framework that nobody operates and no auditor can evidence.

## Conclusion

AI governance fails when it is treated as a policy exercise. It succeeds when it is treated as an asset management problem with a risk overlay: know what you have, rank it by consequence, control access to it, watch it for the failure modes specific to it, and retire it deliberately.

The organisations that will struggle over the next two years are not the ones that adopted AI aggressively. They are the ones that adopted it invisibly, and now have to reconstruct two years of undocumented decisions under audit conditions with no inventory to start from.

**Actionable recommendations:**

- **Run the inventory before writing the policy.** A policy written without knowing what is actually deployed will be either unenforceable or irrelevant. Give yourself thirty days and use all four discovery sources.
- **Classify by consequence, not by technology.** Tiering on whether a system affects a person's rights, money, or employment focuses effort where regulators and customers will actually look.
- **Extend existing controls before authoring new ones.** Your supplier, access, change, and logging controls cover most AI risk once their scope is widened. Reserve net-new controls for provenance, drift, and bias.
- **Set a decommission trigger on day one.** Every inventory entry gets a review date, and anything unused across two cycles retires by default.
- **Report exposure in currency and in contracts.** Regulatory ceilings alone get discounted at board level. Contracts at risk do not.

> **Stop running your AI register in a spreadsheet.** Automate AI asset inventory, consequence-based risk scoring, and control mapping in a single dashboard - with the evidence trail already attached. See how [Dedups.ai](https://dedups.ai) brings AI governance into the same platform as your cloud security and compliance posture.