June 12, 2026

DORA ICT risk: why the DNS layer belongs in your register

DORA Article 6 expects financial entities to identify, classify, and document ICT risk across the full service chain. Endpoint web controls rarely appear as a named entry. They should — because DNS resolution is the first hop to malware delivery, credential phishing, and data exfiltration over unsanctioned SaaS.

The hidden third party

Many fleets still rely on the ISP resolver or a public DNS service with no contractual ICT risk assessment. That resolver sees every query, may apply its own filtering opaque to your SOC, and sits outside your incident reporting boundary. When you delegate policy to a cloud DNS security vendor without tenant isolation evidence, you inherit their outage and breach scenarios in your register whether you documented them or not.

What to document

A defensible DNS control entry should list: enforcement point (endpoint agent vs network gateway), data flows (queries, block events, policy sync), dependency on external feeds, signature verification method, RTO if the management plane is unavailable, and subcontractor chain if a third party hosts policy or indicators.

ClearScreen keeps policy and audit in your Spot Suite Customer Environment while agents pull ed25519-signed threat bundles that continue to enforce when management sync is delayed. That split — local enforcement, central evidence — is the pattern DORA testers look for when they ask whether critical functions survive ICT disruption.

Incident and testing hooks

Map DNS blocks to your incident classification: a user reaching a known phishing domain is a near-miss worth trending; a sudden spike in blocks from a new feed is a detection-quality issue; mass false positives from a category change is a change-management failure. Your ICT risk testing programme should include a tabletop where threat feed delivery fails for 24 hours and endpoints must still block with the last signed bundle.

NIS2 operators of essential services face parallel expectations on supply-chain visibility. If your MSP configures category policy, their access path and change logs belong in the same annex as the control itself.

Board reporting angle

ICT risk committees rarely want raw block counts. They want trend lines: phishing blocks prevented, AI-category enforcement coverage, median false-positive closure time, and fleet percentage on the latest signed bundle version. Package those metrics quarterly alongside penetration-test findings and third-party risk scores. When DORA testers ask whether you understand ICT concentrations, a DNS layer with documented subcontractors, offline behaviour, and exportable evidence is easier to defend than "we use a well-known secure web gateway" with no endpoint behaviour described.

Score your current posture with the DNS policy readiness checklist before the next internal ICT risk committee cycle.