Introduction
The NIS2 directive's most visible structural change from its predecessor is the bifurcation of in-scope entities into two tiers: essential entities and important entities. The split affects supervisory intensity, sanction ceilings, and (through the implementation acts and national transpositions) the practical expectations around technical controls. For an MSP DMARC practice, the tier matters because it shapes the level of DMARC discipline a covered client is going to be held to — and what evidence the client is going to need to produce on demand.
This article is the classification-companion to the NIS2 and DMARC pillar. It walks the tier split, what it means for the DMARC conversation, and how to position the practice's commitments differently depending on which tier a client lands in.
This is orientation, not legal advice. National-law transposition introduces nuance that an MSP practice should always defer to client counsel on.
Why this topic matters
The headline differences between essential and important entities — supervision intensity, sanction ceilings, executive accountability — sound like compliance-counsel concerns. They're also commercial concerns for an MSP. An essential-entity client is buying a different DMARC engagement than an important-entity client: more formal SLAs, more evidence production, more proactive monitoring, and at a higher price point. Misreading the tier means misquoting the engagement.
The MSPs who lead with "what tier are you in" in the discovery conversation are positioning differently from MSPs who lead with "what does your sending infrastructure look like." Both questions matter; the order signals what kind of partner you are.
The two-tier split, in compact form
The directive defines essential and important based on a combination of sector and size. The exact thresholds are set out in the directive and amplified in member-state transpositions, but the working shape is:
Essential entities. Large organisations in highly critical sectors — energy, transport, banking, financial market infrastructure, drinking water, wastewater, digital infrastructure (including DNS providers, TLD registries, cloud computing, data centre services, content delivery, trust services), ICT service management (for B2B services), public administration of central government, and space.
Important entities. Large and medium-sized organisations in other critical sectors — postal/courier, waste management, manufacturing/distribution of chemicals, food production, manufacturing of medical devices, manufacturing of computers/electronics/electrical equipment, manufacturing of machinery/transport equipment, digital service providers (online marketplaces, search engines, social-network platforms), research organisations.
Special-case in-scope. Some entities are in scope regardless of size — trust service providers (regardless of size are essential), DNS providers and TLD registries (regardless of size are essential), and a handful of other categories. The size threshold doesn't apply to these.
National transpositions sometimes add their own sector-specific extensions; the shape is consistent but the edges vary.
What "large" and "medium-sized" mean
The directive uses the EU's standard SME definition:
- Medium-sized: 50-249 employees and annual turnover above €10m (or balance sheet above €10m).
- Large: 250+ employees, or annual turnover above €50m (or balance sheet above €43m).
Microenterprises (under 10 employees and under €2m turnover/balance sheet) are out of scope except for the special-case categories above. Small enterprises (10-49 employees) are similarly out of scope unless they fall into a special-case sector.
The thresholds matter for the DMARC conversation because a client right at the medium/large boundary often won't know which side of the line they're on until counsel confirms. Treat the client's self-classification as provisional; it sometimes shifts during the engagement.
What differs between essential and important
The two tiers have similar substantive obligations but differ on supervisory and enforcement intensity.
Essential entities. Subject to proactive supervision — competent authorities can audit, inspect, and request evidence without a triggering incident. Administrative fines can reach significant percentages of global annual turnover. Management bodies face personal accountability for compliance failures. The bar for "appropriate technical and organisational measures" is interpreted strictly.
Important entities. Subject to reactive supervision — the authority gets involved when something happens (an incident, a complaint, evidence of non-compliance). Administrative fines exist but are lower in ceiling. Executive accountability is present but less aggressive. The bar for "appropriate" is interpreted with somewhat more flexibility on resource constraints.
For DMARC posture, the practical translation:
Essential entities should reach p=reject early and document the journey. Their auditors are going to ask for the posture across every domain. They want to see the historical trace from p=none through phased rollout to full enforcement, with dated evidence at each step. The DMARC engagement is closer to a formal compliance project than to a discretionary IT improvement.
Important entities have more room to phase the rollout commercially. They still need to reach p=reject, but the timeline is less aggressive and the documentation burden is lighter. The DMARC engagement looks more like a standard managed-service rollout with a 6-12 month horizon.
This isn't a license for important entities to underinvest; the substantive expectations converge over time as case law and supervisory practice mature. It's a practical observation about how the conversation plays out in 2026.
How the tier affects the discovery conversation
The MSP discovery conversation looks meaningfully different depending on tier.
For essential-entity clients:
- Start with the regulatory landscape. The client already knows they're in scope; they expect their suppliers to understand it.
- Quote a higher tier of DMARC-as-a-service from the start. The engagement includes audit-evidence production, formal change-control documentation, and the heavier supply-chain attestation work.
- Map the engagement to the client's existing compliance calendar. If they're being audited in Q3, work backwards from that date.
- Expect to be in front of executives, not just IT. Essential-entity boards are briefed on NIS2 posture quarterly; DMARC is one of the line items.
- Document the MSP-side posture before the engagement begins. The client's compliance counsel will ask.
For important-entity clients:
- Start with the operational improvement story. Compliance is a tailwind but not the only motivator.
- Quote the standard DMARC managed-service tier; layer the compliance-evidence add-on as an option for clients who want it.
- Phase the engagement on the client's pace. There's no immediate audit pressure.
- The conversation is usually with IT leadership rather than executives. The compliance brief is shorter.
- The MSP-side posture matters but is checked less formally.
Misreading the tier — quoting an important-entity engagement to an essential-entity client, or vice versa — creates friction either way. Important-entity clients balk at essential-entity pricing; essential-entity clients are unimpressed by lightweight engagements.
The supply-chain pull-through effect
A pattern that's emerged consistently in 2025-2026: organisations that are technically out of NIS2 scope are being pulled into a de-facto compliance posture by their NIS2-covered customers.
A mid-market manufacturer of plastic components might not be in scope itself. But if its largest customer is an essential-entity energy company, the energy company's supply-chain risk-assessment process will require the manufacturer to demonstrate appropriate cybersecurity practices. The manufacturer either invests to demonstrate the posture or loses the customer relationship.
For an MSP, this means a third practical client category beyond essential and important:
Supply-chain-pulled entities. Not directly in scope, but commercially required to act as if they were because their customer base demands it. The engagement looks more like an important-entity engagement than an essential-entity one — phased rollout, lighter documentation — but the customer-attestation work matters more than the regulator-attestation work.
The shape of this category is going to grow over the next two to three years as the supply-chain provisions of NIS2 mature into routine procurement practice.
What essential-entity audit evidence actually looks like
A short list of artefacts an essential-entity client is going to need to produce on demand, and where DMARC fits:
Risk-assessment record. The client's documented identification of email-impersonation as a relevant risk to the organisation. The MSP-produced sender inventory and DMARC discovery report support this.
Control statement. A documented control specifying that DMARC at p=reject is published across every owned domain, monitored continuously, with defined response thresholds. The MSP can supply this in templated form.
Implementation evidence. Dated records of when each domain reached p=quarantine and p=reject, including the supporting reporting data. The DMARC change-record discipline supplies this.
Operational-cadence evidence. Records of monthly report review, quarterly posture verification, annual policy attestation. The MSP's report-review discipline and QBR cadence supply this.
Incident-response evidence. Records of any DMARC-detected spoofing campaigns and the operational response taken. The escalation discipline from the runbook supplies this.
The pattern is consistent across audits: the auditor doesn't want to see the DMARC record itself; they want to see the documented program around it. The DMARC engagement is the source of evidence; the program-level artefacts are what the auditor reads.
What important-entity audit evidence looks like (lighter)
The equivalent list for important entities is shorter and less formal:
- Documentation that DMARC is published and at what enforcement level.
- Evidence that aggregate reports are reviewed periodically.
- Evidence that the operational response to anomalies is defined and exercised.
The same artefacts that support the essential-entity audit support the important-entity audit; they just don't have to be as polished or as comprehensive.
Where the MSP fits in the engagement
The MSP's role differs across tiers in shape, not in substance:
For essential entities, the MSP is a documented supplier of a documented service line, with formal change control, formal SLA, and explicit attestation language in the contract. The relationship is structured for the audit cycle.
For important entities, the MSP is a standard managed-service supplier with a standard contract, with the compliance-evidence-production layer added as an option. The relationship is structured for operational efficiency, with compliance support layered on top.
For supply-chain-pulled entities, the MSP is a standard managed-service supplier whose deliverables are designed to support the client's response to its customers' procurement questionnaires. The relationship is structured for customer-attestation throughput.
Different shapes of the same underlying engagement; the price points, contract templates, and team allocations differ.
What this article doesn't try to do
This article doesn't classify any specific client. Tier classification depends on national-law transposition, the specifics of the entity's operating model, and counsel advice that the MSP isn't qualified to give. What this article tries to do is give an MSP DMARC practice a working orientation to the tier split so the commercial conversation can happen efficiently.
Tools mentioned
- DMARC Validator — verify the published policy posture
- DMARC Record Generator — compose the records the audit will read
- DNS Lookup — produce the cross-resolver verification evidence
Related articles
- NIS2 and DMARC overview — the broader regulatory landscape
- NIS2 obligations for MSPs — supply-chain provisions
- NIS2 incident reporting and DMARC — reporting timelines and detection input
- DMARC change-management policy — the operational discipline NIS2 audits look for
Author: DMARC AI editorial team Last updated: June 2026