The CISO's AI Governance Playbook: 30/60/90 Day Plan

A 90-day CISO playbook to stand up a working AI governance programme: 30 days discovery and shadow AI audit, 60 days policy and DLP baseline with audit logging, 90 days compliance mapping and tabletop. Anchored on NIST AI RMF 1.0 (NIST AI 100-1, January 2023). Updated 2026-05-20.

A 30/60/90 structure works because it forces sequencing. The single most common failure mode in AI governance kickoff is parallel work on policy, DLP, training, and vendor management without first establishing the inventory the rest of the programme depends on. Without an inventory, every other artefact is hypothetical.

The structure below is anchored on the four functions of the NIST AI RMF (GOVERN, MAP, MEASURE, MANAGE) and is designed for a CISO at a 200 to 5,000-employee organisation in a regulated sector (financial services, healthcare, insurance, education, public sector). It assumes the CISO is the named accountable executive and has at least one full-time analyst plus part-time access to Legal, Privacy, IT, and HR. At Areebi, we have run this 90-day structure with mid-market customers many times, and the failure modes cluster heavily around skipping discovery rather than around weak policy drafting.

The 90 days are not meant to deliver "compliance complete". They are meant to take an organisation from a cold start to a defensible, working baseline: inventory live, policy published, enforcement on, incident path tested, and a documented gap-to-target roadmap for the following six to twelve months.

The single goal of the first 30 days is an inventory. Everything else - policy, DLP, training, vendor management - is optional until you have a defensible list of every AI system, vendor feature, and shadow tool in use across the organisation. The discovery work breaks into four streams.

Stream 1: Procurement and vendor inventory. Pull the full vendor list from procurement and the SaaS spend tracker. For each vendor, document whether AI features are present, whether they are on by default, and what data is flowing to them. Most enterprises discover that more than half of their AI exposure lives inside non-AI vendors - features quietly added to CRM, productivity, support, and analytics tools.

Stream 2: Network and identity telemetry. Mine the SSO, CASB, and proxy logs for traffic to known AI provider domains (the major LLM providers, image generation services, code assistants). Cross-reference with expense data. The gap between sanctioned tools and observed traffic is the shadow AI surface. The Areebi shadow AI guide covers the discovery mechanics in depth.

Stream 3: Self-report. A simple structured survey to managers and team leads asking which AI tools their team uses and for what purpose. Self-report alone is unreliable, but combined with streams 1 and 2 it surfaces use cases that telemetry misses (offline use, mobile, personal device usage of corporate data).

Stream 4: Use-case interviews. Targeted 30-minute interviews with the function leaders most likely to have material AI exposure (Engineering, Marketing, HR, Finance, Customer Support, Legal). These interviews tend to surface the highest-risk use cases that telemetry alone misses.

Day 30 deliverable: the AI Inventory v1. A single document or system listing every sanctioned and observed AI tool, vendor feature, and use case, with named owner, data classes involved, and a provisional risk tier (high, medium, low). This is the foundation everything else builds on.

The single goal of days 31 to 60 is enforced policy. The output is a published Acceptable Use Policy, with the machine-readable enforcement rules running at the prompt layer, and audit logging proving the rules are firing. This is the work that converts the inventory into a working control surface.

Policy first, then enforcement. Draft the Acceptable Use Policy as a short, readable document (target: under 10 pages, written for non-lawyers). The policy should name approved tools, prohibit specific actions (no PII to unsanctioned tools, no customer data in untrusted models, no production deployment without a documented impact assessment), define escalation paths, and assign accountability. Run the draft through Legal, Privacy, and HR review. Get committee approval before publication.

Then convert policy to enforcement. Each clause in the published policy should map to a specific enforcement rule. Some rules will be at the prompt layer (the Areebi policy engine blocks or redacts based on data class, user role, and destination provider). Others will be at the network or identity layer (CASB rules, conditional access policies, allowlists for sanctioned tools). The point is that every published clause has a documented enforcement mechanism, not a wish.

