DORA-Art6-P1

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

{
  "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
}

{
  "factId": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
  "evidenceId": "f0e1d2c3-b4a5-6789-0123-456789abcdef",
  "evidenceClassId": "ict-risk-framework",
  "factType": "risk_appetite_statement",
  "data": {
    "statement_version": "3.2",
    "approval_date": "2025-01-14",
    "has_quantitative_thresholds": true,
    "risk_categories": [
      {
        "category": "ICT Operational Availability",
        "appetite_level": "low",
        "threshold_value": 99.8,
        "threshold_unit": "percent uptime per quarter"
      },
      {
        "category": "Cyber Security Incidents",
        "appetite_level": "low",
        "threshold_value": 2,
        "threshold_unit": "significant incidents per year"
      },
      {
        "category": "Third-Party ICT Risk",
        "appetite_level": "moderate",
        "threshold_value": 40,
        "threshold_unit": "percent of critical ICT spend per provider"
      },
      {
        "category": "Data Integrity",
        "appetite_level": "low",
        "threshold_value": 0.001,
        "threshold_unit": "percent error rate in automated processing"
      },
      {
        "category": "Recovery Time Objective — Critical Systems",
        "appetite_level": "low",
        "threshold_value": 4,
        "threshold_unit": "hours"
      }
    ]
  },
  "provenance": "deterministic",
  "extractorVersion": "dora-test-generator/0.1.0",
  "extractedAt": "2025-01-15T09:00:00Z",
  "supersededBy": null
}

ICT RISK MANAGEMENT POLICY
Nordvik Bank AG
Policy Reference: POL-ICT-RM-2025-001
Version 4.0 | Effective Date: 14 January 2025
Policy Owner: Chief Information Security Officer (CISO)
Review Cycle: Annual | Last Review: 14 January 2025
Classification: Internal — Restricted

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. PURPOSE AND SCOPE

1.1 Purpose

This policy establishes the operational procedures, roles, and responsibilities for
managing ICT risks at Nordvik Bank AG ("the Bank"). It translates the strategic
direction set by the ICT Risk Management Framework (v3.2) into actionable
requirements for all staff, contractors, and third-party service providers involved
in the Bank's ICT operations.

1.2 Scope

This policy applies to:
  — All ICT systems, applications, and infrastructure owned or operated by the Bank
  — All ICT services provided by third-party service providers
  — All employees, contractors, and temporary staff with access to ICT systems
  — All business processes that depend on ICT systems for their execution

1.3 Regulatory Basis

This policy is issued in compliance with:
  — Regulation (EU) 2022/2554 (DORA), Articles 5–16
  — EBA Guidelines on ICT and Security Risk Management (EBA/GL/2019/04)
  — Swiss Financial Market Supervisory Authority (FINMA) Circular 2023/1

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2. POLICY STATEMENTS

PS-01  The Bank shall maintain a comprehensive and up-to-date inventory of all
       ICT assets, classified by criticality and data sensitivity.

PS-02  All ICT risks shall be identified, assessed, and documented in the
       enterprise ICT risk register within 10 business days of identification.

PS-03  ICT risk assessments shall be conducted at least annually for all critical
       and important ICT systems, and following material changes.

PS-04  Risk treatment plans shall be approved by the ICT Risk Committee for all
       risks rated High or Critical on the residual risk scale.

PS-05  ICT security controls shall be implemented proportionate to the criticality
       of the systems they protect and the sensitivity of the data they process.

PS-06  All ICT incidents shall be reported, classified, and managed in accordance
       with the ICT Incident Management Procedure (PROC-ICT-IM-2025-001).

PS-07  Business continuity and disaster recovery plans shall be maintained and
       tested at least annually for all critical business functions.

PS-08  Third-party ICT service providers supporting critical or important functions
       shall be subject to ongoing risk assessment and monitoring.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

3. ROLES AND RESPONSIBILITIES

Role                          Responsibilities
─────────────────────────────────────────────────────────────────────────────────
Board Risk Committee          Approve ICT risk appetite; oversee framework
CRO                           Maintain risk register; chair ICT Risk Committee
CIO                           Ensure ICT infrastructure meets resilience standards
CISO                          Own this policy; manage security programme
IT Asset Manager              Maintain ICT asset inventory and classification
Risk Managers (Business)      Conduct first-line ICT risk assessments
Security Operations Manager   Operate SOC; manage detection and response
Business Continuity Manager   Maintain and test BCP/DR plans
Vendor Management             Assess and monitor third-party ICT providers
All Staff                     Comply with this policy; report incidents promptly

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

4. RISK IDENTIFICATION PROCEDURES

4.1 Sources of ICT Risk

ICT risks shall be identified from the following sources:
  (a) ICT asset inventory changes and new system deployments
  (b) Vulnerability scanning and penetration testing results
  (c) Threat intelligence feeds and industry advisories
  (d) ICT incident post-mortem analyses
  (e) Third-party provider risk assessments and audit reports
  (f) Regulatory changes and supervisory findings
  (g) Business change initiatives involving ICT components

