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

This is the operational companion to /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 — but if you’re reading this in 2026, your competent authority almost certainly already has you on a list.

​

Before you start

​

Phase 1 — Week 1: Foundation

Complete the 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, Azure, GCP) — Matproof auto-imports cloud assets
2. Roll out the Matproof 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 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)
   • 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: 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 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 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.