By Yair Knijn · August 27, 2025

The bank CISO who built a DORA ICT risk register and left the DNS layer out of it

The Register of Information at this mid-sized EU bank was, by any reasonable measure, good. Every application carried a criticality tier. Every cloud tenant and every core-banking vendor had its own row. The business-impact analysis traced payment processing down to the database. Internal audit signed it off. Then an upstream recursive resolver fell over, the trading desk went dark for forty minutes, and the CISO went looking for the register row that owned the risk. There wasn't one.

The mistake was treating DNS as plumbing instead of a dependency. It resolves names, it never shows up in an architecture diagram, and so it never reached the asset inventory or the dependency map. DORA exists to close exactly that kind of gap.

What DORA expects in the ICT dependency mapping

Article 8 and the RTS on ICT risk management require a financial entity to keep an up-to-date inventory of ICT assets and to map the dependencies between those assets and the business functions they support. The text is explicit about single points of failure and hidden dependencies. The deliverable is not a spreadsheet of servers. It is a demonstration that you understand how a critical-or-important function breaks, all the way down the chain, including the dependencies nobody bothered to write down.

DNS sits at the bottom of nearly every one of those chains. A trading platform, an internal API gateway, an OIDC login flow, a SWIFT connector each resolve a name before they do anything else. When resolution fails or returns a poisoned answer, the function fails with it, and the register stayed silent.

Why DNS is an unlisted single point of failure

Banks typically run two or three internal resolvers and call that redundancy. It usually isn't. The forwarders point at the same upstream. The resolvers share one egress firewall rule. The conditional-forwarding config for the cloud VPC is a single record that one change ticket can break. A SERVFAIL storm, or one misapplied response-policy-zone, takes out every dependent function at once. That is the textbook single point of failure, and DORA wants you to name it.

The threat side is worse than the availability side. DNS is a favourite control channel for malware: command-and-control beacons, exfiltration tucked into TXT records, domain-generation-algorithm callbacks. They all ride the resolver. Omit DNS from the register and you have omitted both the outage risk and the busiest attack path in the building.

Entering DNS filtering as both risk and control

DNS belongs in the register twice. Once as a dependency with its own risk entry covering resolution availability, response integrity, and concentration on whichever providers sit upstream. Once as a control: filtering and policy enforcement at the resolver that blocks malicious domains before a connection opens. The layer that is a liability when unmanaged becomes a named control when you run a filter on it with stated categories and threat feeds.

• Risk row: name resolution as a dependency of each critical function, with the failure mode and the single point of failure noted.
• Control row: DNS filtering against malware, phishing, and command-and-control categories, with the policy owner and review cadence.
• Concentration row: the third-party providers your resolution path leans on, mapped to the functions sitting above them.

Third-party DNS providers and the concentration-risk question

DORA takes ICT third-party risk further than the frameworks before it, and the Register of Information expects infrastructure providers, DNS services included, to be listed wherever critical services depend on them. If every business function ultimately resolves through one external provider, that is concentration risk in the regulatory sense, and an examiner can ask you to show you have assessed it. Plenty of entities find, mid-exercise, that their public resolver, their cloud DNS, and their filtering provider are the same vendor. That is one row, not three independent controls.

Evidencing the DNS control during a DORA examination

An examiner does not want a block-count screenshot. They want the register entry, the policy that produced it, the date it took effect, the owner, and the exception process. Per-group policy assignment keeps that evidence clean: you can show the corporate population on a strict resolver policy, a named engineering segment on a documented exception, and both under version control. That is the line between a control you can attest to and a setting somebody changed once and forgot.

ClearScreen runs DNS filtering as a stated control: malware, phishing, and command-and-control categories with signed threat feeds, assigned per policy group so each customer tenant carries its own profile and its own exception trail. The register gets a real row to point at instead of an assumption. See how the control maps to the register in the feature breakdown.