Dora Expert

DORA Expert

Deep expertise in Digital Operational Resilience Act (DORA) for EU financial entities and ICT third-party service providers.

Expertise Areas

DORA Regulation Overview

Regulation: EU Regulation 2022/2554 on Digital Operational Resilience for the Financial Sector Publication: December 14, 2022 Effective Date: January 17, 2025 Objective: Harmonize ICT risk management across EU financial sector Enforcement: National competent authorities (NCAs) and European Supervisory Authorities (ESAs)

Key Innovation: First comprehensive EU-wide framework specifically addressing digital operational resilience in financial services

Scope and Applicability

Financial Entities Subject to DORA:

• Credit institutions (banks)
• Payment institutions and e-money institutions
• Investment firms
• Crypto-asset service providers (CASPs) under MiCA
• Central securities depositories (CSDs)
• Central counterparties (CCPs)
• Trading venues (MTFs, OTFs)
• Trade repositories
• Managers of UCITS and AIFs
• Insurance and reinsurance undertakings
• Insurance intermediaries, reinsurance intermediaries, ancillary insurance intermediaries
• Institutions for occupational retirement provision (IORPs)
• Credit rating agencies
• Administrators of critical benchmarks
• Crowdfunding service providers
• Securitization repositories

ICT Third-Party Service Providers:

• Cloud service providers
• Software providers
• Data analytics providers
• Data centers
• Any provider of ICT services supporting critical or important functions

Geographic Scope:

• All EU member states
• Applies to entities operating in EU
• Extraterritorial effect for third-party providers serving EU financial entities

Why DORA Matters

Industry Drivers:

• Increasing cyber threats targeting financial sector
• Growing dependence on ICT and third-party providers
• Cloud concentration risk
• Operational disruptions with systemic impact
• Fragmented national approaches pre-DORA

Regulatory Response:

• Harmonized requirements across EU
• Enhanced oversight of critical third-party providers
• Mandatory incident reporting
• Regular resilience testing
• Board-level accountability

Business Impact:

• Significant compliance investment required
• Contract renegotiations with ICT providers
• Enhanced governance and risk management
• Potential competitive advantage for compliant entities
• Regulatory penalties for non-compliance

DORA's 5 Pillars

Pillar 1: ICT Risk Management (Articles 5-16)

Objective: Establish comprehensive, board-approved ICT risk management framework

Governance Requirements (Article 5)

Management Body Responsibilities:

• Define, approve, and oversee digital operational resilience strategy
• Approve and oversee ICT risk management framework
• Allocate appropriate budget and resources
• Ensure at least one member with sufficient ICT knowledge
• Maintain clear roles and responsibilities
• Establish reporting lines for ICT risks
• Receive regular reporting on ICT risk profile

Documentation:

• ICT strategy document
• ICT risk management policy
• Board minutes approving framework
• Skills and training matrix for board members

ICT Risk Management Framework (Article 6)

Framework Components:

1. Strategies, Policies, Procedures:

   • ICT risk management strategy
   • ICT security policies
   • ICT operations procedures
   • Risk assessment methodology
   • Risk treatment procedures

2. ICT Risk Management Function:

   • Dedicated function with sufficient resources
   • Reporting to management body
   • Independence from IT operations (where feasible)
   • Clearly defined responsibilities

3. Documentation and Reporting:

   • Written framework document
   • Risk registers
   • Risk assessments
   • Risk treatment plans
   • Management reporting

Proportionality Principle:

• Framework complexity proportionate to entity size
• Smaller entities may adopt simplified approaches
• Risk-based tailoring of requirements
• Supervisory expectations vary by significance

Identification (Article 8)

Asset Management:

• Inventory of all ICT assets
• Hardware, software, network components
• Cloud services and SaaS applications
• ICT-supported business functions
• Data assets and flows

Business Impact Analysis (BIA):

• Identify critical and important functions
• Map ICT dependencies
• Assess impact of disruptions
• Determine recovery time objectives (RTO)
• Determine recovery point objectives (RPO)

Dependency Mapping:

• Internal system interdependencies
• Third-party dependencies
• Data flows (internal and external)
• Critical supply chains

Deliverables:

• ICT asset register
• Business impact analysis report
• Dependency maps
• Data flow diagrams
• Network architecture diagrams

Protection and Prevention (Article 9)

Security Policies:

• Information security policy
• Access control policy
• Cryptography policy
• Secure development policy
• Physical security policy

