AI Security Findings & Exceptions Register
Tracks AI-specific findings and accepted deviations through remediation.
Available soon
- Format
- Excel
- Size
- 125 KB
- Length
- 11 sheets
- Version
- 1.0
- Updated
What's inside
What changed
- 1.0
Published.
Preview
The workbook's sheets as you will receive them, with its example rows and the values its formulas calculate. Highlighted [[text]] is for you to replace; rows marked EXAMPLE are for you to delete. Wide sheets scroll sideways. The cover, document control and changelog sheets are in the file.
Instructions
How to use this workbook
| Step | What to do |
|---|---|
| 1 | What this workbook is. It is the register of Generative AI Security Standard (GS-30): one row for each finding on the Findings sheet, fourteen fields (FF-01 to FF-14), and one row for each exception on the Exceptions sheet. Thirteen checks (FV-01 to FV-13) run on the rows. The LLM Application Security Review Procedure reads the open findings at its release gates (RG-3, RG-4). |
| 2 | Start on the Summary sheet. Set the as-at date, the date the register is checked at. Type it, never a formula. Then read the Bands sheet: it holds the days to fix, the approvers and the longest an exception may run for each severity. Change the yellow cells to the values in your own exception policy (P02) and deficiency policy (P20). |
| 3 | Enter one row for each finding on the Findings sheet. Yellow cells are inputs. Choose from the lists where a cell has one. Write the finding in one sentence, with how it was found. The Head of Information Security rates the finding: enter impact and likelihood from 1 to 4 on P05's scales. The severity and the due date appear by themselves, and the owner agrees the fix. |
| 4 | The day the reviewer confirms the finding is the day the clock starts (P20 CA-13). Enter it as the confirmed date. The due date is that day plus the days for the severity: 30 for Critical, then the days P20 sets for High, Medium and Low. |
| 5 | Change the status as the work goes on, using one of these: Open; Plan agreed; Fixed, awaiting retest; Closed; Deferred as an exception. A finding is Closed only after a retest. Enter the retest date and result. A model, prompt or tool change can reopen a closed finding, so test again after one (Generative AI Security Standard GS-18). |
| 6 | To defer a finding, add a row on the Exceptions sheet, give it an ID and the finding's ID, and enter the exception's ID on the finding. Enter the band, the dates, the roles that approved and the expiry. The expiry is the review date: the finding is looked at again on that day. The Bands sheet shows who must approve and the longest the exception may run. |
| 7 | Nobody approves an exception for a finding they own (P02 EX-05). Where a band's approver owns the finding, the approvers of the next band up take that approver's place, the same principle as P24 IS-4. Two kinds of finding take no exception: one that breaks P24 rule AG-03 or AG-05, and one that lets a feature release a payment (GS-27). Enter the P24 rule in the working column. The checks flag an exception on either kind. |
| 8 | Read the calculated columns at the right of each data sheet. "Result" names the checks that fail on the row. "State" says whether the finding is past due or under a live exception, and whether an exception is in date. Read the Summary sheet for the check totals, the counts and the sentences for the report. |
| 9 | Report counts with the gaps named, such as "1 High finding is open without a live exception", and no score or share. Review the register at least as often as the standard (Generative AI Security Standard GS-31) and before every release decision. |
| 10 | To clear the EXAMPLE, delete the EXAMPLE rows on the two data sheets once your own are entered. The formulas stay. |
Legend
Yellow cells are inputs. Everything else is calculated or fixed — do not overwrite formulas.
| EXAMPLE | Rows marked EXAMPLE in the first column show how a completed row looks. Delete them before approval. |
Limitations: 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.
A finding is not an incident. An event that may be an incident goes to the incident route (P09 IM-01), which decides whether it is one and whether anything must be reported. This register holds the gap the event showed.
The checks read the cells as typed. A date typed as text, a status that is not on the list or a role written differently from the Bands sheet is a finding or is ignored. Dates are entered as dates.
An exception is a decision of the people named on the Bands sheet. This workbook records and checks it. It does not make it.
EXAMPLE: the distributor, a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders, as at 30 Sep 2026. Its register holds 1 finding, AF-001, rated Medium and deferred under exception AX-001. The checks find 0 problems.
Adapting this template:
• Small organisation: keep the fourteen fields and the thirteen checks. One person may hold several roles, but nobody approves an exception for a finding they own (FV-10). If the approver of a band owns the finding, the approvers of the next band up take that approver's place (P02 EX-05; the same principle as P24 IS-4), and the register looks for those instead.
• Regulated organisation: add columns to the right of the calculated ones for what your regulator expects (for example the function a finding affects). Do not insert columns between the fields, because the checks read them by position.
• Service provider or outsourced IT: if a supplier builds or runs a feature for you, still record its findings here under your own owner. A finding the supplier reports counts from the day your reviewer confirms it. Put the supplier's own reference in the Finding column.
• Replace the [[placeholders]] and the EXAMPLE rows with your own values. Keep the formulas.
• Change the names of the approvers, the days to fix and the days an exception may run on the Bands sheet to those in your own exception policy (P02) and deficiency policy (P20). The defaults are the pack's.
• Rows are limited to the number the formulas cover. To add rows, copy a whole blank row (every column) to the bottom of the table.
This workbook is your own record. Keep a copy that can be reached when the main systems are down.
Summary
Settings, check totals and counts
Set the yellow cell, then read the check totals and the counts. Each count is a number with the others named: no score and no percentage.
Setting
| As-at date: the date the register is checked at | 30 Sep 2026 | Due dates, expiry and approval dates are tested at this date. EXAMPLE: 30 Sep 2026. Type a date, never a formula. |
Check totals FV-01 to FV-13
| Check | What it looks at | Check findings | Result | Where it reads |
|---|---|---|---|---|
| FV-01 (Findings sheet) | Every finding has an ID in the form AF-nnn, and no two findings share one. | 0 | No finding | Finding ID (FF-01). Duplicates are counted from the second finding with the same ID. |
| FV-02 (Findings sheet) | The threat is one of the pack's threats (LT) and the requirement is one of its requirements (GS). | 0 | No finding | Threat and Requirement (FF-04). Both must be on the Lists sheet. |
| FV-03 (Findings sheet) | Impact and likelihood are whole numbers from 1 to 4, so that the severity can be worked out. | 0 | No finding | Impact (FF-05) and Likelihood (FF-06). The severity (FF-07) is worked out from them by the table on the Bands sheet. |
| FV-04 (Findings sheet) | The due date is the confirmed date plus the days for the severity. It can only be wrong here when the confirmed date is missing. | 0 | No finding | Confirmed on (FF-08). Workbook note: the facts compare a typed due date. Here the due date is a formula, so the check fires only when the confirmed date is missing. |
| FV-05 (Findings sheet) | The status is one of the five statuses. | 0 | No finding | Status (FF-11), against the Lists sheet. |
| FV-06 (Findings and Exceptions sheet) | A deferred finding has an exception in the register. An exception named on a finding is in the register. An exception names a finding that is in the register. | 0 | No finding | Status (FF-11) and Exception ID (FF-12) on the Findings sheet, against Finding ID on the Exceptions sheet. An exception whose finding is not in the register is counted on the Exceptions sheet. |
| FV-07 (Findings sheet) | A finding that is not Closed and not deferred is not past its due date. | 0 | No finding | Status (FF-11) and Due (FF-09), against the as-at date. |
| FV-08 (Findings sheet) | A finding that breaks a rule that takes no exception has no exception. | 0 | No finding | Requirement (FF-04), and the P24 rule column (working column), for a finding that has an exception. |
| FV-09 (Exceptions sheet) | The exception's band is the severity of its finding. | 0 | No finding | Band on the Exceptions sheet, against the severity of the finding it names. |
| FV-10 (Exceptions sheet) | The people the band names have approved (the next band's approvers, where the band's approver owns the finding), and nobody approved who owns the finding. | 0 | No finding | Approved by, against the approvers of the band on the Bands sheet. The finding's owner (FF-10) must not be among them, and neither must the AI use owner. |
| FV-11 (Exceptions sheet) | The approval date is present, on a working day and not after the as-at date, and the decision came within the working days the band allows. | 0 | No finding | Approved on and Requested on, against the working days for the band on the Bands sheet and the as-at date. |
| FV-12 (Exceptions sheet) | The exception has an expiry date, no later than the approval date plus the longest the band allows. | 0 | No finding | Expires on, against Approved on plus the longest the band allows. |
| FV-13 (Exceptions sheet) | The exception has not expired without being closed or renewed. | 0 | No finding | Expires on, against the as-at date. |
A check counts the findings it makes, which can be more than one on a row. The Result column of each data sheet names the checks that fail on a row.
Counts for the report
| Count | Number |
|---|---|
| Findings in the register | 1 |
| Findings not Closed (open) | 1 |
| Open findings of severity Critical | 0 |
| Open findings of severity High | 0 |
| Open findings of severity Medium | 1 |
| Open findings of severity Low | 0 |
| Findings with status Open | 0 |
| Findings with status Plan agreed | 0 |
| Findings with status Fixed, awaiting retest | 0 |
| Findings with status Closed | 0 |
| Findings with status Deferred as an exception | 1 |
| Open findings past their due date, not counting deferred ones (GM-04) | 0 |
| High or Critical findings open without a live exception (GM-03) | 0 |
| Exceptions in the register | 1 |
| Exceptions in date (expiry not passed) | 1 |
| Exceptions past their expiry date | 0 |
| Rows with at least one check finding (findings and exceptions) | 0 |
| Check findings in all (FV-01 to FV-13) | 0 |
In words (for the report)
1 of 1 findings open; 0 Critical, 0 High, 1 Medium, 0 Low.
0 findings are past their due date (GM-04).
0 High or Critical findings are open without a live exception (GM-03).
1 of 1 exceptions are in date.
No register check has a finding.
GM-01, GM-02 and GM-05 come from the review records, the configuration checklist and the provider questionnaires. This register computes GM-03 and GM-04.
Findings
EXAMPLE: 1 finding as at 30 Sep 2026. One row for each finding. Yellow columns are inputs; white columns calculate.
| Example | FF-01 Finding ID | FF-02 Feature (LF-n) | FF-02 P24 use (AI-nnn) | FF-03 Finding and how it was found | FF-04 Threat | FF-04 Requirement | FF-05 Impact (1 to 4) | FF-06 Likelihood (1 to 4) | FF-07 Severity (calc) | FF-08 Confirmed on | FF-09 Due (calc) | FF-10 Owner | FF-11 Status | FF-12 Exception ID (AX-nnn) | FF-12 Exception details (calc) | FF-13 Retest on | FF-13 Retest result | FF-14 Source | P24 rule breached, if any (working column) | Row in use (calc) | Row of its exception (calc) | Live exception (calc) | FV-01 findings (calc) | FV-02 findings (calc) | FV-03 findings (calc) | FV-04 findings (calc) | FV-05 findings (calc) | FV-06 findings (calc) | FV-07 findings (calc) | FV-08 findings (calc) | Check findings on this row (calc) | Result (calc) | Open (calc) | State (calc) | Running list of findings past due (calc) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | AF-001 | LF-1 | AI-001 | A summary of a supplier's price list in PDF repeated hidden text in the file that said the supplier was approved. Found when the tester planted the line in a test copy on 18 Sep 2026. | LT-02 | GS-04 | 2 | 2 | Medium | 18 Sep 2026 | 17 Mar 2027 | Head of IT | Deferred as an exception | AX-001 | AX-001: Head of Information Security, approved 2026-09-25, expires 2027-01-29 | Test | 1 | 1 | 1 | No finding | 1 | Under a live exception |
Exceptions
EXAMPLE: 1 exception as at 30 Sep 2026. One row for each exception. The band sets who approves and the longest it may run (Bands sheet).
| Example | Exception ID (AX-nnn) | Finding ID (AF-nnn) | Band | Severity of the finding (calc) | Requested on | Approved on | Approved by (roles, separated by "and") | Approvers the band requires (calc) | Expires on (the review date) | Longest it may run, to (calc) | State (calc) | Renewals so far | Reason the requirement cannot be met yet | Compensating controls and the review | Row in use (calc) | Row of its finding (calc) | Owner of its finding (calc) | First approver of the band (calc) | Second approver of the band (calc) | First approver of the next band up (calc) | Second approver of the next band up (calc) | The owner is one of the band's approvers (calc) | Band approver kept, first (calc) | Band approver kept, second (calc) | Next band approver taken in, first (calc) | Next band approver taken in, second (calc) | First approver the band requires (calc) | Second approver the band requires (calc) | Status of its finding (calc) | Working days the band allows to decide (calc) | Working days taken to decide (calc) | Approvers as whole names (calc) | Approval date is usable (calc) | FV-06 findings (calc) | FV-09 findings (calc) | FV-10 findings (calc) | FV-11 findings (calc) | FV-12 findings (calc) | FV-13 findings (calc) | Check findings on this row (calc) | Result (calc) | In date (calc) | Past expiry (calc) | Running list of exceptions past expiry (calc) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | AX-001 | AF-001 | Medium | Medium | 21 Sep 2026 | 25 Sep 2026 | Head of Information Security | Head of Information Security | 29 Jan 2027 | 24 Mar 2027 | In date | 0 | The provider cannot yet remove hidden text before summarising and has been asked for a fix (P24 ST-7). The assistant has no tools, and a person reads every output before it is used or sent (P24 T-01 conditions). | • Staff are told that a summary of an outside document is not a substitute for opening it. • The tester repeats the planted-text test each month and when the provider changes the model. • The finding is reviewed again on 29 Jan 2027, or sooner if the provider ships a fix. | 1 | 1 | Head of IT | Head of Information Security | Head of Information Security | Accountable executive | Head of Information Security | Head of Information Security | Deferred as an exception | 10 | 4 | |Head of Information Security| | 1 | No finding | 1 |
Bands
Severity, days to fix and who approves an exception
A finding's severity is the P05 band of impact times likelihood. The band sets the days to fix, who approves an exception, the longest it may run and the working days to decide. Yellow cells hold the pack's defaults: set them to the values in your own exception policy (P02) and deficiency policy (P20).
Severity: impact times likelihood (P05 RM-03)
| Impact \ Likelihood | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| Impact 1 | Low | Low | Low | Medium |
| Impact 2 | Low | Medium | Medium | High |
| Impact 3 | Low | Medium | High | Critical |
| Impact 4 | Medium | High | Critical | Critical |
Fixed by the facts. The Findings sheet reads the lowest product of each band below, not this grid.
The four bands
| Band | Lowest product | Products | Days to fix, from confirmation | First approver of an exception | Second approver | Longest an exception may run (days) | Working days to decide | Renewals the approvers may grant | P02 approver, in full (EX-05) | Who may accept the risk it leaves (P05 RM-04, RM-08) |
|---|---|---|---|---|---|---|---|---|---|---|
| Low | 1 | 1 to 3 | 365 | Control owner | 365 | 5 | 2 | Control owner | Risk owner | |
| Medium | 4 | 4 to 6 | 180 | Head of Information Security | 180 | 10 | 2 | Head of Information Security | Risk owner and Head of Information Security | |
| High | 8 | 8 to 9 | 90 | Head of Information Security | Accountable executive | 90 | 10 | 1 | Head of Information Security and the accountable executive (risk owner) | Accountable executive and Head of Information Security |
| Critical | 12 | 12 to 16 | 30 | Board or its equivalent | 30 | 5 | 1 | 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 board or its equivalent |
The approver names must match the words used in the Approved by cell of the Exceptions sheet: FV-10 looks for each as a whole name, separated by "and" or commas. Where a band's approver is the owner of the finding, FV-10 looks for the next band's approvers instead (P02 EX-05). A Critical exception goes to the board or its equivalent (GS-30). Change the names if your roles have other names.
Products rise in steps: 1, 2, 3, 4, 6, 8, 9, 12 and 16 are the only values impact times likelihood can take, so no product falls between two bands. Each exception is the P02 exception for its band.
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.
The severity of a finding is a P05 band, and the band decides who may accept the risk it leaves (P05 RM-04, RM-08):
Low, the risk owner; Medium, the risk owner and the Head of Information Security; High, the accountable executive and the Head of Information Security; Critical, the board or its equivalent.
Where the risk is outside appetite, at least executive management also approves.
Outside tolerance the band's approvers recommend, and only the board or its equivalent may accept.
Lists
| ListState | ListSeverity | ListScale | ListSource | ListThreat | ListReq | ListNoExcGS | ListNoExcP24 | ListThreatName |
|---|---|---|---|---|---|---|---|---|
| Open | Low | 1 | Review | LT-01 | GS-01 | GS-27 | AG-05 | LT-01 Direct prompt injection |
| Plan agreed | Medium | 2 | Configuration check | LT-02 | GS-02 | AG-03 | LT-02 Indirect prompt injection | |
| Fixed, awaiting retest | High | 3 | Test | LT-03 | GS-03 | LT-03 Sensitive information disclosure | ||
| Closed | Critical | 4 | Red team | LT-04 | GS-04 | LT-04 Excessive agency | ||
| Deferred as an exception | Incident | LT-05 | GS-05 | LT-05 AI supply chain compromise | ||||
| LT-06 | GS-06 | LT-06 Data and model poisoning | ||||||
| LT-07 | GS-07 | LT-07 Unbounded consumption | ||||||
| LT-08 | GS-08 | LT-08 Misinformation | ||||||
| LT-09 | GS-09 | LT-09 Hidden context exposure (system prompt leakage) | ||||||
| LT-10 | GS-10 | LT-10 Vector and embedding weaknesses | ||||||
| LT-11 | GS-11 | LT-11 Improper output handling | ||||||
| LT-12 | GS-12 | LT-12 Poisoned memory and tool descriptions |
GS-13
GS-14
GS-15
GS-16
GS-17
GS-18
GS-19
GS-20
GS-21
GS-22
GS-23
GS-24
GS-25
GS-26
GS-27
GS-28
GS-29
GS-30
GS-31
Definitions
Definitions
| Term | Meaning in this workbook |
|---|---|
| Finding | A confirmed gap between a feature and this standard, found in a review, a configuration check, a test or an incident, rated on P05's scales. |
| Exception | A recorded, time-limited approval to depart from a requirement, made under P02 and approved by the approver the finding's band sets. |
| Feature | One LLM capability the organisation uses, builds or has switched on, for one purpose, with one owner. A feature is the technical view of a P24 use. |
| Event | A suspected security event reported through the incident route (P09 IM-01). It becomes an incident only when it is declared there. |
| Severity | The P05 band of impact times likelihood, each from 1 to 4: Low, Medium, High or Critical (FF-07). |
| Due date | The confirmed date plus the days for the severity: Low 365, Medium 180, High 90, Critical 30 calendar days (FF-09). |
| Band (of an exception) | The severity of the finding the exception defers. The band names the approvers and the longest the exception may run. |
| Live exception | An exception whose expiry date has not passed at the as-at date. |
| Open | Any finding whose status is not Closed. A deferred finding is open until it is Closed. |
| Past due | An open finding that is not deferred and whose due date has passed. A deferred finding is not counted past due. The date that matters for it is the expiry of its exception. |
| (calc) | A column or cell the workbook calculates. Do not type or paste over it. |
| FF-nn, FV-nn, GS-nn | Fields of this register, its checks and requirements of Generative AI Security Standard. The LLM Application Security Review Procedure and the LLM Application Threat Catalogue use the same IDs. |
| EXAMPLE | A worked example: the distributor as at 30 Sep 2026. Every name and value is made up. Delete before use. |
The fourteen fields and the columns that hold them
| Field | What to enter, and the column or columns |
|---|---|
| FF-01 Finding ID | AF-nnn. Column: Finding ID. |
| FF-02 Feature and P24 use | The LF reference and the AI-nnn use. Columns: Feature; P24 use. |
| FF-03 Finding | One sentence, with how it was found. Column: Finding. |
| FF-04 Threat and requirement | The LT and GS it relates to. Columns: Threat; Requirement. |
| FF-05 Impact (1 to 4) | P05's impact scale. Column: Impact. |
| FF-06 Likelihood (1 to 4) | P05's likelihood scale. Column: Likelihood. |
| FF-07 Severity | From impact times likelihood, on P05's bands. Column: Severity (calc). |
| FF-08 Confirmed on | The day the reviewer confirmed it. Column: Confirmed on. |
| FF-09 Due | The confirmed date plus the days for the severity. Column: Due (calc). |
| FF-10 Owner | A named role. Column: Owner. |
| FF-11 Status | One of: Open; Plan agreed; Fixed, awaiting retest; Closed; Deferred as an exception. Column: Status. |
| FF-12 Exception | AX-nnn, with approver, approval date and expiry. Columns: Exception ID; Exception details (calc); the full record is on the Exceptions sheet. |
| FF-13 Retest | The date and the result. Columns: Retest on; Retest result. |
| FF-14 Source | Review, configuration check, test, red team or incident. Column: Source. |
The working column
| Column | What it is for |
|---|---|
| P24 rule breached | The P24 rule the finding breaches, if any (for example AG-03 or AG-05). FV-08 reads it: a breach of a rule that takes no exception has no exception. Leave blank when no P24 rule is breached. |
| Row in use, flags and lists (calc) | Columns the workbook calculates to run the checks and to count. Do not type or paste over them. |
The Exceptions sheet
| Column | What to enter |
|---|---|
| Exception ID | AX-nnn. One exception for each finding. |
| Finding ID | The AF-nnn finding the exception defers. |
| Band | The band of the finding's severity. FV-09 flags a band that is not the severity. |
| Requested on, Approved on | Dates. The band sets the working days allowed between them. |
| Approved by | The roles that approved, written as in the Bands sheet and separated by "and" or commas. Never the finding's owner. |
| Expires on (the review date) | The day the exception ends and the finding is reviewed again. No later than the approval date plus the longest the band allows. |
| Renewals so far | How many times it has been renewed. The Bands sheet shows how many renewals the band's approvers may grant. A renewal beyond that goes to the next approval level up (P02 EX-08). |
| Reason and compensating controls | Why the requirement cannot be met yet, and what limits the risk in the meantime. |
Rules the register uses, by ID
| Rule | What it sets in this register |
|---|---|
| GS-30 | A finding is rated on P05's scales, has an owner and a due date set by its severity, and is tracked here. A departure from the standard is a P02 exception. |
| GS-27 | No feature releases a payment. A finding of this kind takes no exception (FV-08). |
| P24 AG-03, AG-05 | Rules that take no exception (FV-08). |
| P24 AG-09 | Who approves the use. The approvers of an exception are set by the band, not by the tier of the use. |
| P02 EX-05, EX-06, EX-08 | Who approves an exception in each band, the working days to decide, the longest an exception may run, and where a renewal beyond the band's limit goes. |
| P05 RM-03, RM-04, RM-08 | The 4 by 4 scale that rates a finding, the band that decides who accepts, and the rule that outside tolerance only the board or its equivalent accepts. |
| P20 CA-13 | Calendar days to fix a deficiency, from the day the reviewer confirms it: High, Medium and Low. |
| P20 CA-10 | The tester owns and performs none of the controls they test. |
| P09 IM-01 | The incident route. A finding is not an incident; an event goes to P09. |
Framework References
Framework references
These references indicate relevance only and do not reproduce the text of any standard.
| Framework | Reference | Supported by |
|---|---|---|
| ISO/IEC 27001:2022 | Annex A 8.26 — Application security requirements | Findings sheet: a gap in an application's security requirements is recorded, rated and tracked |
| ISO/IEC 27001:2022 | Annex A 5.36 — Compliance with policies, rules and standards for information security | Exceptions sheet: a departure from the standard is approved, dated and reviewed |
| ISO/IEC 42001:2023 | Clause 6.1.3 — AI risk treatment | Bands sheet: the treatment of an AI risk is decided by band and recorded |
| ISO/IEC 42001:2023 | Annex A 8.4 — Communication of incidents | Findings sheet, Source column: an incident that shows a gap becomes a finding. The communication route is P09's |
| NIST CSF 2.0 | ID.RA-07 — “Changes and exceptions are managed, assessed for risk impact, recorded, and tracked” | Exceptions sheet: exceptions are assessed for risk impact, recorded and tracked |
| EU AI Act — Regulation (EU) 2024/1689 | Article 15(1) — high-risk AI systems “shall be designed and developed in such a way that they achieve an appropriate level of accuracy, robustness, and cybersecurity, and that they perform consistently in those respects throughout their lifecycle”. The Article is a requirement on high-risk systems, which providers meet; it applies to Annex III systems from 2 December 2027 (Article 113 as amended) | Findings sheet: the Article asks that a high-risk system reach an appropriate level of cybersecurity throughout its lifecycle. A finding is how a gap in that is tracked until it is fixed and retested. The register does not say that any feature is a high-risk system |
| EU AI Act — Regulation (EU) 2024/1689 | Article 26(5) — deployers monitor the operation of the high-risk system on the basis of the instructions for use; where they have reason to consider that use may present a risk within the meaning of Article 79(1) they inform the provider or distributor and the market surveillance authority “without undue delay” and suspend use; where they identify a serious incident they “immediately inform first the provider, and then the importer or distributor and the relevant market surveillance authorities” | Findings and Exceptions sheets: a deployer of a high-risk system monitors its operation and acts on a risk it sees. A finding from monitoring is recorded here. The incident route is P09's |
| EU AI Act — Regulation (EU) 2024/1689 | Article 113, as amended — the Regulation applies from 2 August 2026, except that Chapters I and II (including Articles 4 and 5) apply from 2 February 2025, with Article 5(1) points (ba) and (bb) and Article 5(1a) and (1b) applying from 2 December 2026; Chapter III Section 4, Chapter V (general-purpose AI models), Chapter VII and Chapter XII and Article 78 apply from 2 August 2025, except Article 101; and Chapter III Sections 1, 2 and 3, except Article 6(5), apply from 2 December 2027 as regards systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 as regards those under Article 6(1) and Annex I. Article 50 is not listed in an exception and so applies from 2 August 2026 | Summary sheet: the register holds no date from the Act. The dates the Act applies from are as Article 113 stands after the amending Regulation |
| EU AI Act — Regulation (EU) 2026/1744 (Digital Omnibus on AI) | Regulation (EU) 2026/1744 of 8 July 2026 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Official Journal, 24 July 2026); in force on the third day after publication (its Article 4), 27 July 2026. Its Article 1 amends Regulation (EU) 2024/1689 | Findings sheet: the amending Regulation moved the dates for high-risk systems. The register holds none of them |
| GDPR — Regulation (EU) 2016/679 | Article 32(1) — appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the likelihood and severity of risk to people's rights and freedoms | Findings sheet: security that is appropriate to the risk, with the severity set from impact and likelihood |
| GDPR — Regulation (EU) 2016/679 | Article 24(1) — the controller implements appropriate technical and organisational measures to ensure, and to be able to demonstrate, that processing is performed in accordance with the Regulation; “Those measures shall be reviewed and updated where necessary.” | Exceptions sheet: the controller reviews and updates its measures. An exception expires and is reviewed on its date |
| GDPR — Regulation (EU) 2016/679 | Article 5(2) — “The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 (‘accountability’).” | Findings and Exceptions sheets: the controller must be able to show what it did. The dates, owners and approvers are that record |
| OWASP Top 10 for LLM Applications 2026 | OWASP GenAI Security Project, OWASP Top 10 for Large Language Model Applications, version 2026, published August 2026: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Excessive Agency, LLM04 Supply Chain, LLM05 Data and Model Poisoning, LLM06 Unbounded Consumption, LLM07 Misinformation, LLM08 Hidden Context Exposure, LLM09 Vector and Embedding Weaknesses, LLM10 Improper Output Handling. A community awareness document, weighted about three-quarters on a community vote and one-quarter on incident data, that states its own limits; it replaces the 2025 edition | Findings sheet, Threat column: the threats LT-01 to LT-12 are this pack's catalogue, which follows the OWASP list |
| NIST AI RMF 1.0 | MANAGE 4.3 — “Incidents and errors are communicated to relevant AI actors, including affected communities. Processes for tracking, responding to, and recovering from incidents and errors are followed and documented.” | Findings sheet: errors and incidents are tracked, responded to and followed to closure with a retest |
| Guidelines for secure AI system development (NCSC, CISA and partners) | Secure deployment, “Develop incident management procedures” — “The inevitability of security incidents affecting your AI systems is reflected in your incident response, escalation and remediation plans.” | Findings sheet, Source column: an event that shows a gap becomes a finding. The incident itself is P09's |
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.
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard.
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.
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.
OWASP, MITRE ATLAS, NIST AI 600-1, NIST SP 800-218A, the NCSC blog, the NCSC and CISA guidelines and the joint agency guidance on agents are voluntary guidance. They are not law, and none of them says what the AI Act or the GDPR requires. This pack cites them as their publishers state them.
The OWASP lists are community lists of the risks the project judges most important. A threat that is not on a list is not therefore safe, and a threat on a list is not therefore present in every application.