NIS2 and what it changes for SaaS email infrastructure

NIS2 (the EU's second Network and Information Security Directive) widens which organizations count as regulated "essential" or "important" entities for cybersecurity purposes, well beyond the critical infrastructure operators the original directive covered. A meaningful number of mid-sized SaaS companies now fall inside its scope where they wouldn't have under the first version. This picks up where "Why EU data residency actually matters for transactional email" (elsewhere on this blog) mentions NIS2 in passing, and goes into the specifics that post doesn't.

What NIS2 actually requires

For in-scope entities, NIS2 requires risk-management measures (things like incident handling, business continuity, supply chain security) and incident reporting obligations with specific timelines. It's a security-governance framework, not a data-protection law like GDPR, though the two overlap in practice: an incident involving personal data usually triggers obligations under both.

Essential vs. important entities

NIS2 splits in-scope organizations into two tiers with different oversight intensity. "Essential" entities (larger organizations in higher-criticality sectors, digital infrastructure, energy, health, and others) face proactive supervision and can be audited before an incident occurs. "Important" entities (a broader set including many digital service providers, at a lower size threshold) face reactive supervision, oversight kicks in after an incident is reported rather than through routine audits. Most SaaS companies newly in scope under NIS2 fall into the "important" tier, but which applies depends on sector classification and size thresholds set at the national transposition level, which vary somewhat by member state.

The incident reporting timeline

NIS2's reporting obligation is notably fast: an early warning within 24 hours of becoming aware of a significant incident, a fuller incident notification within 72 hours, and a final report within a month. This is tighter than GDPR's 72-hour breach notification window in the earliest stage, and it applies to security incidents more broadly, not just ones involving personal data. A vendor's own incident response process, and how quickly they'd actually notify you as a downstream customer, matters directly here: your 24-hour clock can't start until you know something happened.

Where it matters for choosing an email provider

If your company falls inside NIS2's scope, your vendor risk assessment now needs to account for your supply chain, including infrastructure providers like your transactional email API. That's a real, current reason a security or compliance questionnaire might ask about a vendor's incident response process and subprocessor security posture, not paperwork for its own sake.

Questions worth asking a vendor specifically

• What's the vendor's own incident detection and internal escalation timeline, before it ever reaches you as a customer notification
• Does the vendor have a documented incident response process, or is it ad hoc
• How quickly does the vendor commit to notifying customers of an incident that could affect them, in writing, not just as a verbal assurance
• Is the vendor's own infrastructure supply chain (their hosting, their subprocessors) something they can actually describe, or a black box even to them

The honest caveat

Whether NIS2 actually applies to your company depends on sector, size, and specifics that a blog post can't determine for you. This isn't legal advice, and if NIS2 applicability is a live question for your business, that's a conversation for actual counsel, not a vendor's marketing content. What a vendor can honestly say is whether its own practices (incident handling, subprocessor management, documented security measures) would hold up if your NIS2 obligations do apply, which is the more useful question to ask in a security review.