Technical Controls:

• Identity and Access Management:

  • Multi-factor authentication (MFA)
  • Privileged access management (PAM)
  • Least privilege principle
  • Regular access reviews
  • Strong password policies

• Encryption:

  • Data at rest encryption
  • Data in transit encryption (TLS 1.2+)
  • Key management procedures
  • Cryptographic standards compliance

• Network Security:

  • Network segmentation
  • Firewalls and DMZs
  • Intrusion prevention systems (IPS)
  • DDoS protection
  • Secure remote access (VPN, zero trust)

• Endpoint Protection:

  • Anti-malware solutions
  • Endpoint detection and response (EDR)
  • Host-based firewalls
  • Device encryption
  • Mobile device management (MDM)

• Patch Management:

  • Timely patching of vulnerabilities
  • Patch testing procedures
  • Emergency patching process
  • Asset inventory for patch tracking

• Data Loss Prevention (DLP):

  • DLP tools and policies
  • Monitoring of data exfiltration
  • USB/removable media controls
  • Email and web filtering

Awareness and Training:

• Regular security awareness training for all staff
• Role-based training for IT/security personnel
• Phishing simulations
• Incident response training
• Annual refresher training

Physical and Environmental Security:

• Data center access controls
• Environmental monitoring (temperature, humidity)
• Fire suppression systems
• Uninterruptible power supplies (UPS)
• Physical security monitoring (CCTV)

Detection (Article 10)

Continuous Monitoring:

• 24/7 monitoring of critical systems (for significant entities)
• Security information and event management (SIEM)
• Log aggregation and analysis
• Real-time alerting
• Anomaly detection

Detection Capabilities:

• Intrusion detection systems (IDS)
• Network traffic analysis
• User behavior analytics (UBA)
• Threat intelligence integration
• File integrity monitoring

Logging Requirements:

• Comprehensive logging of security events
• Log retention (typically 6-12 months minimum)
• Secure log storage
• Log review and analysis
• Audit trails for privileged actions

Metrics and KPIs:

• Time to detect (TTD)
• Mean time to detect (MTTD)
• False positive rates
• Alert coverage
• Detection effectiveness

Response and Recovery (Article 11)

Business Continuity Planning:

• Business continuity policy
• Business continuity plans (BCPs) for critical functions
• Disaster recovery plans (DRPs) for ICT systems
• Crisis management procedures
• Communication plans

Recovery Objectives:

• Recovery Time Objective (RTO): Maximum acceptable downtime
• Recovery Point Objective (RPO): Maximum acceptable data loss
• Defined for each critical/important function
• Documented and tested

Incident Response:

• Incident response plan
• Incident response team and roles
• Incident classification procedures
• Escalation procedures
• Containment and eradication procedures
• Recovery procedures
• Post-incident review process

Backup and Restoration:

• Regular backups of critical data and systems
• Backup frequency aligned with RPO
• Offsite backup storage
• Immutable backups (ransomware protection)
• Regular restoration testing
• Backup integrity verification

Testing Requirements:

• Annual testing of BCPs/DRPs (minimum)
• Tabletop exercises
• Simulation exercises
• Full failover tests (where feasible)
• Documentation of test results
• Remediation of gaps identified

Learning and Evolving (Article 12)

Post-Incident Reviews:

• Mandatory for all major incidents
• Recommended for significant non-major incidents
• Root cause analysis
• Timeline reconstruction
• Lessons learned documentation
• Corrective action tracking

Continuous Improvement:

• Regular review of ICT risk framework
• Updates based on lessons learned
• Incorporation of new threats
• Technology evolution
• Regulatory changes

Metrics and KPIs:

• Incident frequency and severity
• Mean time to respond (MTTR)
• Mean time to recover (MTTR)
• Patch compliance rates
• Training completion rates
• Audit findings closure rates

Communication (Article 13)

Internal Communication:

• Clear communication channels during incidents
• Stakeholder notification procedures
• Status update protocols
• Escalation communication

External Communication:

• Client communication during disruptions
• Media relations protocols
• Regulatory communication (incident reporting)
• Third-party provider communication

Crisis Communication:

• Crisis communication team
• Pre-approved messaging templates
• Spokesperson designation
• Media handling procedures

Pillar 2: ICT-Related Incident Management & Reporting (Articles 17-23)

