bmad-plus 0.9.0 → 0.9.1

package/src/bmad-plus/packs/pack-shield/references/dora/third-party-risk.md

@@ -1,349 +1,349 @@
-# DORA — ICT Third-Party Risk Management Reference
-
-Chapter V, Articles 28–44, Regulation (EU) 2022/2554.
-Key implementing measures: CDR (EU) 2024/1773, CIR (EU) 2024/2956, CDR (EU) 2025/532,
-CDR (EU) 2024/1502, CDR (EU) 2024/1505, CDR (EU) 2025/295, CDR (EU) 2025/420.
-
----
-
-## Overview: Two-Track Structure
-
-Chapter V operates on two parallel tracks:
-
-**Track 1 — Entity-level obligations (Art. 28–30):**
-Every financial entity must manage its own ICT third-party risks — regardless of
-whether its TPSPs are designated critical.
-
-**Track 2 — Systemic oversight of designated CTPPs (Art. 31–44):**
-ESAs designate and oversee ICT TPSPs that are systemically important to the
-EU financial sector. This is a supervisory regime, not an entity-level compliance task.
-
----
-
-## Art. 28 — General Principles for ICT Third-Party Risk
-
-### Art. 28(1) — ICT Third-Party Risk Policy
-Every financial entity must adopt, regularly review, and update an **ICT third-party
-risk policy** covering:
-- Objectives and principles for managing ICT third-party risk
-- Criteria for identifying critical and important functions (CIF) vs. non-critical
-- Pre-contractual due diligence requirements
-- Contract lifecycle management (onboarding, monitoring, exit)
-- ICT concentration risk management
-- Governance roles and responsibilities
-
-**Key RTS:** CDR (EU) 2024/1773, Art. 1–12 (detailed policy content)
-
-### Art. 28(2) — Maintaining the Register of Information
-Financial entities must maintain and update the **Register of Information** (RoI)
-covering **all** ICT service arrangements (not only those supporting critical
-functions). See the Register of Information section below for full field details.
-
-### Art. 28(3) — Annual Submission of Register of Information
-The RoI must be submitted to the competent authority **at least annually** and
-upon specific request. The submission format follows CIR (EU) 2024/2956 templates.
-
-### Art. 28(4) — Pre-Contractual Due Diligence
-Before entering any new ICT service arrangement supporting a critical or important
-function, financial entities must:
-- **(a)** Assess whether the ICT service arrangement supports a critical or important function
-- **(b)** Assess the risks of the arrangement, including ICT concentration risk
-- **(c)** Carry out appropriate due diligence on prospective ICT TPSPs
-
-The due diligence must be documented and commensurate with the criticality of
-the function.
-
-### Art. 28(5) — Ongoing Monitoring of ICT TPSPs
-- Monitor the performance, security posture, and compliance of ICT TPSPs
-  throughout the contract lifecycle
-- Conduct regular reviews aligned with the contract terms and risk profile
-- Verify that ICT TPSPs continue to meet agreed service levels and security standards
-
-### Art. 28(6) — ICT Concentration Risk Assessment
-Financial entities must:
-- Assess the **concentration risk** arising from reliance on a single or limited
-  number of ICT TPSPs for critical functions
-- Determine whether the failure or unavailability of any TPSP would threaten the
-  entity's ability to maintain critical functions
-- Document this assessment and factor it into risk appetite and strategy
-
-**Common scenario:** A bank using a single hyperscaler (e.g., one major cloud
-provider) for core banking, treasury, and fraud detection creates high concentration
-risk even if the TPSP is not designated critical.
-
-### Art. 28(7) — Exit Strategy
-For each ICT arrangement supporting a critical or important function, financial entities must:
-- Develop and maintain an **exit strategy** covering:
-  - Conditions and triggers for exit
-  - Minimum notice period required to migrate services
-  - Data portability and return procedures
-  - Transition assistance obligations of the departing TPSP
-- Test exit strategies periodically (frequency: risk-based)
-
----
-
-## Art. 29 — Preliminary Assessment of ICT Concentration Risk
-
-Before entering a new arrangement that would cause an entity's concentration in
-a single TPSP to increase for critical functions:
-- Conduct a specific **concentration risk assessment**
-- Document the assessment outcome and risk mitigation measures (if any)
-- Consider the systemic implications if the concentrated TPSP were to fail
-
-This is a transaction-specific obligation (triggered by entering a new arrangement)
-rather than an ongoing monitoring obligation (which is covered by Art. 28(6)).
-
----
-
-## Art. 30 — Key Contractual Provisions
-
-### Scope: When does Art. 30(2) apply?
-
-Art. 30(2) applies to contracts for ICT services that support **critical or important
-functions**. A lighter set of provisions applies to non-critical arrangements
-(Art. 30(3)).
-
-### Critical or Important Function (CIF)
-
-A function is critical or important if its disruption would:
-- Materially impair the financial entity's compliance with legal obligations
-- Materially impair its financial performance, or
-- Materially impair the soundness or continuity of its services
-
-The criteria for identifying CIF are further specified in CDR (EU) 2024/1773.
-
-### Mandatory Contractual Provisions — Art. 30(2)(a)–(i)
-
-| Provision | DORA Requirement |
-|-----------|-----------------|
-| **(a)** Service description | Clear and complete description of the ICT services to be provided |
-| **(b)** Data locations | Location(s) where services will be provided and data stored/processed, including notification obligations if locations change |
-| **(c)** Data protection | Provisions ensuring data protection; compliance with applicable data protection law (GDPR where applicable) |
-| **(d)** Availability, authenticity, integrity, security | Service level specifications; security standards; incident response obligations of the TPSP |
-| **(e)** Audit and access rights | **Full and unrestricted audit rights** for the financial entity, its competent authorities (including ECB for significant institutions), and resolution authorities — including on-site inspection rights at the TPSP's premises |
-| **(f)** Termination rights | Conditions under which the financial entity may terminate; minimum notice periods; the TPSP's obligation to provide transition services |
-| **(g)** Reporting and monitoring | ICT incident reporting by the TPSP to the financial entity; performance monitoring; regular service reviews |
-| **(h)** Data portability and migration | On termination, the TPSP must provide all data in machine-readable format; migration assistance; data deletion certification |
-| **(i)** Sub-contracting | Conditions under which the TPSP may sub-contract ICT services; prior written consent requirement; equivalent contractual provisions in sub-processor contracts; right to audit sub-processors |
-
-**Key RTS:** CDR (EU) 2024/1773 specifies the detailed content of each provision.
-**Key RTS:** CDR (EU) 2025/532 specifies sub-contracting provisions in detail.
-
-### The Audit Rights Problem (Art. 30(2)(e))
-
-The most common contractual gap: large cloud providers offer only third-party
-audit reports (e.g., SOC 2, ISO 27001 certificates) rather than direct audit
-rights. DORA Art. 30(2)(e) requires:
-- **Full and unrestricted** audit rights for the financial entity
-- **Access rights for competent authorities** — including the right to inspect
-  the TPSP's premises
-
-ESA guidance has clarified that:
-- Pooled or third-party audits (SOC 2, ISO 27001 certification) may partially
-  satisfy the **entity's own audit right** where direct audit is genuinely
-  impracticable at hyperscale TPSPs — but only if the entity documents in writing
-  why direct audit is impracticable and confirms the pooled audit outputs are
-  meaningful and sufficient
-- Financial entities must still document their assessment of why pooled audits
-  are acceptable and ensure they receive meaningful, entity-specific outputs
-- **The competent authority's (and resolution authority's) on-site inspection
-  right under Art. 30(2)(e) is NON-WAIVABLE.** Even where the entity accepts
-  pooled audits, the contract must contain an express, unconditional clause
-  preserving the competent authority's right to inspect the TPSP's premises
-  directly. A clause that routes the authority's access through the TPSP's
-  third-party audit programme does NOT satisfy Art. 30(2)(e). This is a common
-  failure in standard cloud provider contracts.
-- Acceptance of pooled audits must be documented with a written risk acceptance
-  approved at an appropriate governance level (e.g., CRO or board)
-
-### Lighter Provisions for Non-Critical Arrangements (Art. 30(3))
-
-For ICT service arrangements that do not support critical or important functions:
-- Service description
-- Data locations
-- Basic availability and security commitments
-- Incident notification obligations
-- Exit/termination provisions
-
-Full Art. 30(2) provisions are not required.
-
-### Art. 30(4) — Review Before Renewal
-
-Before renewing any contract for ICT services supporting critical functions,
-financial entities must review whether:
-- Service levels remain adequate
-- Audit and access rights remain exercisable
-- Exit strategy remains viable
-- New risks (concentration, substitutability) have emerged
-
----
-
-## Register of Information — Complete Field Reference (CIR (EU) 2024/2956)
-
-### When to Maintain and Submit
-
-- **Ongoing maintenance:** Update when new arrangements are entered, modified,
-  or terminated; when sub-processors change; when data locations change
-- **Annual submission:** At least annually to the competent authority
-- **On-demand submission:** Upon specific request from competent authority or ESA
-  (for the oversight framework of CTPPs under Art. 31)
-
-### Complete Field Set
-
-The RoI is structured around **arrangements** — each row represents one ICT
-service arrangement.
-
-| Field | Field Name (CIR 2024/2956) | Description |
-|-------|---------------------------|-------------|
-| 1 | Reporting entity LEI | Legal Entity Identifier of the financial entity |
-| 2 | Reporting entity name | Legal name |
-| 3 | Reporting entity type | Regulated entity type (credit institution, insurer, etc.) |
-| 4 | Arrangement reference | Unique internal reference for this arrangement |
-| 5 | Arrangement type | Type (outsourcing, SaaS, IaaS, PaaS, data services, etc.) |
-| 6 | TPSP legal name | Legal name of the ICT third-party service provider |
-| 7 | TPSP LEI | LEI of the TPSP |
-| 8 | TPSP country of establishment | Country (ISO 3166-1 alpha-2) |
-| 9 | TPSP within group? | Is the TPSP part of the same corporate group as the entity? |
-| 10 | ICT service type | Nature of services (per CIR classification codes) |
-| 11 | ICT service description | Free-text description of specific services |
-| 12 | Critical or important function (CIF)? | Y/N — does this arrangement support a CIF? |
-| 13 | Function identifier | Reference to the function(s) supported |
-| 14 | Function description | Description of the supported function |
-| 15 | Data types processed | Classification of personal/non-personal data processed |
-| 16 | Data sensitivity | Sensitivity level of data (e.g., customer PII, financial data) |
-| 17 | Primary data storage location | Country(ies) where data is primarily stored |
-| 18 | Secondary/backup data storage location | Country(ies) where backup data is stored |
-| 19 | Contract start date | Effective date of the arrangement |
-| 20 | Contract end date or rolling | End date or indication of indefinite/rolling |
-| 21 | Notice period for termination | Minimum notice period (in days) |
-| 22 | Sub-processors used? | Y/N — does the TPSP sub-contract any services? |
-| 23 | Sub-processor names and LEIs | Name and LEI of each sub-processor |
-| 24 | Sub-processor data locations | Country(ies) of data processing by sub-processors |
-| 25 | Substitutability assessment | High / Medium / Low — ease of replacing this TPSP |
-| 26 | Exit strategy reference | Reference to the exit strategy document for this arrangement |
-| 27 | Last due diligence date | Date of most recent due diligence assessment |
-| 28 | Audit rights exercisable? | Y/N — can audit rights be exercised per contract? |
-| 29 | Audit method | Direct audit / pooled audit / third-party certification |
-
-### Register of Information — Key Points
-
-1. **All arrangements, not just critical ones.** The RoI covers every ICT service
-   arrangement, not only those supporting critical or important functions. The
-   criticality flag (field 12) distinguishes them within the register.
-
-2. **Sub-processors must be captured.** For each arrangement, the full chain of
-   sub-processors must be identified (fields 22–24). This is frequently incomplete
-   in practice.
-
-3. **Not a static document.** The RoI must be updated throughout the year as
-   arrangements change; the annual submission is a snapshot of the current state.
-
-4. **LEIs are mandatory.** Both the reporting entity and all TPSPs must have LEIs.
-   Where a TPSP does not have an LEI, the entity should document this and use
-   the TPSP's national business registration number as an alternative.
-
----
-
-## ICT Concentration Risk — Practical Assessment
-
-### What constitutes concentration risk under DORA?
-
-**Horizontal concentration:** Multiple critical functions supported by a single TPSP
-(e.g., core banking, fraud detection, and AML all on the same cloud provider).
-
-**Sectoral concentration:** Many financial entities within the EU using the same
-TPSP for critical functions — creating systemic risk even if each entity's own
-dependency appears manageable.
-
-**Geographic concentration:** All data and processing in a single geographic region
-or data centre cluster, creating correlated failure risk.
-
-### Concentration Risk Assessment Template
-
-For each TPSP supporting critical functions, assess:
-
-| Assessment Area | Question | Rating (H/M/L) |
-|----------------|----------|----------------|
-| Dependency depth | How many critical functions depend on this TPSP? | |
-| Substitutability | Could this service be replaced within the entity's recovery time objectives? | |
-| Contractual exit | Is there a viable exit path with adequate notice period and data portability? | |
-| Financial stability | Is there material risk of the TPSP becoming insolvent or discontinuing the service? | |
-| Geographic diversification | Are services provided from geographically diverse infrastructure? | |
-| Regulatory enforceability | Are audit and competent authority access rights practically exercisable? | |
-
-A TPSP rated High on any two or more areas should be treated as a concentration
-risk concern requiring mitigation action.
-
----
-
-## Oversight Framework for Critical ICT TPSPs (Art. 31–44)
-
-### Designation of Critical ICT TPSPs (Art. 31)
-
-ESAs (EBA, ESMA, EIOPA) jointly designate ICT TPSPs as **critical** based on
-CDR (EU) 2024/1502 criteria. The designation process:
-
-1. Financial entities submit their RoI annually
-2. ESAs aggregate RoI data to map TPSP dependencies across the EU financial sector
-3. ESAs apply CDR 2024/1502 criteria to assess systemic importance
-4. Designated CTPPs are notified and published
-5. ICT TPSPs not established in the EU that serve EU financial entities must
-   designate an EU-established legal representative (Art. 31(11))
-
-### Lead Overseer Assignment (Art. 32)
-
-Each designated CTPSP is assigned a **Lead Overseer** — one of EBA, ESMA, or EIOPA
-— based on the predominant type of financial entity served. The Lead Overseer
-coordinates with other ESAs via the **Joint Oversight Network (JON)**.
-
-**Joint Examination Teams (JETs):** Per CDR (EU) 2025/420, JETs are assembled
-from Lead Overseer and national authority staff to conduct on-site and off-site
-examinations of CTPPs.
-
-### Oversight Powers (Art. 33–38)
-
-| Power | Description |
-|-------|-------------|
-| Art. 33 — Information requests | Lead Overseer can require CTTPSs to provide information, data, and documents |
-| Art. 34 — General investigations | Including interviews, document reviews |
-| Art. 35 — On-site inspections | Physical inspection of CTPSP premises and systems |
-| Art. 36 — Recommendations | Lead Overseer issues recommendations for improvement |
-| Art. 37 — Follow-up | Follow-up recommendations and potential escalation |
-| Art. 38 — Oversight fees | Annual fees per CDR (EU) 2024/1505 |
-
-### What CTPSP Designation Means for Financial Entities
-
-- **No direct obligations change** for the financial entity when its TPSP is
-  designated critical — the entity's Art. 28–30 obligations apply regardless
-- The Lead Overseer interacts with the **CTPSP directly**
-- Financial entities must cooperate with information requests from the Lead
-  Overseer about their use of designated CTPPs (Art. 40)
-- Financial entities should note that oversight recommendations to a CTPSP
-  may result in changes to service terms — monitor this
-
----
-
-## Contract Review Checklist — DORA Art. 30(2) Compliance
-
-Use this checklist when reviewing existing contracts or negotiating new ones:
-
-| Clause | Required by | Present? | Gap? |
-|--------|------------|---------|------|
-| Clear service description | Art. 30(2)(a) | | |
-| Data location — primary and secondary | Art. 30(2)(b) | | |
-| Change notification for data locations | Art. 30(2)(b) | | |
-| GDPR/data protection provisions | Art. 30(2)(c) | | |
-| Service levels (availability, integrity, security) | Art. 30(2)(d) | | |
-| Audit rights — financial entity | Art. 30(2)(e) | | |
-| Audit rights — competent authority | Art. 30(2)(e) | | |
-| Audit rights — resolution authority | Art. 30(2)(e) | | |
-| Termination for cause | Art. 30(2)(f) | | |
-| Termination for regulatory reasons | Art. 30(2)(f) | | |
-| Minimum notice period on exit | Art. 30(2)(f) | | |
-| Incident reporting by TPSP to entity | Art. 30(2)(g) | | |
-| Data portability on exit | Art. 30(2)(h) | | |
-| Migration assistance commitment | Art. 30(2)(h) | | |
-| Data deletion/destruction certificate | Art. 30(2)(h) | | |
-| Sub-contracting — prior consent | Art. 30(2)(i) + CDR 2025/532 | | |
-| Sub-contracting — equivalent provisions | Art. 30(2)(i) + CDR 2025/532 | | |
-| Sub-processor change notification | CDR 2025/532 | | |
+# DORA — ICT Third-Party Risk Management Reference
+
+Chapter V, Articles 28–44, Regulation (EU) 2022/2554.
+Key implementing measures: CDR (EU) 2024/1773, CIR (EU) 2024/2956, CDR (EU) 2025/532,
+CDR (EU) 2024/1502, CDR (EU) 2024/1505, CDR (EU) 2025/295, CDR (EU) 2025/420.
+
+---
+
+## Overview: Two-Track Structure
+
+Chapter V operates on two parallel tracks:
+
+**Track 1 — Entity-level obligations (Art. 28–30):**
+Every financial entity must manage its own ICT third-party risks — regardless of
+whether its TPSPs are designated critical.
+
+**Track 2 — Systemic oversight of designated CTPPs (Art. 31–44):**
+ESAs designate and oversee ICT TPSPs that are systemically important to the
+EU financial sector. This is a supervisory regime, not an entity-level compliance task.
+
+---
+
+## Art. 28 — General Principles for ICT Third-Party Risk
+
+### Art. 28(1) — ICT Third-Party Risk Policy
+Every financial entity must adopt, regularly review, and update an **ICT third-party
+risk policy** covering:
+- Objectives and principles for managing ICT third-party risk
+- Criteria for identifying critical and important functions (CIF) vs. non-critical
+- Pre-contractual due diligence requirements
+- Contract lifecycle management (onboarding, monitoring, exit)
+- ICT concentration risk management
+- Governance roles and responsibilities
+
+**Key RTS:** CDR (EU) 2024/1773, Art. 1–12 (detailed policy content)
+
+### Art. 28(2) — Maintaining the Register of Information
+Financial entities must maintain and update the **Register of Information** (RoI)
+covering **all** ICT service arrangements (not only those supporting critical
+functions). See the Register of Information section below for full field details.
+
+### Art. 28(3) — Annual Submission of Register of Information
+The RoI must be submitted to the competent authority **at least annually** and
+upon specific request. The submission format follows CIR (EU) 2024/2956 templates.
+
+### Art. 28(4) — Pre-Contractual Due Diligence
+Before entering any new ICT service arrangement supporting a critical or important
+function, financial entities must:
+- **(a)** Assess whether the ICT service arrangement supports a critical or important function
+- **(b)** Assess the risks of the arrangement, including ICT concentration risk
+- **(c)** Carry out appropriate due diligence on prospective ICT TPSPs
+
+The due diligence must be documented and commensurate with the criticality of
+the function.
+
+### Art. 28(5) — Ongoing Monitoring of ICT TPSPs
+- Monitor the performance, security posture, and compliance of ICT TPSPs
+  throughout the contract lifecycle
+- Conduct regular reviews aligned with the contract terms and risk profile
+- Verify that ICT TPSPs continue to meet agreed service levels and security standards
+
+### Art. 28(6) — ICT Concentration Risk Assessment
+Financial entities must:
+- Assess the **concentration risk** arising from reliance on a single or limited
+  number of ICT TPSPs for critical functions
+- Determine whether the failure or unavailability of any TPSP would threaten the
+  entity's ability to maintain critical functions
+- Document this assessment and factor it into risk appetite and strategy
+
+**Common scenario:** A bank using a single hyperscaler (e.g., one major cloud
+provider) for core banking, treasury, and fraud detection creates high concentration
+risk even if the TPSP is not designated critical.
+
+### Art. 28(7) — Exit Strategy
+For each ICT arrangement supporting a critical or important function, financial entities must:
+- Develop and maintain an **exit strategy** covering:
+  - Conditions and triggers for exit
+  - Minimum notice period required to migrate services
+  - Data portability and return procedures
+  - Transition assistance obligations of the departing TPSP
+- Test exit strategies periodically (frequency: risk-based)
+
+---
+
+## Art. 29 — Preliminary Assessment of ICT Concentration Risk
+
+Before entering a new arrangement that would cause an entity's concentration in
+a single TPSP to increase for critical functions:
+- Conduct a specific **concentration risk assessment**
+- Document the assessment outcome and risk mitigation measures (if any)
+- Consider the systemic implications if the concentrated TPSP were to fail
+
+This is a transaction-specific obligation (triggered by entering a new arrangement)
+rather than an ongoing monitoring obligation (which is covered by Art. 28(6)).
+
+---
+
+## Art. 30 — Key Contractual Provisions
+
+### Scope: When does Art. 30(2) apply?
+
+Art. 30(2) applies to contracts for ICT services that support **critical or important
+functions**. A lighter set of provisions applies to non-critical arrangements
+(Art. 30(3)).
+
+### Critical or Important Function (CIF)
+
+A function is critical or important if its disruption would:
+- Materially impair the financial entity's compliance with legal obligations
+- Materially impair its financial performance, or
+- Materially impair the soundness or continuity of its services
+
+The criteria for identifying CIF are further specified in CDR (EU) 2024/1773.
+
+### Mandatory Contractual Provisions — Art. 30(2)(a)–(i)
+
+| Provision | DORA Requirement |
+|-----------|-----------------|
+| **(a)** Service description | Clear and complete description of the ICT services to be provided |
+| **(b)** Data locations | Location(s) where services will be provided and data stored/processed, including notification obligations if locations change |
+| **(c)** Data protection | Provisions ensuring data protection; compliance with applicable data protection law (GDPR where applicable) |
+| **(d)** Availability, authenticity, integrity, security | Service level specifications; security standards; incident response obligations of the TPSP |
+| **(e)** Audit and access rights | **Full and unrestricted audit rights** for the financial entity, its competent authorities (including ECB for significant institutions), and resolution authorities — including on-site inspection rights at the TPSP's premises |
+| **(f)** Termination rights | Conditions under which the financial entity may terminate; minimum notice periods; the TPSP's obligation to provide transition services |
+| **(g)** Reporting and monitoring | ICT incident reporting by the TPSP to the financial entity; performance monitoring; regular service reviews |
+| **(h)** Data portability and migration | On termination, the TPSP must provide all data in machine-readable format; migration assistance; data deletion certification |
+| **(i)** Sub-contracting | Conditions under which the TPSP may sub-contract ICT services; prior written consent requirement; equivalent contractual provisions in sub-processor contracts; right to audit sub-processors |
+
+**Key RTS:** CDR (EU) 2024/1773 specifies the detailed content of each provision.
+**Key RTS:** CDR (EU) 2025/532 specifies sub-contracting provisions in detail.
+
+### The Audit Rights Problem (Art. 30(2)(e))
+
+The most common contractual gap: large cloud providers offer only third-party
+audit reports (e.g., SOC 2, ISO 27001 certificates) rather than direct audit
+rights. DORA Art. 30(2)(e) requires:
+- **Full and unrestricted** audit rights for the financial entity
+- **Access rights for competent authorities** — including the right to inspect
+  the TPSP's premises
+
+ESA guidance has clarified that:
+- Pooled or third-party audits (SOC 2, ISO 27001 certification) may partially
+  satisfy the **entity's own audit right** where direct audit is genuinely
+  impracticable at hyperscale TPSPs — but only if the entity documents in writing
+  why direct audit is impracticable and confirms the pooled audit outputs are
+  meaningful and sufficient
+- Financial entities must still document their assessment of why pooled audits
+  are acceptable and ensure they receive meaningful, entity-specific outputs
+- **The competent authority's (and resolution authority's) on-site inspection
+  right under Art. 30(2)(e) is NON-WAIVABLE.** Even where the entity accepts
+  pooled audits, the contract must contain an express, unconditional clause
+  preserving the competent authority's right to inspect the TPSP's premises
+  directly. A clause that routes the authority's access through the TPSP's
+  third-party audit programme does NOT satisfy Art. 30(2)(e). This is a common
+  failure in standard cloud provider contracts.
+- Acceptance of pooled audits must be documented with a written risk acceptance
+  approved at an appropriate governance level (e.g., CRO or board)
+
+### Lighter Provisions for Non-Critical Arrangements (Art. 30(3))
+
+For ICT service arrangements that do not support critical or important functions:
+- Service description
+- Data locations
+- Basic availability and security commitments
+- Incident notification obligations
+- Exit/termination provisions
+
+Full Art. 30(2) provisions are not required.
+
+### Art. 30(4) — Review Before Renewal
+
+Before renewing any contract for ICT services supporting critical functions,
+financial entities must review whether:
+- Service levels remain adequate
+- Audit and access rights remain exercisable
+- Exit strategy remains viable
+- New risks (concentration, substitutability) have emerged
+
+---
+
+## Register of Information — Complete Field Reference (CIR (EU) 2024/2956)
+
+### When to Maintain and Submit
+
+- **Ongoing maintenance:** Update when new arrangements are entered, modified,
+  or terminated; when sub-processors change; when data locations change
+- **Annual submission:** At least annually to the competent authority
+- **On-demand submission:** Upon specific request from competent authority or ESA
+  (for the oversight framework of CTPPs under Art. 31)
+
+### Complete Field Set
+
+The RoI is structured around **arrangements** — each row represents one ICT
+service arrangement.
+
+| Field | Field Name (CIR 2024/2956) | Description |
+|-------|---------------------------|-------------|
+| 1 | Reporting entity LEI | Legal Entity Identifier of the financial entity |
+| 2 | Reporting entity name | Legal name |
+| 3 | Reporting entity type | Regulated entity type (credit institution, insurer, etc.) |
+| 4 | Arrangement reference | Unique internal reference for this arrangement |
+| 5 | Arrangement type | Type (outsourcing, SaaS, IaaS, PaaS, data services, etc.) |
+| 6 | TPSP legal name | Legal name of the ICT third-party service provider |
+| 7 | TPSP LEI | LEI of the TPSP |
+| 8 | TPSP country of establishment | Country (ISO 3166-1 alpha-2) |
+| 9 | TPSP within group? | Is the TPSP part of the same corporate group as the entity? |
+| 10 | ICT service type | Nature of services (per CIR classification codes) |
+| 11 | ICT service description | Free-text description of specific services |
+| 12 | Critical or important function (CIF)? | Y/N — does this arrangement support a CIF? |
+| 13 | Function identifier | Reference to the function(s) supported |
+| 14 | Function description | Description of the supported function |
+| 15 | Data types processed | Classification of personal/non-personal data processed |
+| 16 | Data sensitivity | Sensitivity level of data (e.g., customer PII, financial data) |
+| 17 | Primary data storage location | Country(ies) where data is primarily stored |
+| 18 | Secondary/backup data storage location | Country(ies) where backup data is stored |
+| 19 | Contract start date | Effective date of the arrangement |
+| 20 | Contract end date or rolling | End date or indication of indefinite/rolling |
+| 21 | Notice period for termination | Minimum notice period (in days) |
+| 22 | Sub-processors used? | Y/N — does the TPSP sub-contract any services? |
+| 23 | Sub-processor names and LEIs | Name and LEI of each sub-processor |
+| 24 | Sub-processor data locations | Country(ies) of data processing by sub-processors |
+| 25 | Substitutability assessment | High / Medium / Low — ease of replacing this TPSP |
+| 26 | Exit strategy reference | Reference to the exit strategy document for this arrangement |
+| 27 | Last due diligence date | Date of most recent due diligence assessment |
+| 28 | Audit rights exercisable? | Y/N — can audit rights be exercised per contract? |
+| 29 | Audit method | Direct audit / pooled audit / third-party certification |
+
+### Register of Information — Key Points
+
+1. **All arrangements, not just critical ones.** The RoI covers every ICT service
+   arrangement, not only those supporting critical or important functions. The
+   criticality flag (field 12) distinguishes them within the register.
+
+2. **Sub-processors must be captured.** For each arrangement, the full chain of
+   sub-processors must be identified (fields 22–24). This is frequently incomplete
+   in practice.
+
+3. **Not a static document.** The RoI must be updated throughout the year as
+   arrangements change; the annual submission is a snapshot of the current state.
+
+4. **LEIs are mandatory.** Both the reporting entity and all TPSPs must have LEIs.
+   Where a TPSP does not have an LEI, the entity should document this and use
+   the TPSP's national business registration number as an alternative.
+
+---
+
+## ICT Concentration Risk — Practical Assessment
+
+### What constitutes concentration risk under DORA?
+
+**Horizontal concentration:** Multiple critical functions supported by a single TPSP
+(e.g., core banking, fraud detection, and AML all on the same cloud provider).
+
+**Sectoral concentration:** Many financial entities within the EU using the same
+TPSP for critical functions — creating systemic risk even if each entity's own
+dependency appears manageable.
+
+**Geographic concentration:** All data and processing in a single geographic region
+or data centre cluster, creating correlated failure risk.
+
+### Concentration Risk Assessment Template
+
+For each TPSP supporting critical functions, assess:
+
+| Assessment Area | Question | Rating (H/M/L) |
+|----------------|----------|----------------|
+| Dependency depth | How many critical functions depend on this TPSP? | |
+| Substitutability | Could this service be replaced within the entity's recovery time objectives? | |
+| Contractual exit | Is there a viable exit path with adequate notice period and data portability? | |
+| Financial stability | Is there material risk of the TPSP becoming insolvent or discontinuing the service? | |
+| Geographic diversification | Are services provided from geographically diverse infrastructure? | |
+| Regulatory enforceability | Are audit and competent authority access rights practically exercisable? | |
+
+A TPSP rated High on any two or more areas should be treated as a concentration
+risk concern requiring mitigation action.
+
+---
+
+## Oversight Framework for Critical ICT TPSPs (Art. 31–44)
+
+### Designation of Critical ICT TPSPs (Art. 31)
+
+ESAs (EBA, ESMA, EIOPA) jointly designate ICT TPSPs as **critical** based on
+CDR (EU) 2024/1502 criteria. The designation process:
+
+1. Financial entities submit their RoI annually
+2. ESAs aggregate RoI data to map TPSP dependencies across the EU financial sector
+3. ESAs apply CDR 2024/1502 criteria to assess systemic importance
+4. Designated CTPPs are notified and published
+5. ICT TPSPs not established in the EU that serve EU financial entities must
+   designate an EU-established legal representative (Art. 31(11))
+
+### Lead Overseer Assignment (Art. 32)
+
+Each designated CTPSP is assigned a **Lead Overseer** — one of EBA, ESMA, or EIOPA
+— based on the predominant type of financial entity served. The Lead Overseer
+coordinates with other ESAs via the **Joint Oversight Network (JON)**.
+
+**Joint Examination Teams (JETs):** Per CDR (EU) 2025/420, JETs are assembled
+from Lead Overseer and national authority staff to conduct on-site and off-site
+examinations of CTPPs.
+
+### Oversight Powers (Art. 33–38)
+
+| Power | Description |
+|-------|-------------|
+| Art. 33 — Information requests | Lead Overseer can require CTTPSs to provide information, data, and documents |
+| Art. 34 — General investigations | Including interviews, document reviews |
+| Art. 35 — On-site inspections | Physical inspection of CTPSP premises and systems |
+| Art. 36 — Recommendations | Lead Overseer issues recommendations for improvement |
+| Art. 37 — Follow-up | Follow-up recommendations and potential escalation |
+| Art. 38 — Oversight fees | Annual fees per CDR (EU) 2024/1505 |
+
+### What CTPSP Designation Means for Financial Entities
+
+- **No direct obligations change** for the financial entity when its TPSP is
+  designated critical — the entity's Art. 28–30 obligations apply regardless
+- The Lead Overseer interacts with the **CTPSP directly**
+- Financial entities must cooperate with information requests from the Lead
+  Overseer about their use of designated CTPPs (Art. 40)
+- Financial entities should note that oversight recommendations to a CTPSP
+  may result in changes to service terms — monitor this
+
+---
+
+## Contract Review Checklist — DORA Art. 30(2) Compliance
+
+Use this checklist when reviewing existing contracts or negotiating new ones:
+
+| Clause | Required by | Present? | Gap? |
+|--------|------------|---------|------|
+| Clear service description | Art. 30(2)(a) | | |
+| Data location — primary and secondary | Art. 30(2)(b) | | |
+| Change notification for data locations | Art. 30(2)(b) | | |
+| GDPR/data protection provisions | Art. 30(2)(c) | | |
+| Service levels (availability, integrity, security) | Art. 30(2)(d) | | |
+| Audit rights — financial entity | Art. 30(2)(e) | | |
+| Audit rights — competent authority | Art. 30(2)(e) | | |
+| Audit rights — resolution authority | Art. 30(2)(e) | | |
+| Termination for cause | Art. 30(2)(f) | | |
+| Termination for regulatory reasons | Art. 30(2)(f) | | |
+| Minimum notice period on exit | Art. 30(2)(f) | | |
+| Incident reporting by TPSP to entity | Art. 30(2)(g) | | |
+| Data portability on exit | Art. 30(2)(h) | | |
+| Migration assistance commitment | Art. 30(2)(h) | | |
+| Data deletion/destruction certificate | Art. 30(2)(h) | | |
+| Sub-contracting — prior consent | Art. 30(2)(i) + CDR 2025/532 | | |
+| Sub-contracting — equivalent provisions | Art. 30(2)(i) + CDR 2025/532 | | |
+| Sub-processor change notification | CDR 2025/532 | | |