2026-04-17·17 min read·

DORA Art.10: ICT-Related Incident Detection — SIEM Integration, Anomaly Monitoring, and Multi-Layer Controls for Financial Entities (2026)

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

DORA Chapter II defines a six-domain ICT risk management framework. Article 10 sits at the detection layer — the critical bridge between the protection controls mandated by Art.9 and the business continuity obligations of Art.11. Without functioning detection, protection becomes reactive and continuity becomes guesswork.

The regulation requires financial entities to implement mechanisms that can promptly detect anomalous activities, ICT network performance degradation, and ICT-related incidents — including targeted cyber-attacks. This is not a passive logging obligation. DORA Art.10 requires multi-layer controls, calibrated alert thresholds, and automated escalation paths to ICT-related incident response processes.

This guide walks through all three Art.10 obligations, explains what detection architecture satisfies them, provides a Python self-assessment tool, maps the requirements to NIS2 Art.21(2)(b) for dual-regulated entities, and closes with a 25-item compliance checklist.

1. Who Is Subject to DORA Art.10

DORA Art.2(1) defines scope. Art.10 applies to all approximately 22,000 EU financial entities across the same categories as Art.5–9:

Directly in scope:

Credit institutions (banks under CRD VI)
Payment institutions and e-money institutions
Investment firms (MiFID II)
Insurance and reinsurance undertakings (Solvency II)
Central counterparties (CCPs), central securities depositories (CSDs)
Trading venues, trade repositories, credit rating agencies
Crypto-asset service providers (MiCA)
Crowdfunding service providers

Microenterprise simplified path (Art.16): Entities with fewer than 10 employees and annual turnover/balance sheet ≤ €2M may implement a simplified detection framework. They still must meet the core Art.10 obligations but with proportionate tooling — a centralised log aggregation tool and manual daily review may satisfy Art.10(3) where a full SIEM would be required for larger entities.

Indirect scope — SaaS and cloud providers: Even if your platform is not a financial entity, your financial sector customers will contractually push DORA Art.30 detection requirements downstream. ICT third-party providers are increasingly expected to evidence their own detection capabilities, incident escalation procedures, and alert SLAs in the DORA contractual register.

2. The Three Art.10 Obligations

Art.10(1): Prompt Detection of Anomalous Activities

"Financial entities shall have in place mechanisms to promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents, and to identify potential material single points of failure."

Three detection targets are explicitly named:

Anomalous activities — deviations from established baselines in user behaviour, system activity, or data access patterns
ICT network performance issues — latency spikes, packet loss, throughput degradation, DNS anomalies
ICT-related incidents — events that have actually compromised availability, authenticity, integrity, or confidentiality

The addition of single point of failure (SPOF) identification is notable. Art.10(1) is not purely reactive detection — it also requires proactive topology and dependency analysis to map where a single component failure would cascade to critical business functions (CBFs) defined under Art.11.

What this means in practice:

You need baseline profiles for all Tier 1 and Tier 2 ICT assets (defined under Art.8)
Network and system performance monitoring must cover CBF-supporting infrastructure
SPOF mapping must be documented and reviewed at minimum annually (or after major changes)

Art.10(2): Multi-Layer Controls and Alert Thresholds

"Detection mechanisms referred to in paragraph 1 shall enable multiple layers of control, shall define alert thresholds and criteria to trigger and initiate ICT-related incident response processes, including automatic alert mechanisms for staff in charge of ICT-related incident response."

Art.10(2) adds three specific requirements to the detection obligation:

Multiple layers of control — No single detection mechanism satisfies the regulation. NCA guidance consistently interprets this as requiring at minimum:

Network-layer detection (IDS/IPS, NetFlow analysis, DNS monitoring)
Host-layer detection (EDR, file integrity monitoring, OS audit logs)
Application-layer detection (WAF, API anomaly detection, authentication event monitoring)
Data-layer detection (DLP, database activity monitoring, privileged access logging)

Alert thresholds defined — Detection rules must have explicit, documented thresholds. NCAs have cited entities whose SIEM rules were present but undocumented — no rationale for why a threshold was set, no review history, no link to the ICT risk register.