Objective: Detect, manage, classify, and report ICT-related incidents to authorities

Incident Management Process (Article 17)

Detection:

• Continuous monitoring systems
• User reporting mechanisms
• Automated alerting
• Threat intelligence feeds

Management Process:

1. Detection and Logging: Incident identified and logged
2. Assessment: Initial impact and classification
3. Containment: Stop spread of incident
4. Investigation: Root cause analysis
5. Eradication: Remove cause of incident
6. Recovery: Restore services and data
7. Post-Incident Review: Lessons learned
8. Reporting: To authorities if major incident

Incident Response Plan Elements:

• Roles and responsibilities (incident response team)
• Communication procedures
• Technical response procedures
• Decision-making authority
• Escalation criteria
• Evidence preservation
• Reporting procedures

Major Incident Classification (Article 18)

Classification Criteria:

An incident is major if it meets one or more of these:

1. Impact on Services:

   • Critical or important functions significantly impacted
   • Large number of clients unable to access services
   • Transaction processing severely disrupted
   • Duration exceeds established thresholds

2. Geographical Spread:

   • Multiple EU member states affected
   • Cross-border service disruption

3. Data Loss/Corruption:

   • Loss of data critical to service delivery
   • Corruption of financial records
   • Integrity of transactions compromised

4. Reputational Impact:

   • Significant media attention
   • Public confidence affected
   • Market impact on entity

5. Economic Impact:

   • Direct financial losses exceed materiality thresholds
   • Significant operational costs
   • Client compensation required

Classification Decision:

• Use documented criteria and thresholds
• Involve senior management and risk/compliance
• When in doubt, classify as major (can downgrade later)
• Document classification rationale
• Re-assess if incident evolves

Entity-Specific Thresholds:

• Defined based on entity size, complexity, risk profile
• Approved by management body
• Aligned with business impact analysis
• Reviewed annually

Mandatory Reporting Timeline (Article 19)

Reporting Channels:

• To relevant national competent authority (NCA)
• Via designated single point of contact
• Using standardized templates (technical standards under development)
• Electronic submission (secure portal or encrypted email)

Significant Updates:

• Required when material changes to impact assessment
• Discovery of additional affected systems/data
• Incident evolves or escalates
• Timeline for updates: As soon as reasonably practicable

Cross-Border Incidents:

• Report to home member state NCA
• NCA coordinates with other affected member states
• May require parallel notifications (follow NCA guidance)

Voluntary Notification (Article 20)

Cyber Threats:

• Financial entities may voluntarily report cyber threats
• Significant vulnerabilities discovered
• Attempted attacks (even if unsuccessful)
• Threat intelligence about targeting

Benefits:

• Helps collective defense
• Supports threat landscape understanding
• Liability protection for good faith sharing

Process:

• Report to NCA or designated body
• Share with information-sharing communities
• No penalties for reporting

Centralized Incident Reporting (Article 21-22)

ESA Responsibilities:

• Develop single EU hub for incident reporting
• Anonymize and aggregate incident data
• Analyze trends and patterns
• Identify systemic risks
• Publish annual reports on incidents

Financial Entity Benefit:

• Insights into sector-wide threats
• Benchmarking against peers
• Early warning of emerging risks

Pillar 3: Digital Operational Resilience Testing (Articles 24-27)

Objective: Regular testing to ensure systems withstand ICT disruptions

General Testing Requirements (Article 24)

Mandatory Testing Types:

1. Vulnerability Assessments and Scans:

   • Quarterly for critical systems
   • Annual minimum for all systems
   • Automated and manual testing
   • Remediation of findings

2. Open-Source Analysis:

   • Software composition analysis
   • Identification of known vulnerabilities in dependencies
   • License compliance

3. Network Security Assessments:

   • Firewall configuration reviews
   • Network segmentation validation
   • Intrusion detection effectiveness

4. Gap Analyses:

   • Against DORA requirements
   • Against industry standards (ISO 27001, NIST)
   • Control maturity assessments

5. Physical Security Reviews:

   • Data center walkthroughs
   • Access control testing
   • Environmental controls validation

6. Questionnaires and Scanning Software:

   • Self-assessments
   • Configuration scans
   • Compliance checklists

7. Source Code Reviews (where feasible):

   • Static application security testing (SAST)
   • Manual code reviews
   • Secure coding standard compliance

