The Cyber Dependency a Register of Information Forces Into the Open

Financial entities in Europe maintain a register naming every contractual arrangement for services from technology providers, submitted annually in a prescribed format. It is treated as a reporting artifact, and building it is generally described as a data quality exercise.

‍

Read the other way it is the first document in most organizations that joins a named provider to a specific service to a business function with a criticality rating attached. Nothing else does that, and the difficulty of producing it is the evidence.

‍

What Does the Register Join?

‍

Three things that live in three functions and were never connected, which is why it is hard rather than tedious.

‍

Commission Implementing Regulation (EU) 2024/2956 defines the format as fifteen linked templates spanning the entity, the provider, the contractual arrangement, the service, the function or asset it supports, and any sub-outsourcing. They form a relational model joined by reference keys rather than fifteen independent spreadsheets.

‍

Which Is Exactly a Dependency Map

‍

Procurement holds vendors and contracts. Technology holds systems. Business continuity holds functions and their criticality. The register cannot be completed without joining all three, so the reporting format encodes the analysis rather than merely requesting it.

‍

What Does the Failure Rate Tell You?

‍

It is discovery rather than reporting, and the numbers are stark enough to make the point.

‍

In the supervisory dry run, a small single-digit percentage of submissions passed every validation check. In one member state fewer than two in five could be processed at European level. A survey found close to half of institutions naming the register as the single hardest requirement in the regulation.

‍

Which Is Not a Formatting Problem

‍

Around a third of submissions had missing or invalid legal entity identifiers, which is a data quality issue. The more revealing error is aggregating contracts by provider rather than recording one per arrangement, because an organization that does that cannot say which specific service supports which function. The formatting failure is a symptom of the dependency question never having been answered.

‍

What Do You Do With an Unexpected Name?

‍

Three cases, and each has a different resolution.

‍

• In the register and not in the risk assessment: An undocumented dependency the register found. Assess it, because the contract exists whether or not anybody wrote it down.
• In the risk assessment and not in the register: Either genuinely out of scope, or a contractual arrangement nobody captured, and the second is more common.
• In both with different criticality: Two functions disagree about whether this matters, which is the most useful finding of the three.

‍

The third case is worth pursuing rather than reconciling quietly. A provider rated critical in the register and routine in the risk assessment means somebody made an assumption, and finding out which assumption is wrong is the point of having both documents.

‍

What Does It Reveal at Portfolio Level?

‍

Concentration, which is the reason the supervisor wanted it and the same reason an entity should read its own.

‍

Published analysis of the collected registers found more than sixty-five percent of European entities relying on at least two of the three largest cloud providers for critical functions. The register exists so a supervisor can see that pattern across the sector, and the same fields show an individual entity how much of its own critical function set rests on how few providers.

‍

Which Is the Analysis Nobody Was Doing

‍

A vendor list sorted by spend does not answer it. A concentration reading requires the function link, since the question is how many critical functions stop rather than how much money is at stake, and concentration you cannot diversify away is what to do once the answer is uncomfortable.

‍

What Can the Register Not Tell You?

‍

Anything reached without a contract, which is a boundary worth stating before treating it as complete.

‍

It records contractual arrangements. A free tier somebody signed up for, a component embedded in a purchased product, and a fourth party your provider depends on but you do not contract with are all absent by construction. So it is the complete list of contracted dependencies rather than the complete list of dependencies.

‍

Which Half Is Missing?

‍

The sub-outsourcing templates reach some of it, since they record chains your provider discloses. What they cannot reach is a dependency your provider did not disclose or does not itself know about, and concentration at fourth-party depth is where that becomes a loss rather than a documentation shortfall.

‍

Why Does the Format Matter Operationally?

‍

Because it prevents the register living in a spreadsheet, and that constraint does more good than the submission itself.

‍

Submissions arrive as a structured package with one file per template referencing a published taxonomy, with coded values for countries, currencies, entity identifiers and service types rather than free text. An organization maintaining the register in a spreadsheet has to convert and validate every cycle, and the conversion is where errors enter.

‍

What Follows From That?

‍

Holding the register in a structured system rather than a document, with the joins enforced rather than manual. The difference is between a register that is submission-ready at any moment and one that is rebuilt each year, which what a register does between reviews addresses for the risk equivalent.

‍

Who Should Own the Register?

‍

Not the function that submits it, which is the assignment most organizations default to and the one that keeps it a filing.

‍

Regulatory reporting owns the submission because it owns the deadline and the format. It does not own the underlying facts, since the provider records sit with procurement, the service mapping with technology and the criticality rating with business continuity. A register owned by whoever submits it gets assembled annually and read once.

‍

What Is the Alternative?

‍

Owning the joins where they are maintained and treating the submission as an export. A contract signed in March updates the register in March rather than in the following January, and criticality changing after a business continuity review propagates immediately. The submission then reflects a live record rather than a reconstruction.

‍

Which Also Answers the Duplicate Reporting Complaint

‍

Supervisors have noted that services supporting critical functions frequently also qualify as material outsourcing under existing national regimes, so the same facts are reported twice in different shapes. Holding the facts once and exporting to each format is the only version of that which does not double the work, and normalizing one set across frameworks is the same principle applied to controls.

‍

What Should Be Done With It?

‍

Four things, and none of them is submitting it.

‍

Compare the provider list against the risk assessment population and resolve every name appearing in one and not the other. Count how many critical or important functions depend on each provider, which the function templates already answer. Identify providers supporting more than one critical function, since those are the single points of failure the register just named. Then attach a figure to each. Cyber risk quantification built on the register's own joins turns a compliance submission into a ranked dependency exposure.

‍

A Filing That Contains a Map

‍

The register joins a named provider to a specific service to a business function with a criticality rating, which is a join procurement, technology and business continuity each hold a third of and nobody held whole. The prescribed format is fifteen linked templates rather than fifteen lists, so completing it performs the analysis rather than reporting it. The validation failure rates and the survey findings are evidence of that, and the most revealing error is aggregating by provider rather than by arrangement, because it means the service-to-function link was never established. A name appearing in the register and not in the risk assessment is an undocumented dependency, and one appearing in both with different criticality is two functions disagreeing about what matters. Kovrr's cyber risk quantification attaches a figure to the dependencies the register names.

‍

To see modeled exposure per provider against the dependencies your register already names, book a demo with our risk experts.