2026-04-21·13 min read·

DORA Art.15-16: ESA Technical Standards and the Simplified ICT Risk Management Framework — Developer Guide 2026

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

DORA's Chapter II articles (Art.5–14) establish a comprehensive ICT risk management framework. But two questions remain after reading those articles:

What exactly counts as "sound" under Art.5(2)? What does "adequate" detection mean under Art.10? The principal articles use principles-based language. Art.15 answers these questions by mandating the ESAs to produce granular technical standards that translate principles into audit-ready requirements.
Is a 9-person fintech startup really subject to the same obligations as a systemically important bank? Art.16 answers this with a proportional simplified framework for microenterprises and certain smaller financial entities.

Together, Art.15 and Art.16 form the regulatory architecture layer of DORA Chapter II — the bridge between high-level principles and granular, entity-specific obligations.

1. Article 15 — ESA Mandate to Develop ICT Technical Standards

1.1 Legal Basis and Timeline

Art.15(1) gives EBA, EIOPA, and ESMA a joint mandate to develop regulatory technical standards (RTS) specifying elements of the ICT risk management framework. The ESAs were required to submit draft RTS to the European Commission within one year of DORA entry into force — i.e., by 17 January 2025.

The Commission then adopts the RTS as Commission Delegated Regulations, which have direct legal effect across all EU Member States without national transposition.

DORA Art.15 mandate → ESA joint draft RTS → Commission adoption → CDR published in OJ
Timeline: Jan 2024 → Jan 2025 → Q1-Q2 2025 → Applicable from 17 January 2025

1.2 Scope of Art.15 Mandates

Art.15 covers the following Chapter II articles:

Chapter II Article	Art.15 RTS Focus
Art.5 — ICT Risk Management Framework	Elements of the governance framework, senior management accountability
Art.6 — ICT Systems and Tools	Resilience, capacity management, geographic redundancy requirements
Art.7 — ICT Asset Management	Asset classification methodology, inventory granularity
Art.8 — ICT Risk Identification	Risk assessment methodology, tolerance thresholds
Art.9 — ICT Security Policies	Access control, cryptography, patch management, physical security
Art.10 — ICT Incident Detection	Monitoring thresholds, anomaly detection baselines
Art.11 — BCP Policy	Testing frequency evidence, activation threshold documentation
Art.12 — Backup Procedures	Backup frequency, recovery testing, geographic separation
Art.13 — Post-Incident Learning	Root cause analysis depth, corrective action tracking
Art.14 — Communication	Crisis communication standards, staff awareness content

Art.15 does not cover Chapter III (incident reporting — Art.16-23) or Chapter IV (resilience testing — Art.24-27), which have separate ESA mandates.

1.3 Published Commission Delegated Regulations

The principal CDR produced under the Art.15 mandate:

Commission Delegated Regulation (EU) 2024/1774 — published 25 June 2024 in the Official Journal. This is the primary technical standards act that specifies requirements for:

ICT security policy elements (Art.9(2) RTS)
Access management controls and privileged access management
Cryptographic algorithm selection and key management
Patch management cycles and vulnerability remediation timelines
Physical and environmental security requirements
Network segmentation and perimeter security

Commission Delegated Regulation (EU) 2024/1772 — covers the simplified ICT risk management framework for Art.16 entities (see Section 2 below).

Commission Delegated Regulation (EU) 2024/2439 — incident reporting formats for Art.20 ITS (Chapter III, separate mandate).

# Reference: Key CDRs under DORA Chapter II
CHAPTER_II_CDR_REFERENCES = {
    "2024/1774": {
        "title": "ICT Risk Management Tools, Methods, Processes and Policies",
        "oj_reference": "OJ L 2024/1774, 25 June 2024",
        "covers_articles": ["Art.9", "Art.10", "Art.11", "Art.12"],
        "applicable_from": "2025-01-17",
        "entities": "all_dora_scope_except_art16",
    },
    "2024/1772": {
        "title": "Simplified ICT Risk Management Framework",
        "oj_reference": "OJ L 2024/1772, 25 June 2024",
        "covers_articles": ["Art.16"],
        "applicable_from": "2025-01-17",
        "entities": "art16_simplified_framework",
    },
}

1.4 What CDR 2024/1774 Specifies in Practice

The CDR translates Art.9(2)'s "sound information security policies" into auditable requirements across six domains:

Domain 1 — Access Control (CDR 2024/1774, Chapter II)