DLP baseline. The DLP work in this phase focuses on the prompt layer. The control objective: prevent specific data classes (PII, PHI, IP, financial data) from leaving the perimeter to any model regardless of which user or vendor is involved. The Areebi DLP controls classify content at the prompt and either block, redact, or rewrite based on policy. Get DLP live on the top three use cases identified at day 30, then expand from there.

Audit baseline. Every interaction logged with the model version, policy version, user, role, data classes detected, and the disposition (allowed, blocked, redacted). The audit log is what makes future incident response possible. Without it, you cannot reconstruct what happened. The Areebi audit log does this by default.

Day 60 deliverables. Published Acceptable Use Policy. Enforcement live on the top three use cases. DLP baseline in production. Audit log capturing every interaction. Training launched to all employees with the ability to deploy or use AI in workflows.

The single goal of days 61 to 90 is operational readiness. The output is a documented mapping of controls to the relevant regulatory frameworks, plus a tested incident response path proven through a tabletop exercise.

Compliance mapping. Map the controls now in place (policy, DLP, audit, vendor management, training) to the regulatory frameworks the organisation is subject to. For most US-based mid-market organisations the priority frameworks are NIST AI RMF (with AI 600-1 for GenAI), ISO/IEC 42001, and any applicable US state laws (Colorado AI Act, California SB-942). For EU-exposed organisations add the EU AI Act. The mapping is the artefact that audit, procurement, and regulators will request first.

Tabletop exercise. Run a structured tabletop with the AI Governance Committee, Legal, Privacy, IT Security, Communications, and the business unit owner of the affected use case. Pick a realistic scenario: a vendor model emits sensitive data to an external user, a prompt injection attack succeeds against a customer-facing assistant, a model drift incident causes an unexpected disparate impact pattern. Walk the response through detection, containment, communication, remediation, and post-incident review. Document the timing, the gaps, and the lessons learned.

Roadmap and handoff. Convert the gaps identified through tabletop and compliance mapping into a documented 6-12 month roadmap with named owners and target dates. Hand the roadmap to the AI Governance Committee for ongoing operation. The 90-day playbook ends; the operating model begins.

Day 90 deliverables. Compliance mapping artefact (controls-to-frameworks). Completed tabletop exercise with documented lessons. Six to twelve-month roadmap with named owners. AI Governance Committee operating in steady state with monthly cadence. Quarterly risk report ready for executive distribution.

The summary table for the entire 90 days.

The mapping back to NIST AI RMF functions is intentional. The 30/60/90 structure is a sequencing layer on top of NIST, not a replacement for it. The NIST AI RMF compliance hub walks through the framework in depth, and the GOVERN deep dive and MAP deep dive cover the two functions most relevant to days 1 through 60.

Three failure modes show up repeatedly when CISOs run the 30/60/90.

Failure 1: Skipping discovery to "get to policy faster". The temptation to draft policy in week 1 is strong because policy feels concrete. Without an inventory, policy is hypothetical and enforcement is impossible. The fix is discipline: no policy work before the inventory is at v1.

Failure 2: Policy without enforcement. A published policy that exists only as a PDF is not GOVERN-compliant under NIST and is not defensible in audit. Every clause must map to a specific enforcement rule, and audit logs must prove the rules are firing. The fix is the policy-clause-to-enforcement-rule mapping done during days 31 to 60.

Failure 3: Tabletop as theatre. A scripted tabletop where everyone says the right thing in the right order produces no learning. The fix is to design the scenario for genuine ambiguity, time-box decisions, and require named individuals to make the actual calls under realistic time pressure. Lessons learned should produce concrete control deltas.

Related Areebi resources for CISOs running the 30/60/90.

• Build an AI governance programme - the operating-model layer above the 30/60/90.
• NIST AI RMF implementation guide - the longer-form, 24-week implementation playbook.
• Shadow AI guide - the discovery mechanics for days 1 to 30.
• AI compliance checklist for enterprise - the artefact-level checklist that complements the phase checklists above.
• State of AI governance May 2026 roundup - the regulatory context for the compliance mapping in days 61 to 90.