Automatic alert mechanisms — Manual log review alone does not satisfy Art.10(2). The regulation requires automated alerting to the incident response team. This means SIEM, SOAR, or equivalent systems with documented escalation paths to the IR team.

Art.10(3): Resourcing for User Activity and Cyber-Attack Monitoring

"Financial entities shall devote sufficient resources and capabilities to monitor user activity, the occurrence of ICT anomalies and ICT-related incidents, in particular cyber-attacks."

Three specific monitoring domains:

User activity monitoring — This includes privileged user monitoring, insider threat detection, and access pattern analysis. NCA examiners look for evidence that privileged access (admin, service accounts, vendor access) is actively monitored, not just logged.
ICT anomaly monitoring — Continuous monitoring rather than periodic review. For Tier 1 CBF-supporting systems, this typically means near-real-time alerting (sub-5-minute detection-to-alert latency for critical events).
Cyber-attack monitoring in particular — The phrase "in particular" elevates cyber-attack detection above general monitoring. This requires threat intelligence integration (known IOCs, TTPs from MITRE ATT&CK), attack surface monitoring, and the ability to detect multi-stage attack patterns.

The "sufficient resources" language creates a documentation obligation. NCA auditors ask for evidence of budget allocation, staffing headcount for monitoring functions, and tooling investment proportional to the entity's ICT risk profile.

3. Detection Architecture for DORA Compliance

The Multi-Layer Detection Stack

A DORA-compliant detection architecture for a typical financial entity should span four layers:

┌─────────────────────────────────────────────────────────┐
│  LAYER 4: DATA LAYER                                     │
│  • Database Activity Monitoring (DAM)                    │
│  • DLP: sensitive data exfiltration detection            │
│  • Object storage access anomaly detection               │
│  • Privileged data access alerts                         │
├─────────────────────────────────────────────────────────┤
│  LAYER 3: APPLICATION LAYER                              │
│  • WAF: OWASP Top 10, injection, XSS detection           │
│  • API gateway: rate limiting, auth failure tracking     │
│  • Authentication events: MFA bypass, impossible travel  │
│  • Session anomalies: duration, volume, geography        │
├─────────────────────────────────────────────────────────┤
│  LAYER 2: HOST LAYER                                     │
│  • EDR: process anomalies, lateral movement, fileless    │
│  • File Integrity Monitoring (FIM): critical path changes│
│  • OS audit logs: sudo, SSH, cron, account changes       │
│  • Container runtime security: privileged escape, drift  │
├─────────────────────────────────────────────────────────┤
│  LAYER 1: NETWORK LAYER                                  │
│  • IDS/IPS: known attack signatures                      │
│  • NetFlow: traffic baseline deviation, beaconing        │
│  • DNS: tunnelling, DGA domains, suspicious resolutions  │
│  • Network performance: latency, packet loss, jitter     │
└─────────────────────────────────────────────────────────┘
              ↓ all layers feed into ↓
┌─────────────────────────────────────────────────────────┐
│  SIEM / DETECTION PLATFORM                               │
│  • Log aggregation and normalisation                     │
│  • Correlation rules and detection analytics             │
│  • Alert threshold management with documented rationale  │
│  • Automatic escalation to IR team (SOAR or pagerduty)  │
└─────────────────────────────────────────────────────────┘

Alert Threshold Design

DORA Art.10(2) requires thresholds to be defined and documented. Best practice follows a criticality-tiered threshold model aligned to Art.8 asset classification:

Tier	Asset Type	Detection-to-Alert Target	Review Frequency
Tier 1	Critical CBF-supporting systems	≤ 5 minutes	Daily
Tier 2	Important supporting systems	≤ 30 minutes	Weekly
Tier 3	Standard business systems	≤ 4 hours	Monthly
Tier 4	Non-production systems	Next business day	Quarterly

For each detection rule, the threshold documentation should capture:

Rule ID and name — uniquely identifiable in the SIEM
Detection target — what activity or condition triggers the rule
Threshold value — the specific count, rate, or condition that fires the alert
Rationale — why this threshold was chosen (risk register link, historical incident data, threat intelligence)
Last reviewed — date of most recent review and who approved
Escalation path — who receives the alert and what the initial response action is

