Generative AI Security Standard

Purpose

An LLM application puts instructions and data in one channel. The model reads the organisation's instructions and an attacker's words as the same kind of thing, so the checks that work for ordinary input, such as matching a field against a pattern, cannot tell them apart. The national cyber centres and OWASP both say the defence lies in the system around the model, because the model will sometimes be fooled. Everything the organisation already does for access, logging, secure development, patching and supplier assurance still applies and is not repeated here. This pack adds what is specific: what the model may read, what its output may reach, what it may do, who approves what it does, and how the organisation tests all of this before release and watches it afterwards. The result is counts of features reviewed, checks verified and findings open. It is never one score.

This standard commits [[Organisation Name]] to the same approach. It sets 31 requirements, GS-01 to GS-31, for every generative AI feature the organisation builds, configures or switches on. Each requirement names the threats it answers (LT-01 to LT-12) and the evidence a reviewer looks at. Every other document in the Generative AI Security pack cites the requirements by number.

The other documents in the pack put the standard into practice. The LLM Application Security Review Procedure reviews each feature, and the LLM Application Threat Catalogue, Generative AI Deployment Configuration Checklist, AI Vendor & Model Provider Security Questionnaire, AI Red Team Test Plan Template, AI Security Findings & Exceptions Register and AI Agent Permission & Tool-Access Review Checklist support the review.

What this standard leaves to P24. The rules on which AI may be used, with which data, who approves a use and how a use is recorded are P24's (AG-01 to AG-22). This pack does not change them. It sets what a generative AI feature has to do to be secure once a use is approved, and what the organisation checks before the feature goes live and while it runs.

Legal note. This document helps you secure the generative AI your organisation builds, configures or buys. It is not legal advice, and following it is not a statement that you comply with the EU AI Act, the GDPR or any standard. A test that finds no problem does not show that a feature is secure. Whether the Act binds you, in which role, and which of its duties apply to each system depends on the facts: confirm it with counsel.

Scope

This standard applies to:

• Features: every large language model (LLM) feature the organisation builds, configures or switches on, for staff or for customers: chat assistants, summarisers built into other software, customer chatbots, search over company documents, coding assistants and agents. It covers the model, the instructions sent to it, its tools and connectors, its stores of retrieved content and memory, and its logs (GS-01).
• Features that suppliers add: an LLM feature that arrives in software already in use is in scope from the day it is switched on. A supplier can add one in a release (GS-01).
• People: everyone who builds, configures, approves, tests or runs such a feature, and the suppliers whose models and services the feature uses.
• Other AI: AI that is not generative, such as a forecasting model or an anomaly filter, stays under the AI governance rules of the AI Security Governance & Acceptable Use pack and is not covered here.

Excluded: [[anything deliberately left out, and where it is covered instead, e.g. an AI feature inside a product the organisation sells, which a separate product security process covers; or "None"]].

Everything the organisation already does for access, logging, secure development, patching and supplier assurance still applies and is not repeated here: access under the Joiner-Mover-Leaver & Access Provisioning and Privileged Access Management packs, vulnerabilities and patches under the Vulnerability & Exposure Management and Patch Management packs, classification under the Information Classification & Handling pack, incidents under the Security Incident Management pack and suppliers under the Third-Party Security Risk Management pack.

How this standard works

Every feature answers five questions: what may the model read; where may its output go; what may it do; who approves what it does; how is it tested and watched. The requirements are the detail.

Design on the assumption that the model will be fooled (GS-02). The national cyber centres and OWASP both say the defence lies in the system around the model. Filters and instructions in the prompt lower the chance of an attack working. They are not a barrier. The remaining requirements limit what a successful attack can reach.

The review depth

Each feature is reviewed at a depth. The depth follows the P24 tier of the use and rises with the features that raise the risk: retrieval over company content above the Public level, tools, memory between sessions and the rule of two below (GS-09, GS-14, GS-22, GS-24). The Head of Information Security sets it in the LLM Application Security Review Procedure. The approvers, the decision time and the approval's review interval follow the higher of the P24 tier and the depth; where the two review dates differ, the earlier applies. The depth routes the review and says nothing about how the Act classifies the feature. Values in [[brackets]] are the pack's defaults.

