Regulatory detection obligations: DORA, NIS2, PCI DSS 4.0, SEC
September 24, 2026 · SOCPrime · Severity: MEDIUM
This article examines the detection-related requirements of four major regulatory frameworks: DORA, NIS2, PCI DSS 4.0, and SEC disclosure rules. It clarifies that none of these regimes mandate specific detection tools, but each requires evidence of timely detection, monitoring, logging, or disclosure. The article notes that MITRE ATT&CK is a useful but non-mandatory framework for organizing that evidence. 📌 **Analyst Note:** Security teams should focus on building auditable detection evidence rather than chasing tool-specific compliance. Understanding that only DORA names detection as a standalone obligation helps prioritize investments and avoid over-engineering for frameworks that imply detection through other control
Regulatory detection obligations are the security outcomes that DORA, NIS2, PCI DSS v4.0.1, and the SEC disclosure rules require an organization to achieve and evidence through detection, monitoring, logging, and disclosure.
None of these four regimes prescribes a specific detection tool. Only DORA names detection as a standalone obligation. Each framework requires an outcome: timely detection, continuous monitoring, structured logging, or timely disclosure. Detection capability is what the evidence implies, not a control any regulator mandates by name.
MITRE ATT&CK organizes that evidence into a structure an auditor can query by adversary-behavior category. ATT&CK is not required by DORA, NIS2, PCI DSS, or the SEC rules.
DORA is lex specialis or a specific law that takes precedence over a general law. DORA Article 1(2) makes it a sector-specific Union legal act for the purposes of NIS2 Article 4. A financial entity in DORA scope applies DORA for ICT risk management and incident reporting. NIS2 reaches a bank’s non-financial supply chain, not the bank itself.
What detection evidence supports obligations under PCI DSS 4.0 and DORA?
Both PCI DSS v4.0.1 and DORA treat detection as a means to an evidentiary end. The regulation asks whether detections generate the records the monitoring obligation requires, not whether detections exist.
Five evidence classes carry that proof. Both regimes require them in substance.
| Evidence class | PCI DSS v4.0.1 | DORA |
|---|---|---|
| Log sources collected | Requirement 10: capture audit logs, retain history | Article 9(1): continuously monitor and control the security and functioning of ICT systems; Article 10(3): monitor user activity, ICT anomalies and ICT-related incidents |
| Rules deployed, with owner | Requirement 11: intrusion-detection/prevention, change-detection in place | Article 10: multiple layers of control, defined alert thresholds and criteria |
| Proof of firing | Requirement 10: review logs, detect control-system failures | Article 10: alerts fired and reached responsible staff |
| Change history | Requirement 11: change-and-tamper detection | Article 17: documented incident-management process with root-cause follow-up |
| Dated coverage report | Requirement 10.5.1: audit-log history retained for at least 12 months, the most recent three months immediately available (PCI SSC document library) | Article 10(1): detection mechanisms regularly tested in accordance with Article 25 |
PCI DSS v4.0 was retired on 31 December 2024 and PCI DSS v4.0.1 is the only active version (PCI SSC, June 2024). The 51 future-dated requirements became effective on 31 March 2025 (PCI SSC, August 2024). The H2 above uses “PCI DSS 4.0” to match the searcher’s query.
A detection rule that deploys but generates no auditable record is invisible to an assessor.
Which detection and monitoring obligations do DORA, NIS2, PCI DSS 4.0 and the SEC disclosure rules actually impose?
Each regime imposes an outcome obligation rather than a tool mandate. The table below maps each obligation to the detection evidence it implies.
| Regime | Article or Requirement | Obligation | Detection evidence implied |
|---|---|---|---|
| DORA | Art 9(1), Art 10(3) | Continuously monitor and control the security and functioning of ICT systems (Art 9(1)); monitor user activity, ICT anomalies and ICT-related incidents (Art 10(3)) | Log source inventory, continuous collection records |
| DORA | Art 10(1), (2) | Detect anomalous activities; multiple layers of control with alert thresholds and criteria, including automatic alerts to the staff in charge of incident response; detection mechanisms regularly tested under Article 25 | Rule inventory with owners, threshold rationale, proof alerts reached responders, test records |
| DORA | Art 17 | Detect, manage, and notify ICT-related incidents with root-cause follow-up | Process documentation, per-incident detection and handling records |
| DORA | Art 19 + Delegated Reg (EU) 2025/301 | Report major incidents to the competent authority | Timestamped detection and classification record (initial notification within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware; intermediate report within 72 hours of the initial notification; final report within one month of the intermediate report) |
| NIS2 | Art 21(2) | Risk-management measures including incident handling (point (b)) and policies to assess the effectiveness of the measures (point (f)); monitoring and logging duties sit in the implementing rules below, not in Article 21 itself | Documented measures, detection records |
| NIS2 | Art 23(4) | Significant-incident notification | Early warning within 24 hours of becoming aware, incident notification within 72 hours, final report not later than one month after the incident notification |
| NIS2 | Implementing Reg (EU) 2024/2690 | Monitoring and logging (Annex section 3.2) for the eleven entity types in Article 1(1), managed security service providers included | Explicit logging records for covered entities |
| PCI DSS v4.0.1 | Req 10 | Log and monitor all access to system components and cardholder data | Audit logs reviewed at least daily (10.4.1), automated log review (10.4.1.1), retained log history (10.5.1), failures of critical security control systems detected, reported, and responded to promptly (10.7, 10.7.2); text in the PCI SSC document library |
| PCI DSS v4.0.1 | Req 11 | Test security of systems and networks regularly | Intrusion-detection and prevention records (11.5.1), change-detection alerts (11.5.2), payment-page change- and tamper-detection alerts (11.6.1) |
| SEC | 8-K Item 1.05 | Disclose material incidents within four business days of the materiality determination, which must itself be made without unreasonable delay after discovery (Form 8-K, Item 1.05) | Materiality-determination process, incident detection records |
| SEC | S-K Item 106 | Describe the processes for assessing, identifying, and managing material cybersecurity risks in the annual 10-K (Item 1C) | Documented risk-identification process including detection capability |
DORA (Regulation (EU) 2022/2554, in application since 17 January 2025) is directly applicable. Its reporting clocks are set by Delegated Regulation (EU) 2025/301: initial
Key Takeaways
- Regulatory detection obligations from DORA, NIS2, PCI DSS 4.0, and SEC require organizations to achieve and evidence timely detection, continuous monitoring, structured logging, and timely disclosure without prescribing specific tools.
- Only DORA explicitly names detection as a standalone obligation, while the other frameworks imply detection capability through required outcomes, making evidence of detection the key deliverable for auditors.
- MITRE ATT&CK can organize detection evidence into a structure auditors can query by adversary behavior, but it is not mandated by any of these four regulatory regimes.