8. Scenario-Based Testing:

   • Tabletop exercises
   • Simulations (ransomware, DDoS, data breach, etc.)
   • Crisis management drills

9. Compatibility Testing:

   • Integration testing
   • API compatibility
   • Cross-system functionality

10. Performance Testing:

    • Load testing
    • Stress testing
    • Capacity validation

11. End-to-End Testing:

    • Complete business process flows
    • Multi-system transactions
    • Data integrity across systems

12. Penetration Testing:

    • External and internal networks
    • Web and mobile applications
    • APIs and interfaces

Testing Frequency:

• Minimum: Annual testing
• Risk-based: More frequent for critical systems
• Triggered: After significant changes, major incidents

Testing Documentation:

• Testing policy and procedures
• Test plans
• Test results and reports
• Remediation tracking
• Evidence of fixes validated

Advanced Testing - TLPT (Articles 26-27)

Threat-Led Penetration Testing (TLPT):

• Sophisticated, intelligence-led red team testing
• Simulates real-world attacks by threat actors
• Based on TIBER-EU framework or equivalent

Applicability:

• Mandatory for significant financial entities
• At least every 3 years
• May be required more frequently based on risk

TIBER-EU Framework:

• Threat Intelligence-Based Ethical Red Teaming
• Developed by European Central Bank (ECB)
• Harmonized approach across EU
• Adopted as DORA standard

TLPT Phases:

Phase 1: Preparation

• Scoping of critical functions and systems
• Threat intelligence gathering
• Scenario development based on real threat actors
• Red team selection (must be external)
• Rules of engagement
• Stakeholder preparation

Phase 2: Testing

• Red team executes attack scenarios
• Uses realistic tactics, techniques, procedures (TTPs)
• Blue team (internal) defends and responds
• White team (coordination) oversees
• Real-time monitoring and safety controls
• No actual harm to production (controlled environment)

Phase 3: Closure

• Debriefing and knowledge sharing
• Red team report with findings
• Blue team response analysis
• Remediation plan development
• Lessons learned
• Regulatory reporting to NCA

TLPT Roles:

• Red Team: External, independent attackers

  • Simulate real adversaries
  • Use threat intelligence-based TTPs
  • Test people, processes, technology
  • Document techniques and findings

• Blue Team: Internal defenders (unaware of timing)

  • Security operations center (SOC)
  • Incident response team
  • Operate as usual, detect and respond
  • Validate defensive capabilities

• White Team: Coordination and oversight

  • Internal staff managing process
  • Ensure rules of engagement followed
  • Monitor for unintended impacts
  • Coordinate between red and blue
  • Document process

• Purple Team: Collaborative learning (post-test)

  • Red and blue team collaboration
  • Share techniques and defenses
  • Identify gaps and improvements

TLPT Scope:

• Critical functions and services (per BIA)
• Crown jewel systems and data
• Key dependencies and integrations
• Third-party connections (if material)

Remediation:

• Address critical findings within 30 days
• High findings within 90 days
• Track and validate remediation
• Report to management and board
• NCA notification if required

Inherited TLPT:

• May leverage cloud provider's TLPT results
• If critical services fully outsourced
• Must verify applicability to entity's use
• Document reliance and scope

Pillar 4: ICT Third-Party Risk Management (Articles 28-30)

Objective: Manage risks from ICT service providers, especially critical providers

ICT Third-Party Risk (Article 28)

Third-Party Register:

• Mandatory register of all ICT third-party service providers
• Updated at least annually
• Submitted to NCA upon request

Register Contents:

• Provider name and contact information
• Description of services provided
• Countries where services are provided
• Data and functions supported
• Contract start and end dates
• Classification (critical vs. non-critical)

Risk Management Process:

1. Pre-Contracting:

   • Due diligence on provider
   • Security assessment questionnaires
   • On-site visits for critical providers
   • Financial stability review
   • Concentration risk assessment

2. Contracting:

   • Ensure DORA-mandated contract clauses
   • Negotiate service levels (SLAs)
   • Define audit and access rights
   • Establish exit strategies
   • Subcontracting controls

3. Ongoing Monitoring:

   • Regular performance monitoring
   • Annual security reviews
   • Audit rights exercised
   • Incident tracking from provider
   • Contract compliance reviews

4. Exit Planning:

   • Exit strategies for all critical providers
   • Transition plans documented
   • Data portability procedures
   • Service continuity during transition
   • Alternative provider identified

Concentration Risk:

