Introduction

If you're coming from a classic risk management background, get ready for a change of pace. DORA zeroes in on ICT third-party risks in a way older frameworks never did, nor needed to. Traditional risk assessments often paint with broad strokes, but DORA demands finer detail and continuous attention. It forces us to ask specific questions: Which systems and vendors are truly critical? Have we mapped out all dependencies? How quickly can we bounce back from an IT outage?

Under DORA, financial entities in the EU must treat tech and vendor risks as seriously as internal operational risks. That means no more "set it and forget it" annual reviews. Instead, DORA assessments are ongoing and granular. A common pitfall is trying to shoehorn DORA into an outdated template, such as using a generic operational risk checklist that overlooks third-party technology dependencies. In fact, 60% of data breaches are linked to third parties, with an average breach costing $4.88 million. Ignoring those third-party links is a recipe for trouble. A Deloitte survey found 87% of businesses experienced a third-party disruption (with 28% suffering a major one), so it's not a rare event; it's almost expected.

This means you shouldn’t treat a DORA assessment as a one-off project or pure paperwork exercise. Many teams initially stumble by focusing only on internal systems and forgetting their extended enterprise. The smart move is to embrace DORA's proactive mindset: be specific about your risks, document them thoroughly, and update regularly.

What is a DORA assessment?

A DORA assessment is essentially a deep-dive ICT risk assessment aligned with the EU Digital Operational Resilience Act (DORA). Think of it as your roadmap to meet DORA's regulatory expectations. In plain English, that means evaluating how well your organisation can prevent, respond to, and recover from digital disruptions, with a heavy focus on third-party technology providers.

Under DORA, financial entities (banks, insurers, investment firms, etc.) must have a comprehensive ICT risk management framework. This includes identifying critical systems and outsourced services, assessing risks like cyber threats or system failures, and planning for incident response and recovery. In short, a "DORA assessment" is your method for checking whether all those boxes are ticked and your digital ops are resilient.

Legacy risk frameworks often fall short because they treat third-party and ICT risks as just another line item. They might not require you to map every dependency or to maintain a detailed inventory of vendors. DORA, on the other hand, explicitly requires things like a Register of Information (a structured register of all your ICT third-party service providers and contracts) and oversight of critical tech vendors. DORA expects you to segment your third parties by importance -something older frameworks might ignore. Legacy frameworks also tend to be static; perform assessment, file report, done. DORA is dynamic. Regulators will expect proof that you continuously monitor and update your assessments.

Step 1: Identify critical ICT services and third parties

‍DORA assessments start with identification. You need to pinpoint which ICT systems, applications, and third-party services are critical to your operations. In DORA language, these are the services supporting your critical functions. For a bank, that might be your online banking platform, payment processing system, and trading systems. For an insurance firm, maybe it's your claims management platform or customer portal.

Obviously, not everything can be "critical", so how do you classify? Here are key pointers to segment your ICT services and vendors in a DORA-friendly way:

Impact on operations: Ask, if this system or vendor went down, what's the impact? If the answer is "we'd be in the news and scrambling," it's likely critical. Services directly tied to customer transactions, financial market operations, or regulatory reporting usually qualify as critical.

Substitutability: Consider how easily you could replace or workaround the loss of the service/vendor. If you have readily available backups, it might be less critical. But if the provider offers something unique – say, a core banking software that few others can step in and do overnight, that raises its criticality.

Concentration risk: Check if multiple critical operations depend on one third-party or system. If you find a single point of failure, that item's importance shoots up.

Regulatory or contractual importance: Some services might be critical because a law or contract says so.

Document everything in a list or spreadsheet, tagging each with a category (critical, important, or lower tier). Be practical and consistent. You might use Tier 1, Tier 2, Tier 3 for high/medium/low criticality. The goal is to clearly flag which tech assets and vendors your business can't live without. This will drive the rest of your assessment and your priorities.

