Introduction
The NIS2 directive codifies one of the most operationally consequential provisions in EU cybersecurity law: a tiered incident-reporting clock that runs once a "significant incident" has been identified. The clock requires an initial notification within 24 hours, an intermediate update within 72 hours, and a final report within a month. Missing any of these windows is a compliance failure with documented consequences.
For an MSP DMARC practice, the reporting clock matters in two ways. First, the MSP's own detection discipline contributes to the client's ability to identify an incident in time to start the clock. Second, the MSP's own incident-handling discipline determines whether the MSP-side response supports the client's reporting timeline or undermines it.
This article is the operational companion to the NIS2 and DMARC pillar. It walks the reporting clock, explains how DMARC aggregate reports plug into the detection input, and maps the MSP's response cadence to the client's compliance cadence.
Orientation, not legal advice. The exact obligations on any specific incident depend on the national-law transposition and counsel advice about whether the incident is "significant" under the directive's terms.
Why this topic matters
Pre-NIS2, incident reporting was largely a discretionary or sector-specific obligation. Most MSPs operated with informal client-notification practices — "we'll let you know when something happens" — that worked acceptably in normal times but didn't hold up to formal scrutiny. NIS2 changed the formality requirement: the client's reporting clock starts the moment they become aware of the incident, and the MSP's slow notification can put the client into late-reporting territory.
The MSPs that have responded by tightening internal notification discipline are protecting their clients' compliance posture. The MSPs that haven't are creating compliance exposure their clients hadn't anticipated.
The 24/72/30 clock, in compact form
The directive defines three reporting windows for significant incidents:
Early warning — 24 hours. The covered entity must notify its CSIRT (Computer Security Incident Response Team) or competent authority of an incident likely to be classified as significant. This is a first notification — minimal detail, indication of cross-border impact if applicable, indication of suspected malicious cause.
Incident notification — 72 hours. A more detailed update. Assessment of the incident, severity, impact, indicators of compromise. This is the substantive notification — what's known so far, what's still being investigated.
Final report — one month. A final report including detailed description, type of threat or root cause, mitigation measures applied, and any cross-border impact.
The clock starts when the entity "becomes aware" of the incident. Determining awareness is itself a judgment call — some incidents are clearly recognised at a specific moment; others come into focus gradually. The directive expects entities to have detection discipline that surfaces awareness promptly.
The definition of "significant" varies by sector and by transposition, but the broad pattern is: incidents that cause or are likely to cause serious operational disruption, or that involve serious financial losses, or that affect more than a defined number of users / customers. Many domain-impersonation phishing campaigns meet the threshold; some don't.
How DMARC aggregate reports contribute to detection
DMARC aggregate reports (the rua= stream) are the practical detection input that lets covered entities recognise an active impersonation campaign while it's happening. The reports are XML summaries that receivers send back to the policy-publishing domain on a defined interval (typically daily). Each report aggregates the SPF, DKIM, DMARC verdicts for messages received from a specific sending IP claiming to be from the covered entity's domain.
The patterns that show up in the reports during an active impersonation campaign:
A burst of messages from a previously-unseen sending IP. Day-over-day, the same sending IPs send the same volume of mail. A new IP with high volume on a single day stands out instantly.
SPF failures from sources claiming the domain. Legitimate senders pass SPF; impersonators usually fail because they're not in the SPF record. A spike of SPF failures from messages claiming the brand is a clear impersonation signal.
DMARC failures across the spike. When the impersonating mail is failing DMARC, the policy is doing its job — the messages aren't being delivered to inboxes. The detection value is in seeing that the attempt was made.
Geographic patterns. Impersonation campaigns often originate from specific regions where the attacker's infrastructure lives. A spike of failed-auth mail from an unusual region for the brand is a lead.
For a covered entity with a tight DMARC practice, these patterns surface in the daily report-review cadence. The detection delay is measured in hours, not days. That's fast enough to support the 24-hour notification window if the underlying incident is significant.
What "significant" looks like in practice
Most DMARC-detected events don't trigger the reporting clock. The cases that do:
A spoofing campaign that succeeds. The campaign reaches recipients (DMARC at p=none, or DMARC pass via misconfigured legitimate-sender alignment) and recipients act on the content (clicks, credential submissions, wire transfers). The downstream impact — financial loss, breach of recipient systems, data exposure — meets the significance threshold.
A spoofing campaign targeting critical-infrastructure recipients. Even if the campaign doesn't succeed at the technical layer, the targeting of essential-entity recipients (or recipients whose compromise would cascade into essential entities) can elevate the campaign to significant.
A pattern suggesting account compromise. Aggregate reports showing legitimate-looking authentication from unusual infrastructure (real DKIM signatures from real platforms, but unusual geographic origins) can indicate an attacker has compromised a real sending account. The compromise itself is the significant incident; DMARC reports surface the symptom.
A widespread sender-infrastructure compromise. When a third-party sender platform is itself compromised and adversaries are sending DKIM-signed mail through it, the DMARC reports show aligned-pass mail from unexpected source IPs. This is the most concerning pattern because the messages reach inboxes.
The pattern recognition for "is this report flag significant" is what separates a working DMARC practice from a checkbox one. The MSPs that train analysts on this pattern recognition can support the 24-hour clock; the ones that don't can't.
The MSP's response cadence vs the client's reporting cadence
The reporting clock starts when the client becomes aware. The MSP's job is to enable that awareness as fast as possible, and then to support the client's response without inadvertently delaying their reporting.
A working cadence that maps cleanly to the 24/72/30 clock:
MSP detection → MSP-internal triage (hour 0-2). The aggregate-report-review process surfaces the anomaly. The on-call analyst confirms the pattern, rules out routine causes (a legitimate new sender, a known reporting anomaly), and assesses preliminary severity.
MSP-internal triage → MSP-to-client notification (hour 2-4). If the pattern is consistent with an active impersonation campaign or other significant security event, the MSP notifies the client per the contracted SLA. The notification includes the detection time, the observed pattern, and a recommendation on whether the client should start their reporting clock.
Client awareness → client's 24-hour notification (hour 4-24). The client, now aware, has roughly 20 hours to complete their 24-hour early-warning notification to the authority. The MSP supports the response (more detail, additional analysis, cross-domain check) but doesn't drive the regulatory interaction.
Client's 72-hour incident notification (hour 24-72). The MSP continues to support detection and response work, supplying the client with technical detail for the incident-notification update.
Client's one-month final report (hour 72-30 days). The MSP supplies a final summary of the technical observations and the operational response. This is the artefact that closes the MSP's involvement.
Each hand-off in the cadence has a defined trigger and a defined output. The MSPs that operate this way protect the client's compliance posture; the MSPs that don't risk the client's reporting being late because the MSP took 36 hours to forward the alert.
Documentation expectations during a reportable incident
A few specific artefacts auditors and regulators look for after a reportable incident:
Detection time stamp. When did the MSP first observe the anomaly? When did the MSP confirm the anomaly was an incident? When was the client notified?
The supporting data. The aggregate-report excerpts, the headers from sampled messages, the cross-resolver DNS lookups that confirm the configuration state at the time of the incident.
The decision-making chain. Who made the call that this was significant? On what basis? When?
The mitigation actions. What did the MSP do operationally? What did the client do? When did the actions occur?
The post-incident review. What changed in the practice as a result of this incident? What new detection or response capability was added?
The aggregate-report archive is the most valuable single artefact in the post-incident package. The MSP should retain reports for a documented retention period (12 months is a common floor, 36 months an aggressive ceiling) and be able to produce historical data on request during an incident investigation.
Why the aggregate-report review cadence has to be daily (or close)
Pre-NIS2, weekly or monthly aggregate-report review was common in MSP DMARC practices. Post-NIS2, this isn't tight enough to support the 24-hour clock when something significant happens. A campaign that runs Monday morning is invisible until Friday's weekly review — by which time the 24-hour window passed Tuesday morning.
The cadence that works:
Automated daily report processing. The reports are parsed automatically the moment they arrive. Anomaly detection (volume spikes, new sending IPs, unusual geographic distribution) runs as part of the pipeline.
Analyst review of flagged anomalies. A human looks at every flagged anomaly within a defined window (4-8 hours is typical). Most flags are benign — a new third-party sender, a routine volume bump — but the few that aren't get triaged immediately.
Weekly cross-portfolio review. A broader look across the client portfolio, looking for patterns that don't surface on a per-client basis. Campaign infrastructure often hits multiple targets; cross-portfolio visibility catches it.
Monthly trend analysis. Aggregate trends — pass-rate distribution, sender inventory drift, geographic patterns — surface in monthly review. Not for incident detection; for ongoing posture management.
A practice operating at this cadence supports the 24-hour clock. A practice still on weekly batch review doesn't.
When DMARC reports are NOT enough
It's important to be honest about the limits of aggregate reports as a detection input. Cases where reports alone don't surface the incident in time:
The campaign uses authenticated infrastructure. When the impersonating mail passes SPF / DKIM / DMARC because the attacker is using a legitimate sending platform with valid auth, aggregate reports show pass verdicts and don't flag the campaign. The detection has to come from elsewhere — content analysis at the recipient, abuse-feedback loops, user reports.
The campaign targets a sub-domain not under DMARC coverage. If only the apex is at p=reject and the sub-domain doesn't have its own policy, impersonators using the sub-domain may evade detection in the apex's reports.
The reporting volume is too low. A small domain might not generate enough aggregate-report data to make anomaly detection statistically reliable.
Forensic-report-only campaigns. Some sophisticated campaigns are designed to evade aggregate-report visibility entirely. Forensic reports (ruf=) can catch some of these, but most receivers don't send forensic reports.
The MSPs that have built complete detection programs combine aggregate-report monitoring with at least two other inputs (abuse-feedback loops, user-reported phishing forwarding, sandboxed-URL feeds). The combination catches what any single input misses.
Recovery and post-incident hardening
After a reportable incident, the practice should produce two artefacts beyond the regulatory reports:
A client-facing post-incident summary. What happened, what the MSP did, what the client should do next, what the MSP is changing operationally. The client uses this in their own internal post-incident review.
An internal post-incident review. What did the MSP learn? What new detection or response capability is being added? What gets baked into the practice runbook? This is for the MSP's own continuous improvement.
The MSPs that do both consistently turn each incident into a permanent capability gain. The ones that skip the internal review tend to repeat the same incident shape a quarter later because no learning was captured.
What this article doesn't try to do
It doesn't classify what counts as a "significant" incident under any specific transposition — that's a judgment call that requires counsel advice. It doesn't substitute for the client's incident-response plan. And it doesn't claim that DMARC aggregate reports alone are sufficient detection capability for any specific client's NIS2 posture — they're one input among several that a complete program needs.
What it tries to do is help an MSP DMARC practice align its detection and response cadence with the regulatory clock that NIS2 imposed on its clients, so the MSP's discipline supports the client's compliance instead of undermining it.
Tools mentioned
- Email Header Analyzer — triage during an active incident
- DMARC Validator — verify the policy posture at the time of incident
- DNS Lookup — produce cross-resolver evidence of the configuration state
- DMARC Record Generator — issue emergency-policy adjustments during the response
Related articles
- NIS2 and DMARC overview
- NIS2 essential vs important entities and DMARC
- NIS2 obligations for MSPs and DMARC implications
- Reading DMARC aggregate reports
- DMARC change-management policy for MSP portfolios
Author: DMARC AI editorial team Last updated: June 2026