DORA: all five pillars, without a second risk inventory for the supervisor
ICT risk management, incidents, resilience testing, the third-party register and information sharing run in the same workspace as your BCMS and ISMS. An ISMS access control counts towards Pillar 1, and a BC exercise evidences the continuity tests of Pillar 1 and feeds the testing programme of Pillar 3.
5.0 out of 5
ICT risks in the same register as everything else
Risks from unmet requirements and risks from analysing the systems sit side by side with level, residual risk, status and strategy. Pillar 1 asks for a managed framework across identification, protection, detection, response and recovery, not a second risk register kept for the supervisor.
5DORA pillars covered
Providers with criticality and a next review
Every ICT provider carries its tier, approval status, risk score, the certificates it produced and the date of its next assessment. The register of information under Article 28 comes out of that, instead of being gathered from contracts once a year.
Classify incidents before the clock runs
Security incidents, continuity incidents, data breaches and requests run in one list with category, severity, status and owner. The reporting deadline for major incidents hangs on the classification, and that is documented here.
Evidence DORA with ISO 27001 and ISO 22301
An access control from the ISMS counts towards pillar 1, and an exercise from the BCMS evidences the continuity tests of pillar 1 and feeds the testing programme of pillar 3. KaitoSec runs both regimes on the same inventory, so one implementation yields two pieces of evidence.
4hMajor incident reporting window
Connect DORA with other standards
Connect DORA with the management systems that already carry the same requirements.
- NIS2EU cybersecurity directiveLearn more
- ISO 27001The international ISMS standardLearn more
- ISO 22301The international BCM standardLearn more
DORA by company and role
More for DORA
ICT risk framework with accountable owners
DORA requires financial entities to maintain a comprehensive ICT risk management framework under Article 6. KaitoSec provides a pre-built framework template aligned with the regulatory technical standards of the European Supervisory Authorities, covering identification, protection, detection, response, and recovery.
Third-party ICT risk management
DORA places strict obligations on the management of ICT third-party providers, including mandatory contractual provisions and concentration risk assessment. KaitoSec tracks all ICT providers, their criticality classification, and contract compliance status in one register.
Incident classification and reporting
Represent the classification criteria, approvals and notification steps relevant to your scope. KaitoSec prepares the assessment and reporting data; accountable professionals confirm them.
Track progress per pillar
Track implementation progress across all five DORA pillars: ICT risk management, incident management, digital operational resilience testing, ICT third-party risk, and information sharing. Each pillar shows completion percentage, open gaps, and upcoming deadlines.
TLPT Orchestration
Threat-Led Penetration Testing (TLPT) is required for significant financial entities at least every three years. KaitoSec manages the TLPT lifecycle from planning through coordination to remediation tracking, and keeps the documentation ready for supervisory review. The remaining Pillar 3 resilience tests are planned, documented and linked to your BC plans and recovery strategies in exercise management.
Maintain the Article 28 register of information
Maintain the register of information on all contractual arrangements with ICT third-party providers required under DORA Article 28. KaitoSec tracks provider criticality, contractual provisions, concentration risk, and sub-outsourcing chains, and generates the register in the format required by the European Supervisory Authorities.
Business continuity and recovery planning
DORA requires financial entities to maintain ICT business continuity and recovery plans as part of their ICT risk management framework. KaitoSec connects your DORA obligations with structured BIA workflows, recovery strategy documentation, and testable BC plans. Link recovery targets to critical ICT services, document your strategies, and demonstrate compliance.
The five pillars of DORA
DORA asks for five things at once: a managed ICT risk framework under Article 6, detection, classification and reporting of incidents, a resilience testing programme up to threat-led penetration testing, management of ICT third-party providers including the register of information under Article 28, and the sharing of threat intelligence.
5pillars
- Pillar 1ICT risk management
- Pillar 2Incident reporting
- Pillar 3Resilience testing
- Pillar 4Third-party risk
- Pillar 5Information sharing
3reports for a major incident
- 4 hInitial report
- 72 hIntermediate report
- 1 monthFinal report
Frequently asked questions about DORA
Who is subject to DORA?
DORA applies to a wide range of EU financial entities including credit institutions, payment institutions, investment firms, insurance companies, crypto-asset service providers, and data reporting service providers. It also applies to critical ICT third-party service providers that serve these entities, including major cloud providers.
What are the five pillars of DORA?
DORA is structured around five pillars: ICT risk management (Articles 5–16), ICT incident management and reporting (Articles 17–23), digital operational resilience testing (Articles 24–27), ICT third-party risk management (Articles 28–44), and information and intelligence sharing (Article 45). KaitoSec provides dedicated workspaces for each pillar. ICT business continuity under Pillar 1 draws on the same BIA and BCMS methodology that underpins ISO 22301.
What is the major ICT incident reporting timeline under DORA?
A major ICT incident needs an initial notification within 4 hours of classifying it as major (and no later than 24 hours after becoming aware of it), an intermediate report within 72 hours and a final report after one month. KaitoSec keeps these deadlines and the prepared reporting data with the incident; the accountable function confirms classification and submission.
How does DORA relate to NIS2?
NIS2 covers cybersecurity broadly across critical sectors, while DORA is a sector-specific regulation for financial services that goes into greater depth on ICT resilience, third-party risk, and resilience testing. Where a financial entity falls under both, DORA generally takes precedence for ICT risk matters. KaitoSec maintains a cross-mapping to avoid duplicating compliance work. That is the same implement-once idea our article Resilience Made Easy describes.
What is Threat-Led Penetration Testing (TLPT) under DORA?
TLPT is an advanced, intelligence-led penetration testing methodology required for significant financial entities under DORA Article 26. Unlike standard penetration testing, TLPT simulates the tactics of sophisticated real-world adversaries against your live production systems. It must be carried out at least every three years, by testers who meet the requirements of Article 27, and is aligned with the TIBER-EU framework.
Your DORA plan in thirty minutes.
In the demo we walk the five pillars: risk framework, reporting paths, testing, third parties and sharing. You leave knowing where the widest gap sits.