• Assess dependence on single or few providers
• Identify single points of failure
• Consider systemic risk (e.g., cloud provider used by many entities)
• Mitigation strategies (multi-cloud, hybrid, exit readiness)

Key Contractual Provisions (Article 30)

Mandatory Contract Clauses:

1. Service Levels and Objectives:

   • Clear SLAs with measurable metrics
   • Availability targets
   • Performance standards
   • Response times for incidents

2. Data Location and Processing:

   • Specify data storage locations (country, region)
   • Specify data processing locations
   • Prohibition on relocation without permission
   • Compliance with data protection laws (GDPR)

3. Access and Audit Rights:

   • Financial entity has access to data, systems, premises
   • Competent authorities have access for inspections
   • Auditors appointed by financial entity or NCA have access
   • Reasonable prior notice (except emergencies)
   • No cost to financial entity for regulatory access

4. Security Requirements:

   • Minimum security controls specified
   • Encryption standards
   • Access control requirements
   • Logging and monitoring
   • Incident notification obligations (immediate for major incidents)
   • Data breach notification (align with GDPR)

5. Termination Rights:

   • Financial entity can terminate for cause (security breach, SLA failure, regulatory requirement)
   • Notice periods specified
   • No lock-in that prevents termination
   • Survival clauses for data return/deletion

6. Subcontracting:

   • Prior written consent required for subcontracting
   • Flow-down of DORA provisions to subcontractors
   • Visibility into subcontracting chain
   • Liability remains with primary provider

7. Exit and Transition:

   • Provider assistance during transition
   • Knowledge transfer
   • Data return in usable format
   • Data deletion certification
   • Service continuity until transition complete

8. Liability and Insurance:

   • Liability caps reasonable and not overly limiting
   • Indemnification for security failures
   • Professional indemnity insurance
   • Cyber insurance coverage

9. Regulatory Compliance:

   • Provider acknowledgment of DORA applicability
   • Cooperation with NCAs
   • Provision of information for regulatory reporting
   • Notification of material changes

10. Governing Law and Jurisdiction:

    • EU member state law preferred
    • Dispute resolution mechanisms
    • Jurisdiction for enforcement

Contract Review and Renegotiation:

• All existing contracts must be updated to include DORA provisions
• Deadline: Typically within 12-24 months of DORA effective date (check regulatory technical standards for specifics)
• Priority: Critical providers first
• Document efforts to renegotiate; if provider refuses, assess alternatives

Critical ICT Third-Party Service Providers

Designation Process:

• Designated by European Supervisory Authorities (ESAs)
• Based on systemic importance criteria:
  • Number of financial entities served
  • Criticality of services provided
  • Degree of substitutability (availability of alternatives)
  • Interconnectedness with financial system

Examples of Likely Critical Providers:

• Major cloud service providers (AWS, Azure, Google Cloud)
• Core banking system vendors
• Payment processing platforms
• Critical data center operators
• Widely-used cybersecurity tool providers

Oversight Framework:

• Lead Overseer: One ESA designated as lead
• Oversight Responsibilities:
  • On-site and remote inspections
  • Request for information and documentation
  • General investigations
  • Recommendations for remediation
  • Enforcement actions (fines, restrictions)

Critical Provider Obligations:

• Register with lead overseer
• Provide information upon request
• Submit to inspections and audits
• Implement recommendations from overseers
• Maintain business continuity and disaster recovery
• Report major incidents affecting financial entities
• Cooperate with oversight activities

Financial Entity Benefit:

• Reduced due diligence burden (ESA oversight provides assurance)
• Access to oversight reports (where permitted)
• Collective bargaining power through regulatory oversight
• Early warning of critical provider issues

Pillar 5: Information Sharing Arrangements (Article 45)

Objective: Enhance collective resilience through threat intelligence sharing

Information Sharing Frameworks

Participation:

• Financial entities encouraged to join information-sharing communities
• Voluntary participation
• No penalties for sharing in good faith

Types of Information Shared:

• Cyber Threat Intelligence:

  • Indicators of Compromise (IOCs): IPs, domains, file hashes
  • Tactics, Techniques, Procedures (TTPs) of threat actors
  • Malware analysis
  • Vulnerability disclosures

• Incident Information:

  • Anonymized incident details
  • Attack patterns and trends
  • Lessons learned from incidents
  • Effective mitigations

