> ## Documentation Index > Fetch the complete documentation index at: https://docs.matproof.com/llms.txt > Use this file to discover all available pages before exploring further. # DORA Quickstart > Practical 90-day plan to get from sign-up to DORA-ready in Matproof — covering ICT risk management, third-party register, incident reporting, and operational resilience testing. # DORA Quickstart This is the operational companion to [/frameworks/dora](/frameworks/dora) (which explains *what* DORA requires). Here we cover *how* to deliver each obligation in Matproof, week by week. ## Who this is for * Financial entities (banks, payment institutions, investment firms, crypto-asset service providers, ICT third-party providers) in scope for Regulation (EU) 2022/2554 * Compliance leads, CISOs, ICT risk managers responsible for DORA implementation * Anyone preparing for their first BaFin / national competent authority (NCA) examination If you're not sure DORA applies, see [/frameworks/dora](/frameworks/dora#scope) — but if you're reading this in 2026, your competent authority almost certainly already has you on a list. ## Before you start | Have ready | Why | | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | | Your organization's legal name + entity classification (credit institution, IFM, IORP, etc.) | Drives DORA proportionality (some obligations apply only to "significant" entities) | | Existing list of ICT third-party providers (cloud, SaaS, fintech infrastructure) | You'll seed the [Article 28 register](#week-2-3) from this | | Existing risk register (any format — spreadsheet, GRC tool, Confluence) | You'll port the relevant entries into Matproof's risk module | | Existing incident-management runbook (if any) | Reference material for the [Article 17 setup](#week-4-6) | | Two key approvers identified — typically CISO and one management-body member | DORA Article 5(2) requires management-body sign-off on the ICT risk framework | ## Phase 1 — Week 1: Foundation Complete the [Onboarding](/onboarding) flow first; the steps below assume you're past the setup wizard. ### Day 1–2: Platform setup 1. In **Settings → Frameworks**, confirm DORA is active. The control library should be populated (about 70 controls). 2. Go to **Frameworks → DORA**. Skim the controls list to understand the structure: Article 5–6 (governance), Article 8 (asset inventory), Article 9 (ICT security), Article 17–23 (incident management), Article 24–27 (resilience testing), Article 28–30 (third-party). 3. Run the gap assessment if Matproof prompts you to. ### Day 3–5: Team and ownership 1. **People → Invite team.** At minimum invite: CISO, head of ICT/IT, head of compliance, the management-body member who will sign off on the ICT risk framework. 2. Assign control owners: every Article 5–9 control should have a named owner. Don't try to assign every Article 10–30 control yet; do those as you reach each phase. ## Phase 2 — Week 2–3: ICT Asset Inventory + Third-Party Register (Article 8 + Article 28) ### Article 8 — ICT Asset Inventory DORA Article 8 requires an inventory of every ICT asset that supports business functions. In Matproof: 1. Connect cloud integrations ([AWS](/integrations/aws), [Azure](/integrations/azure-ad), [GCP](/integrations/gcp)) — Matproof auto-imports cloud assets 2. Roll out the [Matproof Device Agent](/features/device-agent) to laptops — populates the endpoint inventory automatically 3. For non-cloud / non-endpoint assets (on-prem servers, network equipment, SaaS without integrations), add manually under **Assets** 4. Tag each asset by **business function** (payments, trading, custody, customer onboarding, etc.) — DORA cares about which assets support which critical/important functions ### Article 28 — ICT Third-Party Register The single most-asked DORA deliverable. Most NCAs (BaFin, AFM, AMF, Banca d'Italia) request the register format defined in the ESAs' Implementing Technical Standards (ITS) — Matproof's [Vendor Risk module](/features/vendor-risk) produces this directly. 1. **Vendor Risk → Vendors → Bulk import** — upload your existing vendor list as CSV 2. For every ICT vendor, complete the additional DORA fields: * **Criticality** — Critical / Important / Standard (use Matproof's classification helper if unsure) * **Function supported** — link to which business function the vendor enables * **Sub-processor list** — collect via the **DORA ICT Third-Party Assessment** questionnaire (see [Questionnaire AI](/features/questionnaire-ai)) * **Data location** — where the vendor processes data (relevant for cross-border transfer risk) * **Exit strategy** — required for Critical vendors (Article 28(8)) 3. Run the **Article 30 contractual checklist** — for each Critical vendor, confirm the contract contains all mandatory clauses (data location, audit rights, sub-contracting limits, security measures, exit support, termination rights, business continuity) 4. Run **concentration risk analysis** in the vendor module — Matproof flags critical functions concentrated on a single provider, region, or parent group ### Output of phase 2 * Article 8 ICT asset inventory complete and tagged by business function * Article 28 register populated with criticality, sub-processors, contractual checklist * Article 28 ROI export available (the format ESAs accept for register submission) ## Phase 3 — Week 3–4: ICT Risk Management Framework (Article 5–6) DORA Article 5 requires a documented ICT risk management framework. Matproof's auto-generated **Risk Management Policy** provides the foundation; customize it. 1. **Policies → ICT Risk Management Policy** — review and customize the AI-generated draft. Specifically tailor: the governance structure (who reports to whom), the risk-tolerance statement, the ICT risk-acceptance criteria 2. **Get management-body sign-off** (Article 5(2)) — submit the policy for review, with an actual member of the management body as the reviewer. Their approval is recorded in the audit trail and serves as evidence 3. **Risks → Risk register** — port your existing top risks. For each, score likelihood × impact, set a treatment, link to the controls that mitigate it, and assign an owner 4. Cross-link risks to assets from phase 2 — Article 6 wants to see the asset → risk → control chain ### Output of phase 3 * ICT Risk Management Policy published, signed off by management body * Risk register populated with linked controls and treatment plans * Risk-treatment monitoring scheduled (Matproof reminds owners as treatment dates approach) ## Phase 4 — Week 4–6: Incident Management (Article 17–23) DORA imposes **strict timelines** on major-incident notification: | Report | Due | What | | ------------------------ | ------------------------------------- | --------------------------------- | | **Initial notification** | 4 hours after classification as major | First-line notification to NCA | | **Intermediate report** | 72 hours after initial | Updated facts, status, impact | | **Final report** | 1 month after resolution | Full root-cause + lessons-learned | The clock starts on **classification as major**, not on detection. Misclassification (or late classification) is itself a finding. 1. **Incidents → Settings** — confirm your NCA is correct. For German entities, this is BaFin. For others, set the relevant national authority. Matproof pre-fills NCA-specific report templates. 2. **Test the incident flow end-to-end** with a tabletop exercise: * Create a synthetic incident in Matproof * Step through classification (use one of the actual DORA major-incident criteria — number of clients, duration, geographic spread, data loss, criticality, economic impact) * Generate the initial 4h notification report * Verify the report meets the ESAs' RTS format (Matproof's templates are aligned by default — confirm any custom fields) 3. **Document your detection sources** — what tools, who's on call, escalation paths. Reference these in the Incident Management Policy 4. **Brief the on-call team** — they need to know the 4-hour clock starts on classification, that classification is a deliberate step they have to perform in Matproof, and where to find the report templates ### Output of phase 4 * Incident Management Policy published with NCA-specific reporting flow * Tabletop exercise documented (this itself is Article 17 evidence) * On-call team trained on the 4h/72h/1mo deadlines ## Phase 5 — Week 6–8: Operational Resilience Testing (Article 24–27) Article 24–25 requires regular testing of operational resilience. Matproof's [Cloud Tests](/features/cloud-tests) module covers the technical side. 1. **Cloud Tests → New test** — set up at minimum: * Availability test for each business-function-supporting service (weekly) * Recovery test against your stated RTO (monthly) * Failover test for any cross-region / cross-AZ redundancy (monthly) * Data integrity test after every major release (event-triggered) 2. **Document the testing programme** in the BCP/DR policy 3. For **significant entities**: scope a Threat-Led Penetration Test (TLPT) per Article 26–27 — TLPT requires red-team engagement at least every 3 years. Matproof's [Penetration Tests](/features/penetration-tests) module is for the AI-powered side; TLPT will additionally require an external accredited red-team firm. ### Output of phase 5 * Resilience testing schedule live, first results recorded as control evidence * BCP/DR policy reflects the testing programme * TLPT scope and external firm engaged (significant entities only) ## Phase 6 — Week 8–12: Operational rhythm By week 8 the core deliverables are in place. The remaining work is establishing the operational rhythm: * **Weekly:** review Findings (vendor questionnaires, Cloud Tests, device-agent CVEs, audit findings) and triage * **Monthly:** review the risk register, vendor concentration, integration health * **Quarterly:** rerun the Article 30 contractual checklist on every critical vendor; refresh DPAs; rerun vendor questionnaires * **Annually:** review the ICT Risk Management Policy; management-body re-affirmation; full BCP test; TLPT planning if significant ## Audit-readiness checklist Use this when preparing for your first NCA examination or internal audit: * [ ] **Art. 5–6:** ICT Risk Management Policy published, signed off by management body * [ ] **Art. 8:** ICT asset inventory complete with business-function tagging * [ ] **Art. 9:** ICT security policies (access control, encryption, network security) published with named owners * [ ] **Art. 11:** BCP / DR plans published and tested at least once in the last 12 months * [ ] **Art. 17:** Incident Management Policy published, on-call team trained on 4h/72h/1mo timeline * [ ] **Art. 17–23:** At least one incident tabletop exercise documented; report templates verified RTS-compliant * [ ] **Art. 24–27:** Resilience-testing programme live with at least one quarter of test results * [ ] **Art. 26–27:** TLPT scope defined (significant entities only); external red-team firm under contract * [ ] **Art. 28:** Article 28 register complete; all critical vendors have signed contracts with Article 30 mandatory clauses * [ ] **Art. 28(8):** Exit strategy documented for every critical vendor * [ ] **Art. 28:** Concentration-risk analysis completed and accepted by management body * [ ] **Art. 30:** Article 30 contractual checklist passing for every critical vendor ## Common gotchas * **"We're a small institution — does DORA apply?"** Yes. DORA is broadly scoped. Microenterprise relief exists but the bar is low (under 10 staff and €2M turnover/balance). Don't assume you're out of scope without checking Article 16. * **The 4-hour clock** isn't 4 business hours. It's 4 calendar hours from classification, including weekends. On-call coverage matters. * **The Article 28 register** is the single most-likely first thing your NCA asks for. Have it ready before the request lands. * **TLPT** requires an external accredited firm — TIBER-EU or similar. Matproof's pen-test feature does NOT satisfy TLPT alone. Don't claim it does. * **Concentration risk** is interpreted broadly: same provider, same region, same parent group, same operating-system family. Be honest in the analysis — a NCA reviewer will probe. Conceptual overview — what DORA requires Article 28 register module Article 17 incident reporting flow Article 24–27 resilience testing