The rule of two (GS-24). Count three properties of the feature. With all three, a person approves every action. With two, the review records the residual risk.

Where the standard comes from

EU AI Act. Regulation (EU) 2024/1689 binds the operators of its Article 2(1). Article 15 sets requirements for high-risk AI systems, and the provider of such a system answers for them. An organisation that uses another party’s AI system under its own authority is a deployer (Article 3(4)), and its duties are those of Article 26 and the other articles that name deployers. This pack cites Article 15 as the Act’s own statement of what security a high-risk system needs, and cites no system as high-risk. Counsel confirms the role and the category of each system.

GDPR. Regulation (EU) 2016/679 binds controllers and processors. Article 25 asks the controller for data protection by design and by default, and Article 32 for security of processing that is appropriate to the risk. Both apply to an LLM application that processes personal data. Whether an organisation is a controller or a processor for a given application depends on the facts, and counsel confirms it.

Threats this standard answers

The twelve threats are those of the LLM Application Threat Catalogue. Each of the ten classes of the OWASP Top 10 for LLM Applications, 2026 edition, has a threat. Prompt injection is split into direct (LT-01) and indirect (LT-02), and LT-12 adds attacks on memory and tool descriptions, for which OWASP points to its agentic list. OWASP and MITRE ATLAS are community sources. They are cited as the sources state them, not as law.

Requirements

The requirements keep the IDs GS-01 to GS-31 that every document in the Generative AI Security pack cites. Values in [[brackets]] are the pack's defaults; set your own before approval. Under each requirement, the threats it answers and the evidence a reviewer looks at.

Scope

GS-01 Every LLM feature the organisation builds, configures or switches on is on the AI inventory (P24 A05) with a named owner before it goes live, and this standard applies to it. That includes a feature a supplier adds to software already in use. A feature the organisation builds on a supplier's model API (prompts, retrieval, tools or code around a model it calls) answers Yes to P24's building question, for staff as for customers (AG-17): a new feature is Tier 3 and held until Legal records the role, and it is reviewed at Depth 3 until then. If Legal records the deployer role, the tier is set again from the answers and the depth follows it; if Legal records the provider role or another role, the hold clears but the feature stays Tier 3 and stays at Depth 3. A feature already running carries the hold as a condition with a date and is reviewed at the depth its tier and properties give. A supplier's finished product used as supplied is not building. Which AI may be used and who approves it are P24's rules (AG-09).

Answers: all twelve threats (LT-01 to LT-12). Evidence: the inventory entry (P24 A05) with owner and a date before go-live; supplier-added features found at the last inventory review.

Design

GS-02 Design on the assumption that the model will be fooled. The security of the feature rests on what the system around the model allows, never on instructions in the prompt. A control that is only a sentence in a prompt is not a control.

Answers: LT-01 direct prompt injection; LT-02 indirect prompt injection; LT-09 hidden context exposure (system prompt leakage). Evidence: the review record showing which controls sit in code, permissions and approvals; a test showing the feature holds when its prompt rules are ignored.

GS-03 Draw a data flow for each feature that shows every source the model reads (user input, files, web pages, email, tool results, retrieved text, memory) and every place its output goes (screens, files, databases, links, tools, other systems). Mark each source trusted or untrusted. Content from outside the organisation, and content from anyone who can submit text, is untrusted, whichever system holds it.

Answers: LT-01, LT-02, LT-03, LT-10, LT-11. Evidence: the data flow (E-1), with every source and destination marked trusted or untrusted.

Input handling

GS-04 Keep untrusted content apart from instructions: send it in a separate, labelled part of the request, and never build instructions by joining text from untrusted sources. Strip hidden characters (tag characters, zero-width characters and variation selectors) when content comes in and when output is shown. Filter every kind of input the feature takes, not only text. These steps lower the chance of success. They are not a barrier.

