By Yair Knijn · February 13, 2026

The CISO facing a 24-hour NIS2 reporting clock with no way to reconstruct what the endpoint talked to

The CISO had EDR, a SIEM, and a tabletop from last quarter that everyone passed. When a finance laptop started beaconing, the analysts isolated it in twenty minutes. Then someone asked the question that mattered to the regulator: in the ninety minutes before isolation, what did this machine talk to? Nobody could answer cleanly, because endpoint DNS was never retained anywhere you could search.

The bad assumption underneath it was that scope is a forensics problem you solve once the fire is out. Under NIS2 it is a reporting deadline, and the clock does not wait for an imaging job to finish.

The NIS2 notification timeline, stage by stage

NIS2 Article 23 runs three stages for a significant incident: a 24-hour early warning, a 72-hour notification, and a final report within one month. The 72-hour notification is where it bites, because it wants an assessment of severity and impact plus indicators of compromise where available. That qualifier is not a get-out-of-jail card. If your egress IoCs exist but you cannot pull them in time, "where available" reads as a gap you built yourself.

The detail people miss is when the clock starts: when you become aware of the incident, not when your investigation wraps. You write that scope statement on partial information by design, and DNS is the cheapest way to make it hold up.

Why DNS history is your fastest scoping signal

Almost every meaningful move a compromised endpoint makes opens with a name lookup. C2 check-ins, data staged to a cloud bucket, a second-stage payload, lateral movement, exfil to a throwaway TLD, all of it starts with a query. A timestamped list of resolved names per device, joined against a threat feed, tells you what it contacted in minutes. Full packet capture would tell you more, but you do not have PCAP on a roaming finance laptop, and you never will. DNS already sits on the wire and costs almost nothing to keep, but nslookup-level visibility vanishes the instant the query is answered, unless something logged it with the client identity attached.

Retention decisions you make before an incident, not during one

You cannot retroactively log a lookup that happened last Tuesday. The posture that survives an Article 23 timeline gets decided in advance:

• Resolve and log at the endpoint or a per-tenant resolver, so every query carries device identity, not a NAT'd office IP shared by hundreds of people.
• Keep at least 30 to 90 days of history. Dwell time runs longer than your gut estimate, and the final report lands a month out.
• Store it queryable. A cold archive you have to thaw and parse is dead weight against a 72-hour window.
• Capture the full QNAME, timestamp, client, and verdict, so you can show what was reached versus what was stopped.

From a domain list to a defensible scope statement

A regulator-grade notification is not a domain dump. It is a bounded claim: this device hit these known-bad names at these times, those other devices did not, and here is the log behind both halves. The "did not" matters as much as the "did", because clean containment keeps a single-laptop incident from being filed as an estate-wide one. Without per-device DNS history you cannot prove that negative, and it gets written up as worst case.

This is the part most teams under-spec. DNS filtering gets bought for the live block and the weekly chart; the retained, searchable record is a separate concern, and if you only specified the chart, you find out at the worst hour. ClearScreen records every block against a known device with domain, category, source feed, and timestamp — as a JSONL audit on the endpoint and, in managed mode, in the Console block feed you can export as CSV or JSON. That turns "what did this endpoint try to reach that we blocked" into a search you finish before the early-warning clock runs out. See how the filtering and logging model is built for the report.