/testing-plan

description: Digital operational resilience testing requirements and planning under DORA

DORA Resilience Testing

Comprehensive guidance on DORA's digital operational resilience testing requirements, including advanced threat-led penetration testing (TLPT).

Arguments

• `$1` - Testing type (required: general, advanced-tlpt, vulnerability, scenario, all)
• `$2` - Entity profile (optional: significant, non-significant)

Testing Framework Overview

**Legal Basis**: Articles 24-27 of DORA **Purpose**: Ensure systems can withstand, respond to, and recover from ICT-related disruptions **Principle**: Risk-based and proportionate approach **Frequency**: Regular basis with minimum annual testing

Testing Requirements by Entity Type

Significant Financial Entities

**Characteristics**:

• Systemically important
• Large market share
• Critical infrastructure provider
• Interconnected with financial system

**Testing Requirements**:

• **All general testing** (Article 24)
• **Advanced testing (TLPT)** at least every 3 years (Article 26)
• More rigorous scope and frequency
• External validation required
• TLPT based on TIBER-EU or equivalent

Non-Significant Financial Entities

**Characteristics**:

• Smaller market footprint
• Limited systemic importance
• Less complex operations

**Testing Requirements**:

• **General testing** (Article 24) required
• **TLPT optional** (but recommended)
• Proportionate scope based on risk profile
• May use simplified methodologies
• Internal testing acceptable with oversight

General Testing Requirements (Article 24)

Mandatory Testing Types

1. Vulnerability Assessments and Scans

**Purpose**: Identify security weaknesses in systems and applications

**Scope**:

• Network infrastructure
• Operating systems
• Applications and databases
• Cloud environments
• APIs and interfaces

**Frequency**:

• Quarterly for critical systems
• At least annually for all systems
• After significant changes

**Tools**:

• Automated vulnerability scanners (Nessus, Qualys, Rapid7)
• Manual testing for complex systems
• Authenticated scans for deeper analysis

**Deliverables**:

• Vulnerability scan reports
• Risk-rated findings (Critical, High, Medium, Low)
• Remediation recommendations
• Tracking of fixes

2. Open-Source Analysis

**Purpose**: Identify vulnerabilities in open-source components

**Activities**:

• Software composition analysis (SCA)
• Identification of known vulnerabilities (CVEs)
• License compliance review
• Dependency analysis

**Tools**:

• OWASP Dependency Check
• Snyk
• Black Duck
• WhiteSource

**Output**:

• Inventory of open-source components
• Known vulnerabilities identified
• Remediation plan for outdated/vulnerable components

3. Network Security Assessments

**Purpose**: Evaluate security of network infrastructure

**Testing Areas**:

• Firewall configurations
• Network segmentation
• Intrusion detection/prevention systems
• VPN security
• Wireless network security
• Router and switch configurations

**Methods**:

• Configuration reviews
• Traffic analysis
• Port scanning
• Packet inspection

**Deliverables**:

• Network security assessment report
• Configuration weaknesses
• Segmentation gaps
• Remediation roadmap

4. Gap Analyses

**Purpose**: Compare current state against desired security baseline

**Frameworks**:

• DORA requirements
• ISO 27001
• NIST Cybersecurity Framework
• Industry best practices

**Process**:

• Document current controls
• Map to framework requirements
• Identify gaps
• Prioritize remediation

**Output**:

• Gap analysis report
• Control maturity assessment
• Remediation priorities
• Investment roadmap

5. Physical Security Reviews

**Purpose**: Assess physical security of facilities and assets

**Scope**:

• Data center access controls
• Office premises security
• Equipment security
• Visitor management
• Environmental controls (fire, flood, HVAC)

**Activities**:

• Physical walkthroughs
• Access control testing
• Surveillance review
• Incident log review

**Findings**:

• Physical vulnerabilities
• Access control gaps
• Environmental risks
• Improvement recommendations

6. Questionnaires and Scanning Software Solutions

**Purpose**: Self-assessment and automated security checks

**Types**:

• Security control questionnaires
• Configuration scanning tools
• Compliance checklists
• Third-party risk questionnaires

**Examples**:

• CAIQ (Consensus Assessments Initiative Questionnaire)
• SIG (Standardized Information Gathering)
• Internal control self-assessments
• Vendor security assessments

7. Source Code Reviews

**Purpose**: Identify security flaws in application code

**Scope** (where feasible):

• Custom-developed applications
• Critical business applications
• Applications handling sensitive data
• APIs and integrations

**Methods**:

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

**Tools**:

• SonarQube
• Checkmarx
• Veracode
• Fortify

**Findings**:

• Code vulnerabilities (SQL injection, XSS, etc.)
• Insecure coding practices
• Hardcoded secrets
• Remediation guidance

8. Scenario-Based Testing

**Purpose**: Test response to specific incident scenarios

**Scenarios**:

• Ransomware attack
• DDoS (Distributed Denial of Service) attack
• Data breach
• Insider threat
• System failure
• Third-party provider outage

**Methods**:

• Tabletop exercises
• Simulations
• War games
• Crisis management drills

**Participants**:

• IT and security teams
• Business continuity team
• Crisis management team
• Senior management
• Communications team

**Outputs**:

• Scenario test report
• Response effectiveness assessment
• Communication gaps identified
• Plan improvements

9. Compatibility Testing

**Purpose**: Ensure systems interoperate correctly and securely

**Testing Areas**:

• System integrations
• API compatibility
• Data format compatibility
• Cross-platform functionality
• Browser/device c