Multi-factor authentication mandatory for privileged access to critical ICT systems
Privileged access management (PAM) solution required for system administrator accounts
Access review frequency: at minimum quarterly for privileged accounts, annually for standard accounts
Zero-trust principle applied to inter-system communication in critical functions

Domain 2 — Cryptography (CDR 2024/1774, Chapter III)

Algorithm selection must follow ENISA guidelines (minimum RSA-2048, AES-128, SHA-256)
Key management lifecycle documentation required (generation, distribution, storage, rotation, destruction)
Encryption at rest required for sensitive customer data in critical ICT systems
Transport encryption mandatory (TLS 1.2 minimum, 1.3 preferred)

Domain 3 — Patch Management (CDR 2024/1774, Chapter IV)

Critical vulnerabilities (CVSS ≥ 9.0): remediation within 1 business day for internet-facing critical systems
High vulnerabilities (CVSS 7.0–8.9): within 7 days
Medium vulnerabilities (CVSS 4.0–6.9): within 30 days
Documented exception process required for patches that cannot meet these timelines

Domain 4 — Network Security (CDR 2024/1774, Chapter V)

Network segmentation between production, development, and test environments
Demilitarised zone (DMZ) for external-facing services
Intrusion detection/prevention system (IDS/IPS) on critical network segments
Firewall rule review: at minimum semi-annually

Domain 5 — Physical Security (CDR 2024/1774, Chapter VI)

Defined security perimeters for critical ICT infrastructure locations
Physical access logs retained minimum 1 year
Clean desk policy and screen lock requirements

Domain 6 — Vulnerability Assessment (CDR 2024/1774, Chapter VII)

Automated vulnerability scanning: minimum monthly for internet-facing systems
Penetration testing frequency determined by entity's DORA classification (see Art.24-25)
Vulnerability register maintained and reviewed by CISO function

from dataclasses import dataclass, field
from enum import Enum
from datetime import date, timedelta

class CVSSSeverity(Enum):
    CRITICAL = "critical"   # ≥9.0
    HIGH = "high"           # 7.0-8.9
    MEDIUM = "medium"       # 4.0-6.9
    LOW = "low"             # 0.1-3.9

@dataclass
class PatchRemediationSLA:
    """CDR 2024/1774 Chapter IV patch management timelines."""
    severity: CVSSSeverity
    internet_facing_critical: int   # business days
    internal_critical: int
    non_critical: int

CDR_PATCH_SLAS = {
    CVSSSeverity.CRITICAL: PatchRemediationSLA(
        severity=CVSSSeverity.CRITICAL,
        internet_facing_critical=1,
        internal_critical=3,
        non_critical=7,
    ),
    CVSSSeverity.HIGH: PatchRemediationSLA(
        severity=CVSSSeverity.HIGH,
        internet_facing_critical=7,
        internal_critical=14,
        non_critical=30,
    ),
    CVSSSeverity.MEDIUM: PatchRemediationSLA(
        severity=CVSSSeverity.MEDIUM,
        internet_facing_critical=30,
        internal_critical=60,
        non_critical=90,
    ),
}

def get_patch_deadline(
    cvss_score: float,
    is_internet_facing: bool,
    is_critical_system: bool,
    discovery_date: date,
) -> date:
    """Calculate CDR 2024/1774-compliant patch deadline."""
    if cvss_score >= 9.0:
        severity = CVSSSeverity.CRITICAL
    elif cvss_score >= 7.0:
        severity = CVSSSeverity.HIGH
    elif cvss_score >= 4.0:
        severity = CVSSSeverity.MEDIUM
    else:
        severity = CVSSSeverity.LOW

    sla = CDR_PATCH_SLAS.get(severity)
    if not sla:
        return discovery_date + timedelta(days=180)

    if is_internet_facing and is_critical_system:
        days = sla.internet_facing_critical
    elif is_critical_system:
        days = sla.internal_critical
    else:
        days = sla.non_critical

    return discovery_date + timedelta(days=days)

2. Article 16 — Simplified ICT Risk Management Framework

2.1 Which Entities Qualify

Art.16 applies to a defined subset of DORA-scope entities — not all small entities, but specifically:

