CISO Role in AI Security, in depth: ownership, inventory, tiered controls, shadow AI, vendors and board reporting

Own the method, not every decision

AI security fails when the CISO owns nothing, or when the CISO owns everything and becomes an approval queue that teams route around. The workable middle is to own the method: how AI risk is classified, which minimum controls apply to each class, how incidents are handled, and how risk is reported. Peers own the decisions inside their own domains.

The split holds if you also have a chief AI officer: they own build and operation, the CISO owns the risk method and baseline. Get the RACI signed before an incident, not during one.

Build an inventory of AI systems

You cannot secure systems you do not know about, and AI systems are especially easy to miss. A team can enable an AI feature in a SaaS product with a toggle, or add a model SDK to a service in one pull request. Build the inventory from several sources, because none of them is complete on its own: procurement and expense records, SSO application logs, egress proxy or DNS logs for model API domains, dependency scanning for model SDKs in repositories, cloud billing line items for AI services, and a short self-declaration form.

Keep each record small enough that teams will fill it in, but include the fields that drive the risk tier.

from dataclasses import dataclass, field
from enum import IntEnum

class Tier(IntEnum):
    LOW = 1        # internal, no sensitive data, no tools
    MEDIUM = 2     # sensitive data or customer-facing, read-only
    HIGH = 3       # tools with write access, regulated decisions, or autonomous actions

@dataclass
class AISystem:
    name: str
    owner: str                      # a named person, not a team alias
    provider: str                   # "internal", or the vendor name
    model: str                      # model id or "vendor-managed"
    data_classes: set[str]          # e.g. {"public", "internal", "customer_pii", "secrets"}
    customer_facing: bool
    tools_with_write: list[str] = field(default_factory=list)
    affects_individuals: bool = False   # credit, hiring, health, access decisions
    retains_prompts_days: int | None = None

def tier(s: AISystem) -> Tier:
    if s.tools_with_write or s.affects_individuals:
        return Tier.HIGH
    if s.customer_facing or s.data_classes & {"customer_pii", "secrets", "regulated"}:
        return Tier.MEDIUM
    return Tier.LOW

Keep the rule simple enough that a product manager can predict the result; complexity belongs in the controls. Re-tier whenever a system gains a tool, a data class or customer exposure, and let the CI scan trigger it.

Extending the threat model

Your existing threat model still applies. What changes is that the model takes instructions from data: any web page, email, retrieved document or tool result in its context can try to steer it. The OWASP Top 10 for LLM Applications (2025 edition) is a useful checklist, and its value is in giving each risk an owner.

MITRE ATLAS adds attacker techniques against machine learning systems in the ATT&CK style, which helps your red team and detection engineers. Threat modelling for a specific LLM application is covered in threat modelling LLM applications, and the full OWASP list is explained in the OWASP LLM Top 10.

A control baseline by tier

Tiers are only useful if each one maps to a fixed set of minimum controls. A team should be able to read its tier and know what it must do without a meeting. The table is cumulative: each tier includes the controls of the tiers below it.

Two rules keep this from becoming paperwork. Write controls as testable statements, such as "every tool credential expires within one hour", not "tools are secured". And provide reusable implementations, like a gateway that enforces logging and limits, so the baseline is the easy path rather than something every team builds from scratch.

Frameworks and regulation

Frameworks give your programme a structure that auditors and boards recognise. Use them to organise what you do, not as a reason to produce documents. Choose one primary framework and map the others onto it.

NIST AI RMF 1.0 organises AI risk work into four functions: Govern, Map, Measure and Manage. Its companion Generative AI Profile, NIST AI 600-1, lists risks and suggested actions specific to generative systems. It is voluntary, free, and a good primary choice in the United States. See the NIST AI RMF article.

ISO/IEC 42001:2023 specifies an AI management system that can be certified. It fits naturally if you already run ISO/IEC 27001, because the structure is similar, and some customers will start asking for it.

The EU AI Act is law, not a framework, and legal owns classification. The CISO's part is the security, logging and robustness obligations for high-risk systems, plus cooperating on serious-incident reporting. The timeline has moved: the 2026 AI Omnibus deferred obligations for stand-alone high-risk systems from August 2026 to December 2027, while prohibitions and general-purpose model duties kept their original dates. Check the current text with counsel before planning against any date. See EU AI Act compliance.

Shadow AI

Blocking every AI tool does not stop employees from using them. It moves the usage to personal devices, where you have no visibility at all. The approach that works is to offer a sanctioned path that is good enough, then measure and reduce what remains outside it. Start by finding out what is happening. A weekly query over egress proxy logs gives you the shape of unsanctioned use without reading anyone's prompts.

-- Weekly shadow-AI census from egress proxy logs (column names vary by proxy)
SELECT d.service_name,
       d.sanctioned,
       COUNT(DISTINCT l.user_id)  AS users,
       SUM(l.bytes_out) / 1e6     AS mb_uploaded
