The CISO and AI: new risks, familiar controls

Generative AI entered the organization through several doors at once: assistants employees switch on by themselves, AI features inside SaaS tools already under contract, internal projects that connect a language model to documents and, increasingly, agents that query systems and take actions. For the CISO, the immediate question is whether a new security program is needed.

The short answer is no. Some risks are genuinely new, with mechanisms that classic controls do not see. But almost all of them are managed with the same functions that already organize the security program: govern, identify, protect, detect, respond and recover. The work is to place each new risk in that structure, adjust existing controls and close a few real gaps. This article proposes that mapping with the NIST Cybersecurity Framework (CSF) 2.0 as the backbone.

Five risks that are genuinely new

It helps to separate what is new from what has only changed in scale. A phishing email written with AI is more convincing, but the control is the same. The five risks below, by contrast, have a mechanism of their own. The first four appear in the OWASP Top 10 for LLM Applications 2025, published in November 2024; the fifth is a governance problem more than a technology one.

Prompt injection

A language model cannot reliably tell apart the instructions of whoever designed the application and the text it is processing. Direct injection is typed by the user to get around restrictions. Indirect injection arrives hidden in an email, a web page or a document the system reads as context. It is the first risk on the OWASP list and has no complete solution today: it is reduced with several layers, not eliminated with a filter.

Data and model poisoning

Anyone who manages to alter training data, fine-tuning data or the document base behind a retrieval-augmented generation (RAG) application can change the system's behavior without touching a line of code. The effect can be subtle: skewed answers on a specific topic, or a backdoor that only fires on a particular phrase.

Data leakage through outputs

The model can reveal sensitive data that was in its context, in the documents it can access or in its own system instructions. The risk grows when the application queries repositories with broader permissions than the user asking: the model answers with what it finds, not with what that user is entitled to see.

Model supply chain

Pretrained models, adapters, datasets and the libraries that load them are third-party components. A model downloaded from a public repository may have been tampered with, and some serialization formats allow code to run the moment the model is loaded. Add to that model-as-a-service providers, which process the organization's data under their own contractual terms.

Unauthorized AI use

Employees pasting contracts, code or customer data into public AI services, or teams turning on AI features in a SaaS platform without review. It is not a technical risk of the model, but it tends to be the first to materialize, because it needs no attacker.

Where each risk fits in CSF 2.0

CSF 2.0, published by NIST in February 2024, organizes cybersecurity risk management into six functions. Govern, the function added in this version, steers the other five. That structure works for AI without changes: what changes is the content of each function.

The mapping is not exclusive. Prompt injection, for example, is also detected and responded to; the diagram places each risk where its main control sits. For how to present Govern to the board, see the Govern function in NIST CSF 2.0.

One clarification: the CSF is not a catalog of AI-specific controls. For that, NIST published the Generative AI Profile of the AI RMF (NIST AI 600-1) in July 2024. It describes twelve risks that are unique to or worsened by generative AI, including information security, data privacy and value chain and component integration, and proposes actions to manage them. The CSF provides the structure; the NIST profile and the OWASP list provide the detail.

From new risk to familiar control

The table translates each risk into controls a mature security program already runs, with the adjustment AI requires. It is a starting point, not a closed list.

New risk	Main function	Familiar control	AI adjustment
Unauthorized AI use	Govern	Acceptable use policy, SaaS application management, web filtering	List of approved AI services, which data each one accepts and an authorized internal alternative
Model supply chain	Identify	Third-party risk management, asset inventory, component analysis	Model inventory with version and provenance, provider data-use terms, safe model formats
Prompt injection	Protect	Input validation, segmentation, least privilege	All external content treated as untrusted; limits on what the model can do even if it is fooled
Data leakage through outputs	Detect	Data loss prevention (DLP), event monitoring	Output filtering, user permissions enforced at document retrieval, logging of inputs and responses
Agent taking improper actions	Respond	Incident playbooks, access revocation	Agent kill switch, revocation of its credentials, log preservation for analysis
Poisoned data or model	Recover	Backups, restore points, change management	Versioned datasets, indexes and models to roll back to a known trusted state

Look at the last column: almost no row calls for a new tool. It calls for extending the scope of processes that already exist. The asset inventory must include models and data sources; third-party management must ask what the provider does with the prompts and documents it receives; event logging must capture what goes into and comes out of the model. For financial entities subject to DORA, model-as-a-service providers also belong in the register of ICT providers; we cover that in DORA and ICT providers.

What you do need to build

Three pieces are missing from most security programs and are worth building on purpose.

AI-specific threat modeling

Threat modeling methodologies still work, but the catalog of attack techniques is different. MITRE ATLAS organizes tactics and techniques against AI systems with a structure similar to ATT&CK, and it is a good starting point for the security and data science teams to speak the same language. Every AI application with access to sensitive data or tools should go through this exercise before reaching production.

Adversarial testing

Traditional penetration tests do not cover prompt injection or leakage through outputs. You need a set of adversarial tests (AI red teaming) that runs before every relevant change of model, instructions or data sources. NIST AI 600-1 lists pre-deployment testing among its primary considerations.

Logging with privacy in mind

Detecting and responding requires logging prompts, retrieved context, responses and tool calls. Those logs contain sensitive data by definition. Their retention, access and masking should be defined with the data protection team before logging is switched on, not after the first incident.

A starter plan for the CISO

If the organization already has a CSF-aligned program, these steps bring AI in without building a parallel structure:

1. Inventory. List the AI services in use (approved or not), internal applications with models and agents with access to systems. The usual sources are the web proxy, the SaaS application catalog and the development teams.
2. Set the policy. Publish which services are approved, for which types of data and how to request a new one. A ban with no alternative pushes usage out of sight.
3. Classify by exposure. Separate uses that only generate text for a person from those that query sensitive data or take actions. The latter go through threat modeling and adversarial testing.
4. Extend existing controls. Add models and datasets to the asset inventory, AI providers to third-party management and AI scenarios to the incident playbooks.
5. Measure and report. Add simple indicators to the risk dashboard: inventoried uses, percentage with a risk assessment and AI-related incidents.

If the organization also wants a certifiable management system for AI, ISO/IEC 42001 fits this approach; we explain it in ISO/IEC 42001 in practice. And if the next step is agents that act on infrastructure, the context is in AI agents in IT operations.

Before setting the usage policy and the classification criteria, validate them with Compliance, Legal and the data protection team, because they touch regulatory and employment obligations.