User Behaviour Analytics (UBA) for Art.10(3)

Art.10(3) specifically requires monitoring of user activity. For financial entities, the highest-priority UBA use cases are:

Privileged user monitoring:

Administrative access outside business hours
Bulk data export by privileged accounts
Privilege escalation (sudo, role assignment changes)
Service account activity from unexpected source IPs
Failed authentication attempts on privileged accounts

Insider threat indicators:

Unusual volume of file access or data download
Access to systems outside normal job function
Access pattern changes preceding resignation or termination notice
Data staging activity (compression, archiving, upload to external services)

Vendor and third-party access:

Vendor sessions outside contracted maintenance windows
Lateral movement from vendor-accessed systems
Access to out-of-scope systems during vendor sessions

4. SIEM Detection Rules for DORA Art.10

The following Sigma-format detection rules cover core Art.10(3) monitoring requirements:

# DORA Art.10(3) — Privileged User Activity Outside Hours
title: DORA Art.10 Privileged Admin Access Outside Business Hours
id: dora-art10-001
status: stable
description: >
  Detects administrative access to Tier 1 and Tier 2 systems
  outside defined business hours. DORA Art.10(3) requires monitoring
  of user activity, in particular for privileged accounts.
logsource:
  category: authentication
  product: any
detection:
  selection:
    EventID: 4624  # Windows / equivalent for Linux: ssh_session_opened
    LogonType: 10  # Remote interactive / SSH
    AccountType: 'Admin'
  timeframe:
    not_between:
      - "07:00"
      - "20:00"
  condition: selection AND timeframe
falsepositives:
  - Documented maintenance windows (requires suppression rule)
  - On-call incident response (requires suppression rule)
level: medium
tags:
  - attack.persistence
  - dora.art10.3
  - nca.audit.evidence

---
# DORA Art.10(3) — Bulk Data Export Detection
title: DORA Art.10 Bulk Data Export by Internal User
id: dora-art10-002
status: stable
description: >
  Detects data export events exceeding defined thresholds.
  Covers DORA Art.10(3) user activity monitoring and
  data-layer detection per Art.10(2) multi-layer requirement.
logsource:
  category: file_access
  product: any
detection:
  selection:
    EventType: 'file_download'
    FileSizeBytes|gt: 104857600  # >100MB in 15-minute window
  timeframe: 15m
  condition: selection | count() by User > 1
level: high
tags:
  - attack.exfiltration
  - dora.art10.3
  - nca.audit.evidence

---
# DORA Art.10(1) — ICT Performance Anomaly
title: DORA Art.10 Critical System Latency Spike
id: dora-art10-003
status: stable
description: >
  Detects latency exceeding threshold on Tier 1 CBF-supporting
  systems. Covers DORA Art.10(1) ICT network performance issue
  detection requirement.
logsource:
  category: apm
  product: any
detection:
  selection:
    ServiceTier: 'Tier1'
    LatencyP99Ms|gt: 2000  # >2000ms P99 — threshold from risk register
  timeframe: 5m
  condition: selection | count() > 3  # sustained, not single spike
level: high
tags:
  - dora.art10.1
  - nca.audit.evidence

5. Python DORADetectionChecker

"""
DORA Art.10 Detection Self-Assessment Tool
Evaluates detection mechanisms against the three Art.10 obligations.
"""

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


class AssetTier(Enum):
    TIER1_CRITICAL = "tier1_critical"
    TIER2_IMPORTANT = "tier2_important"
    TIER3_STANDARD = "tier3_standard"
    TIER4_NON_PROD = "tier4_non_production"


class DetectionLayer(Enum):
    NETWORK = "network"
    HOST = "host"
    APPLICATION = "application"
    DATA = "data"


@dataclass
class DetectionRule:
    rule_id: str
    layer: DetectionLayer
    asset_tier: AssetTier
    threshold_documented: bool
    threshold_rationale: str  # link to risk register entry
    last_reviewed: str  # ISO date
    auto_escalation: bool
    escalation_target: str  # IR team / oncall group


