Introduction
NIS2 affects MSPs along two axes that the original NIS directive didn't fully touch. First, "ICT service management (B2B)" is named as an essential-entity sector in the directive — meaning MSPs above a certain size are themselves directly in scope. Second, the supply-chain provisions extend obligations on covered entities down to their suppliers, which means MSPs that aren't themselves in scope often end up de-facto in scope because their client base demands it. For an MSP DMARC practice, both axes change the conversation.
This article is the MSP-specific companion to the NIS2 and DMARC pillar and the essential-vs-important classification article. It walks the MSP's own obligations, the supply-chain effect on MSPs that aren't themselves in scope, and the DMARC-practice changes both axes imply.
Orientation, not legal advice. The specifics of any MSP's obligations under NIS2 depend on national transposition and on counsel advice about the MSP's specific operating model.
Why this topic matters
The "ICT service management" designation in NIS2 took many MSP leadership teams by surprise during 2024. The directive's text places ICT service providers — including managed service providers, where the service is provided to other organisations — into the essential-entity sector. National transpositions varied on the precise threshold, but the shape was consistent: MSPs above a certain size found themselves in scope as essential entities, with all the supervisory and accountability implications that brings.
Smaller MSPs that weren't direct in-scope often discovered their largest clients were, and that those clients' supply-chain obligations meant the MSPs had to operate as if they were. Either path leads to the same conclusion: the MSP's own DMARC posture, the MSP's documentation discipline, and the MSP's incident-response readiness all matter more than they did three years ago.
When an MSP is itself in scope
The criteria for direct MSP scope under NIS2 follow the same essential-vs-important split as for other sectors, with the ICT service management category specifically named. Practically:
Large MSPs are essential entities. 250+ employees, or turnover above €50m, or balance sheet above €43m. Subject to proactive supervision, significant fine ceilings, executive accountability.
Medium-sized MSPs are important entities. 50-249 employees and turnover above €10m. Subject to reactive supervision, lower fine ceilings, lighter executive accountability.
Small MSPs are out of scope direct. Under 50 employees and under €10m turnover. The supply-chain pull-through still applies, but no direct NIS2 obligation.
The medium/large boundary deserves attention — an MSP that's growing organically through the threshold sometimes doesn't realise it has crossed until the regulator notices. Annual posture-review should include a "where are we on the size threshold" question.
The MSP-side obligations
For an in-scope MSP, the obligations under NIS2 mirror those for any other in-scope entity. The list that matters for the DMARC-practice conversation:
A risk-management framework. Documented identification of cybersecurity risks to the MSP's own operations, including the impact of a successful attack on the MSP's tenant infrastructure. Email impersonation of the MSP is on the list.
Incident-handling discipline. Defined response procedures, defined escalation paths, defined timelines for the 24/72/30 reporting clock that NIS2 codifies. The MSP's own incident response — not just the response on behalf of clients — is in scope.
Business continuity. Backup and disaster recovery for the MSP's own infrastructure, including the DMARC platform tenancy if the MSP operates one.
Supply-chain risk management. The MSP's own suppliers (the DMARC platform vendor if white-labelled, the cloud provider, the DNS provider) are part of the MSP's risk picture and need to be assessed.
Vulnerability management. Patch discipline on the MSP's own infrastructure, including the platform layer that serves clients.
Cryptography. Including, naturally, the email-authentication discipline of the MSP's own owned domains — DMARC, SPF, DKIM, MTA-STS.
Access control. Multi-factor authentication, privileged access management, role-based access on the MSP's own systems.
Secure development. If the MSP develops its own platform code, the directive expects appropriate practices.
Training. Regular cybersecurity training for staff, including phishing awareness.
The list isn't a surprise to any MSP that takes its own security posture seriously. The change NIS2 brings isn't that these expectations exist — it's that they're now documentable obligations the MSP can be supervised on.
The MSP's own DMARC posture
Of the obligations above, the one that's most directly observable from outside the MSP is its email-authentication posture. Clients (and their auditors) can — and increasingly do — check the MSP's own DMARC record before signing.
The baseline expectation for an MSP serving NIS2-impacted clients:
Every MSP-owned domain at p=reject. No exceptions, no "we'll get to it later." This includes the primary commercial domain, every sub-domain used for transactional mail, every domain used for client-facing portals, every legacy domain from acquisitions.
Documented historical posture. When did each domain reach p=reject? What does the pass-rate distribution look like? An MSP that can produce a 3-year history of p=reject posture across every domain is in a different conversation than one whose primary domain went to p=reject six months ago.
Continuous monitoring evidence. The aggregate-report review cadence is documented, the alerting thresholds are defined, and the operational response to anomalies is exercised. The MSP's own monitoring practice should be at least as rigorous as what it sells to clients.
Public attestation. Many MSPs publish a security-posture statement (a /security/ page, a customer trust portal, an SOC2 report addendum). DMARC posture is a one-line addition that's easy to verify externally.
The MSPs that have invested in this externally observable baseline are winning sales-conversations with NIS2-impacted prospects faster than MSPs whose own posture is still being cleaned up.
The supply-chain provisions in practical detail
The supply-chain provisions of NIS2 require covered entities to assess and manage cybersecurity risks arising from their supplier relationships. For an MSP serving covered clients, this translates to a structured set of supplier-questionnaire interactions.
The questions the MSP will see, repeatedly, from NIS2-covered clients:
"What's your own NIS2 posture?" Direct question about whether the MSP is in scope and, if so, where it is in its compliance journey.
"Can you attest to specific control categories in writing?" Often via a standardised questionnaire (variations on SIG, CAIQ, or proprietary frameworks). DMARC-related questions are now a routine line item.
"What's your incident-notification commitment to us?" The client needs to support its own 24-hour reporting clock; suppliers that contribute to relevant incidents need to notify quickly. Commitments around 4-8 hour internal notification from incident detection are increasingly standard.
"What's your sub-supplier posture?" The chain continues. If you white-label a DMARC platform, that platform vendor's posture is part of yours.
"How do you handle our DMARC reporting infrastructure?" Specifically — where do the rua= reports for our domains land, who has access, how long are they retained, what happens to them on offboarding?
The MSP that has good answers prepared answers them in writing in an afternoon. The MSP that hasn't drafts answers under deadline pressure and shows the client it wasn't ready. The first MSP wins the renewal; the second is on the list of suppliers to review.
Documentation the MSP should have ready
A short list of artefacts an MSP should maintain in a state where they can be produced on 48-hour notice:
MSP NIS2 attestation document. One-page summary stating the MSP's scope status (in-scope essential, in-scope important, or out-of-scope-but-prepared), the date of the most recent risk-assessment update, the supplier-questionnaire framework the MSP can complete, and the named contact for compliance discussions.
MSP-side DMARC posture statement. Every MSP-owned domain with its current DMARC posture, the date it reached the current posture, and the latest aggregate-report pass rate. Refreshed at least quarterly.
Per-client DMARC attestation template. A reusable template that produces an attestation for any given client — what posture is in place on their domains, what monitoring discipline applies, what the historical record shows. The MSP fills in the client-specific data and produces a signed document for the client's audit binder.
Incident-response runbook (MSP-side). What happens when the MSP itself experiences an incident that may affect clients. Defined detection paths, defined notification timelines, defined remediation steps. The runbook exists; it's exercised; the exercise is documented.
Platform-vendor posture documentation. If a third-party DMARC platform is white-labelled, the vendor's NIS2 posture flows through. Document the vendor relationship and the vendor's own attestations.
Client-portfolio DMARC overview. A dashboard or report showing the posture distribution across the MSP's client base — how many clients are at p=reject, how many at quarantine, how many at none. Useful internally for capacity planning; useful externally as a credibility signal.
The supply-chain pull-through for small MSPs
A small MSP (under 50 employees, under €10m turnover) is not directly in NIS2 scope. The supply-chain provisions of the directive, however, mean that the small MSP's larger covered clients will treat the MSP as if it were in scope. Practically, the small MSP needs to:
Be prepared to answer supplier-due-diligence questions. The questions don't go away because the MSP is small. They just get asked once per covered client, at procurement time and again at renewal.
Document the MSP's own DMARC posture. Even more important for small MSPs than large ones — if the MSP can't show p=reject on its own domain, no client questionnaire will go well.
Document the MSP's incident-response readiness. Smaller MSPs sometimes lack formal incident-response documentation. A two-page runbook is enough; absence of any documented runbook isn't.
Be selective about clients. A small MSP that wants to serve essential-entity clients should expect to operate at essential-entity discipline even if it's not directly in scope. If that discipline doesn't fit the practice, declining the engagement is a reasonable answer.
The article on when not to sell DMARC as a managed service covers the broader fit question; NIS2 has added one more profile (covered-entity prospect whose compliance bar exceeds the MSP's operational discipline) to the list of profiles to walk away from.
How the MSP's contracts should adapt
A short list of contract-language changes NIS2 has driven across most MSP DMARC engagements:
Defined notification timelines. Specific time-window commitments for notification of incidents that may affect the client. 4-8 hours from MSP-side detection is increasingly standard.
Supplier-attestation language. The MSP commits to providing attestation documentation in a defined format on defined cadence (typically annual, with a 30-day SLA on ad-hoc requests).
Explicit scope of DMARC monitoring. What's monitored, how often, what triggers escalation, what the response looks like. Vague "ongoing monitoring" language doesn't satisfy a NIS2-aware procurement function.
Sub-processor disclosure. If the MSP uses a third-party DMARC platform, the contract names it. If the third party changes, the client is notified.
Audit-evidence-production commitment. The MSP commits to producing the audit-evidence package within a defined timeline of client request. Pricing for this can be a separate line item or bundled into the engagement; either is fine but it should be explicit.
Exit-clause language around data and posture. What happens to the historical DMARC data on offboarding, what happens to the client's monitoring posture, what the MSP commits to about handover. Covered in detail in the tenant offboarding article.
Building the MSP-side practice for the NIS2 era
For an MSP DMARC practice operating in the post-NIS2 reality, three operational changes have proven highest-leverage:
Productise the audit-evidence work. Define a SKU for the evidence-production work, price it, and quote it explicitly. The work happens whether or not it's quoted; quoting it means it's profitable instead of margin-eroding.
Hire or train for compliance-conversation fluency. The MSP's sales and account-management teams need to be able to talk about NIS2 implications credibly. This isn't a developer skill; it's a customer-facing skill that takes specific investment.
Invest in the MSP's own posture before scaling client work. A practice trying to sell at the essential-entity tier while running its own infrastructure at p=none gets called out quickly. Self-discipline first; client-discipline second.
The MSPs that made all three investments are the ones whose practice grew through 2025-2026 rather than struggled.
Tools mentioned
- DMARC Validator — verify the MSP's own posture and each client's posture
- DMARC Record Generator — produce the records that the audit evidence references
- DNS Lookup — produce the cross-resolver verification evidence
- Email Header Analyzer — incident-triage support during NIS2-relevant incidents
Related articles
- NIS2 and DMARC overview
- NIS2 essential vs important entities and DMARC
- NIS2 incident reporting and DMARC aggregate reports
- How MSPs scope DMARC in MSA/SOW templates
- DMARC change-management policy for MSP portfolios
Author: DMARC AI editorial team Last updated: June 2026