Entity Type	Qualifying Condition
Microenterprises	< 10 employees AND < €2M annual turnover AND < €2M balance sheet total
Small and medium investment firms	Within Art.2(1)(b) scope AND below MiFID II Art.32 thresholds
Payment institutions	Art.2(1)(e) entities designated as microenterprises
Electronic money institutions	Art.2(1)(f) entities designated as microenterprises
Small and non-interconnected investment firms	Art.2(1)(b) entities meeting MiFID II Art.32(1) criteria
Crowdfunding service providers	Art.2(1)(n) entities below thresholds in ECSPR Regulation
Crypto-asset service providers	Art.2(1)(d) CASPs that are microenterprises

Critical point: Being a microenterprise alone is not sufficient — the entity must also be within the DORA Art.2(1) scope. A 9-person fintech that is not a licensed financial entity is simply outside DORA's scope entirely. Art.16 is only relevant for DORA-scope microenterprises.

@dataclass
class EntityClassification:
    """Determine applicable DORA ICT risk framework."""
    employee_count: int
    annual_turnover_eur: float
    balance_sheet_eur: float
    entity_type: str  # one of DORA Art.2(1) categories
    is_dora_scope: bool

def determine_ict_framework(entity: EntityClassification) -> str:
    """Return applicable DORA ICT risk management framework."""
    if not entity.is_dora_scope:
        return "out_of_scope"

    # Art.16 microenterprise thresholds
    is_microenterprise = (
        entity.employee_count < 10
        and entity.annual_turnover_eur <= 2_000_000
        and entity.balance_sheet_eur <= 2_000_000
    )

    art16_eligible_types = {
        "payment_institution",
        "emi",
        "small_investment_firm",
        "crowdfunding_provider",
        "casp_micro",
    }

    if is_microenterprise and entity.entity_type in art16_eligible_types:
        return "simplified_art16"

    return "full_art5_15"

2.2 What the Simplified Framework Requires

CDR 2024/1772 defines the Art.16 simplified framework. It is not a compliance exemption — it is a proportional version of Art.5-14.

Retained obligations (apply to Art.16 entities in simplified form):

Full Framework	Simplified Equivalent
Art.5: ICT risk management framework	Basic ICT risk policy document, annual review
Art.6: ICT systems and tools	Core system inventory, availability targets defined
Art.7: ICT asset management	Simplified asset register (critical assets only)
Art.8: ICT risk identification	Annual risk assessment, documented
Art.9: ICT security policies	Password policy, MFA for admin access, basic patch process
Art.10: ICT incident detection	Log collection for critical systems, contact for reporting
Art.11: BCP policy	Basic continuity plan with RTO/RPO for critical functions
Art.12: Backup procedures	Daily backups of critical data, tested annually
Art.13: Post-incident review	Incident log maintained, root cause noted
Art.14: Communication	Named contact for ICT incidents, escalation path

Key differences from the full framework:

No CDR 2024/1774 granularity required: The specific CVSS patch timelines, DMZ requirements, and quarterly access reviews in CDR 2024/1774 apply to full-framework entities. Art.16 entities follow the simplified CDR 2024/1772 standards instead.
No Art.11(5) annual full-failover testing: Art.16 entities need to test their BCP annually but tabletop exercises are sufficient — full failover testing is not required.
No Art.14(1)(c) public communication templates: The simplified framework focuses on internal escalation paths, not public communication plans.
Proportional asset inventory: Art.7 for full-framework entities requires a comprehensive asset register across all ICT components. Art.16 entities need only identify and document critical assets.

2.3 The Simplified ICT Security Policy Template

CDR 2024/1772 Annex I provides a template structure. Minimum required sections:

