Getting Started with DORA

A step-by-step checklist for EU financial institutions and ICT providers activating the DORA framework in Matproof.

Getting Started with DORA

The Digital Operational Resilience Act (DORA) has been enforceable since January 17, 2025. It applies to EU financial entities (over 20 categories listed in Article 2) and their ICT third-party service providers. Providers designated as critical by the ESAs are additionally subject to direct oversight. Once you activate DORA in Matproof, you’ll see approximately 70 controls across five pillars.

This guide walks you through exactly what to do — in order — so you make real progress from day one.

If you haven’t activated DORA yet, go to Settings → Frameworks → DORA and click Activate. Your controls will be pre-populated automatically.

---

What DORA Requires at a Glance

DORA Pillar	Core Obligation	Matproof Module
1. ICT Risk Management	Maintain an ICT risk management framework with documented policies	Policies, Controls
2. ICT Incident Reporting	Report major incidents within 4 hours of classification as major, and no later than 24 hours after detection	Incidents
3. Digital Operational Resilience Testing	Entities identified by competent authorities must conduct TLPT at least every 3 years; all others must conduct proportionate resilience testing	Cloud Tests
4. Third-Party ICT Risk Management	Register, classify, and monitor all ICT vendors by criticality	Vendor Risk
5. Information Sharing	May participate in voluntary threat intelligence sharing arrangements (Article 45)	Voluntary

---

Am I in Scope?

DORA applies to you if your organization is any of the following:

• Credit institution, payment institution, or e-money institution
• Investment firm or crypto-asset service provider
• Insurance or reinsurance undertaking
• Central counterparty or trade repository
• ICT third-party service providers — all are indirectly affected through contractual requirements (Articles 28-30); those designated as critical by an ESA are additionally subject to direct oversight (Articles 31-44)

This is a non-exhaustive list. Article 2(1) covers 21 categories of financial entities. Consult the full list in the Regulation if your entity type is not shown above.

ICT providers that serve in-scope financial entities may be directly supervised under DORA even if they are not themselves financial institutions. Check with your legal counsel if you are unsure.

DORA applies proportionally based on entity size, risk profile, and complexity (Article 4). Microenterprises may apply a simplified ICT risk management framework under Article 16.

---

The 5 DORA Pillars in Matproof

ICT Risk Management

Policies + Controls

Document your ICT risk strategy, define risk tolerance, and complete the governance controls in Pillar 1. Start here before anything else.

Incident Reporting

Incidents Module

Set up your 4-hour initial reporting workflow. Configure incident classification thresholds that match your regulator’s criteria.

Resilience Testing

Cloud Tests

Schedule and document your TLPT cycles. Matproof tracks test scope, results, and remediation actions.

Third-Party Risk

Vendor Risk

Build your ICT third-party register and classify each vendor by DORA criticality. Send risk assessments directly from the platform.

Information Sharing

Voluntary (Article 45)

Financial entities may voluntarily participate in threat intelligence sharing arrangements. This pillar is encouraged but not mandatory.

---

Recommended 8-Week Implementation Plan

Follow this sequence. Skipping ahead — especially past vendor mapping — is the most common reason DORA audits go poorly.

1. Week 1 — Policies and governance
2. Navigate to Policies and complete the three foundational DORA policies:
4. Assign an owner to each policy. Without owners, controls will stall at review time.
5. Week 2 — Pillar 1 controls (ICT Risk Management)
6. Open Controls → Pillar 1 and work through the ~18 governance and risk framework controls. These establish the foundation every other pillar depends on.
7. Sort controls by Priority: High to tackle the regulator-visible ones first. Controls marked with a lock icon are required for initial compliance.

8. Week 3 — Vendor register and DORA criticality classification
9. Go to Vendor Risk and import or manually add all ICT third-party vendors. For each vendor, set the DORA Criticality field:
11. This classification drives which vendors require enhanced contractual clauses and deeper assessments under Article 28-30.
12. Week 4 — Vendor risk assessments
13. For all vendors classified as Critical or Important, send a DORA Vendor Assessment from the vendor record. Matproof includes a pre-built DORA assessment template aligned to RTS requirements.
14. Track response status in Vendor Risk → Assessments.
15. Week 5 — Pillar 2 controls + incident reporting setup
16. Open Incidents and configure your incident classification criteria. DORA mandates:
18. Set up the notification workflow so the right team members are alerted automatically when an incident is classified.
19. The 4-hour clock starts from the moment you classify an incident as major — not from when it was detected. Define your internal escalation threshold carefully so classification happens fast.

20. Week 6 — Pillar 3 controls and testing schedule
21. Go to Cloud Tests and create your TLPT schedule. If you have not yet completed a TLPT, document the planned scope, threat intelligence provider, and target date.
22. Complete the Pillar 3 controls in the Controls module. These ask for evidence that testing is planned, scoped, and tracked.
23. Week 7 — Pillar 4 and 5 controls
24. Work through the remaining controls in Pillars 4 and 5:
26. Week 8 — Gap review and evidence collection
27. Run Controls → Export to produce a compliance gap report. Review any controls still in Not Started or In Progress status. Assign remediation tasks and set due dates.
28. Share the report with your CISO or compliance lead for final sign-off.

---

The Three Things Teams Get Wrong

1. Not prioritizing controls

With ~70 controls across five pillars, trying to do everything at once leads to nothing getting done. Filter by Priority: High and work pillar by pillar in the order above.

2. Missing the 4-hour incident notification window

Most teams only discover this requirement after a real incident. Set up the Incidents module before you need it. Define what constitutes a “major incident” internally, document it, and run at least one tabletop exercise.

3. Skipping vendor criticality classification

DORA’s third-party risk rules (Articles 28-44) are among the most operationally complex. Without classifying vendors, you cannot determine which ones need enhanced contractual clauses, sub-outsourcing controls, or exit plans. This is also the area regulators scrutinize most.

---

Control Prioritization Reference

Priority	Controls to complete first
Immediate	ICT Risk Management Policy, incident classification criteria, vendor register
Week 1-2	All Pillar 1 high-priority controls, governance structure documentation
Week 3-4	Critical and Important vendor assessments, contractual clause review
Week 5-6	Incident workflow live test, TLPT schedule documented
Week 7-8	Remaining controls, evidence collection, gap report

---

What Good Looks Like

By the end of week 8, a complete DORA implementation in Matproof should have:

• All three foundational policies Approved with assigned owners
• Every ICT vendor in the register with a DORA Criticality classification
• All Critical and Important vendors with a completed assessment on file
• The Incidents module configured with classification criteria and a live notification workflow
• A TLPT schedule documented in Cloud Tests
• At least 85% of controls in Completed or In Review status

Use Dashboard → DORA Overview to see your pillar-by-pillar completion percentage at a glance. This is the view your auditor will want to see.

---

Next Steps

• Configure the Incidents module — detailed incident classification and reporting workflow setup
• Vendor Risk assessments — how to send, track, and score assessments
• Cloud Tests and TLPT — scheduling and documenting your resilience testing program