DORA compliance prompt library
About this prompt library
This prompt library helps financial entities comply with the Digital Operational Resilience Act (DORA), the EU regulation establishing comprehensive ICT risk management requirements for the financial sector. Use these prompts with ISMS Copilot to generate DORA-compliant frameworks, policies, and documentation.
DORA applies to credit institutions, payment institutions, investment firms, crypto-asset service providers, insurance undertakings, and critical ICT third-party service providers. Ensure DORA applies to your organization before implementing these prompts.
How to use these prompts
Replace [bracketed placeholders] with your organization's specifics. Start with scoping and assessment prompts, then move to policy development and implementation. Upload existing risk assessments or ICT policies for context-aware outputs.
DORA compliance assessment
DORA applicability and scope assessment
Assess DORA applicability to our organization:
Organization type: [credit institution/payment firm/investment firm/crypto-asset service provider/insurance undertaking/ICT third-party provider]
EU presence: [EU-established/branch in EU/providing services to EU financial entities]
Activities: [describe financial services provided]
Determine:
- Which DORA chapters apply to us (ICT risk management, incident reporting, resilience testing, third-party risk, information sharing)
- Whether we qualify as critical ICT third-party provider
- Proportionality considerations (small, non-interconnected firm provisions)
- Key compliance deadlines and phase-in timelines
Provide a DORA scope statement and compliance roadmap. Gap analysis against DORA pillars
Conduct a gap analysis of our current ICT risk management against DORA's five pillars:
Current state:
- ICT risk management: [describe current practices]
- Incident management: [current incident response and reporting]
- Resilience testing: [current testing activities]
- Third-party risk: [vendor management practices]
- Information sharing: [participation in threat intelligence]
For each DORA pillar, provide:
- Key regulatory requirements
- Our current compliance level (Compliant/Partial/Non-compliant)
- Specific gaps and missing controls
- Risk rating (Critical/High/Medium/Low)
- Remediation recommendations
- Estimated effort and timeline to compliance
Prioritize by deadline: January 2025 is the main compliance date. ICT risk management framework (Chapter II)
ICT risk management policy
Create a comprehensive ICT Risk Management Policy aligned with DORA Article 6:
Organization: [name and type]
ICT environment: [systems, infrastructure, critical services]
Policy sections:
- Governance structure (roles of management body, CIO/CISO, risk functions)
- ICT risk identification, classification, and assessment
- Protection and prevention measures
- Detection capabilities and monitoring
- Response and recovery procedures
- Learning and evolving (lessons learned, continuous improvement)
- Communication and reporting (to management body, supervisory authority)
- Integration with overall risk management
- Proportionality and risk-based approach
Ensure alignment with DORA Articles 5-16 and supervisory expectations. ICT asset inventory and classification
Develop an ICT asset inventory and classification scheme per DORA Article 8:
Our ICT landscape:
- Applications: [list business-critical applications]
- Infrastructure: [data centers, cloud services, networks]
- Data repositories: [databases, data warehouses]
- Third-party services: [critical ICT providers]
For each asset category, provide:
- Inventory template (asset ID, description, owner, location)
- Classification criteria (criticality, confidentiality, availability requirements)
- Interdependencies and connections
- Business impact if unavailable
- Recovery time objectives (RTO)
- Supporting documentation requirements
Create a register template suitable for ongoing maintenance and supervisory review. Business continuity and disaster recovery
Create ICT business continuity and disaster recovery plans meeting DORA Article 11:
Critical functions: [list regulated/critical business functions]
Dependencies: [ICT systems supporting each function]
Risk scenarios: [cyber attacks, system failures, provider outages]
For each critical function, develop:
- Impact analysis (RTO, RPO, criticality)
- Recovery strategies (failover, backup systems, manual workarounds)
- Activation criteria and decision-making
- Communication plan (internal, customers, authorities)
- Testing requirements (frequency, scope, scenarios)
- Plan maintenance and update procedures
Address DORA-specific requirements: severe ICT-related incidents, third-party provider failures, business continuity policy review by management body. DORA requires management body approval and annual review of ICT risk management framework. Ensure governance and oversight are documented throughout your policies and plans.
ICT-related incident management (Chapter III)
Incident classification and reporting procedure
Develop an ICT incident classification and reporting procedure per DORA Articles 17-20:
Incident categories we may face:
- Cyber attacks: [ransomware, DDoS, data breaches]
- System outages: [application failures, infrastructure downtime]
- Data integrity issues: [data corruption, unauthorized changes]
- Third-party failures: [critical provider outages]
Create:
- Incident classification scheme (major incidents requiring supervisory notification)
- Materiality thresholds aligned with RTS (clients affected, duration, data impact, reputational damage, financial losses)
- Initial notification timeline (4 hours for major incidents in some jurisdictions)
- Intermediate and final report timelines
- Root cause analysis requirements
- Integration with existing incident response (CSIRT, SOC)
Template notification reports for competent authorities using prescribed formats. Incident response and recovery procedures
Create ICT incident response procedures aligned with DORA Article 17:
Response team structure:
- Incident commander: [role]
- Technical team: [security, operations, applications]
- Communications: [internal, external, regulatory]
- Legal and compliance: [DPO, legal counsel, compliance]
Procedure elements:
- Detection and alerting mechanisms
- Initial assessment and classification
- Containment and eradication steps
- Recovery and restoration
- Evidence preservation (forensics)
- Communication protocols (supervisory authority, clients, media)
- Post-incident review and lessons learned
- Integration with GDPR breach notification (if applicable)
Address DORA-specific elements: voluntary incident reporting to CSIRT network, cross-border cooperation with other authorities. Digital operational resilience testing (Chapter IV)
Resilience testing program
Design a digital operational resilience testing program per DORA Articles 24-26:
Our risk profile:
- Organization type: [if significant/critical financial entity]
- ICT complexity: [systems, outsourcing level]
- Threat landscape: [relevant cyber threats]
Testing program components:
1. Basic testing (all entities):
- Vulnerability assessments: [frequency, scope, tools]
- Open source analysis: [threat intelligence, vulnerability databases]
- Network security assessments: [external/internal penetration testing]
- Gap analyses: [control assessments]
- Physical security reviews: [data centers, offices]
- Questionnaires and scanning: [security posture reviews]
- Source code review: [critical applications]
- Scenario-based testing: [business continuity, disaster recovery]
- Compatibility testing: [software upgrades, patches]
- Performance testing: [capacity, stress testing]
2. Advanced testing (for significant entities):
- Threat-Led Penetration Testing (TLPT): Red team exercises simulating real attacks
- TLPT scope, frequency (every 3 years), and methodology
- Use of TIBER-EU or equivalent framework
- Internal vs. external testers
- White team coordination and safeguards
Create testing schedule, scope definitions, and deliverable requirements. Smaller, non-interconnected firms benefit from proportionality provisions. Tailor your testing program to your size, risk profile, and complexity rather than implementing all elements.
Third-party ICT risk management (Chapter V)
ICT third-party risk management framework
Create an ICT third-party risk management framework per DORA Articles 28-30:
Our third-party landscape:
- Critical ICT providers: [cloud, data centers, payment processors, software vendors]
- Supporting providers: [less critical services]
- Contractual arrangements: [describe current contracts]
Framework elements:
1. Third-party risk strategy (Article 28):
- Risk assessment criteria and methodology
- Due diligence requirements (pre-contract, ongoing)
- Concentration risk management (over-reliance on single providers)
- Subcontracting and fourth-party risk
- Exit strategies and transition planning
2. Key contractual provisions (Article 30):
- Service level agreements (availability, performance)
- Access, audit, and inspection rights
- Data security and location requirements
- Incident notification obligations
- Termination rights and assistance
- Subcontracting restrictions and notifications
3. Register of information (Article 28):
- Inventory of ICT third-party arrangements
- Criticality classification (critical/important vs. supporting)
- Data processed and locations
- Contractual terms summary
- Risk ratings and controls
Ensure compliance with EBA/ESMA/EIOPA guidelines on outsourcing. Critical ICT third-party provider assessment
Assess whether our ICT service providers qualify as "critical" under DORA and implications:
Our key providers:
[List major ICT providers and services they deliver]
For each provider, analyze:
- Criticality to our operations (essential function, systemic importance)
- Substitutability (availability of alternatives, switching costs)
- Number of financial entities they serve
- Whether they meet critical third-party provider thresholds
If provider is designated as critical:
- Additional oversight by Lead Overseer
- Required cooperation with oversight activities
- Enhanced contractual provisions
- Incident reporting obligations
- Resilience and testing requirements
Develop strategy for managing critical provider relationships under enhanced oversight regime. Information sharing (Chapter V)
Cyber threat information sharing participation
Establish participation in information sharing arrangements per DORA Article 45:
Information sharing opportunities:
- Financial sector ISACs (Information Sharing and Analysis Centers)
- National cybersecurity authorities and CSIRTs
- Industry peer groups
- Threat intelligence platforms
Participation framework:
- Information types to share (threat indicators, vulnerabilities, incidents, defensive measures)
- Information types to receive (threat intelligence, attack patterns, mitigation advice)
- Confidentiality and anonymization requirements
- Legal protections for sharing (GDPR compliance, liability protections)
- Operational procedures (how to share, with whom, when)
- Internal approval processes
- Feedback loops and lessons learned
Address DORA provisions: voluntary participation, liability protections, confidentiality, GDPR exemptions for cybersecurity purposes. Governance and accountability
Management body ICT risk oversight
Define management body responsibilities for ICT risk per DORA Article 5:
Our governance structure:
- Management body composition: [board of directors, executive committee]
- ICT risk function: [CIO, CISO, IT risk team]
- Reporting lines: [how ICT risk reaches management body]
Management body responsibilities:
- Approval of ICT risk management framework
- Approval of digital operational resilience strategy
- Oversight of ICT risk exposure and risk appetite
- Allocation of resources and budget for ICT risk
- Approval of ICT business continuity and disaster recovery plans
- Review of resilience testing results and findings
- Oversight of third-party ICT risk
- Approval of major ICT changes and projects
Create:
- Terms of reference for ICT risk oversight (board committee or full board)
- Reporting templates (ICT risk dashboard, incident summaries, testing results)
- Meeting frequency and agenda items
- Training requirements for non-executive directors on ICT risk
Ensure management body understanding and active oversight, not just rubber-stamping. DORA compliance documentation and evidence
Develop comprehensive DORA compliance documentation for supervisory review:
Documentation requirements across DORA chapters:
Chapter II (ICT risk management):
- ICT risk management framework and policy
- ICT asset inventory and classification
- Business impact analyses
- ICT business continuity and disaster recovery plans
- Backup and restoration procedures
- Change management procedures
- Patch management procedures
Chapter III (Incident management):
- Incident response procedures
- Incident classification methodology
- Incident register and notification records
- Root cause analyses and lessons learned
Chapter IV (Testing):
- Resilience testing program and schedule
- Testing results and findings
- Remediation plans and evidence
- TLPT reports (if applicable)
Chapter V (Third-party risk):
- Third-party risk management policy
- Register of ICT third-party arrangements
- Due diligence assessments
- Contracts with key provisions
- Exit plans
Governance:
- Management body minutes (ICT risk discussions and approvals)
- ICT risk reporting to management body
- Training records for management body
Create a DORA compliance repository structure and evidence collection plan for ongoing supervisory inspections. DORA emphasizes continuous resilience, not point-in-time compliance. Build ongoing monitoring, testing, and improvement into your framework from day one.
DORA compliance best practices
Integration with existing frameworks
Map DORA requirements to our existing compliance frameworks to avoid duplication:
Existing frameworks:
- ISO 27001: [if certified or implementing]
- NIS2: [if in scope as essential/important entity]
- GDPR: [data protection and breach notification]
- SOC 2: [if providing services to US customers]
- PCI DSS: [if processing card data]
For each DORA requirement, identify:
- Overlaps with existing controls
- Gaps requiring new controls
- Opportunities for integrated compliance (e.g., unified testing program)
- Conflicting requirements requiring reconciliation
- Shared evidence and documentation
Create an integrated compliance framework leveraging existing investments while meeting DORA-specific requirements (e.g., management body oversight, incident reporting timelines, TLPT). DORA builds on existing standards like ISO 27001 but adds financial sector-specific requirements. Use existing frameworks as a foundation and layer DORA-specific elements on top.