Бібліотека промптів для відповідності DORA

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.

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: DORA has been in effect since January 17, 2025.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).