Answers: LT-01 direct prompt injection; LT-02 indirect prompt injection. Evidence: the request-building code or settings showing untrusted content in its own labelled part, and the hidden-character filter; results for AC-01 and AC-02.

GS-05 Limit the size, number and type of inputs, files and tool results the model receives, and reject the rest.

Answers: LT-01 direct prompt injection; LT-07 unbounded consumption. Evidence: the configured limits on size, number and type of input; a test that an oversized or wrong-type input is rejected.

Output handling

GS-06 Treat the model's output as untrusted input to whatever receives it. Check it against a schema in application code, encode it for where it goes (page, query, shell, link, terminal), and never pass it to an interpreter, query or template without that.

Answers: LT-11 improper output handling; LT-01 direct prompt injection; LT-04 excessive agency. Evidence: the output schema and encoding in the receiving code; results for AC-11.

GS-07 A screen or message that shows model output does not fetch addresses the output names (images, link previews, frames) unless they are on an allow list, and shows the full address of any link.

Answers: LT-03 sensitive information disclosure; LT-11 improper output handling; LT-02 indirect prompt injection. Evidence: the address allow list; a test that no address named in output loads by itself (DC-24).

Data exposure

GS-08 Send the model only what the task needs, at the lowest data level that works, and apply P24's data permissions at the point of sending (the data permission check of the approved tool list, P24 A07; P15 levels). Personal data goes in only as GDPR Article 25 asks: by design and by default, with the amount, the extent of processing, the storage period and the access limited to the purpose.

Answers: LT-03 sensitive information disclosure; LT-10 vector and embedding weaknesses. Evidence: the data flow with the data level of each item sent; the tool's entry on the approved list (P24 A07); the privacy review where personal data is involved.

GS-09 Retrieval and search tools return only what the signed-in person may already read. The check is made in the index query or the source system, with the person's identity. Asking the model to hold something back is not a check.

Answers: LT-10 vector and embedding weaknesses; LT-03 sensitive information disclosure. Evidence: the identity check in the index or source system; a test with two accounts of different rights (DC-08); results for AC-10.

Secrets

GS-10 No secret, password, key or token goes into a prompt, a system prompt, a tool description or a knowledge store. The application or a secrets store holds keys, one per feature and environment, rotated and recovered as P14 sets (PA-10). A key that appears in output or a log is revoked at once.

Answers: LT-09 hidden context exposure (system prompt leakage); LT-03 sensitive information disclosure; LT-04 excessive agency. Evidence: secrets store entries per feature and environment; scans of prompts, tool descriptions and stores; rotation dates; any key revoked after it appeared in output or a log (DC-12, DC-21).

GS-11 Treat the system prompt, the tool descriptions and any policy text retrieved for the model as readable by users. Nothing in them may give an attacker more access than they already have, and nothing in them is relied on as a security boundary.

Answers: LT-09 hidden context exposure (system prompt leakage). Evidence: the reviewed system prompt and tool descriptions; results for AC-09 showing that revealing them gives an attacker no extra access.

Knowledge stores

GS-12 Every knowledge store (index, vector store, cache, memory) has an owner, a list of its sources, a data level, access control that matches its sources, and a way to remove a document and everything derived from it.

Answers: LT-10 vector and embedding weaknesses; LT-06 data and model poisoning; LT-03 sensitive information disclosure. Evidence: the store's entry: owner, sources, data level, access list and removal route; a removal test (DC-09).

GS-13 Content enters a knowledge store only from named sources, added by named people or processes, with a record of who added it and when. Content from untrusted sources is kept apart from trusted content and checked before it is trusted.

Answers: LT-06 data and model poisoning; LT-10 vector and embedding weaknesses; LT-02 indirect prompt injection. Evidence: the list of named sources and of who may add to them; the log of additions; untrusted content kept apart; results for AC-06.

GS-14 Where a feature keeps memory between sessions, writes to memory are logged with their cause, are limited to what the task needs, and are kept per person. The person and the owner can view and clear them. Text that reads as an instruction is not stored as memory without approval.

