What is NIS2, and why does it reach email infrastructure?
NIS2 (Directive (EU) 2022/2555) replaces the original NIS Directive of 2016 and entered enforcement across EU Member States in October 2024. It expands the scope of cybersecurity obligations to "essential" entities (high-criticality sectors) and "important" entities (other critical sectors) including digital infrastructure providers, ICT service management providers, and providers of digital services such as cloud computing and managed service providers. Email infrastructure providers fall under the digital infrastructure / digital service provider scope. The headline obligations: Article 21 mandates ten specific technical and organizational security measures; Article 23 requires incident notification within 24 hours (early warning), 72 hours (incident notification), and 1 month (final report).
How we meet the Article 21 ten measures.
(a) Policies on risk analysis and information system security — documented in our ISMS under ISO 27001:2022. (b) Incident handling — IR runbook with PagerDuty-backed 5-minute paging 24/7, quarterly tabletop exercises. (c) Business continuity and crisis management — multi-PoP architecture with 35-day backup retention, quarterly restore testing, RPO 6 hours / RTO 4 hours. (d) Supply chain security — annual sub-processor security reviews, Transfer Impact Assessments for cross-border flows. (e) Security in network and information systems acquisition, development, maintenance — secure-SDLC with mandatory code review, automated vulnerability scanning, dependency pinning. (f) Policies and procedures to assess effectiveness — annual external penetration test, internal red-team exercises twice yearly. (g) Cyber hygiene and training — mandatory annual security training, monthly phishing simulations. (h) Cryptography and encryption — TLS 1.3 mandatory, AES-256 at rest, HSM for key protection. (i) Human resources security, access control, asset management — RBAC with named approver and time-bounded access; background checks; quarterly access reviews. (j) Multi-factor authentication and continuous authentication — MFA mandatory for production access; SAML SSO for customers.
How does your Article 23 incident notification work?
When a significant incident affects customer data or service availability, our incident commander triggers a notification cascade. Internal early-warning to affected customers within 24 hours of detection (we typically beat this; the operational target is 30 minutes from confirmation). Initial assessment with material facts within 72 hours including impact scope, root cause hypothesis, and active mitigations. Final report within 1 month with full root cause analysis, lessons learned, and corrective actions. Customers in essential or important entity sectors can rely on our notification timeline to feed their own NIS2 Article 23 notification to the national CSIRT.
Where does NIS2 enforcement actually stand in 2026?
NIS2 stopped being a future obligation. By early 2026 roughly two-thirds of member states had completed transposition into national law, and the European Commission escalated from infringement proceedings against 23 states in late 2024 to reasoned opinions against 19 in mid-2025, pressing the laggards to finish. The first administrative penalties under national NIS2 laws were issued in the first quarter of 2026, and several states set compliance and first-audit milestones around October 2026. The scope is far wider than the directive it replaced: estimates put more than 160,000 entities in scope across the EU, up from around 10,000 under the original NIS Directive, with electronic communications services pulled in as a covered sector in their own right. For an email infrastructure provider this is the operative reality rather than a horizon item, and a vendor still describing NIS2 in the future tense is a vendor that has not done the registration and reporting work the directive already requires. We completed ours under the Austrian implementation, the Network and Information System Security Act, and we are registered with CERT.at as the national CSIRT, which is the baseline a customer should expect to see evidenced rather than asserted.
Management liability under Article 20 changes who cares about your vendors.
NIS2 moved cybersecurity from the IT budget to the boardroom. Article 20 requires the management bodies of regulated entities to approve the cyber risk-management measures, to oversee their implementation, and to follow training so they can identify risks, and it provides for members of management to be held personally liable for failures to comply. That single change explains why vendor due diligence has sharpened: a manager who can be held personally accountable for a supply-chain weakness wants documented evidence from each critical supplier, not a confident sentence on a sales call. The email provider sits inside that supply chain, so the question a liable director now asks is whether the provider can produce the artifacts that let the board discharge its duty. We answer with a single-page Article 21 self-assessment that maps each of the ten measures to a concrete control, the ISO 27001 control-mapping evidence and pre-certification control evidence behind it, and the incident-coordination commitment that shows what happens when something goes wrong. The aim is to be the supplier whose evidence a director can attach to a board paper, because under Article 20 the absence of that evidence is the director's exposure, not only the vendor's.
What are the NIS2 fines and the two-tier supervision model?
NIS2 splits regulated organizations into essential and important entities, and the two tiers carry different ceilings and different supervision. Essential entities face administrative fines up to €10 million or 2% of total worldwide annual turnover, whichever is higher, and are subject to ex-ante supervision, meaning authorities can review them proactively. Important entities face up to €7 million or 1.4% of turnover and ex-post supervision, meaning authorities act on evidence of a problem rather than by routine inspection. We are classified as an important entity in the digital infrastructure sector, which sets our own supervisory posture under the Austrian regime. For a customer the tier matters because it shapes the exposure their own organization carries and the speed at which an authority will look. Where a customer is an essential entity facing proactive review, the evidence chain has to be ready before anyone asks, and a supplier that can hand over a current self-assessment and audit artifacts on demand shortens the part of that review which touches email. The fines are large enough that the documentation reducing them is no longer optional, and the enforcement pattern of rewarding implemented measures over intended ones applies here just as it does under data-protection law.
The supply-chain obligation is why your vendor posture is your problem.
Article 21 lists supply-chain security as one of the ten mandatory measures, which means a regulated entity has to manage the security of its suppliers and service providers as part of its own compliance. This is the mechanism by which NIS2 reaches providers that are not themselves named in the directive: through the contracts and due-diligence demands of the regulated customers they serve. Your email infrastructure provider is part of your attack surface and therefore part of your NIS2 posture, so the provider's security failings become your finding in an audit. We make ourselves a supply-chain asset rather than a gap by being auditable on demand: the public sub-processor list, the annual sub-processor security reviews available under NDA, the documented incident-coordination process, and the Article 21 mapping a customer can fold into its own supplier-risk file. The same transparency that satisfies a procurement questionnaire satisfies a supervisor reviewing your supply chain, because they are asking the same question from different chairs. A provider that treats supply-chain evidence as a routine deliverable rather than a special request is the one that does not become the weak link when your own assessment runs.
The 24-hour clock is an operational design constraint, not a policy line.
Article 23 sets a three-stage reporting cadence: an early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within a month. The hard part is the first stage, because the clock starts on awareness, and significance has a definition — an incident that causes or is capable of causing severe operational disruption, financial loss, or material harm to others. Meeting that deadline is not a matter of having a policy that says 24 hours; it is a matter of building the detection and confirmation pipeline so the notice can actually leave the building inside the window. Our cascade is designed to feed your clock rather than ours. Automated monitoring raises an alert within minutes, an incident commander confirms scope, and affected customers receive an early warning with the material facts well inside 24 hours, with an operational target of thirty minutes from confirmation. The notification carries what your team needs to judge whether your own Article 23 obligation is triggered, because the significance assessment for your organization is yours to make and you cannot make it without the facts. A vendor whose first notice arrives at hour twenty-three has technically complied and practically left you no time to meet your own deadline.
How do the cyber-hygiene and human-layer measures work?
Several of the ten Article 21 measures address the human layer rather than the technical stack, because most incidents start with a person rather than a zero-day. Cyber hygiene and training under measure (g) are implemented as mandatory annual security training for all staff and monthly phishing simulations, with results tracked and remediation required for anyone who repeatedly fails. Human-resources security and access control under measure (i) cover background checks at hiring, role-based access with a named approver and a time limit on every grant, and quarterly access reviews that strip permissions no longer justified by a role. Asset management sits in the same measure: a maintained inventory of systems and data so that nothing critical is unowned and unpatched. None of this is glamorous, and it is the part of a security program that decays fastest without discipline, which is the reason we document the cadence rather than the intention. A supervisor reviewing measure (g) or (i) asks for the schedule and the records, not the policy statement, and the entity that can show twelve months of completed training and access reviews is the one whose human-layer controls are treated as real. We keep those records so a customer folding our posture into a supply-chain assessment points to evidence rather than a paragraph.
Business continuity and the recovery objectives NIS2 expects.
Measure (c) of Article 21 requires business continuity and crisis management, and a regulator reading it wants numbers rather than reassurance. Our architecture spreads across multiple points of presence so the loss of one does not take the service down, backups are retained for thirty-five days and encrypted, and restore procedures are tested quarterly rather than assumed to work. The recovery objectives are stated: a recovery point objective of six hours bounding how much data a worst-case event could cost, and a recovery time objective of four hours bounding how long restoration takes. Crisis management is a documented procedure with a named incident commander and a defined escalation path, exercised in tabletop drills twice a year so the plan is muscle memory rather than a binder. For a customer, these objectives feed directly into their own continuity planning, because the resilience of an email channel that carries password resets, order confirmations, and security alerts is part of the customer's own operational risk picture. A provider that can state its RPO and RTO and show the restore-test evidence lets a customer write a continuity plan against real figures, while a provider that speaks only of high availability leaves the customer guessing at the numbers an auditor will eventually ask for.
Where do NIS2 and DORA divide for a financial customer?
A financial entity reading this page is often subject to both NIS2 and DORA, and the two do not stack arbitrarily. DORA is lex specialis under NIS2 Article 4(1), which means that for the ICT risk-management and incident-reporting obligations the two frameworks share, a financial entity follows DORA and is treated as having met the equivalent NIS2 duties. Banking and financial market infrastructure were carved out of the core NIS2 sectors precisely because DORA governs their operational resilience in more specific terms. For a fintech or a bank choosing an email provider, this decides which reporting timeline and which register obligations bind: the DORA incident-reporting rules and the Register of Information requirements rather than the NIS2 Article 23 cascade, even though the underlying security expectations are closely aligned. We hold the same evidence either way, and our DORA page covers the financial-sector specifics, but the division is worth stating here so a financial buyer does not assemble a NIS2 file when DORA is the framework their supervisor will actually apply.