4.2 Risk Identification Process

  Step 1:  Risk Owner identifies potential ICT risk event
  Step 2:  Risk Owner documents risk in the ICT risk register using the
           standard risk description template (REF: TMPL-RISK-001)
  Step 3:  Risk Owner performs initial risk assessment (inherent risk)
  Step 4:  Risk Management function reviews and validates the assessment
  Step 5:  Risk is presented to the ICT Risk Committee at the next monthly
           meeting (or immediately if rated Critical)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

5. RISK ASSESSMENT METHODOLOGY

5.1 Assessment Approach

The Bank uses a semi-quantitative risk assessment methodology combining:
  — Qualitative assessment using a 5×5 likelihood-impact matrix
  — Quantitative assessment for risks with estimable financial impact
  — Scenario-based assessment for complex or emerging risks

5.2 Assessment Frequency

  Critical systems:    Quarterly reassessment
  Important systems:   Semi-annual reassessment
  Standard systems:    Annual reassessment
  All systems:         Reassessment following material changes or incidents

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

6. RISK TREATMENT OPTIONS

For each identified ICT risk, one of the following treatment options shall be
selected and documented:

  Mitigate:   Implement controls to reduce likelihood or impact to within
              risk appetite. Preferred option for most ICT risks.

  Transfer:   Transfer risk to a third party (e.g., cyber insurance).
              Requires CRO approval and does not transfer regulatory
              accountability.

  Accept:     Accept the residual risk where it falls within appetite.
              Requires ICTRC approval for Medium risks, BRC approval for
              High risks. Not permitted for Critical risks.

  Avoid:      Eliminate the risk by discontinuing the activity or system.
              Requires business case approval from the relevant business
              line head and CIO.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

7. ESCALATION PROCEDURES

7.1 Risk Escalation Thresholds

  Residual Risk Rating    Escalation Requirement
  ─────────────────────────────────────────────────────────────────────────────
  Low                     No escalation required; managed by Risk Owner
  Medium                  Escalate to ICTRC for treatment plan approval
  High                    Escalate to ICTRC and notify BRC at next meeting
  Critical                Immediate escalation to CRO; BRC notification
                          within 24 hours; Board notification if systemic

7.2 Incident-Triggered Escalation

ICT incidents that indicate a previously unidentified or underestimated risk shall
trigger an immediate risk reassessment and escalation per the thresholds above.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

8. COMPLIANCE MONITORING

8.1 Policy Compliance

Compliance with this policy is monitored through:
  — Quarterly self-assessments by first-line risk owners
  — Semi-annual compliance reviews by the Compliance function
  — Annual independent assessment by Internal Audit
  — Continuous monitoring of key risk indicators by the Risk function

8.2 Non-Compliance

Non-compliance with this policy shall be reported to the CISO and documented in
the compliance exception register. Material non-compliance shall be escalated to
the CRO and reported to the Board Risk Committee.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Document History:
  v4.0  14 Jan 2025  Updated for DORA compliance; revised escalation procedures
  v3.2  10 Jan 2024  Annual review; updated risk treatment options
  v3.1  15 Jun 2023  Interim update; added third-party risk provisions
  v3.0  12 Jan 2023  Major revision; aligned with EBA Guidelines

Approved by: CRO
Signature:   [Chief Risk Officer]
Date:        14 January 2025

{
  "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
}

{
  "factId": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
  "evidenceId": "f0e1d2c3-b4a5-6789-0123-456789abcdef",
  "evidenceClassId": "ict-risk-framework",
  "factType": "risk_appetite_statement",
  "data": {
    "statement_version": "3.2",
    "approval_date": "2025-01-14",
    "has_quantitative_thresholds": true,
    "risk_categories": [
      {
        "category": "ICT Operational Availability",
        "appetite_level": "low",
        "threshold_value": 99.8,
        "threshold_unit": "percent uptime per quarter"
      },
      {
        "category": "Cyber Security Incidents",
        "appetite_level": "low",
        "threshold_value": 2,
        "threshold_unit": "significant incidents per year"
      },
      {
        "category": "Third-Party ICT Risk",
        "appetite_level": "moderate",
        "threshold_value": 40,
        "threshold_unit": "percent of critical ICT spend per provider"
      },
      {
        "category": "Data Integrity",
        "appetite_level": "low",
        "threshold_value": 0.001,
        "threshold_unit": "percent error rate in automated processing"
      },
      {
        "category": "Recovery Time Objective — Critical Systems",
        "appetite_level": "low",
        "threshold_value": 4,
        "threshold_unit": "hours"
      }
    ]
  },
  "provenance": "deterministic",
  "extractorVersion": "dora-test-generator/0.1.0",
  "extractedAt": "2025-01-15T09:00:00Z",
  "supersededBy": null
}