LLM Application Security Review Procedure

Purpose

This procedure sets out how [[Organisation Name]] reviews a generative AI feature before it goes live, and again while it runs. It answers one question for the people who build, configure and approve the feature: can it go live? The answer is Release, Release with conditions or Hold, and the evidence is on file.

It applies the Generative AI Security Standard. It sets how much review a feature needs, who does each part, what evidence the review holds, which gates the release must pass, who signs, and how findings and exceptions are handled.

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.

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.

This procedure does not decide whether a system is prohibited, high-risk or subject to a transparency duty, and it does not decide which role the organisation holds under the EU AI Act. A review that finds a feature might touch those questions sends it to Legal.

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.

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.

Scope

This procedure applies to every LLM feature the organisation builds, configures or switches on. That includes a feature a supplier adds to software already in use. A feature is 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.

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. Intake, the tiers and the inventory are in the AI Security Governance & Acceptable Use pack (P24): this procedure cites them by ID and does not repeat them.

Nor does it decide whether an event is a security incident. That is the incident response pack (P09). The reporting duties and their clocks are in Regulatory Incident Notification & Reporting pack (P18).

A feature that is already running when the Generative AI Security Standard is adopted is reviewed within [[90]] calendar days of adoption, at the depth this procedure sets.

Roles

Three rules about people apply throughout. The owner of a feature never approves it. The builder of a feature never tests it at Depth 3, and at Depth 2 a tester who did not build it is expected and the review states who tested. Nobody tests a control they own or perform (P20 CA-10). 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.

The seven stages

Every feature goes through the same seven stages. A simple feature passes through them in a few days. A feature that acts for customers takes longer and has more people in it.

Review depth

Review depth says how much review a feature gets. It is set at Stage 2 and does not depend on how confident the team feels. The depth is the highest any trigger gives, and the review records every trigger that applied.

Decision time, approvers and review interval follow the higher of the P24 tier and the review depth. A feature can sit at a higher depth than its P24 tier. A Tier 2 use reviewed at Depth 3 takes Tier 3's approvers, decision time and review interval: it is signed as Tier 3.

A feature has two review dates: the one this review sets from its depth, and the one in its P24 inventory entry. The earlier of the two applies. The review date is the day set from the decision and the depth's review interval, or the review date in the P24 entry if that is sooner.

What sets the depth

The first row is P24's. A use that P24 has stopped is not reviewed. The other rows come from this procedure. If a feature meets more than one, the highest depth applies.

The rule of two

The rule of two counts three properties of a feature. The count raises the depth and says what the review must record.

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.

Stage 1 (RP-1): Describe

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.

In practice. Open the feature's entry in the P24 inventory and copy its use ID, tier and data level. Draw the data flow on one page: every source the model reads, every place its output goes, every tool, every store and the provider. Mark each source trusted or untrusted. Write down the model name and version, the system prompt version and the tools. Then answer five questions for the depth: does it retrieve company content, what level of tools does it have (none, read or write), does it read untrusted content, does it keep memory, and does it send anything outside. Say whether the organisation built the feature (building on a supplier's model API counts, for staff or for customers), put its own name on it or changed what it is meant for, and tell Legal if so. P24 holds such a feature at Tier 3 until Legal records the role, and Legal decides what that means under the Act. A supplier's finished product used as supplied is not building. When the record is made, ask for the depth to be worked out again. Record: The data flow (E-1) and the five answers.

Stage 2 (RP-2): Select threats

In practice. Run the depth rules with the P24 answers and the five feature answers, and keep the reasons it prints. Then go through the threat catalogue and mark each threat selected or left out. Write one line for each threat left out. Record the rule of two result. Tell the owner the depth, the evidence the depth needs, the approvers and the date the decision is due. Record: The threat selection (E-2) and the depth with its reasons.

The LLM Application Threat Catalogue holds twelve threats. Each has an attack class in the AI Red Team Test Plan Template, which is how it is tested. A class is tried when its threat is selected and the feature has the property in the last column.