@dataclass
class UserMonitoringControl:
    covers_privileged_users: bool
    covers_vendor_access: bool
    covers_bulk_data_export: bool
    detection_to_alert_minutes: int  # for Tier 1 assets
    monitoring_hours: str  # "24x7", "business_hours", "none"


@dataclass
class DORADetectionAssessment:
    entity_name: str
    assessment_date: str
    rules: list[DetectionRule] = field(default_factory=list)
    user_monitoring: Optional[UserMonitoringControl] = None
    spof_mapping_current: bool = False
    spof_last_reviewed: Optional[str] = None
    siem_deployed: bool = False
    threat_intel_integrated: bool = False

    def check_art10_1(self) -> dict:
        """Art.10(1): Prompt detection of anomalies and SPOF identification."""
        findings = []
        score = 0

        layers_covered = {r.layer for r in self.rules}
        tier1_rules = [r for r in self.rules if r.asset_tier == AssetTier.TIER1_CRITICAL]

        if DetectionLayer.NETWORK in layers_covered:
            score += 20
        else:
            findings.append("FAIL: No network-layer detection rules — Art.10(1) anomalous activity requirement not met")

        if tier1_rules:
            score += 20
        else:
            findings.append("FAIL: No detection rules targeting Tier 1 critical assets — highest-risk gap for NCA audit")

        if self.spof_mapping_current:
            score += 30
        else:
            findings.append("FAIL: SPOF mapping not documented or not current — Art.10(1) explicit SPOF identification requirement")

        if self.siem_deployed:
            score += 30
        else:
            findings.append("FAIL: No SIEM deployed — Art.10(1) prompt detection not achievable without centralised log correlation")

        return {"article": "Art.10(1)", "score": score, "max": 100, "findings": findings}

    def check_art10_2(self) -> dict:
        """Art.10(2): Multi-layer controls, documented thresholds, auto-escalation."""
        findings = []
        score = 0

        layers_covered = {r.layer for r in self.rules}
        layer_count = len(layers_covered)

        if layer_count >= 4:
            score += 30
        elif layer_count >= 2:
            score += 15
            findings.append(f"WARN: Only {layer_count} detection layers — Art.10(2) requires multiple layers; NCA expects 4+ for significant entities")
        else:
            findings.append(f"FAIL: Single detection layer — Art.10(2) multiple layers requirement not met")

        documented_rules = [r for r in self.rules if r.threshold_documented and r.threshold_rationale]
        if self.rules and len(documented_rules) / len(self.rules) >= 0.8:
            score += 35
        elif self.rules and len(documented_rules) / len(self.rules) >= 0.5:
            score += 15
            findings.append(f"WARN: Only {len(documented_rules)}/{len(self.rules)} rules have documented thresholds + rationale — NCA audit gap")
        else:
            findings.append("FAIL: Detection rules lack threshold documentation — Art.10(2) explicit threshold definition requirement")

        auto_escalation_rules = [r for r in self.rules if r.auto_escalation]
        if self.rules and len(auto_escalation_rules) / len(self.rules) >= 0.9:
            score += 35
        elif auto_escalation_rules:
            score += 15
            findings.append("WARN: Not all detection rules have auto-escalation — Art.10(2) automatic alert mechanism requirement partially unmet")
        else:
            findings.append("FAIL: No automatic escalation configured — Art.10(2) requires automatic alert mechanisms to IR staff")

        return {"article": "Art.10(2)", "score": score, "max": 100, "findings": findings}

    def check_art10_3(self) -> dict:
        """Art.10(3): Sufficient resources for user activity, anomaly, and cyber-attack monitoring."""
        findings = []
        score = 0

        if not self.user_monitoring:
            findings.append("FAIL: No user activity monitoring programme documented — Art.10(3) explicit user monitoring requirement")
            return {"article": "Art.10(3)", "score": 0, "max": 100, "findings": findings}

        if self.user_monitoring.covers_privileged_users:
            score += 25
        else:
            findings.append("FAIL: Privileged user activity not monitored — Art.10(3) highest-risk gap for NCA audit")

        if self.user_monitoring.covers_vendor_access:
            score += 15
        else:
            findings.append("WARN: Vendor/third-party access not monitored — Art.30 contractual register implies detection obligation")

        if self.user_monitoring.covers_bulk_data_export:
            score += 15
        else:
            findings.append("WARN: Bulk data export detection absent — insider threat and data exfiltration gap")

        if self.user_monitoring.monitoring_hours == "24x7":
            score += 20
        elif self.user_monitoring.monitoring_hours == "business_hours":
            score += 8
            findings.append("WARN: Monitoring only during business hours — cyber-attacks often target off-hours; Art.10(3) 'in particular cyber-attacks' language implies continuous monitoring")
        else:
            findings.append("FAIL: No continuous monitoring — Art.10(3) requirement for sufficient resources not met")

        if self.threat_intel_integrated:
            score += 25
        else:
            findings.append("WARN: No threat intelligence integration — Art.10(3) 'in particular cyber-attacks' requires IOC/TTP monitoring capability")

        return {"article": "Art.10(3)", "score": score, "max": 100, "findings": findings}

    def generate_report(self) -> dict:
        results = {
            "entity": self.entity_name,
            "assessment_date": self.assessment_date,
            "checks": [
                self.check_art10_1(),
                self.check_art10_2(),
                self.check_art10_3(),
            ]
        }
        total = sum(c["score"] for c in results["checks"])
        max_total = sum(c["max"] for c in results["checks"])
        results["overall_score"] = round(total / max_total * 100, 1)
        results["nca_audit_ready"] = results["overall_score"] >= 75
        all_findings = [f for c in results["checks"] for f in c["findings"]]
        results["critical_findings"] = [f for f in all_findings if f.startswith("FAIL")]
        results["warnings"] = [f for f in all_findings if f.startswith("WARN")]
        return results


