Follow 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 notification within 4 hours of classifying an incident as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours of the initial notification, and a final report within one month of the intermediate report. Because the first clock starts at detection and classification, the incident timeline itself is auditable evidence.
NIS2 (Directive (EU) 2022/2555) binds through each Member State’s transposing law, not directly. The transposition deadline was 17 October 2024 (Article 41). On 7 May 2025 the European Commission sent reasoned opinions to 19 Member States for failing to notify full transposition, and on 8 July 2026 it referred Ireland, Spain, France and the Netherlands to the Court of Justice. On 20 January 2026 the Commission proposed amendments to NIS2 (COM(2026) 13) that touch Article 21(5) and add ransomware paragraphs to Article 23, leaving the Article 21(2) measures and the Article 23(4) reporting clocks unchanged. The obligation a buyer faces depends on its Member State’s transposing law.
Implementing Regulation (EU) 2024/2690, published on 18 October 2024 and in force from 7 November 2024, sets explicit monitoring and logging requirements (Annex section 3.2) for DNS service providers, TLD name registries, cloud computing, data centre, content delivery network, managed service and managed security service providers, online marketplaces, search engines, social networking platforms, and trust service providers. This reaches MSSPs as regulated entities in their own right, distinct from their customers’ obligations.
PCI DSS v4.0.1 is the only active version. Requirements 10 and 11 carry the detection and monitoring obligations.
SEC (final rule Release 33-11216, adopted 26 July 2023) is a disclosure and governance rule, not a detection-controls mandate. Detection is derivative: a registrant cannot determine materiality without the ability to detect and assess incidents. Compliance with Item 1.05 was required from 18 December 2023 for most registrants and from 15 June 2024 for smaller reporting companies.
What evidence do auditors typically look for to confirm that our detection systems are effective?
Five evidence classes recur across these regimes. A coverage percentage alone is not evidence for any of them.
| # | Evidence class | What it proves |
|---|---|---|
| 1 | Log sources collected | Which telemetry is ingested, from which systems, and that collection is continuous. The auditor checks whether monitoring is running, not whether it was configured once. |
| 2 | Rules deployed | Detection rules in place, each mapped to the obligation it supports and to its ATT&CK technique where applicable, with an owner. |
| 3 | Proof of firing | Rules fired on real or emulated events and alerts reached responders. A deployed rule that has never fired is untested from the auditor’s standpoint. |
| 4 | Change history | Who changed a rule, when, and why: version control, a review trail, and a documented rationale for each change. |
| 5 | Dated coverage report | Point-in-time report with a date, so trend and currency are provable. An undated report proves nothing about when coverage existed. |
ATT&CK functions as the crosswalk that makes this evidence queryable by adversary behavior. A technique ID is metadata attached to already-existing evidence (data sources, deployed rules, firing records) so that evidence becomes retrievable by behavior category. ATT&CK is not required by any of these four regimes. It organizes evidence against the obligations they impose.
Can you show an auditor who changed a rule, when, and why?
Detection-as-Code answers this. Every detection rule is a versioned artifact in source control. The change history records author, timestamp, review approval, and the reason for the change.
This trail maps to specific obligations:
- DORA Article 17 requires a documented incident-management process with root-cause follow-up.
- PCI DSS v4.0.1 Requirement 11 includes change-and-tamper detection.
- The SEC’s Item 106 expects a registrant to describe its risk-identification processes.
Each framework asks whether the organization governs detection rules as controlled artifacts, not merely whether rules exist.
The operational test: given a rule that fired last quarter, can the team produce its complete lineage? Who wrote it, who reviewed it, when it was last modified, why, what obligation it maps to, and what technique it addresses. A detection-content platform that manages rules as versioned code produces this trail as a byproduct of normal operations.
Where rules are edited in a console without version control, the auditor has no provenance for the current rule state. Detection-as-Code governance removes that ambiguity by construction.
How does detection coverage become a compliance line item?
Detection capability tends to sit inside operations budgets, visible to the SOC manager, invisible to the CFO. Three facts make coverage a board conversation.
- Reporting clocks start at detection. DORA’s 4-hour classification clock and the SEC’s four-business-day materiality clock both begin when the organization detects or becomes aware. Faster detection is the beginning of the compliance timeline.
- Detection evidence is auditable. The five evidence classes above are what an auditor reviews. Producing them costs time and staff whether the team builds its own rules or subscribes to a detection-content source.
- Time-to-coverage is measurable. The window between a technique becoming public and a validated detection firing in the organization’s own environment is trackable.
An engineering team requests detection capacity in terms of headcount and tooling. A compliance team requests it in terms of evidence production. The second framing ties detection spending to a regulatory obligation the board already tracks.
A SIEM posture audit produces the coverage map auditors ask for: rules mapped to MITRE ATT&CK, log sources mapped to the same matrix, and the gaps listed with a plan.
Where this does not hold
Several limitations apply.
Not every obligation maps to detection. SEC Item 1.05 requires disclosure, not specific controls. NIS2 Article 21 and DORA both include supply-chain security, business continuity, and access management. None of these map to ATT&CK techniques. ATT&CK organizes the detection and monitoring subset, not the full compliance surface.
NIS2 transposition is incomplete. Where a Member State’s transposing law is not in force, NIS2 Articles 21 and 23 are not locally enforceable. The January 2026 proposed amendments do not renumber Articles 21 or 23.
The SEC rules are contested. The rescission petition against Item 1.05, filed 22 May 2025 by five banking and securities trade associations (SEC File No. 4-856), remains unresolved: as of 21 September 2026 the SEC has proposed no amendment to Item 1.05, although the petitioners renewed the request in an April 2026 comment letter under the Commission’s Regulation S-K review. A 21 May 2024 statement by Erik Gerding, then Director of the Division of Corporation Finance, clarified that Item 1.05 is reserved for incidents a registrant has determined to be material and encouraged disclosure of other incidents under a different item such as Item 8.01; the Division followed with Compliance and Disclosure Interpretations on 24 June 2024.
Sub-requirement numbers follow v4.0.1. The PCI DSS sub-requirements cited here (10.4.1, 10.4.1.1, 10.5.1, 10.7, 10.7.2, 11.5.1, 11.5.2, 11.6.1) use the v4.0.1 numbering; the standard itself is in the PCI SSC document library, and Requirement 10.7.2 applies to all entities from 31 March 2025.
ATT&CK is a crosswalk, not a regulatory obligation. Mapping detections to ATT&CK techniques organizes evidence. It does not discharge any regulatory obligation, and no framework examined here requires it.
DORA is lex specialis for financial entities. A bank in DORA scope does not apply NIS2 Articles 21 and 23 on top for its own ICT risk management and incident reporting. NIS2 reaches a bank’s non-financial supply chain, not the bank’s own ICT operations.
AUDIT EVIDENCE CHECKLIST: DETECTION OBLIGATIONS
1. LOG SOURCES COLLECTED
[ ] Inventory of telemetry sources ingested
[ ] Evidence of continuous collection (not point-in-time)
[ ] Each source mapped to the systems, assets, and
obligations it covers
2. RULES DEPLOYED
[ ] Detection rules inventory with named owners
[ ] Each rule mapped to the regulatory obligation it supports
[ ] Each rule mapped to ATT&CK technique where applicable
(crosswalk, not required by regulation)
[ ] Alert thresholds documented with rationale
3. PROOF OF FIRING
[ ] Evidence that rules fired on real or emulated events
[ ] Records that alerts reached designated responders
[ ] Dated test records for detection mechanisms
(DORA Article 10)
4. CHANGE HISTORY
[ ] Version control for every detection rule
(Detection-as-Code)
[ ] Author, reviewer, timestamp, and rationale per change
[ ] Review and approval trail
[ ] Change-and-tamper detection records
5. DATED COVERAGE REPORT
[ ] Point-in-time coverage report with a date
[ ] Coverage measured against prioritized technique set,
not full ATT&CK matrix
[ ] Trend data showing coverage over time
[ ] Per-environment reporting (not one aggregate number)
REGIME-SPECIFIC ITEMS
[ ] DORA: alert thresholds documented with rationale
(Article 10)
[ ] DORA: incident timestamps on the reporting clocks
(4h from classification / 24h from awareness,
72h intermediate, 1-month final)
[ ] NIS2: evidence mapped to the transposed national law,
not directive text alone
[ ] PCI DSS v4.0.1: log retention per applicable
sub-requirements
[ ] SEC: documented materiality-determination process
(Item 1.05)
[ ] SEC: board oversight and management role described
(Item 106)
NOTES
- ATT&CK is the crosswalk used to organize this evidence.
It is not required by DORA, NIS2, PCI DSS, or SEC rules.
- DORA is lex specialis: a bank in DORA scope applies DORA,
not NIS2 Articles 21 and 23, for ICT risk management.
- PCI DSS v4.0.1 is the only active version
(v4.0 retired 31 December 2024).
- Every regulatory specific in this document is validated
by ciso-cto-sme before publish.
FAQ
What detection evidence supports obligations under PCI DSS 4.0 and DORA?
Both regimes require evidence of ongoing detection and monitoring, not merely evidence that detection tools are deployed. The five evidence classes are: log sources collected, detection rules deployed with owners, proof those rules fire, change history with version control, and a dated coverage report. MITRE ATT&CK organizes this evidence by adversary-behavior category. ATT&CK is not required by either framework.
What evidence do auditors look for to confirm detection systems are effective?
Auditors look for five evidence classes: which telemetry sources are collected and that collection is continuous, detection rules mapped to obligations and ATT&CK techniques with named owners, proof those rules fire on real or emulated events, version-controlled change history for every rule, and a dated point-in-time coverage report. A coverage percentage alone, without the supporting records underneath it, is not evidence.
Does mapping detections to MITRE ATT&CK satisfy a regulator?
ATT&CK is the crosswalk that organizes detection evidence by adversary behavior. It makes evidence queryable and reportable by technique. It does not itself discharge any regulatory obligation. DORA, NIS2, PCI DSS, and the SEC rules ask for evidence of operation: monitoring, detection, logging, and disclosure. ATT&CK organizes that evidence. No framework examined here requires it.
What are the incident reporting timelines under DORA and NIS2?
Under DORA, Delegated Regulation (EU) 2025/301 sets the clocks for major incidents: initial notification within 4 hours of classifying the incident as major (no later than 24 hours after awareness), an intermediate report within 72 hours of the initial notification, and a final report within one month of the intermediate report. Under NIS2, significant incidents require an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report not later than one month after the incident notification. Both timelines start at detection, making the detection timestamp itself an auditable record.
SOC Prime’s Custom Content Engineering implements detections in your SIEM or EDR and provides high-level documentation of their purpose, function, and usage.
Related reading
- SIEM vs Log Management: Observability, Telemetry, and Detection (March 2026)
- Attack Chains: See the Full Story Behind Every Threat (August 2026)
- Continuous Compliance as a Code P1: Sigma (August 2019)