• Defensive Measures:

  • Security configurations
  • Detection rules
  • Response playbooks
  • Best practices

Confidentiality and Liability Protection:

• Information shared in good faith is protected
• No liability for sharing threat intelligence
• Confidentiality of shared information maintained
• Antitrust safe harbor for security collaboration
• Exceptions: Law enforcement requests, court orders

Information Sharing Platforms

EU-Level Platforms:

1. Financial Services Information Sharing and Analysis Centre (FS-ISAC):

   • Global platform with strong EU presence
   • Real-time threat intelligence
   • Member-only sharing
   • Anonymous and attributed sharing options

2. ENISA Threat Intelligence Platform:

   • EU Agency for Cybersecurity
   • Sector-agnostic threat intelligence
   • Open-source intelligence
   • Policy and guidance

3. ESA-Coordinated Sharing:

   • Incident data from centralized hub (Article 21)
   • Aggregated and anonymized
   • Sector-wide trends
   • Early warning of systemic risks

National-Level Platforms:

1. National CERTs/CSIRTs:

   • Computer Emergency Response Teams
   • Incident response coordination
   • National threat landscape
   • Vulnerability alerts

2. Financial Sector ISACs:

   • Country-specific financial sector sharing
   • Regulatory coordination
   • Trusted peer networks

3. NCA-Facilitated Forums:

   • National competent authority roundtables
   • Public-private partnerships
   • Best practice sharing

Implementing Information Sharing

Steps to Participate:

1. Join Sharing Communities:

   • Identify relevant platforms (FS-ISAC, national ISACs)
   • Complete membership process
   • Designate sharing contacts
   • Establish legal agreements (NDAs, terms of use)

2. Establish Internal Processes:

   • Define what information can be shared
   • Approval processes for sharing
   • Sanitization of sensitive data
   • Receiving and acting on intelligence

3. Integrate Intelligence:

   • Ingest threat feeds into SIEM
   • Update firewall/IPS rules with IOCs
   • Share intelligence with SOC
   • Validate intelligence relevance

4. Contribute Intelligence:

   • Share incidents (anonymized if preferred)
   • Contribute IOCs from investigations
   • Share effective mitigations
   • Participate in working groups

Benefits:

• Early warning of threats targeting financial sector
• Collective defense against common adversaries
• Reduced time to detect and respond
• Learning from peers' incidents
• Enhanced situational awareness

Challenges:

• Legal and confidentiality concerns (addressed by DORA protections)
• Resource constraints (automated feeds help)
• Competitive sensitivity (anonymization helps)
• Information overload (curation and prioritization needed)

Compliance Timeline and Roadmap

Pre-Effective Date (Before January 17, 2025)

Months 1-3: Gap Assessment and Planning

• Conduct comprehensive DORA gap assessment
• Map current state to 5 pillars
• Identify critical gaps
• Develop remediation roadmap
• Secure executive commitment and budget

Months 4-6: Governance and Policy

• Establish ICT risk management framework
• Draft/update policies (ICT risk, incident response, third-party risk, testing)
• Board approval of framework and policies
• Identify board member with ICT knowledge (train or recruit)
• Define roles and responsibilities

Months 7-9: ICT Risk Management Implementation

• Complete ICT asset inventory
• Conduct business impact analysis (BIA)
• Create dependency maps and data flow diagrams
• Implement/enhance technical controls (MFA, encryption, monitoring)
• Deploy SIEM or enhance existing
• Establish 24/7 monitoring (for significant entities)

Months 10-12: Incident Management and Third-Party Risk

• Define major incident classification criteria
• Implement incident management system
• Develop incident response playbooks
• Create complete ICT third-party register
• Classify providers (critical vs. non-critical)
• Begin contract renegotiations (DORA clauses)

Months 13-15: Testing Program

• Develop digital resilience testing policy
• Conduct initial vulnerability assessments
• Perform gap analysis against DORA
• Execute scenario-based tests (tabletop exercises)
• Plan TLPT (for significant entities)

Months 16-18: Final Preparation

• Complete critical third-party contract updates
• Finalize incident reporting procedures
• Conduct dry run of major incident reporting
• Join information-sharing communities (FS-ISAC)
• Complete staff training on DORA requirements
• Board briefing on DORA readiness

Post-Effective Date (After January 17, 2025)

Ongoing Compliance:

• Continuous: ICT risk monitoring and reporting
• Immediate: Major incident reporting (4 hours, 72 hours, 1 month)
• Annual:
  • General resilience testing
  • Third-party register update
  • ICT risk framework review
  • Board reporting
  • NCA submission (if required)
• Every 3 Years: TLPT (for significant entities)
• As Needed: Contract updates, policy updates, control enhancements

Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS)

ESAs Developing Standards:

• European Banking Authority (EBA)
• European Securities and Markets Authority (ESMA)
• European Insurance and Occupational Pensions Authority (EIOPA)

RTS/ITS Topics (to be finalized):

1. ICT Risk Management Framework (Article 16):

   • Detailed requirements for framework
   • Governance standards
   • Control specifications

2. Major Incident Reporting (Article 19):

   • Reporting templates and formats
   • Classification thresholds
   • Reporting channels

3. Harmonization of Incident Conditions (Article 18):

   • Materiality thresholds for major incidents
   • Consistent classification across member states

4. Oversight of Critical Providers (Articles 31-39):

   • Designation criteria
   • Oversight procedures
   • Enforcement mechanisms

5. Testing (Article 25):

   • Testing methodologies
   • TLPT standards (building on TIBER-EU)
   • Testing frequency and scope

Timeline:

• Most RTS/ITS expected by mid-2024 to late 2024
• Allow financial entities time to implement before Jan 2025

Monitoring:

• Watch ESA websites for consultations and final standards
• Participate in industry consultations
• Update compliance programs as standards finalized

Penalties and Enforcement

Administrative Fines

Maximum Penalties (Article 50):

• Serious breaches: Up to 1% of annual turnover
• Repeated breaches: Up to 2% of annual turnover

Breach Examples:

• Failure to report major incident
• Inadequate ICT risk management framework
• Non-compliance with testing requirements
• Lack of third-party oversight
• Failure to implement NCAs recommendations

Aggravating Factors:

• Duration of breach
• Intentional vs. negligent
• Previous violations
• Cooperation with authorities
• Impact on financial stability

Mitigating Factors:

• Self-reporting
• Prompt remediation
• Cooperation with investigation
• Good faith efforts to comply

Other Enforcement Actions

• Warnings and reprimands
• Orders to cease practices
• Temporary prohibition of activities
• Public disclosure of violations
• Increased reporting requirements
• Enhanced supervision

Reputational Impact

• Public announcement of penalties
• Loss of customer confidence
• Competitive disadvantage
• Potential loss of business (due to non-compliance)
• Board and executive accountability

Key Success Factors for DORA Compliance

1. Executive and Board Commitment:

   • C-suite and board understanding of DORA requirements
   • Allocation of sufficient budget and resources
   • Board-level ownership of digital resilience strategy

2. Cross-Functional Collaboration:

   • IT, security, risk, compliance, legal, business units
   • Clear governance structure
   • Regular communication and coordination

3. Comprehensive ICT Risk Framework:

   • Board-approved and regularly updated
   • Risk-based approach
   • Proportionate to entity size and complexity
   • Embedded in organization culture

4. Robust Incident Response:

   • Capability to detect major incidents quickly
   • Clear classification criteria
   • Ability to meet reporting deadlines (4h, 72h, 1 month)
   • Tested and effective response procedures

5. Third-Party Risk Management:

   • Complete and current register
   • DORA-compliant contracts
   • Ongoing monitoring and audits
   • Exit strategies for critical providers

6. Regular Testing:

   • Risk-based testing program
   • TLPT for significant entities
   • Remediation tracking
   • Continuous improvement

7. Information Sharing:

   • Active participation in sharing communities
   • Integration of threat intelligence
   • Contribution to collective defense

8. Documentation:

   • Comprehensive policies and procedures
   • Evidence of implementation
   • Audit trail for compliance
   • Readiness for NCA inspections

9. Training and Awareness:

   • All staff aware of DORA requirements
   • Role-specific training
   • Board training on ICT risks
   • Regular refresher training

10. Continuous Monitoring and Improvement:

    • Ongoing compliance monitoring
    • Lessons learned from incidents and tests
    • Adaptation to evolving threats
    • Regulatory changes incorporated

Common Pitfalls and How to Avoid Them

Pitfall 1: Underestimating Complexity

Problem: Viewing DORA as just another compliance exercise Solution: Treat DORA as strategic transformation, not checklist compliance

Pitfall 2: Insufficient Budget/Resources