A threat is left out only with a reason in writing, such as no retrieval source or no memory. 'Low risk' is not a reason. The Head of Information Security reads the reasons.

Stage 3 (RP-3): Check the standard

In practice. The developer marks each of the thirty-one requirements as met, not met or not applicable. A met requirement has evidence: a setting export, a screenshot, a test result or a document. A not applicable one has a reason. The Head of IT and the developer then go through the configuration checklist together and mark each applicable check Verified, Failed or Not verified. A Verified check has evidence and a date. Note which of the checks hold the release. Record: The standard check (E-3) and the configuration checklist result (E-4), each as a count.

The configuration checklist has 30 checks. 14 of them hold the release if they fail or are not verified. Which checks apply depends on the feature: all features, features with retrieval, features with tools, and features the organisation hosts or builds itself. A check that does not apply is shown as not applicable without being entered.

Report both as counts: for example, 14 of 17 applicable checks verified, with the three that are not verified listed. Never report them as a share.

Stage 4 (RP-4): Assess the provider

In practice. Required from Depth 2 when a provider outside the organisation supplies the model or the service. Procurement sends the questionnaire and asks for evidence with every answer. At Depth 1 no questionnaire is required: the Head of Information Security reads the provider's published security statement and records the date it was read. The Head of Information Security reads the answers and counts them: answered with evidence, answered without evidence, not answered. Open questions get a date agreed with the provider. The questionnaire informs the supplier decision. The decision, and the contract terms, are not made here. Record: The returned questionnaire with the Head of Information Security's reading (E-8); at Depth 1, the date the published statement was read.

The contract terms for an AI supplier (ST-1 to ST-8) and the supplier decision are in the AI Security Governance & Acceptable Use pack and the Third-Party Security Risk Management pack (P06). The questionnaire's answers are evidence for that decision. They do not replace it.

Stage 5 (RP-5): Test

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.

In practice. At Depth 1 the configuration checks are the test. At Depth 2 the team runs the tests for each selected attack class, with the safety rules in the red team plan template, and writes down what it tried, what happened and who tested. A tester who did not build the feature is expected at Depth 2. At Depth 3 an independent tester, who did not build or own the feature, runs them under a written plan approved before anything is sent, and writes the report. No tester is required at Depth 1. A feature with tools also gets the agent permission review. Every confirmed problem becomes a finding. Record: The test results (E-5), the independent report at Depth 3 (E-6) and the agent permission review for a feature with tools (E-7).

The test plan template (AI Red Team Test Plan Template) holds the safety rules SR-1 to SR-9 and the report parts. Three matter most when you plan. The plan is approved in writing before anything is sent (SR-1). Where a provider owns the model or the service, its terms permit the test or it has agreed in writing (SR-2). A test never releases a payment or changes supplier bank details (SR-5). If a test exposes real sensitive data or has a real effect, stop, keep the evidence and report it through the incident route (SR-8).

Test the content the feature reads, as well as what users type. Most serious cases arrive in a document, an email, a web page or a tool result.

A test that finds no problem does not show that the feature is secure. It shows what the testers tried. The report says what was not tried.

Evidence the review holds

Nine pieces of evidence make up a review. Which are required depends on the depth, on whether an outside provider supplies the model or service, and on whether the feature has tools.

What each depth needs. Each row is the list the review must hold before the release gates are run:

Stage 6 (RP-6): Decide

In practice. The AI governance lead convenes the decision, collects the file and runs the release gates. The approvers named under RG-6 read the gate result and decide. Any approver may hold. Each approver signs the decision record with name, role and date. A condition has an owner and a date. Record: The decision record (E-9), kept in the P24 inventory.

The release gates

A gate is a statement that must be true before a feature is released. The AI governance lead runs the gates in order and writes down each one that fails.

A gate that fails holds the release. Something that is open and does not fail a gate does not hold the release, and becomes a condition.

The three outcomes

Who signs

