Financial entities shall, taking into account their size and their overall risk profile, establish, maintain and review a sound and comprehensive digital operational resilience testing programme as an integral part of the ICT risk management framework.
Comprehensive document defining the institution's digital operational resilience testing programme, including testing strategy, scope, frequency, methodologies, and governance as required by DORA Article 24.
resilience-testing-programmeGenerated example artifact using the default institution profile (COMMON availability, synthetic data only).
DIGITAL OPERATIONAL RESILIENCE TESTING PROGRAMME
Nordvik Bank AG
Version 2.1 | Approved: 20 January 2025 | Next Review: 20 January 2026
Approving Authority: Board Risk Committee
Classification: Internal — Restricted
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PROGRAMME OVERVIEW
Nordvik Bank AG ("the Bank") maintains a comprehensive digital operational resilience
testing programme in accordance with the Digital Operational Resilience Act
(Regulation (EU) 2022/2554, "DORA"), Article 24. This programme establishes the
Bank's approach to systematically testing the resilience of its ICT systems,
processes, and third-party dependencies against a range of operational disruption
scenarios.
The programme is designed to identify vulnerabilities, assess the effectiveness of
existing controls, and validate the Bank's ability to withstand, respond to, and
recover from ICT-related disruptions. Testing activities are risk-based, proportionate
to the Bank's size and risk profile, and cover all critical and important ICT systems
and business functions.
This programme was substantively revised in Q4 2024 to incorporate the testing
requirements introduced by DORA, which became applicable on 17 January 2025. Key
changes from version 2.0 include: alignment of testing methodologies with DORA
Article 25 requirements, introduction of threat-led penetration testing (TLPT)
provisions per Articles 26–27, and enhanced governance and reporting structures.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TESTING STRATEGY
The Bank's resilience testing strategy follows a layered approach combining
continuous automated testing with periodic manual assessments:
Layer 1 — Continuous Automated Testing
Automated vulnerability scanning, configuration compliance checks, and
regression testing executed on a continuous or weekly basis. Provides
baseline assurance that known vulnerabilities are identified promptly.
Layer 2 — Periodic Structured Testing
Scheduled penetration testing, network security assessments, and scenario-
based resilience exercises conducted quarterly or semi-annually. Validates
control effectiveness against realistic attack scenarios.
Layer 3 — Advanced Threat-Led Testing
Threat-led penetration testing (TLPT) conducted every three years for
critical functions, using real-world threat intelligence to simulate
sophisticated adversary behaviour. Required by DORA Article 26 for
institutions meeting the designation criteria.
The strategy is reviewed annually by the CISO and approved by the Board Risk
Committee. Testing priorities are determined by the annual ICT risk assessment,
threat intelligence, and regulatory requirements.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SCOPE DEFINITION
The testing programme covers the following categories of ICT systems and processes:
Category In Scope Testing Frequency
─────────────────────────────────────────────────────────────────────────────
Core Banking Platform Yes Quarterly vulnerability scan,
annual penetration test
Payment Processing Systems Yes Quarterly vulnerability scan,
annual penetration test
Digital Banking Channels Yes Monthly vulnerability scan,
semi-annual penetration test
Regulatory Reporting Systems Yes Semi-annual vulnerability scan,
annual penetration test
Internal Network Infrastructure Yes Semi-annual network assessment
Cloud-Hosted Services (AWS) Yes Quarterly configuration review,
annual penetration test
Third-Party Integrations Yes Annual security assessment
End-User Computing Partial Annual vulnerability scan
Development Environments No* Excluded — low risk, no
production data
* Exclusion justified by risk assessment: development environments are
network-isolated and contain no production or customer data.
Total systems in scope: 127 (of 143 total ICT assets)
Coverage rate: 88.8%
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TESTING METHODOLOGIES
The programme employs the following testing methodologies, as required by DORA
Article 25:
1. Vulnerability Assessments and Scans
Automated scanning using Qualys VMDR for infrastructure and Checkmarx for
application code. Covers OWASP Top 10, CVE databases, and custom rules
aligned with the Bank's security baseline.
2. Open-Source Analyses
Review of open-source components using Snyk for dependency vulnerability
tracking. All production applications scanned for known vulnerabilities
in third-party libraries.
3. Network Security Assessments
Comprehensive assessment of network architecture, firewall rules, network
segmentation effectiveness, and traffic flow analysis. Conducted by the
internal Network Security team with annual external validation.
4. Gap Analyses
Structured assessment of the Bank's ICT security posture against DORA
requirements, EBA Guidelines, and ISO 27001 controls. Identifies areas
where current capabilities fall short of regulatory expectations.
5. Physical Security Reviews
Assessment of physical access controls, environmental protections, and
physical security of data centres and critical infrastructure.
6. Penetration Testing
Manual penetration testing by qualified external providers, covering
network, application, and social engineering attack vectors. Conducted
annually for critical systems and semi-annually for internet-facing
services.
7. Scenario-Based Testing
Tabletop exercises and simulation-based testing of incident response,
business continuity, and disaster recovery procedures. Scenarios are
derived from the Bank's threat landscape assessment.
8. Source Code Reviews
Static and dynamic analysis of internally developed applications.
Integrated into the CI/CD pipeline for continuous assessment.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TESTING SCHEDULE
Quarter Planned Activities
─────────────────────────────────────────────────────────────────────────────
Q1 2025 — Automated vulnerability scans (all in-scope systems)
— Network security assessment (internal)
— Gap analysis against DORA requirements
— Source code review (digital banking platform)
Q2 2025 — Automated vulnerability scans (all in-scope systems)
— Penetration test: digital banking channels (external provider)
— Scenario-based BCP exercise (ransomware scenario)
— Physical security review (Zurich DC-1)
Q3 2025 — Automated vulnerability scans (all in-scope systems)
— Penetration test: core banking platform (external provider)
— Network security assessment (external validation)
— Open-source dependency review
Q4 2025 — Automated vulnerability scans (all in-scope systems)
— Penetration test: payment processing (external provider)
— Annual programme review and planning for 2026
— TLPT planning phase (if designated by competent authority)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
GOVERNANCE AND OVERSIGHT
Programme Owner: Chief Information Security Officer (CISO)
Programme Manager: Security Testing Lead
Oversight Body: Board Risk Committee (quarterly reporting)
Executive Sponsor: Chief Risk Officer (CRO)
Governance Structure:
— The CISO is accountable for the design, execution, and continuous
improvement of the testing programme.
— The Security Testing Lead manages day-to-day programme execution,
coordinates with testing providers, and maintains the testing schedule.
— The ICT Risk Committee reviews testing results monthly and approves
remediation priorities.
— The Board Risk Committee receives quarterly reports on testing programme
status, key findings, and remediation progress.
— Internal Audit provides independent assurance on the programme's
effectiveness annually.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RESOURCE ALLOCATION
Resource Category Annual Budget (CHF)
─────────────────────────────────────────────────────────────────────────────
External penetration testing 320,000
Vulnerability management tooling 85,000
Network security assessment 45,000
TLPT (triennial, annualised) 150,000
Internal testing team (3 FTE) 450,000
Training and certification 25,000
─────────────────────────────────────────────────────────────────────────────
Total 1,075,000
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
REPORTING AND ESCALATION
Testing results are reported through the following channels:
Finding Severity Reporting Timeline Audience
─────────────────────────────────────────────────────────────────────────────
Critical Immediate (within 4 hours) CISO, CRO, BRC Chair
High Within 24 hours CISO, ICT Risk Committee
Medium Within monthly reporting cycle ICT Risk Committee
Low Within quarterly reporting Security Testing Lead
All testing reports are retained for a minimum of five years in accordance with
the Bank's document retention policy and DORA Article 24(6) requirements.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Document History:
v2.1 20 Jan 2025 Updated for DORA compliance; added TLPT provisions
v2.0 15 Jan 2024 Annual review; expanded scope to cloud services
v1.5 10 Jan 2023 Added scenario-based testing methodology
v1.0 20 Jan 2022 Initial programme document
Approved by: Board Risk Committee
Signature: [Board Risk Committee Chair]
Date: 20 January 2025
Example structured facts that Detrixa would extract from this evidence (synthetic data, deterministic seed).
resilience_testing_programme_status — fs-resilience-testing-programme
{
"factId": "c1d2e3f4-a5b6-7890-abcd-300000000001",
"evidenceId": "d0e1f2a3-b4c5-6789-abcd-300000000001",
"evidenceClassId": "resilience-testing-programme",
"factType": "resilience_testing_programme_status",
"data": {
"programme_version": "2.1",
"approval_date": "2025-01-20",
"testing_frequency": "quarterly",
"has_risk_based_scope": true,
"methodologies_count": 8,
"covers_critical_systems": true,
"budget_allocated": true,
"last_programme_review_date": "2025-01-20"
},
"provenance": "deterministic",
"extractorVersion": "dora-test-generator/0.1.0",
"extractedAt": "2025-01-25T09:00:00Z",
"supersededBy": null
}
testing_scope_definition_status — fs-testing-scope-definition
{
"factId": "c1d2e3f4-a5b6-7890-abcd-300000000002",
"evidenceId": "d0e1f2a3-b4c5-6789-abcd-300000000002",
"evidenceClassId": "testing-scope-definition",
"factType": "testing_scope_definition_status",
"data": {
"scope_version": "2.0",
"effective_date": "2025-01-15",
"systems_in_scope_count": 20,
"exclusions_count": 4,
"has_risk_based_prioritisation": true,
"covers_third_party_systems": true,
"covers_cloud_services": true
},
"provenance": "deterministic",
"extractorVersion": "dora-test-generator/0.1.0",
"extractedAt": "2025-01-25T09:00:00Z",
"supersededBy": null
}
Document defining the scope of digital operational resilience testing, including systems in scope, exclusions, risk-based prioritisation criteria, and testing boundaries.
testing-scope-definitionGenerated example artifact using the default institution profile (COMMON availability, synthetic data only).
RESILIENCE TESTING SCOPE DEFINITION
Nordvik Bank AG
Document Reference: SCOPE-RT-2025-001
Version 2.0 | Effective Date: 15 January 2025
Document Owner: Security Testing Lead
Review Cycle: Annual | Last Review: 15 January 2025
Classification: Internal — Restricted
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. SCOPE OVERVIEW
This document defines the scope of Nordvik Bank AG's digital operational resilience
testing programme for the 2025 testing cycle. It identifies the ICT systems,
applications, infrastructure components, and third-party services subject to
resilience testing, together with any exclusions and the risk-based justification
for those exclusions.
The scope is determined by the Bank's ICT asset inventory, business impact analysis,
and the risk-based prioritisation criteria defined in Section 4. The scope is
reviewed annually and updated following material changes to the Bank's ICT landscape,
in accordance with DORA Article 24.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. SYSTEMS IN SCOPE
The following ICT systems and services are included in the 2025 testing scope:
ID System / Service Criticality Testing Type
─────────────────────────────────────────────────────────────────────────────
SYS-001 Core Banking Platform (Temenos) Critical Full pentest + vuln scan
SYS-002 Payment Gateway (SWIFT/SEPA) Critical Full pentest + vuln scan
SYS-003 Digital Banking Portal Critical Full pentest + vuln scan
SYS-004 Mobile Banking Application Critical Full pentest + vuln scan
SYS-005 Regulatory Reporting (ABACUS) Important Vuln scan + config review
SYS-006 Customer Relationship Mgmt Important Vuln scan + config review
SYS-007 Treasury Management System Critical Full pentest + vuln scan
SYS-008 Anti-Money Laundering Platform Important Vuln scan + config review
SYS-009 Active Directory / IAM Critical Full pentest + vuln scan
SYS-010 Email and Collaboration (M365) Important Config review + phishing sim
SYS-011 SIEM Platform (Splunk) Critical Config review + log integrity
SYS-012 Endpoint Protection (CrowdStrike) Critical Efficacy testing
SYS-013 Network Infrastructure (Core) Critical Network assessment
SYS-014 Firewall Estate (Palo Alto) Critical Rule review + pentest
SYS-015 AWS Cloud Infrastructure Critical Cloud config review + pentest
SYS-016 Backup Infrastructure Important Recovery testing
SYS-017 VPN and Remote Access Important Vuln scan + config review
SYS-018 Database Servers (Oracle, MSSQL) Critical Vuln scan + access review
SYS-019 API Gateway Important API security testing
SYS-020 Document Management System Standard Vuln scan
Total systems in scope: 20
Critical systems: 11
Important systems: 7
Standard systems: 2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. EXCLUSIONS AND JUSTIFICATIONS
The following systems are excluded from the 2025 testing scope:
ID System / Service Criticality Justification
─────────────────────────────────────────────────────────────────────────────
EXC-001 Development Environments Low Network-isolated; no
production data; no
external connectivity
EXC-002 Training / Sandbox Systems Low Isolated environment;
synthetic data only
EXC-003 Decommissioned Legacy Apps N/A Scheduled for removal
(3 systems) by Q2 2025; no active
users; network access
disabled
EXC-004 Physical Access Control Low Managed by Facilities;
System (building) separate security
assessment programme
Total exclusions: 4 systems (plus 3 decommissioned)
Exclusion rate: 5.3% of total ICT asset inventory
All exclusions are reviewed and approved by the CISO. Exclusions for systems rated
Important or above require additional approval from the ICT Risk Committee.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. RISK-BASED PRIORITISATION
Testing priority is determined using a composite score based on three factors:
Factor Weight Scoring
─────────────────────────────────────────────────────────────────────────────
Asset Criticality 40% Critical=4, Important=3, Standard=2, Low=1
Threat Exposure 35% Internet-facing=4, Partner-facing=3,
Internal=2, Isolated=1
Change Velocity 25% High (monthly releases)=4, Medium
(quarterly)=3, Low (annual)=2, Stable=1
Systems scoring ≥3.0 receive priority testing (penetration test + vulnerability
assessment). Systems scoring 2.0–2.9 receive standard testing (vulnerability
assessment + configuration review). Systems scoring <2.0 receive baseline testing
(automated vulnerability scan only).
Current priority distribution:
Priority testing: 11 systems (55%)
Standard testing: 7 systems (35%)
Baseline testing: 2 systems (10%)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. TESTING BOUNDARIES
Boundary Type Specification
─────────────────────────────────────────────────────────────────────────────
Network Boundaries All five internal security zones (DMZ, Production,
Management, User, Development) plus AWS VPCs
Geographic Boundaries Zurich DC-1 (primary), Geneva DC-2 (DR),
AWS eu-central-1 (Frankfurt)
Temporal Boundaries Testing window: business hours for non-disruptive
tests; maintenance windows for active exploitation
Data Boundaries No testing against production customer data;
synthetic data used for application-level tests
Third-Party Boundaries Testing of Bank-managed components only; provider-
hosted components tested via API and configuration
review (no direct infrastructure access)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6. THIRD-PARTY SYSTEMS COVERAGE
Third-party ICT service providers supporting critical or important functions are
included in the testing scope through the following mechanisms:
Provider Service Testing Approach
─────────────────────────────────────────────────────────────────────────────
AWS Cloud infrastructure Cloud configuration review,
penetration test of Bank-
managed resources
Temenos Core banking SaaS API security testing,
configuration review, review
of provider SOC 2 report
SWIFT Payment messaging Configuration review, review
of SWIFT CSP assessment
CrowdStrike Endpoint protection Efficacy testing, review of
provider SOC 2 report
Microsoft M365 collaboration Configuration review (CIS
benchmark), phishing simulation
Third-party coverage rate: 100% of critical providers, 80% of important providers.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Document History:
v2.0 15 Jan 2025 Updated for DORA compliance; added third-party coverage
v1.5 12 Jan 2024 Annual review; expanded cloud scope
v1.0 20 Jan 2023 Initial scope definition
Approved by: CISO
Signature: [Katrin Halvorsen, CISO]
Date: 15 January 2025
Example structured facts that Detrixa would extract from this evidence (synthetic data, deterministic seed).
resilience_testing_programme_status — fs-resilience-testing-programme
{
"factId": "c1d2e3f4-a5b6-7890-abcd-300000000001",
"evidenceId": "d0e1f2a3-b4c5-6789-abcd-300000000001",
"evidenceClassId": "resilience-testing-programme",
"factType": "resilience_testing_programme_status",
"data": {
"programme_version": "2.1",
"approval_date": "2025-01-20",
"testing_frequency": "quarterly",
"has_risk_based_scope": true,
"methodologies_count": 8,
"covers_critical_systems": true,
"budget_allocated": true,
"last_programme_review_date": "2025-01-20"
},
"provenance": "deterministic",
"extractorVersion": "dora-test-generator/0.1.0",
"extractedAt": "2025-01-25T09:00:00Z",
"supersededBy": null
}
testing_scope_definition_status — fs-testing-scope-definition
{
"factId": "c1d2e3f4-a5b6-7890-abcd-300000000002",
"evidenceId": "d0e1f2a3-b4c5-6789-abcd-300000000002",
"evidenceClassId": "testing-scope-definition",
"factType": "testing_scope_definition_status",
"data": {
"scope_version": "2.0",
"effective_date": "2025-01-15",
"systems_in_scope_count": 20,
"exclusions_count": 4,
"has_risk_based_prioritisation": true,
"covers_third_party_systems": true,
"covers_cloud_services": true
},
"provenance": "deterministic",
"extractorVersion": "dora-test-generator/0.1.0",
"extractedAt": "2025-01-25T09:00:00Z",
"supersededBy": null
}
fs-resilience-testing-programmeDORA-Art24-P1approval_datemethodologies_count{
"properties": {
"approval_date": {
"format": "date",
"type": "string"
},
"budget_allocated": {
"type": "boolean"
},
"covers_critical_systems": {
"type": "boolean"
},
"has_risk_based_scope": {
"type": "boolean"
},
"last_programme_review_date": {
"format": "date",
"type": "string"
},
"methodologies_count": {
"minimum": 1,
"type": "integer"
},
"programme_version": {
"minLength": 1,
"type": "string"
},
"testing_frequency": {
"enum": [
"quarterly",
"semi-annual",
"annual"
],
"type": "string"
}
},
"required": [
"programme_version",
"approval_date",
"testing_frequency",
"has_risk_based_scope",
"methodologies_count"
],
"type": "object"
}
fs-testing-scope-definitionDORA-Art24-P1effective_datesystems_in_scope_count{
"properties": {
"covers_cloud_services": {
"type": "boolean"
},
"covers_third_party_systems": {
"type": "boolean"
},
"effective_date": {
"format": "date",
"type": "string"
},
"exclusions_count": {
"minimum": 0,
"type": "integer"
},
"has_risk_based_prioritisation": {
"type": "boolean"
},
"scope_version": {
"minLength": 1,
"type": "string"
},
"systems_in_scope_count": {
"minimum": 0,
"type": "integer"
}
},
"required": [
"scope_version",
"effective_date",
"systems_in_scope_count",
"has_risk_based_prioritisation"
],
"type": "object"
}