Answers: LT-12 poisoned memory and tool descriptions; LT-06 data and model poisoning; LT-02 indirect prompt injection. Evidence: the memory design; the log of memory writes with cause; the view-and-clear function; results for AC-12.

Model and provider

GS-15 Choose a model and its provider through P24's tool approval (A07) and the supplier assessment of P06, and record the model name and version each feature uses. The provider answers the questionnaire (A06). A model or adapter taken from a public source is used only after its publisher, source and file hash are checked and it is loaded in a form that does not run code when loaded.

Answers: LT-05 AI supply chain compromise; LT-06 data and model poisoning; LT-03 sensitive information disclosure. Evidence: the record of model name and version; publisher, source and hash checks; the P06 supplier decision; the questionnaire answers (A06).

GS-16 Keep a list of the models, adapters, datasets, libraries, tools and connectors each feature uses, with versions, and manage them as the vulnerability and patch packs manage other software (P01, P17). Tool and connector servers are pinned to a version and approved before use.

Answers: LT-05 AI supply chain compromise; LT-12 poisoned memory and tool descriptions. Evidence: the list of models, adapters, datasets, libraries, tools and connectors with versions; pinned versions; approval of each connector server.

GS-17 The contract carries the AI terms ST-1 to ST-8 (P24) and the clauses P06 clause CL-04, P06 clause CL-05, P06 clause CL-06, P06 clause CL-07, P06 clause CL-13 and P06 clause CL-20, and the provider's answers to A06 are on file.

Answers: LT-03 sensitive information disclosure; LT-05 AI supply chain compromise; LT-06 data and model poisoning. Evidence: the contract showing ST-1 to ST-8 and the named clauses; the questionnaire (A06) on file.

Change control

GS-18 A change of model, model version, system prompt, tool, retrieval source or filter setting is a change: it goes through the change control that applies to the system, the attack classes it could affect are tested again at the feature's review depth, and the change is recorded. A provider's change of model is a trigger for review within [[10]] working days of the notice (P24 ST-7; AG-10).

Answers: LT-01, LT-02, LT-05, LT-08, LT-09. Evidence: the change record for each change; retest results; the date each review started after a provider's notice.

Logging

GS-19 Log, for each request: who asked and when; the feature, model and version; the system prompt version; the sources retrieved; every tool call with its arguments and result; the output; and the verdict of each filter. Write the log to a store that the feature's administrators cannot change. Keep it for the period the owner records for the purpose, at least [[6]] months, and for a high-risk system at least 6 months where the Act applies (Article 26(6)). Limit who can read prompt logs and keep secrets out of them.

Answers: LT-01, LT-02, LT-03, LT-04, LT-06, LT-10, LT-11, LT-12. Evidence: the log settings: fields captured, protected store, retention and access list (DC-15 to DC-17).

Monitoring

GS-20 Monitor use for the signals AS-01 to AS-12. Alerts go to a named person, who looks at each within [[2]] working days. An event goes to the incident route (P09 IM-01).

Answers: LT-01, LT-02, LT-03, LT-04, LT-07, LT-08, LT-09, LT-10, LT-11, LT-12. Evidence: the alert rules (DC-18); the alert log with date seen and by whom; events passed to the incident route.

Resource limits

GS-21 Set limits per person and per feature on requests, tokens and the number of steps and tool calls in one task, and a hard spending cap per key and per feature that stops use when it is reached. A cap that only sends a warning is not a cap.

Answers: LT-07 unbounded consumption; LT-04 excessive agency. Evidence: the limits and spending cap; results for AC-07 showing the cap stops use (DC-25 to DC-27).

Agents and tools

GS-22 Give the model only the tools the task needs. Each tool does one job and takes a strict input. Do not offer an open-ended tool (run any command, fetch any address) unless it runs in a sandbox with no network access to internal systems and no secrets.

Answers: LT-04 excessive agency; LT-12 poisoned memory and tool descriptions; LT-11 improper output handling. Evidence: the tool list with each tool's one job and input rules; for an open-ended tool, the sandbox settings (DC-10, DC-13, DC-19).