FROM proxy_logs l
JOIN ai_domains d ON l.host LIKE CONCAT('%', d.domain)
WHERE l.ts >= CURRENT_DATE - INTERVAL '7' DAY
GROUP BY d.service_name, d.sanctioned
ORDER BY d.sanctioned, mb_uploaded DESC;

Upload volume matters more than user count, because large uploads are where data leaks. Then make the sanctioned tool cover the common use case, publish a short acceptable-use policy, coach heavy users directly, and block only services that train on submitted data or offer no enterprise agreement.

Vendors and models as supply chain

Most AI risk in a typical company sits with vendors: model APIs, SaaS products with AI features, and AI coding tools. Add AI-specific questions to your vendor review, and make sure the answers end up in the contract, because a questionnaire answer is not a commitment.

• Is customer data used to train or improve models? Is that off by default, and is it stated in the contract?
• How long are prompts and outputs retained, where, and who at the vendor can read them?
• Which sub-processors, including model providers, receive the data?
• Will you be notified before the underlying model changes, and can you pin a version?
• What logs can you export for your own investigations?

Treat models and model weights you download like any other third-party code: record where they came from, verify hashes, and scan pickled formats or avoid them. Wider third-party controls are covered in third-party LLM risk.

Incident response for AI systems

Besides familiar incidents such as leaked keys, AI adds new ones: an agent acting on an injected instruction, retrieval leaking another tenant's data, a vendor model change silently removing a safety behaviour. Extend your existing process rather than building a separate one: put the AI platform lead on the roster, keep a way to disable each high-tier system's tools on their own, and log enough to reconstruct what the model saw.

Disclosure timelines do not change because the cause was a model. US public companies, for example, must file Form 8-K Item 1.05 within four business days of determining that a cybersecurity incident is material. Your playbook needs to show how an AI incident reaches that materiality decision. Detailed playbooks are in LLM incident response.

What to report to the board

Boards need to know three things: how much AI is in use, how much of it meets the baseline, and what went wrong. Report a short, stable set of measures every quarter, with trends:

• Inventoried AI systems by tier, and the share that meets its tier's baseline.
• High-tier systems with a red-team test in the last 12 months.
• Unsanctioned AI usage: users and upload volume, with the trend.
• AI vendors under contract with training on customer data disabled, as a share of all AI vendors.
• AI incidents and near misses, with time to contain.
• Open exceptions: risks accepted above appetite, each with a named owner and an expiry date.

Do not report blocked prompts or jailbreak attempts as success metrics; they measure attacker activity, not your risk.

Worked example: the first 90 days

Here is how the first 90 days might go for a newly responsible CISO at a 900-person SaaS company. In days 1 to 30, they run the inventory sweep. Procurement lists 11 AI vendors, egress logs show 23 AI services in use, dependency scanning finds model SDKs in 14 repositories, and teams self-declare 9 internal systems. After merging duplicates, there are 31 systems: 19 at tier 1, 9 at tier 2 and 3 at tier 3. The three tier-3 systems are a support agent that can issue refunds, an internal coding agent with repository write access, and a sales tool that drafts and sends emails.

In days 31 to 60, tier 3 gets controls first: refunds above a set amount need approval, the coding agent opens pull requests instead of pushing, and email sending gets a daily cap and a kill switch. The RACI is signed, and one enterprise assistant launches with a one-page acceptable-use policy.

In days 61 to 90, a red-team exercise against the support agent finds an indirect prompt injection through order notes that could trigger refunds below the approval threshold. It is fixed by separating untrusted notes in the context and lowering the threshold. The first board report shows 31 systems, 74% meeting baseline, unsanctioned upload volume down 60% since the sanctioned tool launched, and two accepted exceptions with expiry dates.

Failure modes

• The approval bottleneck. Security reviews every prompt change, and teams route around it. Review by tier, and keep low-tier systems self-attested.
• Policy without tooling. A rule that says "log all prompts" with no gateway to do it. Provide the implementation alongside the rule.
• Questionnaire trust. Vendor answers that never reach the contract. Put training, retention and change notice in writing.
• Static inventory. A spreadsheet from last spring. Feed it from CI scans, billing and egress logs.
• Treating AI as purely novel. Ignoring leaked keys, over-broad service accounts and missing logs, which cause most real incidents.

What to do next

1. Write and sign a RACI for AI risk with the AI lead, privacy, legal and procurement.
2. Run a multi-source inventory sweep (procurement, SSO, egress, CI, billing, self-declaration) and tier every system.
3. Publish a cumulative control baseline per tier, written as testable statements.
4. Fix tier-3 systems first: scoped tool credentials, approval for irreversible actions, kill switches, audit trails.
5. Launch a sanctioned AI assistant and a one-page acceptable-use policy, then start the weekly shadow-AI census.
6. Add AI questions to vendor review and contract templates.
7. Extend incident playbooks to AI incidents and rehearse one tabletop.
8. Choose a primary framework (NIST AI RMF or ISO/IEC 42001) and send the first quarterly board report.