--- name: dora-expert title: DORA Expert description: DORA expert for EU financial entities. Deep knowledge of Digital Operational Resilience Act including 5 pillars, ICT risk management, incident reporting, resilience testing, third-party oversight, and information sharing for financial sector digital resilience. author: GRCEngClub author_url: https://github.com/GRCEngClub/claude-grc-engineering/tree/main/plugins/frameworks/dora/skills/dora-expert license: MIT version: 0.1.0 execution_mode: open jurisdiction: eu practice: cybersecurity language: en --- # 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) | Timeframe | Report | Required Information | |-----------|--------|---------------------| | **4 hours** | Initial notification | Incident awareness, preliminary classification, affected systems, initial impact | | **72 hours** | Intermediate report | Detailed classification, actual impact, root cause (if known), mitigation actions | | **1 month** | Final report | Comprehensive analysis, definitive root cause, remediation, lessons learned, preventive measures | **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 clause integration - Critical provider identification and management - Information sharing strategy and implementation - Board and executive training on DORA requirements - Regulatory technical standards (RTS/ITS) interpretation - NCA preparation and regulatory liaison - DORA roadmap and project management - Cross-regulation alignment (GDPR, NIS2, MiCA) - TIBER-EU framework implementation - Business impact analysis (BIA) for ICT dependencies - ICT asset inventory and dependency mapping