Lastly, you must maintain a Register of Information for all your ICT third-party contracts. In practice, this means recording key details for each provider, such as name, services provided, whether they're critical, and other risk info. It's easiest to build these details in from the start.

You can read this blog for a more in-depth look at how to tier your vendors for DORA.

Step 2: Map dependencies and assess Impact

Map out the web of dependencies. With your list of critical ICT services and third parties in hand, the next step is mapping out all the interconnections. It's not enough to know "System X is critical"; you need to understand why and what feeds into it. Does System X rely on a third-party data centre, a cloud API, or perhaps a chain of sub-vendors?

Start by diagramming or listing each critical service and all the inputs/partners that make it run. For example, if online banking is necessary, list the infrastructure providers (cloud hosting, DNS services), software vendors, payment gateways, etc., on which it depends. It's like making a resilience family tree, upstream providers, downstream processes, all of it.

Prioritise by operational criticality

Once you have the maps, identify choke points. These are points in the network that have an outsized impact. Maybe you discover that two of your top critical services rely on the same third-party cloud vendor; that's a concentration risk. Highlight these in your assessment. This is where you rank risks not just by the individual service, but by how bad a failure would ripple through operations.

Fictional example

‍A mid-sized EU bank discovers that its mobile banking app, online banking portal, and internal trading system all route through one cloud service provider for data storage. Individually, each service was flagged as critical, but mapping shows a bigger picture. CloudCo is a single point of failure for three critical functions. If CloudCo has an outage, customers can't access accounts, traders can't execute orders, and the bank might even miss regulatory trade reporting. Furthermore, they learn that CloudCo subcontracts some maintenance to a smaller IT firm (a fourth-party dependency they weren't aware of). Through this exercise, they uncover both concentration risk and hidden fourth-party risk, helping them prioritise CloudCo as a top risk to address.

This mapping helps you comply with DORA's emphasis on concentration risk analysis. Regulators want to see that you've considered scenarios where one failure could knock out multiple functions. The proportion of confirmed data breaches involving third-party relationships doubled from 15% to 30% in one year. Supply chains and interconnections are increasingly where things break.

Step 3: Conduct the ICT risk assessment

Now that you know what you're dealing with, it's time to assess the risks associated with them. This is the heart of the DORA assessment, evaluating threats and vulnerabilities in your ICT landscape and third-party relationships. The key is to tailor your risk criteria to DORA's focus areas and to differentiate between inherent and residual risk for each item.

Unlike a generic risk assessment, a DORA-focused assessment will specifically look at several dimensions:

Cybersecurity risk

‍How secure is the system or vendor? Consider threats like hacking, malware, and data breaches. For each critical system or third-party, review their cybersecurity posture. Do they have strong encryption, access controls, and incident response plans? For vendors, check certifications (ISO 27001, SOC 2, etc.) and incident history.

Operational resilience risk

‍This includes concentration risk and continuity. What's the risk of this system or provider failing? Does this system have backups and failovers? Does the vendor have a solid disaster recovery plan? A provider supporting a critical service with no redundancy is a high risk.

Compliance and contractual risk

‍DORA has specific rules for contracts and oversight of third parties. Check if each critical vendor contract meets DORA requirements, audit rights, incident reporting, and exit strategies. If not, there's a compliance risk. Also, assess if the vendor might cause you to breach any laws if they fail.

Other risk factors

Depending on your business, you might include financial stability of vendors, geographic risk, and fourth-party risk (do they heavily outsource themselves?).

For each critical ICT asset or vendor, assign an inherent risk level for each criterion; this is the risk before any mitigations. Then look at what controls or mitigations are in place and determine the residual risk. Residual risk is essentially "what's the risk after we've applied shields and safeguards?" Understanding residual risk shows whether your controls are sufficient.

Document your findings in a structured way, ideally in a risk register linked to your DORA Register of Information. Keep the language clear and avoid jargon; remember, you may need to show this to regulators.

Step 4: Build and maintain your DORA RoI

Consolidate your information into something actionable and referenceable, your DORA Register of Information. This register is your master inventory of ICT third-party arrangements and related risk info. Think of it as your single source of truth for all things ICT risk and vendor compliance.

What to include in the register:

• ‍Provider name and details: Basic vendor information and contact details‍
• Services provided: What they do for you (e.g., "Cloud hosting for core banking platform")‍
• Criticality tier: Critical, Important, or neither -- flag it clearly‍
• Inherent and residual risk levels: Summary risk scores from Step 3‍
• Controls/mitigations in place: Brief note of key controls and safeguards‍
• Last assessment date & next review date: Track when assessed and when due next‍
• Contract information: Start/end dates and any DORA-required clauses‍
• Dependency notes: Key fourth-party dependencies or concentration issues ‍
• Owner: Who in your organisation is responsible for this vendor

The register should give anyone a clear snapshot of your ICT vendor landscape and risk posture. If done right, a quick scan lets you answer "Who are your critical tech providers and how are you managing them?"

Keeping it updated: A register is only useful if it's current. Integrate updates into your processes. Establish that whenever a new ICT contract is signed, the register must be updated before the contract goes live. Set periodic reviews and consider using GRC software to reduce manual burden and provide automated reminders when reviews are due.

For five tips on how to implement the DORA Register of Information, you can read this blog article by us.

Step 5: Review regularly

DORA assessments are ongoing by design. Set up a cadence and triggers to keep your assessment and register evergreen, and ensure you maintain evidence of all this work.

Manage change proactively

‍Any time you introduce a new system or vendor, or make significant changes, it should trigger a risk assessment update. Bake risk checks into your change processes. Include a step in every major IT project to consider DORA implications.

Keep an eye out for events that could alter risk levels:

• Vendor incidents or outages (even if they didn't fully knock you out)
• New cyber threat bulletins affecting technologies your critical systems use
• Regulatory updates or guidance on DORA
• Changes in business reliance on vendors (volume or importance increases)
• Contract renewal times for key suppliers

Maintaining audit trails

‍Keep clear records of what was done, when, and by whom. DORA will have your work scrutinised; you want to prove your process is robust and repeatable. Use tools or a simple versioning system to log changes to assessments and register. If you update a vendor's risk rating after a review, note the date, reason, and reviewer.

Many firms set up quarterly DORA risk committee meetings to discuss any changes or incidents and decide if the register and assessments need tweaking. Regular reviews should also consider lessons learned, feed data from incidents and near-misses back into the process for continuous improvement.

Conclusion

DORA assessments represent a shift to ongoing digital resilience. By breaking the work into manageable steps, you turn a daunting regulation into practical actions: identify your critical services and vendors, map and assess to create a prioritised to-do list, maintain your DORA register as your trusty reference tool, and treat the assessment as a living process.

Actionable takeaways:

Make it collaborative: Engage IT, business units, procurement, and risk teams together, after all, DORA compliance is a team sport

Leverage frameworks and tools: Don't reinvent the wheel. Using templates for risk criteria. Furthermore, using tools to automate, such as 3rdRisk, can help a great deal. In this blog, we discuss how 3rdRIsk helps financial institutions with our DORA framework.

Focus on what matters: Keep emphasis on operational impact. The purpose is not just to please regulators, it's to avoid outages, breaches, and crises

Stay informed: Keep an ear out for guidance from regulators and experiences shared by other firms

Remember that resilience is a journey, not a destination. Every quarter, every incident, every vendor change is an opportunity to refine your resilience stance. DORA pushes us all to be better at managing digital risk, and in doing so, we not only comply with the law but also build trust with customers and stability in operations. Make DORA's continuous assessment ethos part of your organisation's DNA.

If you're ready to take your DORA strategy to the next level with a more structured and streamlined approach, you can schedule a demo or check out our on-demand preview here.

‍