The AI governance lead convenes the decision and collects the signatures. The approvers of the higher of the use's P24 tier and the review depth sign (RG-6), and from Depth 2 the Head of Information Security signs as well. A Tier 2 use reviewed at Depth 3 is signed as Tier 3: the executive decision-maker signs. Where an approver owns the feature, P24 names who takes that approver's place (P24 AG-09, IS-4): the executive decision-maker, or the board or its equivalent where the executive decision-maker owns a Tier 3 use.

The use owner is consulted and signs the conditions it accepts. The developer and the independent tester advise and sign nothing. The P24 responsibility matrix (RS-05 to RS-07 and RS-16) holds the rest.

Any approver may hold a release. Only the approvers named above may approve it.

Stage 7 (RP-7): Release and watch

In practice. The Head of IT switches the feature on, or leaves it on, with the settings the review verified. Keep a copy of the settings as they stand on the day. Check that the alerts go to a named person, that the switch-off works where the feature acts, and that the findings and exceptions are in the register. Put the next review date in the owner's calendar: the earlier of the date the depth sets and the review date in the P24 entry. Record: The settings copy, the alert owner, the next review date and the register entries.

Alerts are looked at within [[2]] working days by a named person. The review repeats at the depth's interval, and at once when something changes.

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).

What forces a new review

A change in this list forces a review of the feature within [[10]] working days of the change or of the provider's notice. The owner tells the AI governance lead as soon as they know. The review repeats the stages the change touches, and repeats the tests for the attack classes it could affect.

• A new model, or a new version of the model, including a change the provider makes.
• A change to the system prompt or to a tool description.
• A new tool or connector, or a change in what a tool is allowed to do.
• A new retrieval source, or a change in who can add to one.
• A change to a filter setting or to a safety setting.
• A finding from an event, a test or a report that shows a gap in the review.

GS-18 names these threats as the ones a change touches: LT-01, LT-02, LT-05, LT-08 and LT-09. Their attack classes are AC-01, AC-02, AC-05, AC-08 and AC-09. Test at least those, and any other class the change could affect.

What is a new use, not a change

Some changes make a new use. It goes back to the intake in the AI Security Governance & Acceptable Use pack (P24), and this review follows its decision.

• A new purpose for the feature.
• A higher data level, or personal data where there was none.
• A new audience, such as customers or the public where there were only staff.
• More freedom to act without a person reading the output.

Signals and events

The monitoring signals AS-01 to AS-12 are in the Generative AI Security Standard. When one is confirmed, the response is not part of this review. 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 what P09 will need (EP-01 to EP-10 in the Generative AI Security Standard). 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.

Findings and exceptions

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.

Rating a finding

A finding is rated from its impact and its likelihood, each from 1 to 4 on the risk management scales (P05). The severity is the band of the two multiplied together.

What each severity needs

The fix days for High, Medium and Low are those of the control assurance pack (P20 CA-13). A Critical finding is due in the longest time the exception pack (P02 EX-05) allows a Critical exception to run. Days are calendar days from the day the reviewer confirms the finding. The approvers and the lengths are from the exception pack (P02 EX-05, EX-06).

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.

What happens to a finding

A finding is always in one of these states: Open; Plan agreed; Fixed, awaiting retest; Closed; Deferred as an exception.

Exceptions

• The request names the finding, the severity, the reason the fix is not possible by the due date, and the date by which it will be.
• The request lists the compensating actions that lower the risk meanwhile, each with an owner.
• The approvers for the severity decide, within the working days the band allows. The owner of the finding is never among them.
• The exception has an expiry no later than the days the band allows. A renewal is a new decision by the same approvers. The band sets how many renewals they may grant, and a renewal beyond that goes to the next approval level up (P02 EX-08).
• A High finding reaches the gate only with an exception approved by both approvers. A Critical finding reaches it only with one approved by the board or its equivalent.
• On the expiry date the finding is fixed and retested, or the exception is renewed, or the feature is held.

RG-3 and RG-4 apply the exception rules at the release gate. An open Medium or Low finding does not hold a release. It becomes a condition with an owner and a date.

What takes no exception

