NIS2 AI Audit Evidence That Survives a 72 Hour Notification
NIS2 AI audit evidence has two customers: a competent authority testing Article 21 measures, and a CSIRT reading an incident notification written against the clocks in Article 23(4). This guide builds one evidence package that serves both, covering population definition, sample binding, integrity, retention, and the boundary where an AI gateway stops contributing.

A CSIRT asks which authenticated users reached which model endpoint during a six hour window, what the policy decided, and whether regulated data crossed the boundary. Under Article 23(4) of Directive (EU) 2022/2555, the early warning is due within 24 hours of becoming aware and the incident notification within 72 hours. NIS2 AI audit evidence either answers that question from a query, or the entity spends the first day of the clock reconstructing history from application logs.
I build these packages so the second reader, the one who arrives eleven months later for a supervisory assessment, can repeat the same query and get the same rows.
TL;DR
- Freeze a population of in-scope AI requests for a named UTC window before anyone selects a sample, including permitted, redacted, denied, and failed events.
- Bind every sample to the authenticated principal, model destination, policy version, decision, timestamp, and response disposition, joined by a stable correlation identifier.
- Build the package against both readers: Article 21 supervisory testing and the Article 23(4) clocks at 24 hours, 72 hours, and one month after the incident notification.
- Protect the records against modification by the application that produced them, and test historical retrieval rather than assuming the archive works.
Define the population before anyone samples
An evidence population starts with every in-scope HTTP AI request in a named UTC window. Successful model calls belong in it, and so do redactions, denials, policy errors, missing-identity failures, and blocked responses. A population built only from successful calls hides the events that best demonstrate whether the control operated.
Export a manifest with a stable event identifier, timestamp, originating principal, calling application, model route, policy version, action taken, and record location. Freeze it, then let the reviewer choose rows or document a repeatable selection method. Owner-picked screenshots demonstrate a product. A frozen manifest with reviewer-selected rows is evidence, and the difference shows up the moment somebody asks why the denial count is zero.
Article 32(2) lets competent authorities require targeted security audits by an independent body, with the results made available to the authority and the cost paid by the audited entity except in duly substantiated cases. The population definition is what an external auditor will attack first.
Bind the sample to the decision that was made
Each selected event needs the identity assertion and its validation result, the requested model and route, the policy rule and version that ran, the enforcement outcome, and the response disposition. Article 21(2)(i) covers access control policies, so the evidence has to show the policy operating on a specific request rather than existing in a repository. For the nine categories of digital infrastructure and digital provider entities it covers, Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 sets out the technical and methodological requirements behind those measures in its Annex.
The originating identity deserves attention. A common pattern authenticates a person in the application, then calls the provider through one shared service account, and the provider record shows the relay. Joining the upstream authentication event to the outbound request with a correlation identifier is what makes the human originator recoverable. The AI agent identity guide covers the design side of that join.
Where the design stores a fingerprint instead of prompt content, document the controlled retrieval path for the source record. A hash on its own answers integrity questions and leaves content questions open.
Protect the records from the system that wrote them
Article 21(2)(b) requires incident handling and item (e) covers security in acquisition, development and maintenance. Evidence that the calling application can silently rewrite its own decision history fails both in spirit. The package should name the record writer, the destination store, the roles with write and delete permission, and the integrity mechanism.
Run a staged tamper test on a copied event. Change one decision field, execute the documented integrity check, and record the failure output and the reviewer who ran it. Then attempt a modification as an application administrator against the protected store and record the rejection. Two short tests prove more about custody than three pages of policy text. The tamper-evident AI audit logs guide describes the write-path design those tests exercise.
Build for the Article 23 clocks, not just the assessment
Article 23(4) sets four artifacts: an early warning within 24 hours indicating whether the incident is suspected of being caused by unlawful or malicious acts or could have a cross-border impact, an incident notification within 72 hours updating that information with an initial severity and impact assessment and available indicators of compromise, an intermediate report on request, and a final report no later than one month after the notification. The final report must cover a detailed description including severity and impact, the likely threat type or root cause, applied and ongoing mitigation measures, and cross-border impact where applicable.
Each of those needs a query that runs in minutes. Write and save them in advance: all requests for a principal, all traffic to a model destination, all events under a policy version, all denials in a window, and all events carrying a regulated data classification. Then run a drill against real data and time it. The drill artifact belongs in the evidence package, because it is the only thing that proves the reporting capability existed before the incident.
Article 23(1) also notes that the mere act of notification shall not subject the notifying entity to increased liability. That sentence is worth quoting to a nervous executive at hour twenty.
Retention, retrieval, and the edges
NIS2 does not set a single retention period the way some sector rules do, so the schedule comes from national transposing law and the entity's own records policy. Whatever the number, test retrieval against the oldest available period rather than the configuration screen. Compare the returned record with its integrity value, confirm the original ordering, and record the query time and any archive restoration step. The LLM audit log retention guide covers how retention design affects whether that retrieval succeeds.
Name the exclusions in the boundary folder. Direct provider traffic that bypasses the enforcement point, local model execution, browser sessions outside the route, compromised endpoints, and opaque inference embedded in a vendor product all sit outside the evidence a routed gateway can produce. Marking those edges plainly makes the rest of the package more credible, not less.
DeepInspect
DeepInspect intercepts HTTP AI traffic between authenticated users or agents and LLM endpoints. For routed traffic it evaluates the identity and policy context the application supplies, classifies the request, applies a permit, redact or deny decision, inspects the response, and writes a signed per-decision record. Those records give a NIS2 entity a population export, reviewer-selectable samples, integrity checks, saved queries, and historical retrieval.
Upstream identity proofing, enforced routing, endpoint security, cryptography key management, human review, and the notification submission to the CSIRT or competent authority remain with their existing owners. Book a demo today.
Frequently asked questions
- What counts as a significant incident for an AI service?
Article 23(3) treats an incident as significant if it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or if it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. The entity applies that test to its own AI failure modes and records the reasoning.
- Should denied and redacted AI requests appear in the population?
They belong in it. Denials and redactions are the clearest proof that the control point generated records consistently and that policy ran. Excluding them produces an incomplete population and removes the strongest evidence of enforcement.
- Who can demand this evidence?
Competent authorities designated under the national transposing law, using the supervisory powers in Article 32 for essential entities and Article 33 for important entities. Article 32(4) includes binding instructions, orders to bring measures into compliance with Article 21, and the designation of a monitoring officer.
- Does a gateway record replace application logging?
No. The gateway record covers the request-layer decision inside the assessed route. Application behaviour, downstream data handling, business outcomes, and user session context stay with the application and its own logging. The audit-log chain of custody guide explains how the two sets are correlated.