# Example usage
if __name__ == "__main__":
    assessment = DORADetectionAssessment(
        entity_name="Example Payment Institution",
        assessment_date="2026-04-17",
        siem_deployed=True,
        spof_mapping_current=True,
        spof_last_reviewed="2026-01-15",
        threat_intel_integrated=True,
        rules=[
            DetectionRule(
                rule_id="NET-001",
                layer=DetectionLayer.NETWORK,
                asset_tier=AssetTier.TIER1_CRITICAL,
                threshold_documented=True,
                threshold_rationale="risk-register-entry-NET-T1-001",
                last_reviewed="2026-03-01",
                auto_escalation=True,
                escalation_target="ir-team-pagerduty",
            ),
            DetectionRule(
                rule_id="HOST-001",
                layer=DetectionLayer.HOST,
                asset_tier=AssetTier.TIER1_CRITICAL,
                threshold_documented=True,
                threshold_rationale="risk-register-entry-HOST-T1-001",
                last_reviewed="2026-03-01",
                auto_escalation=True,
                escalation_target="ir-team-pagerduty",
            ),
            DetectionRule(
                rule_id="APP-001",
                layer=DetectionLayer.APPLICATION,
                asset_tier=AssetTier.TIER2_IMPORTANT,
                threshold_documented=True,
                threshold_rationale="risk-register-entry-APP-T2-001",
                last_reviewed="2026-02-15",
                auto_escalation=True,
                escalation_target="ir-team-slack",
            ),
            DetectionRule(
                rule_id="DATA-001",
                layer=DetectionLayer.DATA,
                asset_tier=AssetTier.TIER2_IMPORTANT,
                threshold_documented=False,
                threshold_rationale="",
                last_reviewed="2026-01-10",
                auto_escalation=False,
                escalation_target="",
            ),
        ],
        user_monitoring=UserMonitoringControl(
            covers_privileged_users=True,
            covers_vendor_access=True,
            covers_bulk_data_export=False,
            detection_to_alert_minutes=4,
            monitoring_hours="24x7",
        ),
    )

    report = assessment.generate_report()
    print(json.dumps(report, indent=2))

6. DORA × NIS2 Art.21(2)(b) Dual-Compliance Mapping

Financial entities that are also NIS2 essential or important entities face overlapping detection obligations. DORA applies as lex specialis — where DORA imposes a more specific or stricter requirement than NIS2, DORA prevails. Where NIS2 covers ground DORA does not, NIS2 fills the gap.

