NIS2 AI Controls Mapping for the Authenticated LLM Request Path

An authenticated application inside a NIS2 entity opens an HTTPS connection to a model endpoint. A useful NIS2 AI controls mapping answers five things about that transaction: which measure in Article 21(2) applies, which component enforces it, who owns that component, how the enforcement is tested, and which adjacent path the mapping does not cover. Assigning a whole measure to a single proxy weakens the map.

Maps with visible gaps are better than clean ones, because the gaps attract the right technical argument before an assessor arrives.

TL;DR

• Give each Article 21(2) measure one control point, one accountable owner, one repeatable test, one retained artifact, and one stated boundary.
• Access control under (i) and authentication under (j) apply at the routed request, where caller identity, model destination and data context are all available at once.
• Incident handling under (b) connects the request record to the Article 23(4) clocks at 24 hours, 72 hours, and one month after the incident notification.
• A gateway covers authenticated HTTP requests routed through it. Direct provider traffic, local execution, endpoints, and opaque vendor inference need separate controls and separate evidence.

Use six fields for every entry

Directive (EU) 2022/2555 states in Article 21(2) that the measures shall be based on an all-hazards approach and shall include at least ten items. Each mapping entry should carry:

• Measure: the Article 21(2) item and the national transposing provision that enacts it.
• Control point: the component where the mechanism actually operates.
• Owner: the role accountable for configuration and operation.
• Test: a repeatable action with an expected result.
• Evidence: the retained configuration and events, plus the report or sign-off.
• Boundary: the traffic covered, and the adjacent paths needing another control.

Article 21(1) requires the measures to be appropriate and proportionate, taking account of the state of play, relevant European and international standards, cost of implementation, the entity's exposure, its size, and the likelihood and severity of incidents. The proportionality argument belongs in the map, not in a separate memo. The zero trust for AI guide sets out the same reasoning from the architecture side.

Access control policies and asset management, item (i)

Requirement: human resources security, access control policies and asset management.

Control point: the inline HTTP decision point in front of the LLM endpoint, plus the asset inventory that lists every model route.

Owner: the AI platform owner with the IAM lead.

Test: send an authorized role, an unauthorized role, and a request with no identity context to the same route. Confirm each outcome before the request leaves the perimeter, then confirm the route appears in the inventory with an owner and a data classification.

Evidence: versioned policy, identity and role on each event, model destination, decision, UTC timestamp, inventory record.

Boundary: coverage is direct for calls that traverse the control point. Network and application owners have to prove routing and bypass prevention separately. Personnel screening and joiner-mover-leaver processes sit with HR and IAM.

Authentication, item (j)

Requirement: the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications, and secured emergency communication systems within the entity, where appropriate.

Control point: the identity provider and the calling application, upstream of the model request.

Owner: the IAM lead, working with the application owner.

Test: authenticate a staged user, validate the assertion at the request point, join that event to the AI decision by correlation identifier, then repeat with an expired assertion and confirm the denial.

Evidence: authentication record, assertion schema, validation result, correlation identifier, denial event.

Boundary: an enforcement point can validate the identity context an application supplies. Identity proofing, authenticator management, account lifecycle, and compromised-session investigation stay upstream. Identity discarded before the outbound call cannot be recovered at the model boundary, which is the single most common defect in these maps.

Incident handling, item (b)

Requirement: incident handling across the entity.

Control point: the record writer at the request boundary, feeding the security operations pipeline.

Owner: the security operations lead with the CSIRT liaison.

Test: run a tabletop against a real export. Produce the population for a six hour window, identify candidate events, and time the assembly of an Article 23(4) early warning.

Evidence: per-decision records, saved queries, drill artifacts with timestamps, escalation log, closed case reference.

Boundary: Article 23(3) significance assessment, cross-border impact analysis, root cause determination, and the submission itself involve people and systems well beyond the request path. The AI audit trail requirements guide covers what the record has to contain to be usable under time pressure.

Supply chain security, item (d)

Requirement: supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.

Control point: procurement controls, contract terms, and the route allowlist that decides which provider endpoints are reachable.

Owner: third-party risk with procurement.

Test: attempt a call to a model endpoint that is not on the approved list and confirm the denial. Then confirm the supplier file records what Article 21(3) requires the entity to consider, including vulnerabilities specific to each direct supplier and their secure development procedures.

Evidence: allowlist configuration, denial event, supplier assessment, contract clauses on notification and evidence access, subprocessor list, review date.

Boundary: the provider's internal security posture is evidenced by its own assurance reports, not by traffic records.

Cryptography and vulnerability handling, items (h) and (e)

Requirement: policies and procedures regarding the use of cryptography and, where appropriate, encryption, and security in network and information systems acquisition, development and maintenance including vulnerability handling and disclosure.

Control point: transport configuration on the outbound leg, secrets storage for provider credentials, and the change process for the enforcement component itself.

Owner: platform engineering with the cryptography owner.

Test: verify the negotiated cipher suite and certificate validation on the outbound connection, confirm provider keys are not readable by the calling application, and trace one change to the policy set through review and approval.

Evidence: TLS configuration, key custody record, change ticket, approval, deployment timestamp, rollback plan.

Boundary: key management, certificate lifecycle, and the vulnerability disclosure programme are separate functions. For the nine categories it covers, Commission Implementing Regulation (EU) 2024/2690 sets more detailed technical requirements in its Annex, and entities in those categories should map against that text rather than the directive alone.

What the map deliberately leaves out

Three measures run at programme level and belong to their existing owners: business continuity under (c), basic cyber hygiene and training under (g), and the effectiveness assessment under (f). Approval of the whole set sits with the management body under Article 20(1), which also makes that body liable for infringements of Article 21, while Article 20(2) requires its members to follow training. Neither duty is a technical control, and a map that quietly claims them loses credibility.

Four paths carry no gateway coverage at all: direct provider traffic from an unmanaged device, local model execution, browser sessions outside the enforced route, and inference embedded inside a vendor product where the call is invisible. List them by name with the compensating control assigned to each. My preference is to put that list on the first page rather than the last, because it is the part an assessor will find anyway. The audit-log chain of custody guide covers how the covered and uncovered records get correlated during an investigation.

DeepInspect

DeepInspect operates at the routed HTTP boundary between authenticated users or agents and LLM endpoints. It evaluates the identity and policy context an application supplies, permits, redacts or denies the request, inspects the response, and writes a per-decision record. In this mapping it is the control point for access control under item (i), the validation point for supplied identity context under item (j), the record source for incident handling under item (b), and the enforcement surface for the provider allowlist under item (d).

Identity proofing, endpoint security, cryptographic key management, business continuity, training, and the reporting submission stay with the teams that already own them. Book a demo today.