NIS2 AI Compliance Checklist for Authenticated LLM Traffic

Article 21(2) of Directive (EU) 2022/2555 lists ten measures that essential and important entities must include, and item (i) covers "human resources security, access control policies and asset management." An LLM route inside a NIS2 entity lands on that measure, along with incident handling under (b) and security in acquisition, development and maintenance under (e). A NIS2 AI compliance checklist that stops at "we use a reputable model provider" has graded the vendor, not the entity.

Article 20 puts the approval on management bodies and says they can be held liable for infringements of Article 21. I would put that sentence at the top of the checklist, because it changes who has to read the results.

TL;DR

• Grade AI routes against the ten measures in Article 21(2), starting with access control, incident handling, and supply chain security. Each check needs an owner, a pass condition, and an evidence reference.
• Article 20 makes management bodies approve the risk-management measures, oversee implementation, and carry liability. Record the approval date and the version approved.
• Article 23(4) sets an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month of the notification. Test whether AI request records can support all three.
• Fines under Article 34 reach at least EUR 10 000 000 or 2 percent of worldwide annual turnover for essential entities, and EUR 7 000 000 or 1.4 percent for important entities.

Check 1: fix scope and the management approval record

Owner: Legal and the accountable member of the management body.

Pass condition: The workpaper names the entity, its sector annex, its classification as essential or important, and the transposing national law. Article 41 required Member States to adopt and publish transposing measures by 17 October 2024 and to apply them from 18 October 2024, so the operative text is national, not the directive itself. The European Commission's NIS2 page tracks the transposition status per Member State.

Evidence: entity classification memo, national implementing act reference, management body approval minute, approved policy version, training record under Article 20(2). A checklist that cites only the directive skips the layer that regulators enforce.

Check 2: inventory every AI route as an asset

Owner: Security architecture with the AI platform owner.

Pass condition: The asset inventory names each authenticated path from a user or agent to an LLM endpoint, including the calling application, the model destination, the data classes involved, the business owner, and whether the call is visible to an inspection point. Article 21(2)(i) covers asset management, and an undocumented model route is an undocumented asset.

Evidence: service catalogue entries, network diagram, route samples, provider account list, exception register. Mark vendor-embedded inference that you cannot observe as opaque rather than assuming coverage. The row that usually stalls a review is the internal tool somebody wired to a personal API key eighteen months ago.

Check 3: test access control on the request itself

Owner: IAM lead with AI platform engineering.

Pass condition: Article 21(2)(i) requires access control policies, and item (j) covers multi-factor or continuous authentication where appropriate. The test sends an authorized role, an unauthorized role, and a request with missing identity context to the same route, then confirms the outcome before the request reaches the model.

Evidence: versioned policy, identity assertion schema, decision events for permit and deny, correlation identifier joining authentication to the model call. Many applications authenticate a person and then call the provider through one shared service account, which erases the originator from the provider's record. The AI agent identity guide covers that failure in more detail.

Check 4: bring AI events into incident handling

Owner: The CSIRT liaison with the security operations lead.

Pass condition: Article 21(2)(b) requires incident handling, and Article 23(3) defines a significant incident as one that has caused or is capable of causing severe operational disruption or financial loss, or that has affected other natural or legal persons through considerable material or non-material damage. Playbooks name the AI failure modes that qualify and the person who makes the significance call.

Evidence: playbook version, triage criteria, tabletop record, escalation log, a closed case referencing AI request records. Run the exercise with a real export rather than a slide.

Check 5: prove the three reporting clocks can be met

Owner: Regulatory reporting with security operations.

Pass condition: Article 23(4) requires an early warning within 24 hours of becoming aware, an incident notification within 72 hours 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 incident notification. The final report must describe the incident and its severity and impact, the likely root cause or threat type, applied and ongoing mitigations, and cross-border impact where applicable.

Evidence: timestamped drill artifacts for each deadline, query used to assemble the population, named approver, submission confirmation. My opinion is simple: an entity that has never produced a 24 hour AI early warning under drill conditions does not know whether it can.

Check 6: grade supply chain security for model providers

Owner: Procurement with the security third-party risk owner.

Pass condition: Article 21(2)(d) covers relationships with direct suppliers and service providers, and Article 21(3) requires entities to consider vulnerabilities specific to each supplier, the overall quality of their products and cybersecurity practices, and their secure development procedures. The file records those findings for every model provider and AI middleware vendor in the inventory.

Evidence: supplier assessment, contract clauses on notification and evidence access, subprocessor list, review date, residual risk decision. The AI audit trail requirements guide shows what evidence access to ask for before signature.

Check 7: close gaps with named corrective measures

Owner: The named control owner, with the management body receiving the summary.

Pass condition: Article 21(4) requires an entity that finds non-compliance with the paragraph 2 measures to take all necessary, appropriate and proportionate corrective measures without undue delay. Every failed check therefore produces a dated corrective action, not a note.

Evidence: gap register with severity, owner and target date, interim measure, retest result, closure approval. Article 32(4) gives competent authorities powers including binding instructions, orders to comply with Article 21, monitoring officers, and orders to make infringements public, so an open gap has an enforcement path attached to it.

DeepInspect

DeepInspect sits between authenticated users or agents and HTTP-based LLM endpoints. On traffic the application routes through it, DeepInspect evaluates the supplied identity and policy context, permits, redacts or denies the request, inspects the response, and writes a per-decision record. Those records support the access control checks under Article 21(2)(i), the asset visibility work behind item (i), and the population an entity needs when the 24 hour and 72 hour clocks in Article 23(4) start running.

Personnel security, physical controls, cryptography key management, business continuity, and the notification submission itself stay with their existing owners. Direct provider traffic that bypasses the route, local execution, and opaque vendor inference need separate controls, and a NIS2 file is stronger when it marks those edges instead of hiding them. The NIS2 AI logging requirements article goes deeper on the record design. Book a demo today.