Requirement	DORA Art.10	NIS2 Art.21(2)(b)	Lex Specialis
Multi-layer detection	✅ Explicit (Art.10(2))	Implied by "incident handling"	DORA more specific
Alert thresholds documented	✅ Explicit (Art.10(2))	Not explicit	DORA more specific
User activity monitoring	✅ Explicit (Art.10(3))	Partial (Art.21(2)(a) risk analysis)	DORA more specific
Cyber-attack monitoring	✅ Explicit "in particular" (Art.10(3))	Implied	DORA more specific
SPOF identification	✅ Explicit (Art.10(1))	Not present	DORA only
Detection-to-response escalation	✅ Automatic (Art.10(2))	Required in IR process	Equivalent
Monitoring resources documented	✅ "Sufficient resources" (Art.10(3))	Not explicit	DORA more specific
Threat intelligence integration	Not explicit	Implied by Art.21(2)(b)	NIS2 may be stricter

Practical implication for dual-regulated entities: A single detection programme that satisfies DORA Art.10 will also satisfy NIS2 Art.21(2)(b) for all but the threat intelligence gap. Adding documented threat intel integration (MISP, commercial TI feeds, FS-ISAC membership) closes the NIS2 gap without creating a separate programme.

7. Common NCA Audit Failures for Art.10

Based on published EBA/ESMA/EIOPA guidance and supervisory feedback from 2025 DORA dry-run assessments:

Failure 1: Detection rules present but thresholds undocumented A SIEM with rules and no documented threshold rationale fails Art.10(2). NCAs look for a register that explains why a threshold was set — not just what it is.

Failure 2: Single detection layer An EDR-only or firewall-only detection posture fails the multi-layer requirement. Network, host, application, and data layers are all expected for Tier 1 and Tier 2 assets.

Failure 3: SIEM logs but no auto-escalation Entities that aggregate logs to a SIEM but rely on analyst manual review without automatic alerting fail Art.10(2)'s automatic alert mechanism requirement.

Failure 4: SPOF mapping absent or outdated Art.10(1) explicitly names SPOF identification. An outdated topology map (12+ months without review following architecture changes) fails this requirement.

Failure 5: User monitoring covers authentication but not privileged activity Logging sign-in events without monitoring what privileged users do post-authentication fails Art.10(3). NCA examiners specifically ask for privileged session monitoring evidence.

Failure 6: Detection-to-alert latency undocumented Art.10 requires prompt detection. Without documented and measured detection-to-alert latency targets by asset tier, you cannot evidence compliance with the "promptly detect" standard.

Failure 7: No monitoring of vendor/third-party access Given DORA's extensive Art.28–30 third-party risk framework, NCAs now expect that vendor access sessions are monitored and anomalous vendor activity triggers alerts.

8. 25-Item DORA Art.10 Compliance Checklist

Art.10(1) — Prompt Detection and SPOF Identification

1. SIEM or equivalent detection platform deployed and operational
2. Detection coverage mapped to all Tier 1 and Tier 2 ICT assets from Art.8 register
3. Network performance baselines established for all CBF-supporting infrastructure
4. Deviation thresholds defined for network latency, packet loss, and throughput
5. ICT topology documented with material single points of failure identified
6. SPOF mapping reviewed within last 12 months (or after any major architecture change)
7. Detection-to-alert latency targets defined by asset tier (Tier 1: ≤5 min, Tier 2: ≤30 min)

Art.10(2) — Multi-Layer Controls, Thresholds, and Auto-Escalation

8. Network-layer detection deployed (IDS/IPS, NetFlow, DNS monitoring)
9. Host-layer detection deployed (EDR, FIM, OS audit logging)
10. Application-layer detection deployed (WAF, auth failure monitoring, API anomaly)
11. Data-layer detection deployed (DAM or equivalent, privileged data access logging)
12. Detection rule register maintained with threshold values and rationale for each rule
13. Threshold rationale linked to ICT risk register entries
14. All Tier 1 detection rules reviewed within last 12 months
15. Automatic alerting configured for all detection rules (no manual-review-only paths for Tier 1/2)
16. Escalation paths documented: who receives alerts, initial response action, time to acknowledge