GS-23 A tool acts as the signed-in person, or under a named service identity with the least access its job needs (P14 PA-11; P13 JML-12). Credentials are held by the application, never the model, and the person's permission is checked on every call by code, not by the model.

Answers: LT-04 excessive agency; LT-10 vector and embedding weaknesses. Evidence: the identity and scopes of each tool; a test that a call for data the person may not read is refused (DC-11, DC-14).

GS-24 Count three properties of a feature: it reads untrusted content (A), it can reach sensitive data (B), and it can change state or communicate outside the organisation (C). With all three it needs a person to approve every action. With two the review records the residual risk. The review procedure (A03) counts them.

Answers: LT-04 excessive agency; LT-02 indirect prompt injection; LT-01 direct prompt injection. Evidence: the rule of two result in the review; for all three, the per-action approval setting; for two, the recorded residual risk.

Human approval

GS-25 A person approves, seeing the exact action and not a summary of it, before any action that is irreversible, leaves the organisation, changes access, runs code outside a sandbox or affects a person. The agent permission checklist (A09) gives the answer for each kind of action. Spending is controlled through the cap on spend in the agent permission review (AP-13) and the hard spending cap (GS-21), and payments through the payment rule (GS-27), not through this approval. A decision about a person is made by a named person (P24 AG-06).

Answers: LT-04 excessive agency; LT-02 indirect prompt injection; LT-08 misinformation. Evidence: the list of actions with the approval each needs (A09); the approval screens showing the exact action; a sample of recorded approvals.

GS-26 A feature that can act (send, change records, run commands or spend) has a switch-off that one named person can use in one step. It stops the feature, revokes its keys and tool access, and is tested before release and after any change to the feature (NIST AI RMF MANAGE 2.4).

Answers: LT-04 excessive agency; LT-12 poisoned memory and tool descriptions; LT-07 unbounded consumption. Evidence: the switch-off procedure, the named person and the date of its last test (DC-30).

GS-27 No feature releases a payment or changes supplier bank details, by any tool or path (P24 AG-16). A feature may draft a payment request that a named person then makes through the normal approval. This requirement takes no exception (GS-30).

Answers: LT-04 excessive agency; LT-02 indirect prompt injection; LT-08 misinformation. Evidence: a test that no tool and no path releases a payment or changes bank details (A09 AP-10); results for AC-04.

Testing

GS-28 Test each feature before release against the attack classes AC-01 to AC-12 at the depth the review procedure (A03) sets. At Depth 3 someone other than the builder tests (P20 CA-10). At Depth 2 the team tests, the review states who tested, and a tester who did not build the feature is expected. At Depth 1 no separate test is required. A feature already running when this standard is adopted is reviewed within [[90]] calendar days of adoption. Tests are repeated after a change that could affect an attack class.