@dataclass
class Art16SimplifiedICTPolicy:
    """Minimum required policy structure under CDR 2024/1772 Annex I."""

    # Section 1: Scope and Objectives
    entity_name: str
    policy_owner: str            # must be C-level
    policy_version: str
    review_date: date            # at least annual
    critical_ict_systems: list[str]

    # Section 2: Access Control (CDR 2024/1772 Art.4)
    admin_mfa_enabled: bool      # MANDATORY — no simplified exception
    password_policy: str         # minimum complexity defined
    admin_account_list: str      # reference to maintained register

    # Section 3: Data Protection (CDR 2024/1772 Art.5)
    sensitive_data_locations: list[str]
    encryption_at_rest: bool     # for sensitive customer data
    encryption_in_transit: bool  # TLS minimum

    # Section 4: Patch Management (CDR 2024/1772 Art.6)
    patch_process_description: str
    critical_patch_timeline_days: int  # max 30 days (vs 1 day in CDR 2024/1774)

    # Section 5: Backup (CDR 2024/1772 Art.7 — mirrors Art.12)
    backup_frequency: str        # "daily" for critical data
    backup_test_frequency: str   # "annual" minimum
    rto_hours: int               # must be defined
    rpo_hours: int               # must be defined

    # Section 6: Incident Response
    incident_contact: str        # named person or role
    nca_notification_contact: str

    # Section 7: Annual Review Record
    last_review_date: date
    reviewer: str
    changes_made: str

    def validate_minimum_requirements(self) -> list[str]:
        """Return list of compliance gaps."""
        gaps = []
        if not self.admin_mfa_enabled:
            gaps.append("CRITICAL: MFA for admin accounts is mandatory under CDR 2024/1772 Art.4(1)")
        if not self.encryption_at_rest:
            gaps.append("HIGH: Encryption at rest for sensitive customer data required")
        if self.critical_patch_timeline_days > 30:
            gaps.append(f"MEDIUM: Critical patch timeline {self.critical_patch_timeline_days}d exceeds 30-day maximum")
        if self.rto_hours == 0 or self.rpo_hours == 0:
            gaps.append("HIGH: RTO and RPO must be defined (not zero)")
        return gaps

2.4 Art.16 vs. Full Framework: Decision Matrix

┌─────────────────────────────────────────────────────────────┐
│  Is your entity within DORA Art.2(1) scope?                 │
│                    │                                         │
│         No ────────┴──────────► Not subject to DORA         │
│         │                                                    │
│         ▼                                                    │
│  Does your entity meet ALL three criteria?                   │
│  1. < 10 employees                                           │
│  2. ≤ €2M annual turnover                                   │
│  3. ≤ €2M balance sheet                                     │
│                    │                                         │
│   No ──────────────┴──────────► Full Art.5-15 + CDR 2024/1774│
│   │                                                          │
│   ▼                                                          │
│  Is your entity type Art.16-eligible?                        │
│  (PSP, EMI, CASP, small investment firm, etc.)               │
│                    │                                         │
│   No ──────────────┴──────────► Full Art.5-15 + CDR 2024/1774│
│   │                                                          │
│   ▼                                                          │
│  Simplified Art.16 framework + CDR 2024/1772                 │
└─────────────────────────────────────────────────────────────┘

3. Interaction Between Art.15 and Art.16

The two articles work as a tiered standards architecture:

Full-scope entities (Art.2(1), not Art.16):
  → Subject to Art.5-14 as specified by Art.15 RTS (CDR 2024/1774)
  → Higher granularity, shorter remediation timelines, comprehensive documentation

Art.16 entities:
  → Subject to simplified Art.5-14 as specified by Art.16 RTS (CDR 2024/1772)
  → Reduced documentation depth, longer remediation timelines, proportional testing

What is NOT simplified for Art.16 entities:

The following obligations apply in full regardless of Art.16 status:

Chapter III (Incident Reporting, Art.17-23): Art.16 does not modify incident reporting obligations. A microenterprise payment institution must still report major ICT incidents within the Art.19 timelines (4h initial, 72h intermediate, 30 days final).
Chapter IV (Resilience Testing, Art.24-27): Basic testing obligations from Art.24 apply. TLPT (Art.26-27) applies only to significant entities designated by NCAs.
Chapter V (Third-Party Risk, Art.28-44): ICT third-party risk management obligations apply in full to Art.16 entities.
Chapter VI (Information Sharing, Art.45): Applies to all entities.

4. NCA Supervisory Approach to Art.15-16

4.1 How NCAs Use CDR 2024/1774 in Audits

CDR 2024/1774 functions as a de facto audit checklist. NCA examiners will specifically test against the six CDR domains:

CDR Domain	Typical NCA Evidence Request
Access Control	PAM solution name and version, privileged access review logs, MFA configuration screenshots
Cryptography	Certificate inventory, key rotation logs, TLS configuration output
Patch Management	Vulnerability scanner output, patch ticket logs, exception register
Network Security	Network diagram with segmentation, firewall rule review records
Physical Security	Datacenter entry logs, clean desk policy acknowledgements
Vulnerability Assessment	Last 12 months scanner reports, pentest report

4.2 CDR Gap Assessment for Art.16 Entities

Art.16 entities cannot rely on CDR 2024/1774 non-compliance as a defence if they fail to meet CDR 2024/1772 standards. The simplified framework is still legally binding.

A common NCA finding: Art.16 entities believe "simplified = minimal effort" and produce a one-page policy that names no systems, defines no RTO/RPO, and has no evidence of annual review. CDR 2024/1772 requires actual documentation with the specific elements listed in Annex I.

