Insights ── Cybercompliance ── 2026-05-20

A DORA register, not a DORA tool

A DORA third-party register doesn’t require its own software, but a configured evaluation grid on a platform that scores partners and business units anyway. How a register is mapped onto OpenScorecard — and why the audit mode changes in the process.

Autor Patrick ── Lesezeit 3 Min
A DORA register, not a DORA tool
Fig.01

Most institutions buy a dedicated tool for DORA. A GRC module, a TPRM suite, a register product — each with its own data model, its own vendor master-data maintenance, its own audit trail. That’s the most expensive way to meet a requirement that already fits structurally with what an evaluation platform does anyway: capture evaluation subjects, score them multi-dimensionally, track change. How a DORA register instead emerges as a configured framework on OpenScorecard.

The starting point

A DORA third-party register is not a list. Supervision demands a continuously maintained, audit-proof view of ICT providers — with criticality per service relationship, documented substitutability, visible concentration risks, and a traceable path from every statement back to its source.

In practice, the register almost always starts as an Excel exercise: vendors in rows, criticality flat per vendor instead of per service, concentration risks visible only when someone cross-references by hand. At the first serious supervisory visit, the gap gets expensive — not because the data is missing, but because the trail from the compliance statement back to the original source doesn’t hold.

Why not a dedicated register tool

A DORA register does structurally the same thing as any other evaluation on the platform: it captures evaluation subjects (vendors), scores them across dimensions (criticality, substitutability, concentration), models relationships (vendor to sub-provider to service) and maintains an audit trail. That structure is exactly what OpenScorecard is as a platform.

DORA thus doesn’t become a product, but a configuration: an evaluation-subject type “ICT provider”, a set of evaluation dimensions, a question catalog for vendor self-assessments, a score mapping onto the DORA requirements. If a DORA annex or a NIS-2 tightening arrives tomorrow, that’s a configuration question, not a software project.

How the register emerges on OpenScorecard

Criticality per service relationship. Instead of one score per vendor, the platform models Vendor ↔ Service ↔ Criticality. A hyperscaler is “critical” for the trade platform and “non-critical” for the internal learning portal — both relationships in the same profile, scored separately.

Substitutability as a mandatory field. Per service relationship: are there alternatives, with what effort, in what timeframe. Not as a free-text placeholder, but as a structured attribute that feeds into the scoring.

Concentration risk from the relationship graph. Because sub-provider relationships are captured as a graph, the question “which critical services depend on the same tier-3 provider?” is a query — not a three-day Excel cross-reference.

Self-assessments standardized. Vendor self-disclosures run against a uniform, runtime-configurable question catalog. Answers become comparable because they run against the same grid — not every vendor with their own questionnaire in their own format.

Audit trail to the source. Every register entry has a traceable path to the self-assessment, the external rating, the incident report — with timestamp and version history. The supervisory question “where does this criticality scoring come from?” has an answer in minutes.

What changes in the audit mode

The annual DORA reporting shifts from an Excel campaign to a pipeline task: data exists structured, the report is generated, not assembled. The trail from statement to source is continuous, not interrupted by manual intermediate steps. And because the register runs on the same platform as the internal BU resilience scoring, there is one data model and one audit trail instead of two separate tool worlds.

DORA is just the most regulatory-visible shape here. The same platform carries NIS-2 supply-chain requirements, NIST CSF and NIST SP 800-171 for supplier cybersecurity, the EU Supply Chain Act, internal maturity assessments and any other evaluation grid — as configuration, not as a separate product each. If your DORA register is stuck in Excel reality today, the Tactical Assessment clarifies what the transition looks like.