July 10, 2026

What NIS2 actually expects from web filtering and DNS controls

NIS2 — Directive (EU) 2022/2555 — never names web filtering or DNS by product. It requires in-scope essential and important entities to manage ICT risk, apply baseline cyber hygiene, and report significant incidents on tight deadlines. That framing hands the real question to the security engineer: which of your controls produce evidence an auditor and a national CSIRT will accept, and which are merely switched on. Treat what follows as a practical interpretation, not legal advice.

Risk-management measures, not a product checklist

Article 21 of NIS2 calls for risk-management measures that are proportionate to the risks: policies, incident handling, access control, network security, supply-chain practices, and secure configuration. In web-control terms that means a documented filtering policy mapped to actual risk — not a line in a spreadsheet that reads "DNS filtering: enabled." The measure has to be appropriate and proportionate, reviewed regularly, and supported by an audit trail. A blocklist imported silently with no provenance, no category mapping, and no change log is hard to defend as a risk-management measure when someone scrutinizes it.

Incident reporting lives or dies on evidence

Article 23 sets the deadlines everyone remembers: an early warning to the relevant CSIRT within 24 hours of detecting a significant incident, and a fuller notification within 72 hours. Meeting those windows is rarely about typing speed. It is about whether you can reconstruct what happened. If a phishing domain reached an endpoint, you need to show whether it was on a feed, whether the agent held the current bundle, and whether policy would have blocked it. Controls that log only after the fact, or only while cloud-reachable, turn that reconstruction into guesswork right when the clock is loudest.

Why DNS is a good evidence-producing control

Endpoint DNS-layer enforcement suits this well because each decision is a discrete, exportable event: the domain requested, the category it matched, the feed that supplied the indicator, and a timestamp. An audit trail with those fields answers both "was the control active?" and "what did it decide?" in the same export. It also keeps working off-network and offline, when the laptop is away from corporate infrastructure and incidents tend to surface. Offline-signed bundles mean the control and its evidence do not disappear the moment a resolver or vendor API is unreachable.

This is also why enforcement belongs at the endpoint, not only at the network edge. An incident on a roaming laptop on a hotel network never touches your on-premise resolver, so a control that lives there produces no record of it. An agent that resolves and logs on the device captures the decision wherever the device is — which is exactly the evidence the 24-hour early warning assumes you can assemble. Network-level filtering alone cannot give you that, and the gap tends to surface during the incident rather than in the design review.

What an auditor actually asks

Expect three questions. First, provenance: where do your blocklist entries come from, and can you demonstrate feed integrity end to end? Second, scope: which devices, which policy groups, and what is the real coverage gap? Third, evidence: can you export block decisions with enough context to support an incident timeline? If your current stack cannot answer all three without a spreadsheet and several days of manual work, that gap is what a NIS2 assessment will find. For the evidence side specifically, our piece on the audit trail behind every block decision walks through what that export needs to contain.

ClearScreen runs an endpoint agent on Windows and Linux (macOS on demand), applies UT1 and StevenBlack lists alongside URLhaus, OpenPhish, and PhishTank feeds, and exports block events with domain, category, feed, and timestamp. See the feature overview to map those controls onto your NIS2 risk register.