A breach of P24 AG-03 or AG-05 takes no exception. Nor does a feature that releases a payment or changes supplier bank details (GS-27).

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).

Records

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.

The review file holds E-1 to E-9 as the depth requires, the gate result, the findings and exceptions, and the decision record. A held or stopped review is kept as well: it shows what was asked and why the answer was no. The decision record is also recorded in the P24 inventory (AI System & Use Case Inventory).

Worked review cases

EXAMPLE, not part of the procedure. 13 features, each run through the depth rules. Every feature starts from the same plain case: Internal information, no personal data, staff only, a person reads every output, no effect on a person, a low operational effect, an approved supplier, a bar on training on the organisation's data and processor terms in place. Each row changes only what the case says. The depth is what the rules give.

Of the 13, 1 is Depth 1, 7 are Depth 2, 4 are Depth 3 and 1 is stopped by P24.

Three cases read closely

RD-A: The supplier's office-suite assistant, used as supplied, drafts and summarises internal text, and reads documents that come from suppliers

• P24 tier 1 sets Depth 1. (GS-28)
• The feature retrieves company content above Public, so access control at the index needs a test. (GS-09)
• Two of the three properties of the rule of two hold (untrusted content and sensitive data). The review records the residual risk. (GS-24)

The P24 tier is 1, so the use is easy to approve. The review is Depth 2 because the feature reads documents from suppliers and handles Internal data: two properties of the rule of two. The decision takes up to [[15]] working days, not [[5]], and the Head of Information Security signs as well. The review records what remains: a hidden instruction in a supplier's file could change a summary, so a person reads every output.

RD-F: A supplier's coding assistant, used as supplied, that runs commands, reads public repositories and has access to source code

• P24 tier 2 sets Depth 2. (GS-28)
• The feature has tools. (GS-22)
• The feature reads untrusted content, reaches sensitive data and can change state or communicate outside: all three of the rule of two. (GS-24)

All three properties hold, so a person approves every action and the test is independent, whatever the P24 tier. Here the P24 tier is 2 and the depth is 3, so the use is signed as Tier 3: executive decision-maker and head of information security sign, and the decision takes up to [[30]] working days. Compare RD-C, where P24 gives Tier 3 and the executive decision-maker signs.

RD-J to RD-M: a feature built on a model API

• P24 tier 3 sets Depth 3. (GS-28)
• The feature retrieves company content above Public, so access control at the index needs a test. (GS-09)

The team builds the assistant on a supplier's model API, so P24 counts it as building even though only staff use it. It is Tier 3 and held until Legal records which role the organisation holds, so the review runs at Depth 3. When Legal records the deployer role (RD-K), P24 sets the tier again from the answers. Here the tier falls to 1, and the retrieval of company content puts the review at Depth 2. The review is worked out again at that point; it does not stay at Depth 3 because the question was once answered Yes. If Legal records the provider role or another role instead (RD-L), P24 clears the hold but keeps the feature at Tier 3, so the review stays at Depth 3: the organisation is outside P24's deployer governance, and the executive decision-maker decides. This applies to a new feature. A feature already running when the standard starts (RD-M) is not raised to Tier 3 by the signal; P24 carries the hold as a condition with a date, and the review depth follows the feature's tier and properties (Depth 2 here).

Worked example: the distributor's September 2026 reviews

EXAMPLE, not part of the procedure. The organisation used throughout the packs is a wholesale distributor with about 900 staff and three warehouses, an important entity under NIS2 in its Member State, and not a financial entity, so DORA's reporting duties do not apply. The Executive Committee approved the standard on 8 Sep 2026. 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. In scope: 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. Existing features are due for review by 7 Dec 2026. Values are as at 30 Sep 2026.

Three features through the procedure

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.

LF-1: the office-suite assistant (Depth 2)

