DORA broke “check-the-box TPRM.” Here’s the Day 1 operating model that holds up.

If you’ve been treating DORA like “another compliance deadline,” you’re not alone. But here’s what’s become clear since DORA started applying in January 2025: DORA doesn’t just require you to assess vendors. It requires you to operate third-party ICT risk as a living system.

That shift is why conversations have spiked around:

• Register of Information (RoI) – not a list of vendors, but a structured dataset of ICT contractual arrangements that must stay current.
• Contract and oversight readiness – audit/access, cooperation, locations, termination rights, and more, at a level that boilerplate contracts rarely deliver.
• Exit strategies – not a slide deck, but documented, tested, periodically reviewed plans that can actually be executed when a provider fails or service deteriorates.

And in November 2025, the urgency intensified when the European Supervisory Authorities published the first list of designated “critical ICT third-party providers” (CTPPs) – a visible milestone that the DORA oversight framework is now real, not theoretical. 

This post is a practical guide for teams that need to be DORA-ready without turning VRM into a second full-time job. That’s especially relevant for the audience Perimeter is built for: regulated industries with small risk/security teams who still need an effective program.

What DORA changes (and why “check-the-box TPRM” breaks)

Traditional TPRM often revolves around one question:
“Did we assess the vendor?”

DORA forces a different question:
“Can we prove – continuously – that we understand and can govern the ICT dependencies that support critical services?”

That’s why “check-the-box” approaches break in three places.

1) Your RoI becomes a supervisory-grade dataset, not internal paperwork

DORA requires maintaining a register of ICT third-party service contracts, distinguishing between critical and non-critical services, and being able to report it annually or on request.

The EU also published standard RoI templates via Commission Implementing Regulation (EU) 2024/2956.

In practice, this means your RoI can’t be a static spreadsheet that goes stale the moment it’s generated. It has to be a system you can maintain, validate, and reproduce under pressure.

2) Contracts become operational controls

DORA sets expectations that contracts cover concrete operational and oversight requirements (not just legal cover). That’s why contract remediation has become a major DORA workload for many teams.

3) Exit strategies must be executable

DORA requires exit strategies and contingency planning to preserve continuity and compliance when an ICT service disrupts or an arrangement must be terminated.

Your own attached DORA/TPRM write-up states it plainly: exit plans must be well-documented, thoroughly tested, and periodically reviewed.

If your “exit plan” is currently a slide deck, that’s not a moral failure – it’s simply a signal that you haven’t yet built the operating model DORA assumes.

Why the “critical provider” list matters (even if you’re not in the EU)

In November 2025, the ESAs published their first list of designated CTPPs.

Even if you’re a US-based firm, this matters if you have:

• EU entities,
• EU customers,
• EU-regulated counterparties,
• or contractual obligations to support EU financial entities’ compliance.

It also changes vendor conversations because “critical” designation is tied to a formal oversight regime, which influences expectations around governance, cooperation, and resilience.

The Day 1 DORA operating model (what to build first)

If you want DORA readiness that survives scrutiny, focus on three outputs – and tie everything else to them.

Output 1: A dependency map you can defend (Function → Service → Provider)

Start by mapping:

• critical/important functions
• to the ICT services that support them
• to the providers (and, where relevant, critical subcontracting paths)

This is how you make concentration and substitutability conversations real, not speculative.

Output 2: An RoI that stays current

Your RoI is not a one-time migration project. Treat it like a living asset with:

• clear ownership by field (procurement, legal, IT, security, business owners)
• an update cadence
• reconciliation rules (what is the “source of truth” when systems disagree)

Your attached summary highlights the core requirement: maintain the register, distinguish critical/non-critical, and be able to report annually or upon request.

And the EU’s RoI templates are standardized – so teams benefit from designing around that structure early.

Output 3: Exit strategies that move from “idea” to “ability”

A credible DORA exit plan includes:

• realistic triggers (provider failure, quality deterioration, disruptive events)
• data return/recovery steps
• a minimum viable substitute path (alternate provider, in-house, hybrid)
• proof you tested and reviewed the plan

Again, your attached document is explicit about this expectation.

A practical 30–60–90 day plan for small teams

Perimeter’s positioning is built around helping small teams in regulated industries run an effective program with less admin burden.
This 30–60–90 approach is designed with that reality in mind.

Days 1–30: Make the inventory real

• Build/validate your ICT vendor + service inventory
• Tag what supports critical/important functions
• Identify “unknowns” (shadow ICT, unowned systems, missing contracts)

Days 31–60: Make it auditable

• Produce the RoI in the standard template structure (even if you’re still improving data quality)
• Perform a reconciliation sweep with procurement + legal + IT/security
• Create a contract gap list for the top critical dependencies

Days 61–90: Make it resilient

• Draft “minimum viable exit” plans for the top critical services
• Run one tabletop test per critical function
• Establish an oversight cadence (monthly/quarterly) so your evidence trail exists before the audit

The buyer’s shortcut: 10 DORA questions that expose gaps fast

Use these questions to quickly determine whether a provider relationship is “DORA-shaped” or “legacy-shaped”:

1. Which of our critical/important functions does this ICT service support?
2. Where is the service delivered, and where is data processed/stored?
3. What subcontractors are involved, and how do they change our risk?
4. What audit/access rights do we actually have in the contract (not in marketing)?
5. What incident reporting and cooperation obligations are contractually enforceable?
6. What’s the realistic termination path – and what events trigger it?
7. What dependencies would block migration (data formats, tooling, integrations)?
8. What is the “minimum viable substitute” if this provider fails?
9. When did we last test the exit plan?
10. What ongoing monitoring signals do we use to detect risk changes between assessments?

These align with the operational posture your attached DORA/TPRM content emphasizes: continuous oversight, contracts that support compliance, and tested exit planning.

Where Perimeter fits (without adding more work)

Perimeter’s promise is painless end-to-end vendor risk management designed for small teams in regulated industries with many vendors, where manual programs and fragmented tools create unmanageable admin burden.

The platform is positioned as a single source of truth for VRM / TPRM activities, with a strong emphasis on simplicity and productivity for small teams.

Perimeter’s module set supports the DORA work that typically becomes a bottleneck:

• keeping vendor risk understanding current (manual systems are often out of date)
• reducing the time cost of reviewing vendor documentation and evidence
• validating vendor responses rather than simply trusting them
• supporting faster onboarding for teams moving off manual processes or switching from another VRM / TPRM platform

Closing

DORA doesn’t reward paperwork. It rewards proof you can operate resilience.

If your RoI is still a static spreadsheet and your exit strategy is still a slide deck, you’re not “behind” – you’re simply at the starting line of DORA’s operating model. Your next step is straightforward:

• make your dependency map defensible,
• make your RoI maintainable,
• and turn exit planning into a documented, tested, periodically reviewed capability.

Want a DORA-ready RoI and exit strategy you can defend?

Perimeter helps small teams in regulated industries with many vendors automate documentation and reporting, keep records current, and operationalize contingency/exit planning – without headcount or time sprawl