def assess_art16_readiness(policy: Art16SimplifiedICTPolicy) -> dict:
    """Produce CDR 2024/1772 gap assessment report."""
    gaps = policy.validate_minimum_requirements()

    # Additional CDR 2024/1772 Annex I checks
    annex_checks = []
    if not policy.critical_ict_systems:
        annex_checks.append("No critical ICT systems identified — Annex I Section 2.1 requires list")
    if not policy.nca_notification_contact:
        annex_checks.append("No NCA notification contact — required for Art.19 incident reporting readiness")
    days_since_review = (date.today() - policy.last_review_date).days
    if days_since_review > 365:
        annex_checks.append(f"Policy review overdue by {days_since_review - 365} days")

    return {
        "framework": "simplified_art16_cdr_2024_1772",
        "critical_gaps": [g for g in gaps if g.startswith("CRITICAL")],
        "high_gaps": [g for g in gaps if g.startswith("HIGH")] + annex_checks,
        "medium_gaps": [g for g in gaps if g.startswith("MEDIUM")],
        "compliant": len([g for g in gaps if g.startswith("CRITICAL") or g.startswith("HIGH")]) == 0,
    }

5. Common Implementation Errors

Error	What Happens	Correct Approach
Treating Art.16 as a full exemption	NCA finds no documentation, issues binding instruction	Apply CDR 2024/1772 in full — simplified ≠ none
Not checking CDR 2024/1774 for Art.15 obligations	Using generic security policy, fails audit on patch timelines	Map your policies to CDR 2024/1774 six domains
Misidentifying as Art.16 entity	Full-scope entity uses simplified framework, major gaps	Run Art.16 eligibility check against all three criteria
Ignoring incident reporting for Art.16 entities	Missing 4h notification for major ICT incident	Art.16 does not reduce Chapter III obligations
Not updating policies when CDR changes	Operating on pre-2025 policies that don't reference CDR	Review annually against current CDR text
Patch SLA from CDR 2024/1774 for Art.16 entity	Unnecessarily strict timelines cause resource strain	Use CDR 2024/1772 30-day window for critical patches

6. Cross-Framework Mapping

Obligation	DORA Art.15/CDR 2024/1774	NIS2 Art.21	ISO 27001:2022
Security policy	Art.9(2) + CDR Ch.II	Art.21(1)	Annex A 5.1
Access management	CDR Ch.II (MFA, PAM)	Art.21(2)(i)	Annex A 5.15-5.18
Cryptography	CDR Ch.III	Art.21(2)(h)	Annex A 8.24
Patch management	CDR Ch.IV	Art.21(2)(e)	Annex A 8.8
Network segmentation	CDR Ch.V	Art.21(2)(a)	Annex A 8.22
Vulnerability assessment	CDR Ch.VII	Art.21(2)(e)	Annex A 8.8

NIS2 essential/important entities that are also DORA-scope must satisfy CDR 2024/1774 — in most areas CDR 2024/1774 is more prescriptive than NIS2 Art.21, so CDR compliance implies NIS2 compliance for overlapping obligations.

7. 18-Item NCA Compliance Checklist

Art.15 / CDR 2024/1774 (Full-scope entities)

1. ICT security policy references CDR 2024/1774 and is dated post-January 2025
2. MFA enforced on all privileged accounts (CDR Ch.II)
3. PAM solution deployed for system administrator accounts
4. Access review completed in last 90 days for privileged accounts
5. Cryptography policy specifies approved algorithms aligned to ENISA guidelines
6. Key management lifecycle documented (generation through destruction)
7. Patch SLA defined: critical 1 day / high 7 days / medium 30 days for critical internet-facing systems
8. Vulnerability scanner runs at minimum monthly on internet-facing systems
9. Network segmentation diagram current, prod/dev/test separated
10. Firewall rule review completed in last 6 months
11. Physical access logs for ICT infrastructure retained ≥ 1 year
12. Vulnerability register maintained and CISO reviews quarterly

Art.16 / CDR 2024/1772 (Simplified framework entities)

13. Art.16 eligibility confirmed (all three thresholds verified, entity type eligible)
14. Simplified ICT policy exists with all Annex I sections completed
15. Critical ICT systems identified and listed
16. MFA for admin accounts enabled (no exception even under Art.16)
17. RTO and RPO defined for critical functions
18. Annual policy review completed and documented