Reads documents that suppliers send, so the review treats that content as untrusted. No tools. A person reads every output (P24 T-01 conditions). The rule of two gives 2 of 3 properties, so the review records the residual risk. The decision falls inside the [[15]] working days of Depth 2. The evidence on file is E-1, E-2, E-3, E-4, E-5, E-8, E-9. The team tested on 17 Sep 2026 and 18 Sep 2026; the review names who tested ([[name of the tester, who did not build the feature]]). The next review is due by 25 Mar 2027: the depth sets 25 Mar 2027 and the P24 entry sets 2 Sep 2027, and the earlier applies.

The configuration checklist stands at 14 of 17 applicable checks verified; 0 failed, 3 not verified. Three checks are not verified, and none of them holds the release:

• DC-06. The provider's page names a region; the contract schedule is awaited.
• DC-09. The time to remove a deleted document from the index is not stated by the provider.
• DC-18. Alert rules for AS-01 to AS-12 are being written.

The provider returned the questionnaire on 25 Sep 2026. The count is 24 of 31 applicable questions answered with evidence; 5 answered without evidence, 2 not answered. The open questions are VQ-03, VQ-10, VQ-14, VQ-15, VQ-16, VQ-20 and VQ-26, to be answered by [[date agreed with the provider for the open items]].

The gate result is Release with conditions. The conditions are: checks not yet verified: DC-06, DC-09, DC-18; AF-001 (Medium) is open under an approved exception.

AF-001: the one finding, and its exception

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. The reviewer rated impact 2 and likelihood 2, which is Medium. It was confirmed on 18 Sep 2026, so the fix is due on 17 Mar 2027. The Head of Information Security approved exception AX-001 on 25 Sep 2026, 4 working days after the request and inside the 10 working days the band allows. It ends on 29 Jan 2027, before the fix is due.

Why. 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).

Compensating actions.

• 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.

LF-2: the image generator (Depth 1)

Public information only, and every published image is signed off by the marketing lead (P24 T-03). Two settings cannot be seen from the tenant and wait for the provider. The next review is due by 23 Sep 2027: the depth sets 28 Sep 2027 and the P24 entry sets 23 Sep 2027, and the earlier applies. The feature has no tools and does not read untrusted content, so the evidence is E-1, E-3, E-4, E-9 and the review needs no separate test and no tester. The provider's published security statement is read instead of the questionnaire. The checklist stands at 13 of 15 applicable checks verified; 0 failed, 2 not verified. The two checks that are not verified wait for the provider:

• DC-05. The tenant administrator cannot see the retention period; asked of the provider.
• DC-06. The data location is not stated on the provider's page.

The gate result is Release with conditions, decided on 28 Sep 2026. Depth 1 does not require the questionnaire, so it has not been sent. [[P06 reference of the design tool supplier]] is the reference to enter if the next supplier review sends it.

LF-3: the customer-service chatbot (Depth 3), held

Held under P24 until the contact centre's P06 assessment (planned 1 Dec 2026), a bar on training on our data and processor terms are in place. The review waits for the questionnaire and the red team test. All three properties of the rule of two hold: it reads customers' words, it reaches data above Public and it sends output outside. The review is Depth 3 and the approvers are the executive decision-maker and the Head of Information Security. The threats were selected on 23 Sep 2026.

The gate result is Hold. Four gates fail:

• RG-1. Evidence missing: E-3, E-4, E-5, E-6, E-7, E-8, E-9.
• RG-2. Checks that hold the release: DC-01, DC-02, DC-04, DC-07, DC-10, DC-11, DC-14, DC-15, DC-16, DC-30.
• RG-5. The independent red team report has not been received.
• RG-6. The approval record (E-9) is not on file, so the approvers have not signed.

Only E-1 and E-2 are on file. The checklist has not been run, the provider has not received the questionnaire and no test has taken place. A Hold is not a finding. It says the file is not ready.

The red team plan for LF-3

The one classes left out each have a reason:

• AC-10. The chatbot has no vector store.

The test is planned for 9 Nov 2026 to 20 Nov 2026, and the provider's permission must arrive before it starts. The release gate stays on Hold until the report (E-6) is on file and its findings are in the register.

Related documents

Adapting this template

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.

Definitions