The ICT risk management framework shall be documented and reviewed at least once a year, or periodically in the case of microenterprises, as well as upon the occurrence of major ICT-related incidents, and following supervisory instructions or conclusions derived from relevant digital operational resilience testing or audit processes.
Comprehensive document describing the institution's ICT risk management framework, governance structure, risk appetite, and risk management methodology as required by DORA Article 6.
ict-risk-frameworkGenerated example artifact using the default institution profile (COMMON availability, synthetic data only).
ICT RISK MANAGEMENT FRAMEWORK
Nordvik Bank AG
Version 3.2 | Approved: 14 January 2025 | Next Review: 14 January 2026
Approving Authority: Board Risk Committee
Classification: Internal — Restricted
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
EXECUTIVE SUMMARY
Nordvik Bank AG ("the Bank") operates in an increasingly complex digital environment
where ICT systems underpin every material business function — from core banking
operations and payment processing to customer-facing digital channels and regulatory
reporting. The integrity, availability, and confidentiality of these systems are
prerequisites for the Bank's operational continuity, regulatory compliance, and
customer trust.
This ICT Risk Management Framework ("the Framework") establishes the Bank's
comprehensive approach to identifying, assessing, treating, and monitoring ICT-related
risks in accordance with the Digital Operational Resilience Act (Regulation (EU)
2022/2554, "DORA"), the EBA Guidelines on ICT and Security Risk Management, and the
Bank's internal risk appetite. The Framework applies to all ICT systems, processes,
and third-party ICT service providers that support the Bank's operations.
The Framework was last substantively revised in Q4 2024 to incorporate the
requirements of DORA, which became applicable on 17 January 2025. Key changes from
version 3.1 include: explicit mapping of all framework components to DORA articles,
updated risk appetite thresholds reflecting the Bank's current risk profile, and
enhanced provisions for third-party ICT risk management.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
GOVERNANCE STRUCTURE
1.1 Board of Directors
The Board of Directors bears ultimate responsibility for the Bank's ICT risk
management. The Board approves this Framework, sets the ICT risk appetite, and
receives quarterly reports on the Bank's ICT risk posture from the Board Risk
Committee. The Board has designated ICT risk as a principal risk category requiring
direct board-level oversight in accordance with DORA Article 5(2).
1.2 Board Risk Committee
The Board Risk Committee ("BRC") oversees the implementation of this Framework on
behalf of the Board. The BRC meets quarterly and reviews: (a) the ICT risk dashboard
prepared by the Chief Risk Officer; (b) material ICT incidents and near-misses;
(c) the status of open ICT risk remediation actions; and (d) any proposed changes to
the ICT risk appetite. The BRC Chair reports to the full Board at each Board meeting.
1.3 Executive Management
The Chief Information Officer ("CIO") is accountable for the design, implementation,
and maintenance of the Bank's ICT systems and infrastructure. The Chief Information
Security Officer ("CISO") is accountable for the ICT security programme, including
threat detection, vulnerability management, and security incident response. The Chief
Risk Officer ("CRO") is accountable for the independent oversight of ICT risk,
including the maintenance of this Framework and the ICT risk register.
1.4 Three Lines of Defence
The Bank applies the Three Lines of Defence model to ICT risk management:
First Line: ICT operations, development, and business units own and manage
ICT risks within their domains. They implement controls, maintain
asset inventories, and report incidents.
Second Line: The Risk Management function (CRO) provides independent oversight,
maintains the ICT risk framework and appetite, and challenges the
first line's risk assessments. The Compliance function monitors
adherence to regulatory requirements including DORA.
Third Line: Internal Audit provides independent assurance on the effectiveness
of ICT risk management and control frameworks, reporting directly
to the Audit Committee.
1.5 ICT Risk Committee
The ICT Risk Committee ("ICTRC") is an executive-level committee chaired by the CRO
with membership comprising the CIO, CISO, Head of Business Continuity, Head of
Vendor Management, and representatives from material business lines. The ICTRC meets
monthly to review the ICT risk register, approve risk treatment decisions, and
escalate material issues to the BRC. Terms of Reference are maintained separately.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RISK APPETITE STATEMENT
The Bank's ICT risk appetite is defined as the aggregate level of ICT-related risk
the Bank is willing to accept in pursuit of its strategic objectives, before action
is required to reduce the risk. The ICT risk appetite is set by the Board annually
and is reviewed following any material change in the Bank's risk profile or operating
environment.
The Bank's ICT risk appetite is expressed through the following quantitative
thresholds, approved by the Board Risk Committee on 14 January 2025:
Category Appetite Level Threshold
─────────────────────────────────────────────────────────────────────────────
ICT Operational Availability Low Maximum tolerated downtime for
critical systems: 4 hours per
quarter (99.8% availability)
Cyber Security Incidents Low Zero tolerance for incidents
resulting in material data
exfiltration or system compromise.
Maximum 2 significant security
incidents per year.
Third-Party ICT Risk Moderate Maximum 3 critical ICT providers
without approved exit strategies.
No single provider to represent
>40% of critical ICT spend.
Data Integrity Low Zero tolerance for undetected
corruption of financial records.
Maximum 0.001% error rate in
automated data processing.
Recovery Time Objective Low Critical systems: RTO ≤ 4 hours,
RPO ≤ 1 hour. Important systems:
RTO ≤ 24 hours, RPO ≤ 4 hours.
Any breach of these thresholds triggers mandatory escalation to the CRO and, where
the breach is material, to the Board Risk Committee within 24 hours.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RISK IDENTIFICATION METHODOLOGY
The Bank employs a structured, continuous risk identification process covering all
ICT systems, processes, and third-party dependencies. Risk identification is conducted
through the following mechanisms:
4.1 Annual ICT Risk Assessment
A comprehensive ICT risk assessment is conducted annually by the Risk Management
function, with input from ICT operations, business lines, and the CISO. The
assessment covers: (a) the threat landscape relevant to the Bank's sector and
geography; (b) vulnerabilities in the Bank's ICT infrastructure and applications;
(c) risks arising from third-party ICT dependencies; and (d) emerging risks from
technology change and regulatory developments. The methodology follows ISO 31000 and
is aligned with the NIST Cybersecurity Framework.
4.2 Continuous Monitoring
The Security Operations Centre ("SOC") operates 24/7 monitoring of the Bank's ICT
environment using a Security Information and Event Management ("SIEM") platform.
Anomaly detection rules are reviewed quarterly. Monitoring coverage is assessed
annually against the Bank's ICT asset inventory to identify gaps.
4.3 Vulnerability Management
Automated vulnerability scanning is conducted weekly for internet-facing systems and
monthly for internal systems. Critical and high-severity vulnerabilities are escalated
to the CISO within 24 hours of identification. Remediation timelines are: Critical —
72 hours; High — 14 days; Medium — 90 days; Low — next scheduled maintenance window.
4.4 Third-Party Risk Identification
ICT third-party risks are identified through: (a) annual due diligence reviews of
critical and important ICT providers; (b) review of provider-supplied security
certifications and audit reports; (c) monitoring of provider incident notifications;
and (d) concentration risk analysis conducted semi-annually.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RISK ASSESSMENT PROCESS
Identified ICT risks are assessed using a two-dimensional matrix evaluating:
Likelihood: The probability of the risk materialising, rated on a five-point
scale from Rare (1) to Almost Certain (5), based on historical
incident data, threat intelligence, and expert judgement.
Impact: The potential consequence if the risk materialises, rated on a
five-point scale from Negligible (1) to Catastrophic (5), assessed
across four dimensions: financial loss, operational disruption,
reputational damage, and regulatory sanction.
The inherent risk score (Likelihood × Impact) determines the risk rating:
1–4: Low — managed within normal operations
5–9: Medium — requires documented treatment plan
10–16: High — requires ICTRC approval and quarterly monitoring
17–25: Critical — requires BRC notification and immediate treatment
Residual risk is assessed after applying existing controls. Risks with residual
scores of High or Critical are included in the Board-level ICT risk dashboard.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RISK MITIGATION CONTROLS
The Bank maintains a comprehensive set of ICT risk mitigation controls, documented
in the ICT Security Controls Register (reference: CTRL-REG-2025-001). Controls are
organised by the following categories:
Preventive Controls: Access management (MFA enforced for all privileged
accounts), network segmentation, encryption at rest and
in transit (AES-256 / TLS 1.3), patch management,
secure software development lifecycle.
Detective Controls: SIEM with 24/7 SOC monitoring, endpoint detection and
response (EDR), data loss prevention (DLP), privileged
access monitoring, anomaly detection.
Corrective Controls: Incident response procedures, business continuity and
disaster recovery plans, backup and restoration
procedures, forensic investigation capability.
Control effectiveness is assessed annually through independent testing, including
penetration testing, vulnerability assessments, and BCP exercises. The results are
reported to the ICTRC and, for material findings, to the BRC.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
MONITORING AND REPORTING
The Bank maintains a structured ICT risk reporting framework:
Frequency Report Audience
─────────────────────────────────────────────────────────────────────────────
Real-time SOC alerts and incident CISO, ICT Operations
notifications
Weekly Vulnerability management CISO, IT Security Team
status report
Monthly ICT risk register update ICTRC
Open remediation action status
Quarterly ICT risk dashboard Board Risk Committee
Incident trend analysis
Third-party risk summary
Annual ICT risk assessment report Board of Directors
Framework review report
DORA compliance self-assessment
Key Risk Indicators ("KRIs") are monitored continuously and reported monthly to the
ICTRC. KRIs include: system availability rates, mean time to detect/respond to
incidents, vulnerability remediation rates, patch compliance rates, and third-party
SLA performance.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
REVIEW AND UPDATE SCHEDULE
This Framework is subject to formal review at least annually, and additionally
following any of the following trigger events:
— A material ICT incident affecting critical or important functions
— A significant change to the Bank's ICT architecture or operating model
— A supervisory instruction or regulatory finding relating to ICT risk
— A material change in the threat landscape
— The results of an internal audit or resilience testing exercise
The next scheduled review is due by 14 January 2026. The CRO is responsible for
initiating and coordinating the review process. All proposed changes to this
Framework require approval by the Board Risk Committee before taking effect.
Document History:
v3.2 14 Jan 2025 Updated for DORA compliance; revised risk appetite thresholds
v3.1 10 Jan 2024 Annual review; updated third-party risk provisions
v3.0 15 Jan 2023 Major revision; adopted Three Lines of Defence model
v2.4 12 Jan 2022 Annual review; updated monitoring and reporting section
Approved by: Board Risk Committee
Signature: [Board Risk Committee Chair]
Date: 14 January 2025
Example structured facts that Detrixa would extract from this evidence (synthetic data, deterministic seed).
ict_risk_framework_status — fs-ict-risk-framework-status
{
"factId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"evidenceId": "f0e1d2c3-b4a5-6789-0123-456789abcdef",
"evidenceClassId": "ict-risk-framework",
"factType": "ict_risk_framework_status",
"data": {
"framework_version": "3.2",
"approval_date": "2025-01-14",
"next_review_date": "2026-01-14",
"has_governance_structure": true,
"has_risk_appetite": true,
"risk_appetite_thresholds": [
{
"category": "ICT Operational Availability",
"threshold": 99.8,
"unit": "percent uptime per quarter"
},
{
"category": "Cyber Security Incidents",
"threshold": 2,
"unit": "significant incidents per year"
},
{
"category": "Third-Party ICT Concentration",
"threshold": 40,
"unit": "percent of critical ICT spend per provider"
},
{
"category": "Recovery Time Objective — Critical Systems",
"threshold": 4,
"unit": "hours"
}
]
},
"provenance": "deterministic",
"extractorVersion": "dora-test-generator/0.1.0",
"extractedAt": "2025-01-15T09:00:00Z",
"supersededBy": null
}
framework_review_record — fs-framework-review-record
{
"factId": "c1d2e3f4-a5b6-7890-cdef-100000000003",
"evidenceId": "a0b1c2d3-e4f5-6789-abcd-100000000003",
"evidenceClassId": "framework-review-record",
"factType": "framework_review_record",
"data": {
"review_date": "2025-01-10",
"reviewer": "Katrin Halvorsen, Chief Information Security Officer",
"review_trigger": "periodic",
"findings_count": 7,
"changes_made": true,
"change_summary": "Framework updated from v3.1 to v3.2: added DORA compliance mapping matrix, enhanced third-party ICT risk provisions, revised cyber security incident risk appetite threshold from 3 to 2 significant incidents per year, updated governance structure for Q3 2024 organisational changes.",
"next_review_date": "2026-01-10",
"approved_by": "Erik Lindqvist, Chief Risk Officer"
},
"provenance": "deterministic",
"extractorVersion": "dora-test-generator/0.1.0",
"extractedAt": "2025-01-15T09:00:00Z",
"supersededBy": null
}
Structured JSON record documenting each periodic review of the ICT risk management framework, including review date, findings, changes made, and next review date.
framework-review-recordGenerated example artifact using the default institution profile (COMMON availability, synthetic data only).
{
"reviewId": "FRR-2025-001",
"reviewDate": "2025-01-10",
"reviewType": "periodic",
"reviewTrigger": "annual_scheduled_review",
"frameworkReference": "ICT Risk Management Framework v3.1",
"reviewer": {
"name": "Katrin Halvorsen",
"role": "Chief Information Security Officer",
"department": "Information Security"
},
"reviewScope": [
"Governance structure and reporting lines",
"Risk appetite statement and thresholds",
"Risk identification and assessment methodology",
"Control framework and effectiveness",
"Third-party ICT risk management provisions",
"Business continuity and recovery planning",
"Monitoring and reporting mechanisms",
"DORA Article 5-16 compliance mapping"
],
"findingsSummary": {
"totalFindings": 7,
"critical": 0,
"high": 2,
"medium": 3,
"low": 2,
"findings": [
{
"findingId": "FRR-2025-001-F01",
"severity": "high",
"area": "DORA Compliance Mapping",
"description": "Framework lacks explicit article-by-article mapping to DORA requirements. While substantive coverage exists, the absence of a formal mapping table creates risk of gaps in compliance demonstration.",
"recommendation": "Create a DORA compliance mapping matrix linking each framework component to specific DORA articles and paragraphs."
},
{
"findingId": "FRR-2025-001-F02",
"severity": "high",
"area": "Third-Party ICT Risk",
"description": "Third-party ICT risk management provisions do not fully address DORA Article 28-44 requirements for contractual arrangements and concentration risk monitoring.",
"recommendation": "Enhance third-party risk provisions to include mandatory contractual clauses per DORA Article 30 and implement concentration risk monitoring per Article 31."
},
{
"findingId": "FRR-2025-001-F03",
"severity": "medium",
"area": "Risk Appetite Thresholds",
"description": "Cyber security incident threshold of 3 significant incidents per year is above peer benchmark. Industry median for comparable institutions is 2 incidents per year.",
"recommendation": "Tighten cyber security incident threshold to maximum 2 significant incidents per year."
},
{
"findingId": "FRR-2025-001-F04",
"severity": "medium",
"area": "Monitoring Coverage",
"description": "SOC monitoring coverage assessment has not been updated since Q2 2024. New cloud-native services deployed in Q3-Q4 2024 may not be fully covered.",
"recommendation": "Conduct updated monitoring coverage assessment including all cloud-native services deployed in H2 2024."
},
{
"findingId": "FRR-2025-001-F05",
"severity": "medium",
"area": "Business Continuity Testing",
"description": "BCP testing in 2024 was limited to tabletop exercises. No live failover test was conducted for critical payment processing systems.",
"recommendation": "Schedule live failover test for payment processing systems in Q2 2025."
},
{
"findingId": "FRR-2025-001-F06",
"severity": "low",
"area": "Documentation",
"description": "Several supporting procedures referenced in the framework have not been updated to reflect the current organisational structure following the Q3 2024 reorganisation.",
"recommendation": "Update all referenced procedures to reflect current organisational structure by Q1 2025."
},
{
"findingId": "FRR-2025-001-F07",
"severity": "low",
"area": "Training",
"description": "Board-level ICT risk training was last conducted in March 2024. Two new board members appointed in September 2024 have not yet received ICT risk training.",
"recommendation": "Schedule ICT risk training for new board members before Q1 2025 Board meeting."
}
]
},
"changesMade": true,
"changeSummary": "Framework updated from v3.1 to v3.2 incorporating the following changes: (1) Added DORA compliance mapping matrix as Appendix A; (2) Enhanced third-party ICT risk management provisions per DORA Articles 28-44; (3) Revised cyber security incident risk appetite threshold from 3 to 2 significant incidents per year; (4) Updated governance structure to reflect Q3 2024 organisational changes; (5) Added explicit digital operational resilience testing requirements per DORA Articles 24-27.",
"approvedBy": {
"name": "Erik Lindqvist",
"role": "Chief Risk Officer",
"approvalDate": "2025-01-14"
},
"nextReviewDate": "2026-01-10",
"nextReviewType": "periodic",
"attachments": [
"DORA_Compliance_Mapping_Matrix_v1.0.xlsx",
"Framework_Change_Log_v3.2.pdf",
"BRC_Approval_Minutes_20250114.pdf"
]
}
Example structured facts that Detrixa would extract from this evidence (synthetic data, deterministic seed).
ict_risk_framework_status — fs-ict-risk-framework-status
{
"factId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"evidenceId": "f0e1d2c3-b4a5-6789-0123-456789abcdef",
"evidenceClassId": "ict-risk-framework",
"factType": "ict_risk_framework_status",
"data": {
"framework_version": "3.2",
"approval_date": "2025-01-14",
"next_review_date": "2026-01-14",
"has_governance_structure": true,
"has_risk_appetite": true,
"risk_appetite_thresholds": [
{
"category": "ICT Operational Availability",
"threshold": 99.8,
"unit": "percent uptime per quarter"
},
{
"category": "Cyber Security Incidents",
"threshold": 2,
"unit": "significant incidents per year"
},
{
"category": "Third-Party ICT Concentration",
"threshold": 40,
"unit": "percent of critical ICT spend per provider"
},
{
"category": "Recovery Time Objective — Critical Systems",
"threshold": 4,
"unit": "hours"
}
]
},
"provenance": "deterministic",
"extractorVersion": "dora-test-generator/0.1.0",
"extractedAt": "2025-01-15T09:00:00Z",
"supersededBy": null
}
framework_review_record — fs-framework-review-record
{
"factId": "c1d2e3f4-a5b6-7890-cdef-100000000003",
"evidenceId": "a0b1c2d3-e4f5-6789-abcd-100000000003",
"evidenceClassId": "framework-review-record",
"factType": "framework_review_record",
"data": {
"review_date": "2025-01-10",
"reviewer": "Katrin Halvorsen, Chief Information Security Officer",
"review_trigger": "periodic",
"findings_count": 7,
"changes_made": true,
"change_summary": "Framework updated from v3.1 to v3.2: added DORA compliance mapping matrix, enhanced third-party ICT risk provisions, revised cyber security incident risk appetite threshold from 3 to 2 significant incidents per year, updated governance structure for Q3 2024 organisational changes.",
"next_review_date": "2026-01-10",
"approved_by": "Erik Lindqvist, Chief Risk Officer"
},
"provenance": "deterministic",
"extractorVersion": "dora-test-generator/0.1.0",
"extractedAt": "2025-01-15T09:00:00Z",
"supersededBy": null
}
fs-ict-risk-framework-statusDORA-Art6-P1approval_datenext_review_date{
"properties": {
"approval_date": {
"format": "date",
"type": "string"
},
"framework_version": {
"pattern": "^\\d+\\.\\d+$",
"type": "string"
},
"has_governance_structure": {
"type": "boolean"
},
"has_risk_appetite": {
"type": "boolean"
},
"next_review_date": {
"format": "date",
"type": "string"
},
"risk_appetite_thresholds": {
"items": {
"properties": {
"category": {
"type": "string"
},
"threshold": {
"type": "number"
},
"unit": {
"type": "string"
}
},
"type": "object"
},
"type": "array"
}
},
"required": [
"framework_version",
"approval_date",
"next_review_date",
"has_governance_structure",
"has_risk_appetite"
],
"type": "object"
}
fs-framework-review-recordDORA-Art6-P8review_datenext_review_date{
"properties": {
"approved_by": {
"type": "string"
},
"change_summary": {
"type": "string"
},
"changes_made": {
"type": "boolean"
},
"findings_count": {
"minimum": 0,
"type": "integer"
},
"next_review_date": {
"format": "date",
"type": "string"
},
"review_date": {
"format": "date",
"type": "string"
},
"review_trigger": {
"enum": [
"periodic",
"major_incident",
"supervisory_instruction",
"audit_finding",
"resilience_test"
],
"type": "string"
},
"reviewer": {
"minLength": 1,
"type": "string"
}
},
"required": [
"review_date",
"reviewer",
"review_trigger",
"changes_made",
"next_review_date"
],
"type": "object"
}