Answers: all twelve threats (LT-01 to LT-12). Evidence: the depth and its reasons; results for each selected attack class; who tested (at Depth 3 the independent tester's report); for an existing feature, its review date against the adoption date.

Evidence

GS-29 The owner keeps for each feature the data flow, the threat selection, the standard check, the configuration checklist, the test results, the findings and exceptions, and the approval, while the feature runs and for [[3]] years after it ends, or longer where law or a contract asks.

Answers: all twelve threats (LT-01 to LT-12). Evidence: the evidence set E-1 to E-9 that the depth needs, held by the owner.

Findings

GS-30 A finding is rated on P05's impact and likelihood scales, has an owner and a due date set by its severity, and is tracked in the register (A08). A departure from this standard is a P02 exception approved by the approver its band sets, and a Critical one goes to the board or its equivalent. A breach of P24's AG-03 or AG-05, and a feature that releases a payment (GS-27), take no exception.

Answers: all twelve threats (LT-01 to LT-12). Evidence: the register entries (A08) with rating, owner and due date; each exception with approver and expiry; none against GS-27, AG-03 or AG-05.

Review

GS-31 This standard is reviewed at least every [[12]] months (P04 Standard tier), and when a new edition of the OWASP list or the MITRE ATLAS matrix is published, when an incident shows a gap, or when the law changes.

Answers: all twelve threats (LT-01 to LT-12). Evidence: the document control table; the record of the last review and the triggers considered.

Signals to watch and evidence to keep

GS-20 asks for monitoring of twelve signals. Each is a sign that an attack may be under way or that a control has failed. When a person confirms one, the P24 incident trigger in the last column applies. P09 decides whether an event is an incident. Regulatory Notification Operating Procedure and its clocks stay with the Regulatory Incident Notification & Reporting pack, and this standard restates none of them.

Report an event at once through the incident route (P09 IM-01). Nobody is blamed for a report made in good faith. P09 decides whether it is an incident and whether anything must be reported, and P18's clocks apply. P09 IM-07 sets the order of containing and preserving. Where harm can still spread, such as an agent that can still act (AS-03, AS-07, AS-08) or data still leaving, contain first by switching the feature's access off, and capture what you can in the same step. Otherwise preserve the evidence first, then switch the feature off.

Keep the evidence as P09 IM-07 asks: preserve it before anything is changed, unless waiting would let the harm spread. If it would, contain first and capture what you can in the same step. Keep (EP-01 to EP-10): the prompts and outputs of the affected sessions, with times and the person or account; the system prompt, tool descriptions and filter settings in force at the time, with their versions; the model name and version, and the provider's request identifiers; every tool call in the sessions, with arguments, results, identity and any approval; the passages and documents retrieved, with their source and the index version; the content of the document, page, email or ticket that carried the injection, kept as received; the contents of memory before and after, and the log of memory writes; a snapshot of the configuration checklist settings as found, taken before anything is changed or, where harm is still spreading, in the same step as the switch-off; access, sign-in and key-use logs for the feature's identities and keys; the cost and usage records for the period.

Roles and responsibilities

Every feature has one AI use owner, recorded by role in the inventory. The owner answers for the feature and for what it produces. The head of Information Security owns this standard. One person may hold several roles in a small organisation, with two limits: nobody approves a feature they own, and nobody tests at Depth 3 a feature they built or own. The P24 rules on who approves a use stay as the AI Security Governance & Acceptable Use pack sets them.

The matrix sets out who is responsible (R), accountable (A), consulted (C) and informed (I) for each of 14 activities. Columns, in order: Lead for AI governance lead; Owner for AI use owner; Dev for application developer; Sec for head of Information Security; Test for independent tester; DPO for data Protection Officer; Legal for legal; Buy for procurement; IT for head of IT; Exec for executive decision-maker.

Findings and exceptions

A finding is a confirmed gap between a feature and this standard, found in a review, a configuration check, a test or an incident (GS-30). The Head of Information Security rates it on the impact and likelihood scales of the Information Security Risk Management pack, each from 1 to 4, and the band of impact times likelihood is its severity. Each finding has an owner, who agrees the fix, and a due date, and is tracked in the register (AI Security Findings & Exceptions Register). The due date runs from the day the reviewer confirms the finding.

Exceptions. A departure from this standard is requested, rated and approved under the Security Exception & Waiver Standard (P02-A02, Security Exception, Waiver & Segregation of Duties pack), using the Security Exception Request & Approval Form, before the departure begins (GS-30). The approver is the one the finding's band sets. An exception names the requirement, the feature, the reason, the compensating measures and an expiry date, and is recorded in the Security Exception Register. Agreement by email, in a meeting or by a manager is not an exception.

The renewals a band shows are the renewals its approvers may grant. A renewal beyond the band's limit goes to the next approval level up (EX-08). A renewal is a new decision.

A Critical exception goes to the board or its equivalent: the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management. The finding's owner is never among the approvers. The decision time is counted in working days from a complete request. Due dates are calendar days.

Release. A release does not go ahead while a Critical finding is open without an exception from the board or its equivalent, or while a High finding is open without an exception from the Head of Information Security and the accountable executive. The LLM Application Security Review Procedure holds the release gates.

No exception. GS-27, AG-05, AG-03 take no exception: a feature never releases a payment or changes a supplier's bank details, and the rules of the AI Security Governance & Acceptable Use pack on special category data and on the practices Article 5 of the EU AI Act prohibits stand. An exception never changes a legal duty. Personal data is protected under data protection law, and an incident is reported, exception or not.

Review and change

Changing a feature

A change of model, model version, system prompt, tool, retrieval source or filter setting is a change: it goes through the change control that applies to the system, the attack classes it could affect are tested again at the feature's review depth, and the change is recorded. A provider's change of model is a trigger for review within [[10]] working days of the notice (P24 ST-7; AG-10). A model can change under a feature without anyone in the organisation asking for it, so the contract asks for notice (GS-17) and the checklist records how the notice will arrive (DC-28).

A feature already running when this standard is adopted is reviewed within [[90]] calendar days of adoption (GS-28). The depth follows the same rules as for a new feature.

Reviewing the standard

This standard is reviewed at least every [[12]] months (Security Policy Management pack, Standard tier), and sooner when a new edition of the OWASP list or the MITRE ATLAS matrix is published, when an incident shows a gap, or when the law changes (GS-31). The Security Policy Management pack also names these triggers: a major incident, or an incident the document should have prevented; a material change to the organisation's activities, systems or suppliers; a change in law, regulation or a contract the document supports; an audit or assessment finding against the document; a significant change in the threats the document addresses. The review is recorded in the document control table.

Changing the standard. The head of Information Security proposes a change and consults the lead, the owners of live features and Legal. The approver of the standard tier approves it. A change that adds or tightens a requirement says by when features that are already live must meet it. Unless the change says otherwise, a feature already live has [[90]] calendar days from the day the change is approved.

Measures

The AI governance lead reports five measures each period. Each is a count with the gaps named. None is combined into a score or a share.

Related documents

Definitions

Document control

Approval record

Review. See Review and change. This standard is reviewed at least every 12 months (GS-31).

Worked example: the first three weeks

EXAMPLE, not part of the standard. The organisation is the one used throughout the pack: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders, an important entity under NIS2 in its Member State. Replace it with your own, or delete this section before approval.

The standard was approved on 8 Sep 2026 by the Executive Committee. The Head of Information Security owns the standard, and nobody approves a document they own or wrote (P04 PF-03), so the Executive Committee approves it. The three generative uses on the P24 inventory: AI-001, AI-003 and AI-004. AI-002 (forecasting) and AI-006 (anomaly detection) are not generative. AI-005 was stopped and AI-007 declined under P24. Features already running have until 7 Dec 2026 for their first review.

The position for the leadership team: 2 of 3 generative AI features have a completed review; 27 of 32 configuration checks on live features are verified; 0 High or Critical findings are open without an exception; 0 findings are past their date; 1 of 2 providers have returned the security questionnaire, with 7 questions still open.

Adapting this template

Small organisation

Regulated entity (NIS2, DORA, GDPR, EU AI Act)

IT and services run by suppliers

Framework references

These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: Regulation (EU) 2024/1689 (the EU AI Act) as amended by Regulation (EU) 2026/1744; Regulation (EU) 2016/679 (GDPR); OWASP Top 10 for LLM Applications, 2026 edition; MITRE ATLAS 2026.09; NIST AI 600-1; NIST AI RMF 1.0; NIST CSF 2.0; ISO/IEC 27001:2022 incl. Amd 1:2024; ISO/IEC 42001:2023 (by number and title only); as published and read on 8 October 2026.

ISO/IEC 27001 and ISO/IEC 42001 references name the clause or control this document relates to, by number and title only. ISO/IEC 42001 is a paid standard whose text was not read for this document. A reference does not say that meeting a clause or control meets any requirement of the EU AI Act or the GDPR.

This pack does not say which OWASP, MITRE ATLAS, NIST or ISO/IEC 42001 items meet a requirement of the EU AI Act or the GDPR. Each reference says what its source asks for and which CISO Times document helps with that work. Using a document does not by itself show that a requirement is met.