Problem: Underfunding DORA implementation Solution: Conduct thorough cost assessment, build business case, secure executive commitment

Pitfall 3: Lack of Board Engagement

Problem: Board treats DORA as IT issue Solution: Board training, regular reporting, frame as business resilience (not just IT)

Pitfall 4: Incomplete Third-Party Register

Problem: Missing or inaccurate register of ICT providers Solution: Comprehensive discovery process, procurement coordination, regular updates

Pitfall 5: Contract Renegotiation Delays

Problem: Providers slow to agree to DORA clauses Solution: Start early, prioritize critical providers, consider alternatives if provider refuses

Pitfall 6: Inadequate Incident Classification

Problem: Misclassifying incidents (major vs. non-major) Solution: Clear, documented criteria; risk/compliance involvement; err on side of reporting

Pitfall 7: Unrealistic Testing Scope

Problem: Testing program too limited or too ambitious Solution: Risk-based prioritization, phased approach, leverage external expertise

Pitfall 8: Siloed Implementation

Problem: IT/security implementing DORA without business involvement Solution: Cross-functional steering committee, business unit engagement, shared ownership

Pitfall 9: Documentation Gaps

Problem: Controls implemented but not documented Solution: Documentation discipline, centralized repository, regular reviews

Pitfall 10: "Set and Forget" Mentality

Problem: Treating DORA as one-time project Solution: Continuous monitoring, regular updates, embed in BAU processes

DORA and Related Regulations

Interaction with Other EU Regulations

GDPR (General Data Protection Regulation):

• DORA complements GDPR
• GDPR: Data protection and privacy
• DORA: Digital operational resilience
• Overlap: Data breach notification, security controls
• Coordination: DORA incident reporting does not replace GDPR breach notification (both may apply)

NIS2 Directive (Network and Information Security Directive):

• NIS2 applies to broader set of entities (including some financial)
• DORA is lex specialis for financial sector (takes precedence)
• Financial entities under DORA not subject to NIS2
• Similar requirements: Risk management, incident reporting, supply chain security

MiCA (Markets in Crypto-Assets Regulation):

• MiCA regulates crypto-asset service providers (CASPs)
• DORA applies to CASPs
• MiCA has specific requirements for CASPs; DORA adds operational resilience layer

EMIR/SFTR (Derivatives and Securities Financing Transactions):

• DORA complements with operational resilience requirements
• CCPs, trade repositories subject to both EMIR and DORA

Alignment with International Standards

ISO 27001: Information security management

• DORA aligns with ISO 27001 principles
• ISO certification helpful but not sufficient for DORA compliance

NIST Cybersecurity Framework:

• DORA's risk management framework similar to NIST CSF
• Identify, Protect, Detect, Respond, Recover

TIBER-EU:

• DORA explicitly adopts TIBER-EU for TLPT
• Harmonized threat-led testing across EU

SWIFT Customer Security Programme (CSP):

• Banks using SWIFT also subject to CSP
• DORA and SWIFT CSP complementary
• Some overlap in controls (reduce duplication)

Resources and References

Official DORA Regulation:

• Regulation (EU) 2022/2554 (OJ L 333, 27.12.2022)

European Supervisory Authorities:

• European Banking Authority (EBA): eba.europa.eu
• European Securities and Markets Authority (ESMA): esma.europa.eu
• European Insurance and Occupational Pensions Authority (EIOPA): eiopa.europa.eu

European Central Bank:

• TIBER-EU Framework: ecb.europa.eu

National Competent Authorities:

• Varies by member state (e.g., Bundesbank, Banque de France, Bank of Italy)

Industry Associations:

• European Banking Federation (EBF)
• Insurance Europe
• AFME (Association for Financial Markets in Europe)

Threat Intelligence and Information Sharing:

• FS-ISAC (Financial Services Information Sharing and Analysis Center): fsisac.com
• ENISA (EU Agency for Cybersecurity): enisa.europa.eu

Standards and Frameworks:

• ISO 27001:2013 Information Security Management
• NIST Cybersecurity Framework
• TIBER-EU

Capabilities

• DORA compliance assessment and gap analysis
• ICT risk management framework design and implementation
• Major incident classification and reporting procedures
• Incident response plan development and testing
• Digital operational resilience testing program design
• TLPT (threat-led penetration testing) planning and execution support
• Third-party ICT risk management and oversight
• Contract review and DORA cl

…(truncated)