DORA Art.1–4: Scope, Definitions, and Proportionality — General Provisions for Financial Services (2026)

Post #506 in the sota.io EU Cyber Compliance Series

Before any DORA Article 5 board resolution, any Art.10 SIEM deployment, or any Art.19 incident report gets filed, a regulated entity needs to answer three threshold questions that Articles 1–4 address directly:

1. Does DORA apply to us at all? (Art.1–2)
2. What do the key terms in our obligations actually mean? (Art.3)
3. Which version of the obligations applies — full or simplified? (Art.4 + Art.16)

These are not formalities. Incorrect scope determinations have led to entities either over-complying (spending significant resources on inapplicable obligations) or being surprised by supervisory findings when they concluded DORA did not apply to them. Article 3 definitions are the anchor points for every audit finding — what counts as an "ICT-related incident," whether a function is "critical or important," and when a provider qualifies as a "critical ICT third-party provider" are all defined here and cited in every NCA enforcement action.

1. Art.1 — Subject Matter: What DORA Actually Regulates

Article 1 defines DORA's regulatory object in four components:

1.1 ICT Risk Requirements (Art.1(a)) DORA establishes requirements for the management of ICT risk in the financial sector. This covers the entire Art.5–16 Chapter II framework: governance, identification, protection, detection, recovery, testing, and third-party risk.

1.2 Incident Reporting (Art.1(b)) DORA creates a harmonised regime for reporting ICT-related incidents to competent authorities. This is Chapter III (Art.17–23): classification, materiality thresholds, the 4h/24h/5-day timeline cascade, and voluntary threat notifications.

1.3 Digital Operational Resilience Testing (Art.1(c)) DORA mandates testing of digital operational resilience. Chapter IV (Art.24–27) requires annual basic testing for all in-scope entities and Threat-Led Penetration Testing (TLPT) for significant entities under Art.26.

1.4 ICT Third-Party Risk (Art.1(d)) DORA establishes a framework for managing ICT third-party risk. Chapter V (Art.28–44) covers due diligence, contractual provisions, and the critical ICT third-party provider (CTPP) oversight regime under the Lead Overseer.

What Art.1 does NOT regulate:

• Prudential capital requirements (CRD/CRR regime)
• Consumer protection obligations (separate from DORA's operational resilience focus)
• Data protection processing rules (GDPR remains the applicable framework; DORA cross-references GDPR Art.5 where relevant)
• Cybersecurity product conformity (CRA Regulation 2024/2847 applies to manufacturers)

2. Art.2 — Scope of Application: The 21 Entity Categories

DORA Art.2(1) lists the financial entities to which the regulation applies. The complete list covers 21 categories:

2.1 Core Banking and Payments

2.2 Investment Services and Markets

2.3 Insurance and Pensions

2.4 Alternative and Crowdfunding

2.5 Explicit ICT Third-Party Providers

The 21st category under Art.2(1)(u):

• ICT third-party service providers — explicitly in scope for Chapter V oversight obligations only (not the full Art.5–16 framework)

2.6 Art.2 Exclusions — Who Is NOT in Scope

DORA Art.2(3) excludes the following categories regardless of size:

Member State discretion (Art.2(4)): Member States may exclude from DORA scope:

• IORPs operating pension schemes with total assets below certain thresholds
• Other specifically defined small financial entities

3. Art.3 — Statutory Definitions: The 56 Terms That Anchor Every Audit Finding

DORA Art.3 provides 56 definitions. These are not explanatory aids — they are the precise legal meanings that NCAs and the ESAs apply when issuing findings. The following definitions are most frequently contested in supervisory review or material for compliance program design.

3.1 ICT Risk (Art.3(2))

"Any reasonably identifiable circumstance in relation to the use of network and information systems, including a malfunction, capacity overflow, failure, disruption or impairment, which, if materialised, may compromise the security of the network and information systems, of any technology-dependent tool or process, of operations and processes, or of the provision of services by financial entities, thereby causing an adverse impact on the integrity or availability of data, or on the confidentiality of data, or on ICT-related services provided by that financial entity."

Practical scope: ICT risk under DORA is broader than cybersecurity. It explicitly includes:

• Capacity overflow (performance degradation under load)
• Failures (hardware faults, cloud availability events)
• Malfunctions (software bugs that affect operations)
• Disruptions (third-party outages)
• Impairments (degraded service without full failure)

A cloud provider SLA breach causing 30-minute degradation of a core banking service is an ICT risk materialisation. Whether it triggers Art.17 incident classification depends on the materiality thresholds — but it is within the definitional scope.

3.2 Critical or Important Function (Art.3(22))

"A function, the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the continued provision of a financial entity's activities and services, or have material effects on the financial entity's compliance with the conditions and obligations of its authorisation, or its other obligations under applicable financial services law."

Why this definition matters: The Art.3(22) definition is the gating criterion for:

• Art.28(2): ICT third-party risk assessment scope (only services supporting critical/important functions require full due diligence)
• Art.30(1): Mandatory contractual provisions (only for TSPs supporting critical/important functions)
• Art.26(1): TLPT scope (critical functions determine which systems undergo threat-led penetration testing)
• NCAs audit the mapping — undeclared critical functions are a frequent finding

The "materiality" threshold challenge: Neither DORA nor the ESA technical standards define a quantitative materiality threshold for Art.3(22). ECB guidance suggests applying the existing EBA RTS on outsourcing (Art.8) analogy: functions are "important" if their disruption would materially impair the entity's ability to meet regulatory obligations. EBA Opinion EBA/Op/2019/09 provides the most detailed guidance, though it predates DORA.

3.3 ICT-Related Incident (Art.3(8))

"A single event or a series of linked events unplanned by the financial entity that compromises the security of the network and information systems, and has an adverse impact or may have an adverse impact on the availability, authenticity, integrity or confidentiality of data or on the services provided by the financial entity."

Key elements:

• Unplanned: Scheduled maintenance outages are excluded by definition
• Single event or linked series: A multi-stage attack is one incident
• Actual or potential impact: Near-misses with potential impact qualify
• Four security properties: availability, authenticity, integrity, or confidentiality (not just availability)

3.4 Major ICT-Related Incident (Art.3(9))

An ICT-related incident that meets the materiality thresholds defined in Art.18(1) (as specified in the Commission Implementing Regulation 2024/2956). An incident only becomes "major" — triggering the Art.19 reporting cascade — when it crosses these quantitative thresholds. The definition itself does not set the thresholds; the ITS does.

Materiality threshold summary (Commission ITS 2024/2956):

3.5 Digital Operational Resilience (Art.3(1))

"The ability of a financial entity to build, assure and review its operational integrity and reliability by ensuring, either directly or indirectly through the use of services of ICT third-party service providers, the full range of ICT-related capabilities needed to address the security of the network and information systems which a financial entity uses, and which support the continued provision of financial services and their quality."

This is the foundational concept the entire regulation is built around. "Digital operational resilience" is not just uptime — it includes:

• The ability to detect incidents (Art.10)
• The ability to recover within defined RTOs (Art.11–12)
• The ability to learn and adapt (Art.13)
• The ability to test and verify resilience (Art.24–27)

3.6 Threat-Led Penetration Testing (Art.3(17))

"A framework that mimics the tactics, techniques and procedures of real-life threat actors perceived as posing a genuine cyber threat, that delivers a controlled, bespoke, intelligence-led (red team) test of the critical live production systems of the financial entity."

Distinct from standard penetration testing: TLPT must be intelligence-led, must target live production systems, and must follow the TIBER-EU framework or its national variants. Art.26 applies TLPT obligations only to significant entities as designated by competent authorities.

3.7 ICT Third-Party Service Provider (Art.3(19))

"An undertaking providing digital and data services, including providers of cloud computing services, software, data analytics, data centres, but excluding providers of hardware components and undertakings authorised under Union law which provide ICT services only incidentally to the provision of their main financial service."

Exclusions from the TSP definition:

• Hardware providers (selling servers without managed services)
• Financial entities that provide ICT services incidentally (a bank's IT subsidiary serving only group entities may be excluded depending on structure)

The "critical ICT third-party service provider" designation (Art.31) is a separate supervisory determination made by the Lead Overseer using criteria in Art.31(2).

3.8 Other Key Art.3 Definitions for Compliance Programs

4. Art.4 — Proportionality: How Size Shapes Obligations

Art.4 is the calibration article. It does not reduce the list of obligations — all in-scope entities must comply with all applicable articles. What Art.4 allows is the manner of implementation to be proportionate.

4.1 The Art.4 Proportionality Factors

Art.4(1) lists the factors NCAs and entities must consider:

"Financial entities shall implement the rules laid down in this Chapter in accordance with the principle of proportionality, taking into account their size and overall risk profile, and the nature, scale and complexity of their services, activities and operations."

Factor 1 — Size: Balance sheet total, transaction volume, number of clients. EBA and ECB supervisory practice maps to the CRD IV/V category system (significant institutions vs. less-significant institutions).

Factor 2 — Overall risk profile: Systemic importance, interconnectedness, substitutability. A small payment institution routing high transaction volumes has a higher risk profile than its balance sheet suggests.

Factor 3 — Nature: Retail vs. wholesale, domestic vs. cross-border, product complexity.

Factor 4 — Scale: Geographic reach, operational scope, cross-jurisdictional presence.

Factor 5 — Complexity: Number of ICT systems, interdependencies, cloud architecture complexity.

4.2 What Proportionality Allows in Practice

Proportionality under Art.4 affects implementation depth, not obligation existence:

4.3 Art.4 vs. Art.16: Two Different Things

Art.4 proportionality applies to all in-scope entities for implementation depth.

Art.16 simplified framework applies to specific smaller entity categories and replaces Art.5–15 with a lighter obligation set. These are distinct:

• Art.4: You comply with Art.5, but can implement it proportionately
• Art.16: You replace Art.5–15 entirely with the simplified framework if you qualify

Art.16 eligibility requires meeting all three size thresholds simultaneously:

• Fewer than 10 employees AND
• Annual turnover ≤ €2 million AND
• Annual balance sheet total ≤ €2 million

Plus the entity must be one of the Art.16-eligible types: payment institutions, account information service providers, small e-money institutions, certain insurance intermediaries, UCITS management companies, AIFMs below thresholds, and crowdfunding service providers.

Important: Art.16 does not simplify Chapter III (incident reporting) or Chapter V (third-party risk). Even microenterprises must report major ICT incidents under Art.19 and conduct ICT third-party risk assessments under Art.28.

5. Python: EntityScopeClassifier

The following implementation covers the Art.2 scope determination, Art.4 proportionality tier assignment, and Art.16 simplified framework eligibility check.

from dataclasses import dataclass, field
from enum import Enum
from typing import Optional


class EntityCategory(Enum):
    CREDIT_INSTITUTION = "credit_institution"
    PAYMENT_INSTITUTION = "payment_institution"
    AISPS = "account_information_service_provider"
    EMI = "electronic_money_institution"
    INVESTMENT_FIRM = "investment_firm"
    CASP = "crypto_asset_service_provider"
    ART_TOKEN_ISSUER = "asset_referenced_token_issuer"
    CCP = "central_counterparty"
    CSD = "central_securities_depository"
    TRADING_VENUE = "trading_venue"
    TRADE_REPOSITORY = "trade_repository"
    DATA_REPORTING = "data_reporting_service_provider"
    INSURANCE_UNDERTAKING = "insurance_undertaking"
    REINSURANCE_UNDERTAKING = "reinsurance_undertaking"
    INSURANCE_HOLDING = "insurance_holding_company"
    INSURANCE_INTERMEDIARY = "insurance_intermediary"
    ANCILLARY_INSURANCE_INTERMEDIARY = "ancillary_insurance_intermediary"
    IORP = "iorp"
    AIFM = "aifm"
    UCITS_MANAGEMENT = "ucits_management_company"
    CROWDFUNDING_CSP = "crowdfunding_service_provider"
    ICT_TSP = "ict_third_party_service_provider"
    NOT_IN_SCOPE = "not_in_scope"


class ProportionalityTier(Enum):
    SIGNIFICANT = "significant"      # Large institutions, systemic entities
    STANDARD = "standard"            # Mid-size entities
    SIMPLIFIED = "simplified"        # Art.16 microenterprise framework
    PROPORTIONATE = "proportionate"  # Art.4 reduced depth but full obligations


@dataclass
class EntityProfile:
    name: str
    category: EntityCategory
    # Size metrics
    employees: int
    annual_turnover_eur: float
    balance_sheet_eur: float
    # Risk profile indicators
    is_significant_institution: bool = False  # ECB SSM significant institution
    systemic_importance: str = "low"  # low, medium, high
    cross_border_presence: bool = False
    # Additional
    iorp_member_count: Optional[int] = None
    is_sub_threshold_aifm: bool = False
    notes: list[str] = field(default_factory=list)


@dataclass
class ScopeResult:
    in_scope: bool
    framework: ProportionalityTier
    applicable_chapters: list[str]
    exclusion_basis: Optional[str]
    art16_eligible: bool
    notes: list[str]


# Art.16-eligible entity types
ART16_ELIGIBLE_CATEGORIES = {
    EntityCategory.PAYMENT_INSTITUTION,
    EntityCategory.AISPS,
    EntityCategory.EMI,
    EntityCategory.INSURANCE_INTERMEDIARY,
    EntityCategory.ANCILLARY_INSURANCE_INTERMEDIARY,
    EntityCategory.UCITS_MANAGEMENT,
    EntityCategory.AIFM,
    EntityCategory.CROWDFUNDING_CSP,
}

# Entity types subject to Chapter V (ICT third-party risk) only
CHAPTER_V_ONLY = {EntityCategory.ICT_TSP}


def classify_entity(profile: EntityProfile) -> ScopeResult:
    """
    Determine DORA scope, proportionality tier, and applicable chapters.
    Based on Art.2 (scope), Art.4 (proportionality), and Art.16 (simplified framework).
    """
    notes = []

    # Step 1: Exclusions under Art.2(3)
    if profile.category == EntityCategory.NOT_IN_SCOPE:
        return ScopeResult(
            in_scope=False,
            framework=ProportionalityTier.SIMPLIFIED,
            applicable_chapters=[],
            exclusion_basis="Art.2(3): entity type explicitly excluded",
            art16_eligible=False,
            notes=["No DORA obligations apply"],
        )

    if profile.is_sub_threshold_aifm:
        return ScopeResult(
            in_scope=False,
            framework=ProportionalityTier.SIMPLIFIED,
            applicable_chapters=[],
            exclusion_basis="Art.2(3)(a): sub-threshold AIFM excluded",
            art16_eligible=False,
            notes=["AIFM below AIFMD Art.3 thresholds — DORA does not apply"],
        )

    if profile.category == EntityCategory.IORP and (
        profile.iorp_member_count is not None and profile.iorp_member_count < 15
    ):
        return ScopeResult(
            in_scope=False,
            framework=ProportionalityTier.SIMPLIFIED,
            applicable_chapters=[],
            exclusion_basis="Art.2(3)(c): IORP with fewer than 15 members excluded",
            art16_eligible=False,
            notes=["Very small IORP — DORA does not apply"],
        )

    # Step 2: ICT TSP — Chapter V only
    if profile.category == EntityCategory.ICT_TSP:
        return ScopeResult(
            in_scope=True,
            framework=ProportionalityTier.STANDARD,
            applicable_chapters=["Chapter V (Art.28-44): ICT Third-Party Risk"],
            exclusion_basis=None,
            art16_eligible=False,
            notes=["ICT TSPs are subject to Chapter V oversight only, not Art.5-16"],
        )

    # Step 3: Art.16 simplified framework eligibility check
    art16_size_eligible = (
        profile.employees < 10
        and profile.annual_turnover_eur <= 2_000_000
        and profile.balance_sheet_eur <= 2_000_000
    )
    art16_type_eligible = profile.category in ART16_ELIGIBLE_CATEGORIES
    art16_eligible = art16_size_eligible and art16_type_eligible

    if art16_eligible:
        notes.append("Art.16 simplified framework applies instead of Art.5-15")
        notes.append("Note: Art.17-23 (incident reporting) and Art.28-44 (third-party risk) still apply in full")
        return ScopeResult(
            in_scope=True,
            framework=ProportionalityTier.SIMPLIFIED,
            applicable_chapters=[
                "Art.16: Simplified ICT Risk Management Framework",
                "Chapter III (Art.17-23): ICT Incident Reporting (full obligations)",
                "Chapter IV (Art.24-27): DORA Testing (basic testing)",
                "Chapter V (Art.28-44): ICT Third-Party Risk (full obligations)",
            ],
            exclusion_basis=None,
            art16_eligible=True,
            notes=notes,
        )

    # Step 4: Proportionality tier for full-framework entities
    if profile.is_significant_institution or profile.systemic_importance == "high":
        tier = ProportionalityTier.SIGNIFICANT
        notes.append("Significant institution — full implementation depth expected by supervisor")
        if profile.is_significant_institution:
            notes.append("ECB SSM direct supervision — heightened expectations under Art.4")
    elif (
        profile.employees > 250
        or profile.annual_turnover_eur > 50_000_000
        or profile.cross_border_presence
    ):
        tier = ProportionalityTier.STANDARD
    else:
        tier = ProportionalityTier.PROPORTIONATE
        notes.append("Art.4 proportionality applies — implementation depth may be reduced")

    # Log Art.16 ineligibility reason if close to threshold
    if art16_size_eligible and not art16_type_eligible:
        notes.append(
            f"Entity type ({profile.category.value}) is not eligible for Art.16 "
            "simplified framework despite meeting size criteria — full Art.5-15 applies"
        )

    return ScopeResult(
        in_scope=True,
        framework=tier,
        applicable_chapters=[
            "Chapter II (Art.5-15): ICT Risk Management Framework",
            "Chapter III (Art.17-23): ICT Incident Reporting",
            "Chapter IV (Art.24-27): Digital Operational Resilience Testing",
            "Chapter V (Art.28-44): ICT Third-Party Risk Management",
        ],
        exclusion_basis=None,
        art16_eligible=False,
        notes=notes,
    )


# Usage example
if __name__ == "__main__":
    # Small payment institution — potentially Art.16 eligible
    small_pi = EntityProfile(
        name="EasyPay Ltd",
        category=EntityCategory.PAYMENT_INSTITUTION,
        employees=6,
        annual_turnover_eur=1_200_000,
        balance_sheet_eur=800_000,
    )
    result = classify_entity(small_pi)
    print(f"{small_pi.name}: {'IN SCOPE' if result.in_scope else 'NOT IN SCOPE'}")
    print(f"Framework: {result.framework.value}")
    print(f"Art.16 eligible: {result.art16_eligible}")
    for note in result.notes:
        print(f"  → {note}")
    print()

    # Mid-size credit institution
    mid_bank = EntityProfile(
        name="RegionalBank AG",
        category=EntityCategory.CREDIT_INSTITUTION,
        employees=450,
        annual_turnover_eur=85_000_000,
        balance_sheet_eur=2_400_000_000,
        cross_border_presence=True,
    )
    result2 = classify_entity(mid_bank)
    print(f"{mid_bank.name}: Framework: {result2.framework.value}")
    print(f"Chapters: {', '.join(result2.applicable_chapters[:2])}")

6. Common Scope Determination Errors

Error 1: Assuming the ICT subsidiary is out of scope

A bank's wholly-owned IT operations subsidiary that provides ICT services only to group entities may argue it falls under the Art.2(1)(u) exclusion ("undertakings authorised under Union law which provide ICT services only incidentally"). NCAs have consistently rejected this for dedicated ICT subsidiaries — "incidentally" means the ICT service is a by-product of the main regulated service, not the primary business activity. Dedicated group IT companies are typically in scope as ICT TSPs.

Error 2: Treating Art.4 proportionality as an exemption

Art.4 proportionality adjusts how deeply you implement Art.5–15 — it does not exempt any obligation. A small payment institution cannot simply skip the asset inventory (Art.8) citing proportionality; it can maintain a simpler inventory format than a systemic bank is expected to maintain.

Error 3: Missing the Art.3(22) critical function scope

Entities sometimes map "critical functions" narrowly to functions directly subject to regulatory obligations and miss operational dependencies. A payment institution's transaction routing middleware is a critical function even if it is not itself a licensed service — because its disruption would impair the licensed payment service. NCAs audit the mapping in detail.

Error 4: Applying DORA to parent entities without EU authorisation

DORA follows the regulatory authorisation, not ownership. A US-headquartered group's EU subsidiary that holds EU financial authorisation is in scope; the US parent is not, unless it separately holds EU authorisation. Third-country branches of EU-authorised entities follow Member State implementation rules.

Error 5: Confusing Art.16 microenterprise status with full proportionality

Some smaller entities qualify for Art.4 proportionality (reduced depth) but not Art.16 simplified framework (simplified obligation set). A payment institution with 15 employees falls outside Art.16 (≥10 employees fails the threshold) but is entitled to Art.4 proportionate implementation of the full Art.5–15 framework.

7. Scope Determination Decision Tree

Is the entity one of Art.2(1)(a)-(u)?
├── NO → DORA does not apply
└── YES → Does Art.2(3) exclusion apply?
    ├── YES (sub-threshold AIFM, very small IORP, etc.) → DORA does not apply
    └── NO → Is the entity an ICT TSP under Art.2(1)(u)?
        ├── YES → Chapter V only (Art.28-44)
        └── NO → Does entity meet ALL Art.16 criteria?
            ├── YES (size + eligible type) → Art.16 simplified framework
            │   (plus Art.17-23, Art.24-27, Art.28-44 in full)
            └── NO → Full DORA Art.5-15 + all chapters
                └── Apply Art.4 proportionality to implementation depth

8. Art.3 Definitions Most Frequently Cited in NCA Findings

Based on early DORA supervisory guidance from ECB, EBA, and national competent authorities:

9. Cross-Regulation Scope Mapping

DORA does not operate in isolation. Art.1(2) explicitly provides that DORA is lex specialis to NIS2 for financial entities:

"Where this Regulation is to be applied by financial entities and where Union law on financial services does not contain provisions on the management, classification or reporting of ICT risk or digital operational resilience testing, this Regulation shall apply."

Key interactions:

GDPR interaction: DORA Art.1(3) clarifies that data protection obligations under GDPR are not affected. Where an ICT-related incident involves personal data, both GDPR Art.33 (72-hour breach notification to DPA) and DORA Art.19 (4h/24h/5-day reporting to NCA) apply independently.

10. 15-Item DORA Art.1–4 Compliance Checklist

Use this checklist to verify your entity's baseline Art.1–4 compliance status:

Scope Determination (Art.2)

• 1. Entity classification against Art.2(1)(a)–(u) documented with legal basis and authorisation reference
• 2. Art.2(3) exclusion applicability assessed and documented (relevant for AIFMs, small IORPs, insurance captives)
• 3. Group structure map completed — which entities in the group are individually in scope
• 4. ICT subsidiary status determined (dedicated IT subsidiary vs. incidental provider)
• 5. Cross-border branches assessed — each EU-authorised entity assessed separately

Definitions Applied (Art.3)

• 6. "Critical or important function" mapping completed and approved by management body
• 7. Incident taxonomy aligned with Art.3(8) ICT-related incident definition (includes availability degradation, near-misses with potential impact)
• 8. Materiality threshold process documented against ITS 2024/2956 (Art.3(9) major incident determination)
• 9. ICT risk definition applied in risk register — includes capacity overflow, failures, and third-party impairments (not just cyber threats)
• 10. TSP register uses Art.3(19) definition — all cloud, software, data analytics, and data centre providers assessed for inclusion

Proportionality (Art.4 + Art.16)

• 11. Art.16 eligibility determination documented if entity is PAYMENT_INSTITUTION, AIFM, UCITS, or other Art.16-eligible type
• 12. Art.4 proportionality tier documented — size metrics (employees, turnover, balance sheet, systemic importance) recorded
• 13. Implementation depth decisions recorded — where proportionality applied, rationale documented
• 14. Art.16 simplified framework entities confirmed: incident reporting (Art.17–23) and third-party risk (Art.28–44) still apply in full
• 15. Annual review scheduled — proportionality tier reassessed if size or risk profile changes materially

11. Why EU-Native Infrastructure Matters for Art.3(2) ICT Risk

DORA Art.3(2) defines ICT risk to include any circumstance that "may compromise the security of the network and information systems" — including through the use of ICT third-party providers. The definition captures systemic exposure, not just direct attacks.

For financial entities using infrastructure from US-headquartered cloud providers, the CLOUD Act creates a legally distinct exposure: data stored on EU servers is accessible to US government authorities under 18 U.S.C. § 2713 regardless of where it is physically stored. This exposure:

• Falls within Art.3(2) ICT risk (it is an identifiable circumstance that may compromise data confidentiality)
• Is relevant to Art.3(22) critical function assessments if the data concerns client transactions or positions
• Must be addressed in Art.28 due diligence for TSPs supporting critical functions

Infrastructure deployed on sota.io — EU-native PaaS with no US-affiliated corporate structure — eliminates this exposure category at the architecture layer rather than managing it through contractual provisions that US courts may not recognise.

See Also

• DORA Art.5–9: ICT Risk Management Framework — Governance, Identification, and Protection
• DORA Art.15–16: ESA Technical Standards and the Simplified ICT Risk Management Framework
• DORA Art.17–18: ICT Incident Classification and Materiality Thresholds
• DORA Art.11: ICT Business Continuity Policy, RTO/RPO, and Annual Testing
• NIS2 × DORA Overlap for Financial Sector SaaS
• DORA Art.28–30: ICT Third-Party Risk — TSP Due Diligence and Contractual Provisions