Art.10(3) — Resourcing for User Activity and Cyber-Attack Monitoring

17. Privileged user activity monitoring deployed (admin, service accounts, DBA)
18. Vendor and third-party access sessions monitored for out-of-scope and anomalous activity
19. Bulk data export detection rules operational with documented thresholds
20. Monitoring operates 24×7 for Tier 1 and Tier 2 assets
21. Threat intelligence feeds integrated (FS-ISAC, MISP, commercial TI, or equivalent)
22. IOC-based detection rules updated with threat intel feed cadence (minimum weekly)
23. Monitoring resource budget documented and proportional to ICT risk profile
24. Monitoring staffing or MSSP contract documented with coverage hours and SLAs
25. Detection programme reviewed by management body annually and after significant incidents

9. 12-Week Implementation Timeline

For entities that need to remediate Art.10 gaps ahead of NCA examination:

Weeks 1–2: Gap assessment and prioritisation

Run DORADetectionChecker against current state
Document current detection layers and identify missing layers
Map detection gaps to Tier 1/2 assets from Art.8 register
Identify SPOF mapping status

Weeks 3–4: Network and host layer foundation

Deploy or validate network-layer detection (IDS/IPS, NetFlow, DNS)
Validate host-layer EDR coverage across all Tier 1 and Tier 2 endpoints
Establish detection-to-alert latency baseline measurements

Weeks 5–6: Application and data layers

Deploy or validate WAF with authentication anomaly rules
Enable database activity monitoring or equivalent for Tier 1 data stores
Configure DLP detection for bulk export scenarios

Weeks 7–8: Threshold documentation and rule register

Audit all existing SIEM rules for documented thresholds and rationale
Create or update detection rule register with risk register links
Assign review dates to all rules

Weeks 9–10: Auto-escalation and user monitoring

Configure automated escalation paths for all Tier 1/2 rules
Deploy or validate privileged user monitoring
Enable vendor session monitoring

Weeks 11–12: Testing, documentation, and management review

Conduct detection test (simulate anomalous events across all four layers)
Measure actual detection-to-alert latency against targets
Prepare management body report on detection programme
Update ICT risk register with detection control mapping

10. Integration with DORA's Broader Framework

Art.10 sits at the Detection phase of DORA's six-domain ICT risk management cycle:

Art.5–6: Governance and Framework
    ↓
Art.7–9: ICT Systems, Identification, and Protection
    ↓
Art.10: Detection ← YOU ARE HERE
    ↓
Art.11: Business Continuity and Recovery
    ↓
Art.12: Backup Policies
    ↓
Art.13–16: Learning, Communication, and Testing

Detection results feed directly into the Art.17–23 incident reporting chain. An Art.10 detection event that meets the Art.17 "major incident" threshold triggers the Art.19 reporting obligations: early warning within 4 hours, intermediate report within 72 hours, and final report within 1 month.

Entities that integrate their SIEM alert escalation path with their Art.19 reporting workflow can automate the threshold assessment step — when a detection event fires, the workflow checks whether it meets major incident criteria, and if so, initiates the regulatory notification process automatically.

11. Detection for SaaS Providers

If you are building SaaS infrastructure deployed by financial sector customers, DORA Art.30 will flow detection requirements into your contracts. Common contractual obligations pushed downstream:

Incident notification SLAs: SaaS vendors must notify customers of ICT incidents affecting their service within defined timeframes (typically 4 hours for major incidents)
Detection evidence: Customers may audit your detection capabilities — evidence of multi-layer controls and documented alert thresholds reduces audit friction
Log access: Customers may require access to logs from your platform for their own Art.10 monitoring
SPOF documentation: Customers mapping their own SPOF exposure need your architecture documentation

Platforms running on EU-native infrastructure with no US cloud dependencies eliminate the CLOUD Act jurisdiction risk that US-based SaaS introduces into financial sector customers' Art.28 third-party risk registers. DORA Art.30(4)(j) requires contracts to specify the jurisdictions where data is processed and stored — EU-only providers have a structural advantage in demonstrating DORA contractual compliance to their financial sector customers.