NIS2 and DORA Email Requirements: Encryption, Authentication, and Incident Reporting Standards for EU Compliance

A misdirected spreadsheet, a spoofed invoice, or one compromised mailbox can now trigger three separate regulatory clocks across the European Union. The NIS2 Directive and the Digital Operational Resilience Act (DORA) have made email a supervised control surface for essential entities, important entities, and financial institutions, with administrative fines reaching €10 million or 2% of global annual turnover. According to ENISA's Threat Landscape 2025, phishing accounts for roughly 60% of observed initial intrusion cases across the European Union, which places email at the center of the risk both regulations were written to contain.

Supervisory authorities are no longer asking whether email security policies exist. They are sampling configuration evidence, authentication records, and incident timelines against specific legal articles. The gap between a policy document and a provable control is where enforcement action begins.

This guide covers:

• The encryption mandates and cryptographic key management obligations embedded in the NIS2 and DORA email requirements;
• How DMARC, DKIM, SPF, MTA-STS, and DANE satisfy the authentication standards regulators expect;
• The incident reporting cascades that both frameworks impose on email-borne compromises;
• Third-party and supply chain obligations that extend the NIS2 and DORA email requirements to every supplier;
• Human error controls, data loss prevention, and the cybersecurity awareness training obligations both regulations name;
• A phased roadmap for auditing email security posture and producing supervisory-grade evidence.

Compliance programs fail inspection when technical controls exist but the human layer generates no evidence. Adaptive Security produces the audit trail supervisory authorities request.

Take a self-guided tour

What Are the NIS2 and DORA Email Requirements?

The NIS2 and DORA email requirements originate in two separate EU instruments that arrived within months of each other and now govern overlapping populations of regulated entities. NIS2 (Directive EU 2022/2555) establishes a common cybersecurity framework for essential and important entities across 18 sectors, while the Digital Operational Resilience Act (DORA, Regulation EU 2022/2554) imposes ICT risk management, incident reporting, and resilience testing obligations on financial entities. Understanding which instrument governs which control is the first prerequisite for building a defensible email security posture.

The NIS2 Directive: Scope, Classification, and Deadlines

The NIS2 Directive represents the most significant expansion of EU cybersecurity law in a decade. Where the original NIS Directive covered approximately seven sectors, NIS2 extends to 18, split across two annexes.

Annex I lists 11 sectors of high criticality: energy, transport, banking, financial market infrastructures, health, drinking water, waste water, digital infrastructure, ICT service management, public administration, and space. Annex II covers seven other critical sectors: postal and courier services, waste management, chemicals, food, manufacturing, digital providers, and research. The European Commission estimates that roughly 160,000 entities fall within scope throughout the Union.

Entity classification follows a size-cap rule derived from the EU's SME definition. An organization falls within scope when it meets either threshold of at least 50 employees or annual turnover exceeding €10 million, and crossing a single threshold triggers compliance obligations under the NIS2 and DORA email requirements where applicable.

Classification then depends on sector and size:

• Large enterprises in Annex I sectors, meaning 250 or more employees or turnover above €50 million, are designated as essential entities, subject to proactive ex-ante supervision and fines up to €10 million or 2% of global annual turnover, whichever is higher;
• Medium enterprises in Annex I sectors, meaning 50 to 249 employees or €10 million to €50 million turnover, are classified as important entities facing reactive ex-post supervision;
• All medium and large enterprises in Annex II sectors are also classified as important entities, with maximum penalties of €7 million or 1.4% of global turnover.

Certain entity types fall within scope regardless of size. DNS service providers, TLD registries, trust service providers, and public electronic communications networks are automatically covered even with fewer than 50 employees and turnover below €10 million. Public administration entities at central government level are captured irrespective of headcount.

Member States were required to transpose NIS2 into national law by 18 October 2024, and only four met the deadline. By 2026, most have completed transposition, though several remain outstanding, which creates a fragmented enforcement landscape. Organizations operating across multiple Member States must assess compliance under each jurisdiction's transposition, because national implementations may impose stricter requirements than the directive's minimum baseline.

The DORA Regulation: Financial Sector Operational Resilience

DORA is a regulation rather than a directive, which means it applies directly and uniformly in all EU Member States without requiring national transposition. It came into force on 17 January 2025 and targets 21 categories of financial entities, including credit institutions, payment institutions, electronic money institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers, central securities depositories, trading venues, fund managers, and crowdfunding platforms. ICT third-party service providers designated as critical by the European Supervisory Authorities are also captured.

The regulation is organized around five foundational pillars:

• ICT risk management requires financial entities to maintain a comprehensive internal governance and control framework, documented, reviewed annually, and approved by the management body, covering asset identification, protection measures, detection capabilities, response and recovery procedures, and continuous learning;
• ICT-related incident management and reporting mandates processes for detecting, classifying, and notifying major incidents, with an initial notification deadline of four hours after classification;
• Digital operational resilience testing requires a testing program conducted by independent parties, with systemically important entities performing threat-led penetration testing at least every three years under the TIBER-EU framework;
• ICT third-party risk management imposes contractual obligations on ICT service providers, mandates a register of all ICT arrangements, and establishes direct supervision of critical providers;
• Information and intelligence sharing permits financial entities to establish voluntary arrangements for exchanging cyber threat data, subject to notification to competent authorities.

Penalties under DORA reach up to 2% of total annual worldwide turnover, and management body members can face individual fines of up to €1 million. The regulation also empowers competent authorities to temporarily suspend individuals from management functions for non-compliance. That personal liability mechanism concentrates attention at board level in a way earlier financial-sector rules did not.

How the NIS2 and DORA Email Requirements Intersect

The relationship between the two frameworks is governed by Article 4 of DORA, which establishes the regulation as lex specialis, a specialist law that takes precedence over the general law for financial entities. Both Recital 16 of DORA and Recital 28 of NIS2 confirm this hierarchy. Wherever DORA imposes a specific requirement, covering ICT risk management under Articles 5 through 16, incident reporting under Article 19, and resilience testing under Articles 24 through 27, financial entities follow DORA and national authorities cannot impose overlapping NIS2 obligations in those areas.

The table below summarizes where the two instruments diverge on the dimensions that matter most for email.

Financial entities do not receive a blanket exemption from NIS2. DORA addresses ICT risk comprehensively but does not cover every obligation in NIS2 Article 21. Supply chain security provisions under NIS2 Article 21(2)(d) that extend beyond ICT providers, reaching physical security suppliers or facilities management contractors, remain enforceable for financial entities.

Human resources security, cryptography policies, and certain governance reporting requirements under NIS2 may also apply where DORA is silent. Compliance teams must map both frameworks to identify gaps rather than assuming DORA compliance alone is sufficient.

On email specifically, both instruments converge. NIS2 Article 21(2) lists email security measures among the required cybersecurity risk management practices for all in-scope entities, including policies on secure communication and cybersecurity awareness training that addresses social engineering delivered through email. DORA's ICT risk management framework under Articles 5 through 16 encompasses the same domain, requiring protection measures for communication channels, detection capabilities for email-borne cyber threats, and staff awareness programs.

Because DORA's provisions are more prescriptive, financial entities meet their obligations under the NIS2 and DORA email requirements primarily through DORA compliance, while non-financial entities rely on Article 21 and its national transpositions. The critical divergence is that DORA mandates regular, independent resilience testing of those email security controls, a specificity NIS2 does not match for non-financial sectors.

For organizations building a unified compliance program, starting with DORA as the baseline and layering NIS2 requirements where DORA is silent produces the most efficient path to dual compliance. DORA's framework is more granular in nearly every domain, spanning risk management, testing, and third-party oversight. Satisfying DORA inherently covers the majority of NIS2 obligations for financial entities, though leaving the remaining gaps unaddressed exposes organizations to penalties under both.

Mapping two overlapping frameworks by hand produces duplicated effort and uncovered gaps in equal measure. Adaptive Security aligns email security evidence to both regulatory baselines at once.

Explore the platform

NIS2 Article 21: Core Email Security Requirements

NIS2 Article 21 mandates email security through three intersecting obligations that transform email from a compliance blind spot into a regulated control surface. Subparagraph (h) requires state-of-the-art encryption for data in transit and at rest, subparagraph (j) compels multi-factor authentication on email accounts processing sensitive data, and subparagraph (d) extends these controls to every supplier and service provider exchanging email with the organization. The Commission Implementing Regulation (EU) 2024/2690 specifies internationally agreed and interoperable modern email communications standards as the benchmark, which turns protocols like DMARC, MTA-STS, and TLS into evidence of regulatory diligence under the NIS2 and DORA email requirements.

Encryption Mandates Under NIS2 Article 21

Article 21(2)(h) requires policies and procedures regarding the use of cryptography and, where appropriate, encryption. That language carries more weight than it appears. The Directive's Implementing Regulation translates it into concrete expectations: entities must protect data in transit and at rest with cryptographic measures appropriate to asset classification, establish the protocols and families of protocols to be adopted, and define key management practices spanning generation, distribution, revocation, and destruction.

For email, this means encrypting messages across every state where they exist. In transit, the obligation maps to transport-layer security that resists downgrade cyberattacks. Three protocols carry that load:

• MTA-STS (RFC 8461) publishes a TLS policy over HTTPS so sending servers refuse plaintext fallback;
• DANE (RFC 6698 and RFC 7672) pins TLS certificates in DNS via DNSSEC, creating cryptographic certainty about the receiving server's identity;
• TLS-RPT (RFC 8460) provides the visibility layer, generating structured reports when transport encryption fails.

Together, these three protocols satisfy the Annex point 6.7.2(i) requirement for trusted channels isolated using logical, cryptographic, or physical separation. Deploying one without the others leaves either the enforcement or the monitoring half of the obligation unmet.

At rest, the same encryption policy must cover stored email, including archives and backups. The Implementing Regulation's Annex point 9.2(a) explicitly names data at rest as within the cryptography policy's scope. For organizations running on-premises mail servers or maintaining years of archived communications, this means encrypting mail databases with AES-256 or equivalent and managing keys with documented rotation, revocation, and recovery procedures.

The phrase "state-of-the-art" appears in Article 21(1) and carries specific legal weight under EU law. It means the measure must reflect what is technically possible and reasonably available at the time of assessment, instead of what was standard when systems were deployed. What satisfies the obligation today will not necessarily satisfy it in 2028.

This dynamic standard is what makes the Implementing Regulation's reference to internationally agreed and interoperable modern email communications standards so consequential. It anchors compliance to an evolving, consensus-driven benchmark rather than a fixed checklist that ages out.

Multi-Factor Authentication Requirements Under NIS2

Article 21(2)(j) requires the use of multi-factor authentication or continuous authentication solutions, secured voice, video, and text communications, and secured emergency communication systems within the entity, where appropriate. The Annex to Implementing Regulation (EU) 2024/2690 sharpens this into operational detail at point 11.7, mandating that entities establish and implement a policy on multi-factor authentication. Point 11.3.2 adds a requirement for strong identification, authentication, and authorisation procedures covering privileged accounts and system administration accounts.

For email specifically, MFA becomes mandatory on any account that provides access to sensitive data or administrative controls. A single-factor mailbox password no longer meets the legal standard. Every email account with access to personal data, financial information, intellectual property, or system administration functions must be protected by at least two independent authentication factors.

This applies with equal force to cloud-based email platforms such as Microsoft 365 and Google Workspace as it does to on-premises Exchange deployments. According to Verizon's 2026 Data Breach Investigations Report, stolen credentials were involved in 13% of all breaches, which keeps single-factor mailbox access squarely inside the risk population regulators are examining.

The interplay with zero-trust architectures is deliberate. Recital 20 of the Implementing Regulation explicitly names zero-trust principles among basic cyber hygiene practices, and in a zero-trust email architecture MFA operates as a continuous verification layer rather than a one-time gate. Authentication persists throughout the session, and anomalous behavior such as access from an unusual location, device, or time triggers re-authentication.

Recital 23 reinforces this by noting that multi-factor authentication can be combined with other techniques to require additional factors under specific circumstances, based on predefined rules and patterns. The practical consequence for security teams is that NIS2 MFA compliance requires integrating authentication into a broader access control framework, extending well past the act of deploying a second factor.

Password-only email access, even with complex password policies, is no longer defensible under Article 21. Every organization in scope must document which email accounts process sensitive data, confirm MFA is enforced on those accounts, and retain logs demonstrating enforcement continuity over time. The Implementing Regulation's point 3.2.1 requires logging of authentication-related events, which means MFA enforcement must be provable rather than merely asserted.

Supply Chain Email Security Under NIS2 Article 21

Article 21(2)(d) requires supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers. Paragraph 3 then demands that entities take into account the vulnerabilities specific to each direct supplier and service provider, the overall quality of their products and cybersecurity practices, and their secure development procedures.

For email, this obligation cascades in two directions. First, organizations must assess whether their own email infrastructure meets the standards their regulators will measure against. A February 2026 scan of 5.5 million domains found that only 12.8% enforce DMARC, 0.3% publish MTA-STS, and near-zero domains deploy DANE.

An organization sitting in the majority without DMARC enforcement sends every supplier a message that arrives without cryptographic assurance of authenticity. That creates a supply chain vulnerability that the regulation explicitly requires the entity to close.

Second, the obligation reaches outward into the supplier ecosystem. The Implementing Regulation's Annex point 5.1.4 requires cybersecurity provisions in supplier contracts, and Annex point 5.1.7 requires entities to monitor service level agreement reports, review supplier incidents, and analyse the risks introduced by changes. Compliance under Article 21 is therefore continuous, since a supplier's posture at onboarding tells a supervisor nothing about its posture eighteen months later.

Where suppliers fall short, the entity owes documented remediation or contractual enforcement. Organizations that skip that step face a regulatory finding on the supply chain obligation even when their own email infrastructure is fully compliant. Phishing simulations that test employee response to supplier-impersonation scenarios close the gap between technical controls and human judgment.

One supplier sending unencrypted sensitive data over plaintext SMTP creates a violation traceable back to the entity that failed to mandate encryption contractually. A supplier's failure becomes the entity's liability, because the enforcement mechanisms built into Article 21 ensure that responsibility follows the data.

Supplier impersonation succeeds because employees have no reference point for what a compromised vendor thread looks like. Adaptive Security builds that recognition through targeted phishing simulations.

Take a self-guided tour

DORA's Email Security Framework for Regulated Communications

Financial entities cannot treat email as a generic communication tool under the Digital Operational Resilience Act. DORA's Regulatory Technical Standards, specifically Commission Delegated Regulation (EU) 2024/1774, impose a structured, auditable framework governing how sensitive information is classified, encrypted, and delivered on email channels. The framework leaves no ambiguity within the NIS2 and DORA email requirements: email containing critical or important information must be protected from composition through delivery, access, and retention, with documented proof that controls functioned correctly at every stage.

How DORA Requires Financial Entities to Classify Email Content

Data classification is the foundation on which every subsequent email security control rests under DORA. Articles 6, 7, 13, and 14 of the RTS on ICT risk management create a chain of obligations that begins with the sensitivity assessment and extends through proportionate protection measures.

Article 6, paragraph 2 requires financial entities to develop, document, and implement a policy on encryption and cryptographic controls whose design flows directly from an approved data classification scheme. Email content cannot receive uniform treatment. A routine meeting invitation and a message containing payment instructions, client portfolios, or regulatory filings must trigger different levels of protection, and the entity must be able to demonstrate the logic that assigned each classification tier.

Article 7, paragraph 2 reinforces this by tying cryptographic key management directly to the sensitivity of the information being protected. The more sensitive the email content, the more rigorous the key lifecycle governance that must surround it.

Article 13 extends classification logic into network security management, requiring financial entities to configure network controls so that traffic carrying classified data is segmented and monitored in accordance with its sensitivity level. Article 14, paragraph 2 then mandates that these classification decisions travel with the data.

Information in transit must be secured using controls commensurate with the classification established at rest, and the entity must document how that proportionality is maintained. An email classified as containing critical information at composition cannot be downgraded to a lower protection tier mid-transmission without violating the RTS framework.

Classification must persist throughout the data lifecycle, and this is the provision most financial institutions underestimate. An email archived in a mailbox six months after delivery retains its original classification obligation, and the encryption and access controls applied at that stage must reflect it. A 2025 Deloitte European survey found that only 25% of institutions reported full compliance with DORA's ICT risk management pillar, where classification and encryption requirements reside, and half of surveyed entities expected to reach full compliance only by 2026 or 2027.

DORA Encryption Requirements Across All Three Data States

DORA's encryption mandate is unusual in regulatory frameworks because it explicitly addresses three states within a single article: in transit, at rest, and in use. Article 6 of the RTS requires financial entities to adopt a policy containing rules for the encryption of data at rest and in transit, the encryption of data in use where necessary, and the encryption of internal network connections and traffic with external parties. No other major financial-sector regulation in Europe treats encryption as a tri-state obligation with this level of specificity.

Encryption in transit protects email and attachments from interception or modification during transmission. For financial entities, this means enforcing TLS 1.3 or equivalent protocols on all email relays and refusing plaintext SMTP connections with external counterparties.

Article 14, paragraph 1 expressly requires entities to develop, document, and implement the policies, procedures, protocols, and tools to protect information in transit, with an emphasis on preserving availability, authenticity, integrity, and confidentiality. Those four properties collectively rule out opportunistic TLS alone as sufficient.

Encryption at rest covers stored email on servers, endpoint devices, and backup systems. Article 7 establishes the cryptographic key management policy that must govern this layer, requiring keys to be securely generated, stored, rotated, and retired according to documented procedures, with access to key material restricted on a least-privilege basis. The policy must also define criteria for selecting encryption algorithms and key lengths appropriate to the sensitivity of the protected data, such as AES-256 for critical financial communications instead of weaker ciphers that would fail a regulatory audit.

Encryption in use is the most operationally demanding of the three states. It requires financial entities to evaluate whether sensitive email content needs protection while being processed, such as when an anti-malware scanner inspects an attachment or a compliance review tool indexes message content.

Article 6, paragraph 4 adds a forward-looking obligation: entities must include provisions for updating cryptographic technology on the basis of developments in cryptanalysis. Post-quantum encryption migration planning is not optional for DORA-scoped institutions. A cryptographic standard that is acceptable today must have a documented path to replacement when cryptanalytic advances render it obsolete.

How Financial Entities Must Authenticate Recipients and Prove Secure Delivery

DORA's recipient authentication and delivery verification obligations close a gap that traditional email security architectures have long ignored, which is proving not just that a message was sent but that it was received and accessed by the correct person. Articles 12, 14, 20, and 21 of the RTS collectively construct an accountability chain that links identity verification, access logging, and delivery assurance into a single auditable workflow.

Article 20, paragraph 1 establishes the baseline, requiring financial entities to implement policies and procedures that ensure the unique identification and authentication of natural persons and systems accessing the entity's information. Before a recipient can open a message containing classified data, their identity must be verified through a method commensurate with the data's sensitivity.

A password-protected mailbox does not satisfy this requirement for critical communications. Multi-factor authentication, applied at the point of access to the email content itself, is the expected control, particularly when the message contains information classified under Article 8(1) of the DORA Regulation.

Article 21 reinforces this by requiring authentication methods calibrated commensurate to the classification of the ICT assets and information, considering leading practices. This proportionality principle creates a sliding scale: an email containing publicly available regulatory filings may require basic authentication, while one containing non-public financial data or personally identifiable information demands stronger verification. The entity must document the rationale for each authentication tier.

Article 12 mandates that financial entities log all events related to logical and physical access control and identity management. In the email context, this translates to recording when a classified message was accessed, by whom, from which device, and with which authentication method. These logs must be retained in a format that supports regulatory audit and incident investigation.

Article 14 brings delivery assurance under the same framework by requiring entities to establish procedures that assess compliance with confidentiality requirements during network transmission. Practical implementation includes delivery receipts with cryptographic proof of recipient identity, read confirmations tied to authenticated sessions, and tamper-evident delivery logs.

Those logs demonstrate to a supervisor that a critical communication reached its intended recipient and was accessed only by authorized parties. For financial institutions facing disputes over whether a regulatory notification or client instruction was received, this audit trail transforms email from a trust-based medium into an evidentiary-grade communication channel.

Delivery logs establish that a message arrived, yet they cannot establish that the recipient treated it correctly. Adaptive Security measures and improves how employees handle regulated communications.

Book a demo

Email Authentication Protocols for NIS2 and DORA Compliance

Authentication protocols are the most testable component of the NIS2 and DORA email requirements, because a supervisory authority can verify them from outside the organization in seconds. SPF, DKIM, and DMARC close the authentication gap that enables domain spoofing and business email compromise (BEC), while DANE and MTA-STS enforce TLS encryption in transit and prevent downgrade cyberattacks that strip encryption from SMTP traffic. Each protocol addresses a distinct attack surface, and partial deployment leaves specific vectors open even when other controls are in place.

1. Deploy DMARC, DKIM, and SPF: The Authentication Triad

SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance) together answer the question every receiving mail server asks about whether an email genuinely originates from the domain it claims. NIS2 leaves these protocols unnamed in its own text, though the Implementing Act published by the European Commission requires essential and important entities to adopt an implementation plan for the deployment of internationally agreed and interoperable modern email communications standards, and SPF, DKIM, and DMARC are precisely those standards.

SPF publishes a DNS TXT record listing every IP address and domain authorized to send email on behalf of a domain. When a receiving server sees an inbound message, it checks the Return-Path domain against the published SPF record, and if the sending IP is not listed, SPF fails. SPF alone addresses direct domain spoofing, though it does nothing to protect the visible From address that recipients actually see.

DKIM adds a cryptographic signature to every outbound message. The sending server signs the email with a private key, and the receiving server verifies the signature using the public key published in the domain's DNS. A passing DKIM check confirms the message genuinely originated from an authorized server and was not altered in transit, though DKIM alone cannot tell a receiving server what to do when authentication fails.

DMARC ties SPF and DKIM together and publishes a policy telling receiving servers how to handle messages that fail authentication. DMARC also requires alignment, meaning the domain authenticated by SPF or DKIM must match the domain in the visible From header.

This alignment requirement defeats the exact-domain-spoofing cyberattacks that fuel BEC and executive impersonation fraud. Without DMARC enforcement, a cyberattacker can pass SPF or DKIM using a different domain while still displaying an executive's domain in the recipient's inbox.

The configuration best practice is unambiguous, which is to progress DMARC to p=reject. At p=none, the domain owner receives reports but no mail is blocked, and at p=quarantine, failing mail is sent to spam. Only at p=reject does the receiving server silently discard unauthorized messages at the SMTP level, eliminating the delivery vector entirely.

2. Implement DANE and MTA-STS for Transport Encryption

Authentication protocols verify sender identity, while transport encryption protocols prevent cyberattackers from reading or modifying email as it moves between servers. SMTP by default transmits email in plaintext, and opportunistic TLS through STARTTLS attempts to upgrade the connection to encrypted. A man-in-the-middle cyberattacker can strip the STARTTLS command and force the sending server to fall back to cleartext, which is exactly the downgrade cyberattack that DANE and MTA-STS are designed to prevent.

DANE (DNS-based Authentication of Named Entities) uses DNSSEC to publish a TLSA record that cryptographically binds a domain's MX servers to specific TLS certificates. When a sending server queries the receiving domain's DNSSEC-signed TLSA record, it receives a verified assertion about which certificate to expect, and if the certificate presented during the TLS handshake does not match, the connection is refused. DANE eliminates the trust-on-first-use problem that plagues opportunistic TLS, though it requires DNSSEC deployment on the receiving domain as a prerequisite.

MTA-STS (Mail Transfer Agent Strict Transport Security) achieves a similar outcome through a different trust model. Instead of DNSSEC, MTA-STS relies on a policy file hosted at a well-known HTTPS URL, plus a DNS TXT record signaling that the policy exists. The policy declares that the domain requires TLS and specifies which MX hosts are authorized.

Because HTTPS certificate authorities validate domain control, MTA-STS sidesteps the DNSSEC dependency that has constrained DANE adoption. The trade-off is that MTA-STS trusts the web PKI rather than the DNS hierarchy.

Adoption of both protocols remains extremely low. A URIports survey of the top one million domains in January 2024 found that only 2,924 domains had published an MTA-STS policy, of which 19.5% were misconfigured and ineffective. Roughly 1,278 domains had a correctly implemented enforced policy actively preventing downgrade cyberattacks, and DANE adoption is similarly sparse, held back by the prerequisite of DNSSEC deployment across the domain's DNS zone.

NIS2 Article 21 requires entities to take measures taking into account the state of the art and, where applicable, relevant European and international standards. Both DANE (RFC 6698 and RFC 7672) and MTA-STS (RFC 8461) are published IETF standards representing the current state of the art for SMTP transport encryption.

Organizations under NIS2 scope that process sensitive data via email can reasonably expect transport encryption to be assessed as part of their compliance posture. Estonia has already set a precedent, requiring public bodies to implement DMARC in addition to MTA-STS or DANE under its national cybersecurity framework.

3. Align With EU Member State Precedents and the Bulk Sender Baseline

Six EU member states have established national mandates requiring DMARC and DKIM for public bodies and, in some cases, critical infrastructure operators. These precedents indicate how supervisory authorities are likely to interpret the NIS2 and DORA email requirements in jurisdictions that have not yet legislated specifics, and they cluster tightly around the same protocol set.

The national mandates break down as follows:

• The Netherlands has required DMARC and DKIM for public bodies since at least 2018, making it the earliest mover in the bloc;
• Czechia extended the requirement to important and essential entities in 2021, aligning national policy with NIS2 classification language ahead of transposition;
• Denmark mandated DMARC and DKIM for government bodies in 2022, and Ireland published Cyber Security Baseline Standards imposing the same requirements on public service bodies that year;
• Poland's 2023 regulation covers both public bodies and certain private-sector entities;
• Estonia's 2023 standards go furthest, requiring DMARC plus either MTA-STS or DANE, explicitly pairing authentication with transport encryption in a single national mandate.

The remaining 21 member states have no binding national requirements, though several have published non-binding guidance. That asymmetry does not reduce exposure, because Article 21's state-of-the-art clause applies uniformly regardless of whether a national regulator has named a protocol.

The 2024 Google and Yahoo bulk sender requirements created the compliance forcing function that national mandates alone could not. Beginning February 2024, any domain sending more than 5,000 messages per day to Gmail or Yahoo inboxes was required to publish SPF, DKIM, and a DMARC record.

The impact was immediate and measurable. Valimail reported, citing Google data shared at the October 2024 M3AAWG meeting, that Gmail users received 265 billion fewer unauthenticated emails in 2024 than in 2023, a 65% year-over-year reduction, and that 2.5 million domains newly implemented email authentication in the first 60 days of 2024 alone.

Google and Yahoo required only DMARC at p=none, the monitoring policy that provides no actual spoofing protection. Organizations that rushed to publish a p=none record in early 2024 checked the deliverability box without closing the spoofing vector.

The demand for state-of-the-art measures within the NIS2 and DORA email requirements implies a higher standard. A domain at p=none is monitoring the cyber threat; a domain at p=reject is eliminating it, and for entities classified as essential or important under NIS2 and financial institutions subject to DORA, that difference separates a documented process from a functional security control.

The bulk sender mandate proved the ecosystem can shift rapidly when commercial consequences are clear. NIS2 and DORA now supply the regulatory consequence, and organizations treating authentication as a one-time compliance exercise leave the same attack surface open that regulators are now examining.

Publishing a DMARC record at p=none satisfies a deliverability requirement and stops nothing. Adaptive Security helps compliance teams demonstrate enforcement across every sending domain.

Explore the platform

Why Email Remains the Primary Cyberattack Vector for Regulated Entities

Email concentrates regulatory risk because it combines an architecture that predates encryption with a user population that regulators now expect organizations to train and measure. When entities fail to secure email, cyberattackers exploit its inherent lack of encryption and authentication to bypass technical controls and target employees directly. Under the NIS2 and DORA email requirements, that failure converts into direct regulatory liability, because one successful phishing email can trigger credential theft, lateral movement, data exfiltration, and service disruption that violates multiple frameworks simultaneously.

Email's Inherent Insecurity as a Compliance Problem

Email was not built for the regulatory environment in which it now operates. The Simple Mail Transfer Protocol (SMTP), designed in 1982, transmits messages in plain text with no built-in encryption or sender authentication. A 2023 analysis published in the journal Sustainability confirmed that SMTP server communications travel in plain text, which makes eavesdropping possible.

Transport Layer Security can encrypt messages in transit, though it remains optional, inconsistently deployed, and vulnerable to downgrade cyberattacks that strip encryption silently. Sender authentication protocols were retrofitted decades after email's design, and their adoption remains fragmented across organizations.

This architectural deficit means standard email cannot meet the baseline expectations of the NIS2 and DORA email requirements without additional controls layered on top. NIS2 Article 21 requires state-of-the-art measures including multi-factor authentication, encryption, and secure communications for essential and important entities, while DORA's ICT risk management framework mandates that financial entities protect the confidentiality, integrity, and availability of their communication channels. Plain SMTP email, the default for most organizations, satisfies none of these requirements.

Security was added to internet protocols after the fact, and email remains the clearest illustration of that sequence. A system designed for open academic communication now transmits sensitive financial data, personal information, and critical infrastructure commands across the same fundamentally insecure channels. The gap between what regulators require and what email natively delivers is architectural, which places it beyond the reach of any settings change.

The Regulatory Risk of Unsecured Email Communications

Regulatory exposure from unsecured email takes three concrete forms that directly undermine compliance with the NIS2 and DORA email requirements. Each maps to a different article, and each generates a different evidentiary burden when a supervisory authority begins asking questions. When teams assess each failure mode on its own, they can assign a specific control to each one.

First, misaddressed emails remain one of the most common causes of personal data breaches. An employee accidentally sends a spreadsheet containing customer financial data to the wrong recipient, and the organization has committed a notifiable GDPR breach with potential fines of up to €20 million or 4% of global annual turnover. For entities within NIS2 and DORA scope, that same incident triggers additional reporting obligations and compounds regulatory exposure.

Second, business email compromise and phishing operate as the primary vectors for operational disruption across NIS2-covered sectors. A cyberattacker who compromises one email account at an energy provider, hospital, or financial institution gains a foothold that can cascade into service-disrupting ransomware, data theft, or fraudulent wire transfers, each a reportable incident under both frameworks.

According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, business email compromise accounted for $3.046 billion in losses across 24,768 incidents, averaging roughly $123,000 per case. The scale of that figure reflects a fraud model that exploits email's lack of built-in sender verification to impersonate executives and redirect payments.

Third, unsecured email fundamentally undermines the ICT risk management frameworks both regulations demand. An organization cannot demonstrate risk proportionality when its most-used communication channel lacks encryption, authentication, and monitoring.

The interconnected nature of these regulations compounds the risk further. One phishing incident at a financial institution can simultaneously trigger DORA's major incident reporting requirement within four hours of classification, NIS2's incident notification obligation within 24 hours, and GDPR's breach notification duty within 72 hours.

Real-World Consequences for EU Entities Under NIS2 and DORA

The consequences are already material, and they arrive through enforcement records rather than projections. European regulators have consistently ranked misdirected emails and phishing-related breaches among the most common triggers for enforcement action, which places email failures at the center of the penalty history that supervisory authorities now build on. The DLA Piper GDPR Fines and Data Breach Survey reported that cumulative GDPR fines reached €5.88 billion by January 2025.

Operational losses from email-borne cyberattacks cascade rapidly through regulated entities. For entities within NIS2 scope, an email-originated disruption affecting service continuity triggers mandatory incident reporting and potential enforcement action. DORA-governed financial entities face an even tighter timeline, which makes email security an operational necessity for avoiding regulatory escalation, extending well beyond a compliance checkbox.

Supplier compromise compounds that exposure across the financial sector. According to ENISA's Finance Sector Threat Landscape 2024, cyberattacks on financial suppliers resulted in sensitive data exposure in 63% of cases alongside significant operational disruption.

The entities with the least tolerance for a reportable incident are also the ones absorbing the highest volume of attempts against their inboxes.

Phishing simulations that replicate the full spectrum of email-borne cyber threats, from credential harvesting to executive impersonation, are an essential control for any entity operating under that pressure. Phishing simulation programs also produce the behavioral record that turns a defensive claim into supervisory evidence.

Simulated executive impersonation reveals which teams escalate and which comply silently. Adaptive Security turns that finding into measurable behavior change.

Take a self-guided tour

Incident Reporting Obligations Under NIS2 and DORA

When a phishing cyberattack compromises employee credentials or a business email compromise scam diverts six figures to a fraudulent account, the reporting clock starts immediately and runs faster than most security teams expect. Both frameworks impose mandatory, multi-stage timelines within the NIS2 and DORA email requirements, obliging organizations to notify the correct authorities within hours, provide a detailed assessment within days, and deliver a root-cause analysis within one month. Email remains the dominant initial cyberattack vector, and email-borne incidents trigger these obligations more often than any other category.

1. NIS2 Incident Reporting: The 24-Hour Cascade

NIS2 Article 23 establishes a three-stage reporting obligation for essential and important entities. The trigger is a significant incident, defined as one that causes or could cause severe operational disruption or financial loss for the entity, or that affects other persons through considerable material or non-material damage. An email-based ransomware cyberattack that encrypts core systems, a spear-phishing breach exposing customer data, or a BEC wire fraud exceeding a materiality threshold each qualify.

The cascade operates on a fixed schedule in three stages:

• An early warning must reach the national CSIRT or competent authority within 24 hours of the entity becoming aware of the incident, indicating whether malicious acts are suspected and whether cross-border impact exists;
• A full incident notification follows within 72 hours, updating the early warning with an initial assessment of severity, impact, and any available indicators of compromise;
• A final report is due no later than one month after the 72-hour notification, covering a detailed incident description, root cause or cyber threat type, applied and ongoing mitigation measures, and cross-border impact where applicable.

For email-borne incidents specifically, the CSIRT notification must include the phishing methodology, the email systems affected, the data types exposed, and whether the cyberattacker achieved lateral movement. The competent authority varies by member state, with Germany's BSI, France's ANSSI, and the Netherlands' NCSC each serving as the national point of contact.

The reporting clock is uniform across the EU. NIS2 also requires entities to notify affected service recipients without undue delay when a significant incident is likely to disrupt their services, which adds a parallel customer-communication obligation that security leadership must plan for in advance.

2. DORA's Three-Tier Reporting Structure for Email Incidents

DORA applies exclusively to financial entities, covering banks, insurers, investment firms, and their ICT third-party providers, and its reporting clock starts even faster. Under the Regulatory Technical Standards developed by the European Supervisory Authorities, a major ICT-related incident triggers a three-tier reporting structure. When an incident involves successful malicious and unauthorized access, which encompasses essentially every phishing breach and BEC cyberattack, it automatically qualifies as major regardless of other thresholds.

The three tiers operate in sequence:

• The initial notification is due within four hours of classifying the incident as major and no later than 24 hours from discovery, reporting incident type, affected services, estimated impact, and initial mitigation actions to the national competent authority;

• The intermediate progress report follows within 72 hours of the initial notification, providing root cause analysis if available, full impact scope, and ongoing recovery measures;
• The final report is due within one month, containing the complete incident timeline, root cause determination, recovery effectiveness assessment, lessons learned, and preventative measures implemented.

Email-based incidents that trigger DORA reporting include phishing cyberattacks that compromise customer account access, BEC scams resulting in material financial loss, and data exfiltration via compromised email accounts. For a financial institution, even one employee mailbox compromise that exposes client personally identifiable information can meet the major-incident threshold if it affects a large number of users or involves data loss across the confidentiality dimension.

The RTS requires entities to submit reports even when information is incomplete, with updated reports following as soon as missing details become available or the situation changes. That provision removes any justification for delaying an initial notification while an investigation matures.

3. Building an Email Incident Response Plan for the NIS2 and DORA Email Requirements

Organizations subject to both frameworks, typically large financial institutions carrying essential-entity designations, need a single incident response plan that triggers both notification workflows simultaneously rather than operating two disconnected processes. The ENISA technical implementation guidance, published in June 2025, emphasizes that entities must maintain a clear overview of overlapping reporting obligations to avoid duplication during active incident response.

Start by mapping every email-based incident type, spanning credential phishing, BEC, malware delivery, account compromise, and data exfiltration, against both frameworks' significance thresholds. Document which incident types trigger NIS2 only, which trigger DORA only, and which trigger both. For each dual-trigger scenario, pre-assign notification responsibilities covering who contacts the CSIRT, who contacts the financial regulator, and who manages customer notifications.

Build email-specific playbooks that pre-populate the fields both frameworks require. Every phishing incident playbook should capture the sender address, subject line, payload type, number of recipients, click-through rate, credential entry rate, and any evidence of lateral movement, because these are all data points both final reports demand.

Evidence preservation is equally critical. Automate the retention of original .eml files, mail server logs, authentication logs, and endpoint detection records for at least the one-month reporting window, since DORA's root-cause analysis requirements demand forensic-level detail.

Speed of containment determines how much of that evidence matters. According to the CrowdStrike 2026 Global Threat Report, the average adversary breakout time, meaning the window between initial access and lateral movement, dropped to 29 minutes, with the fastest measured at just 27 seconds.

Finally, establish a cross-notification trigger protocol. When a BEC incident at a bank qualifies as both a NIS2 significant incident and a DORA major incident, the team must execute both notification timelines in parallel: the CSIRT early warning and the financial regulator initial notification at hour 24, both intermediate reports at hour 72, and both final reports at the one-month mark. The timelines align closely enough that a single coordinated response can satisfy both, and that coordination only works when the playbook is written and tested before the phishing email lands.

Reporting deadlines measured in hours collapse when nobody escalates the message that started it. Adaptive Security rehearses the escalation path across every department.

Explore the platform

Third-Party ICT Risk Management for Email Under NIS2 and DORA

According to Verizon's 2026 Data Breach Investigations Report, third-party involvement now appears in 48% of all breaches, a 60% increase over the previous year. Both frameworks treat third-party email risk as a direct extension of the organization's own security perimeter, because when a supplier's email system is compromised, the cyberattacker inherits the trust relationship between that supplier and every client in its address book. The NIS2 and DORA email requirements diverge on mechanism, with NIS2 working through contractual obligations and DORA introducing direct regulatory oversight of large cloud email providers.

Supplier Due Diligence and Evaluation Under NIS2

NIS2 lists supply chain security among the ten baseline cybersecurity risk management measures that essential and important entities must implement, and the evaluation obligation begins before any contract is signed. Organizations must assess, monitor, and manage cyber risks originating from every supplier with access to their network, data, or ICT systems. Email infrastructure sits at the center of that obligation because it is the one channel almost every supplier relationship depends on.

Under ENISA's Technical Implementation Guidance (2025), entities must establish a supply chain security policy covering supplier selection criteria, formal evaluation of each supplier's cybersecurity practices, and an analysis of the resilience of ICT products and services provided. For email, that evaluation is documentary: the entity must be able to show which criteria a supplier was measured against and what evidence it produced before onboarding began.

Suppliers that cannot evidence these controls during due diligence represent a compliance liability rather than a security concern alone. Organizations that neglect to embed email security requirements into supplier evaluation face enforcement action from their national competent authority under NIS2's harmonized penalty framework.

DORA's Critical ICT Third-Party Provider Framework and Email Classification

DORA draws a hard regulatory line between ordinary ICT vendors and those designated as critical. Under Article 31(2), the three European Supervisory Authorities (EBA, ESMA, and EIOPA) designate critical ICT third-party providers by evaluating four mandatory criteria: the systemic impact of a potential large-scale failure, the systemic importance of the financial entities relying on the provider, reliance on the provider for critical or important functions, and the degree of substitutability. A provider must satisfy all four criteria to receive the critical designation.

On 18 November 2025, the ESAs published the first official list of 19 designated critical providers, capturing cloud computing providers including Microsoft Ireland Operations Limited, Google Cloud EMEA Limited, and Amazon Web Services EMEA Sarl. Cloud email platforms Microsoft 365 and Google Workspace fall squarely within the scope of these designated providers, which means their email services are now subject to direct ESA oversight instead of oversight routed only through their financial entity customers.

For critical providers, the oversight framework includes joint examination teams that conduct inspections, review incident reporting procedures, assess subcontracting arrangements, and can recommend cybersecurity measures directly. Non-critical email providers do not face this direct supervision. Financial entities must still impose DORA-compliant contractual requirements covering encryption, authentication, business continuity, and exit planning on every ICT vendor supporting a critical or important function.

Practical Third-Party Email Risk Assessment for NIS2 and DORA Compliance

Operationalizing these obligations throughout a supplier ecosystem demands a structured assessment methodology rather than an annual questionnaire. Organizations should first classify every third party by email risk exposure, separating suppliers that send email inbound, those that receive sensitive data outbound, and the cloud email platforms underpinning critical business functions. Each tier requires a different depth of assessment, and conflating them produces assessment fatigue without reducing risk.

Contractual provisions form the enforceable backbone of third-party email risk management. Every supplier contract governing email services or email-adjacent ICT services must include:

• Minimum transport encryption requirements of TLS 1.2 or higher across all message flows;
• Mandatory DMARC, SPF, and DKIM implementation with reject policies on every sending domain;
• Incident notification timelines measured in hours rather than days, aligned to the entity's own reporting cascade;
• Audit rights permitting periodic verification of email security controls;
• Chain-subcontractor transparency clauses that prevent security degradation when the supplier itself outsources email infrastructure.

For organizations in the financial sector, contracts with designated critical providers must additionally address exit strategy documentation and annual resilience testing. These obligations remain the financial entity's responsibility even when an ESA oversees the provider directly.

Ongoing monitoring closes the gap between contractual language and operational reality. Automated external scanning for DMARC and SPF configuration drift, continuous review of supplier security ratings, and periodic tabletop exercises simulating a supplier email compromise provide the evidence regulators will request during an audit.

The most mature programs integrate supplier email security posture directly into the organization's own risk reporting, treating third-party email risk as a first-party metric that sits inside the entity's own risk register. Aligning that assessment with the broader ICT risk management framework turns a supplier register into a functioning control. Controls that satisfy auditors and controls that stop actual intrusions diverge, and only structured, recurring testing surfaces the difference.

Vendor questionnaires capture what a supplier claims rather than how its employees behave under pressure. Adaptive Security extends measurable readiness throughout the extended workforce.

Take a self-guided tour

Human Error and Data Loss Prevention in Email Communications

According to Verizon's 2026 Data Breach Investigations Report, 62% of confirmed breaches involve a human element, which places employee behavior at the center of the NIS2 and DORA email requirements rather than at their periphery. For financial entities, the most common email failure modes are misaddressed messages, CC used where BCC was required, and accidental attachment of confidential files. DORA explicitly requires financial entities to deploy ICT solutions protected from risks arising from data management, including poor administration, processing-related risks, and human error.

DORA's Human Error Provisions: What Articles 9 and 11 Require

DORA is the first major EU financial-sector regulation to treat human error as a first-class ICT risk carrying its own control obligations. Article 9(3)(d) of the regulation mandates that financial entities deploy ICT solutions and processes ensuring data is protected from risks arising from data management, including poor administration, processing-related risks, and human error. This sits alongside Article 9(3)(c), which requires entities to prevent the lack of availability, the impairment of authenticity and integrity, breaches of confidentiality, and the loss of data.

The Regulatory Technical Standards build on this foundation. Article 11(2)(i) of the RTS requires financial entities to develop data and system security procedures that include the identification and implementation of security measures to prevent data loss and leakage for systems and endpoint devices.

In the email context, this covers the most common failure modes: misaddressed messages sent to the wrong domain, the use of CC where BCC is required for bulk recipient communications, and accidental exfiltration of sensitive attachments to personal or unauthorized external accounts. One misaddressed email containing non-public personal information can trigger mandatory incident reporting obligations and expose the entity to regulatory scrutiny. DORA treats human error as a foreseeable and controllable risk, and expects controls to match that classification.

Technical Controls for Human Error Prevention in Email

DORA expects financial entities to implement reasonable technical measures that catch human error before it becomes a data loss event. The regulation does not prescribe specific vendors, though it establishes what reasonable looks like in practice, and supervisory authorities assess the resulting control set against the sensitivity of the data flowing through email. Three control layers carry most of that burden.

Data loss prevention for outbound email is the first line of defense. Modern DLP engines scan outgoing messages and attachments against classification rules, blocking or quarantining emails containing patterns that match sensitive data, account numbers, personal identifiers, and internal project codes before they leave the organization. For financial entities subject to DORA, DLP rules must align with the data classification framework required under Article 6 of the RTS, applying progressively stricter controls as information sensitivity increases.

Automated warnings for external recipients form a second critical layer. When an email is addressed to a mix of internal and external recipients, or when a recipient domain does not match the expected domain for a contact name, a real-time warning prompts the sender to verify before sending. These confirmation prompts intercept the most common human error, which is autocomplete selecting the wrong contact, before it becomes irreversible.

Message revocation capabilities close the gap when a mistake slips through. The ability to recall a sent email from the recipient's inbox, particularly within the same email ecosystem, provides a last-resort control that DORA's operational resilience framework implicitly expects. Without revocation, one mis-send becomes a permanent data exposure with no remediation path short of legal escalation.

The Role of Cybersecurity Awareness Training in Reducing Email Errors

Technical controls are necessary, and on their own they fall short. DLP rules can block a credit card number in a message body, though they cannot detect when an employee emails a correct quarterly earnings summary to a journalist instead of a board member. That judgment gap, where data is unremarkable by pattern and damaging in context, closes only when a workforce is trained and measured.

DORA's operational resilience framework implies a human risk management dimension extending past technology. Article 9(2) requires financial entities to maintain high standards of availability, authenticity, integrity, and confidentiality of data, and achieving those standards over thousands of daily email interactions demands employees who recognize the stakes of every “send” action.

Technical controls operate best as a safety net beneath employee judgment, which they cannot replace. Regulators increasingly expect organizations to demonstrate that staff handling sensitive data understand the specific risks of the communication channels they use every day.

The regulatory expectation is clear: employees who handle sensitive data must receive role-specific cybersecurity awareness training. A finance team member emailing client portfolios needs different risk awareness than a developer sharing API keys, and DORA's framework expects training to be continuous and risk-proportional instead of a once-a-year compliance module.

Organizations that pair technical DLP controls with a cybersecurity awareness training program simulating authentic email-error scenarios create the layered defense both frameworks were designed to incentivize. Measuring whether that program actually changes behavior is what separates genuine risk reduction from another compliance checkbox, and it is also what produces the evidence a supervisory authority will ask to see.

Awareness modules record completion, though only behavioral data proves a control is working. Adaptive Security reports on both for every regulated role.

Book a demo

Limitations of Standard Email Platforms Under NIS2 and DORA

Organizations working toward the NIS2 and DORA email requirements quickly discover that standard email platforms were architected for productivity, with regulated communications treated as an afterthought. The fundamental mismatch is that native email encryption defaults to opportunistic TLS, a transport-layer best-effort mechanism. NIS2 Article 21 mandates cryptography and encryption as a baseline measure, and DORA demands demonstrable, auditable protection of data in transit and at rest.

Both major platforms do offer stronger encryption through add-on configurations. Those configurations require certificate management and user training that most organizations have not operationalized, which makes the gap one of implementation maturity as much as feature availability.

Microsoft 365 Compliance Gaps Under NIS2 and DORA

Microsoft 365's email encryption architecture exposes several compliance gaps when evaluated against NIS2 Article 21 and DORA's operational resilience standards. The first and most consequential is Purview Message Encryption's dependency on DANE with opportunistic TLS fallback.

When a recipient domain lacks DNSSEC, Purview silently downgrades to unauthenticated, plaintext TLS, stripping encryption without alerting the sender. For a financial institution governed by DORA, sending a transaction confirmation that downgrades to plaintext mid-delivery is a compliance failure with a documented technical cause.

Purview Message Encryption also introduces structural operational gaps. Encrypted email replies routed through Microsoft's web portal bypass the sender's standard inbox, which means they never reach CRM systems, ticketing platforms, or automated compliance archiving tools. DORA mandates continuous, auditable communication records, and a reply landing outside the organization's retention infrastructure creates a traceability gap an auditor cannot overlook.

Beyond encryption, Microsoft 365 provides no native misaddressed email prevention, no built-in recipient MFA enforcement, and no zero-access encryption. Purview Message Encryption is built on Microsoft's rights management infrastructure, which means the provider retains technical access to plaintext content on its servers.

The 25MB attachment limit pushes employees toward ungoverned file transfer tools for larger documents, and message revocation requires Advanced Message Encryption while functioning only for recipients accessing email through the web portal. Both gaps implicate the supply chain security provisions inside the NIS2 and DORA email requirements, because ungoverned transfer channels sit outside every contractual control the entity has negotiated.

Google Workspace and Other Enterprise Email Platforms

Google Workspace encrypts data at rest and in transit by default, though its native DLP capabilities introduce their own compliance gaps. Google's own documentation confirms that Google Workspace DLP for Gmail scans only the first 10MB of extracted text.

A lengthy regulatory filing or a complex financial model spreadsheet with sensitive clauses beyond that threshold passes through the engine unscanned. For DORA-governed entities handling large transaction documents, this partial scanning creates a classification gap where content beyond the threshold is invisible to automated policy enforcement.

Google Workspace DLP also lacks real-time contextual enforcement, relying on static pattern matching without behavioral analysis. It cannot analyze audio, video, or image-based attachments, and comments and metadata within collaborative documents go unscanned entirely.

Policy changes take hours to days to propagate to all assets, leaving newly classified sensitive documents exposed during the window between rule creation and enforcement. Client-side encryption addresses the zero-access concern because encryption keys remain customer-controlled, though the feature is limited to higher-tier editions and requires manual configuration per message.

Regardless of platform, compliance teams should verify three properties. Transport encryption must never silently downgrade, DLP scanning must cover the full content of every attachment, and encrypted replies must remain within the organization's auditable communication chain without manual re-routing.

What to Look for Beyond Native Platform Capabilities

When evaluating whether native platform capabilities satisfy the NIS2 and DORA email requirements, security teams should begin with a gap analysis structured around four questions. Each question maps to a distinct article obligation, and each produces a documented answer that becomes part of the compliance evidence file. Organizations that answer them informally cannot demonstrate diligence once an inspection begins.

The four questions are as follows:

• Does the encryption guarantee hold across every recipient domain, or does it silently fall back? Where opportunistic TLS fallback is possible without explicit administrator awareness, enforced TLS with DANE and DNSSEC validation must be the floor;
• Does the DLP engine scan entire files, all file types, and all collaboration surfaces, including metadata, comments, and embedded objects? Partial scanning is not defensible to a DORA auditor;
• Does the email platform prevent human error at the point of sending? Misaddressed email blocking, recipient verification prompts for external domains, and attachment size governance that routes large files through secure channels are baseline cyber hygiene controls under NIS2;
• Does every encrypted communication remain within an unbroken audit chain, including replies from external recipients? Encrypted replies that land outside the archive fragment the organization's own compliance perimeter.

Organizations that identify gaps across these four questions should evaluate supplemental email security controls that integrate without requiring MX record changes. API-based inspection layers preserve existing mail flow while adding enforcement, and the goal is to close the compliance gaps major platforms carry by design without replacing those platforms.

Tool sprawl creates its own risk. Adding disconnected point solutions for encryption, DLP, and human error prevention fragments audit data into multiple dashboards, and every additional tool becomes an additional compliance surface.

The ENISA Threat Landscape 2025 reports that supply chain risks account for 10.6% of all incidents, with adversaries actively exploiting third-party dependencies. Compliance teams should choose controls that consolidate enforcement, logging, and reporting into a single operational view, then validate through testing that encryption never degrades silently under any scenario.

Consolidated tooling still leaves the human layer unmeasured at every audit cycle. Adaptive Security supplies that missing dimension of compliance evidence.

Take a self-guided tour

How to Build a NIS2 and DORA Email Security Roadmap

Building a compliant email security posture requires organizations to classify their regulatory tier, audit existing controls against specific legal articles, implement controls in a risk-prioritized sequence, and establish continuous evidence collection for supervisory reviews. Each step must produce auditable documentation, because unwritten controls carry zero weight in a supervisory authority inspection. Classification comes first within the NIS2 and DORA email requirements, since skipping it risks building against the wrong penalty and supervision regime entirely.

Step 1: Determine the Applicable Regulatory Classification

Before touching a single email control, organizations must confirm whether they qualify as an essential entity, an important entity under NIS2, a financial entity under DORA, or fall under both frameworks simultaneously. The classification changes oversight intensity, penalty exposure, and the depth of evidence supervisory authorities will demand.

NIS2 divides regulated organizations across two annexes. An Annex I organization qualifies as an essential entity when it meets the large enterprise threshold of 250 or more employees or annual turnover exceeding €50 million, and as an important entity when it meets only the medium threshold of 50 or more employees or annual turnover exceeding €10 million. Organizations in Annex II sectors are classified as important entities when they meet the medium threshold.

DORA operates on a separate classification logic. It applies directly to more than 20 types of financial entities, including credit institutions, payment institutions, investment firms, insurance undertakings, crowdfunding platforms, and crypto-asset service providers, with no size threshold attached. An organization holding a financial services license in the EU should assume DORA applies until a mapping exercise proves otherwise.

Where both frameworks apply, the lex specialis principle described earlier means DORA's ICT risk management requirements govern. The entity may still appear on NIS2 registration lists maintained by national authorities.

Mergers, acquisitions, and restructurings can shift classification overnight. An important entity that acquires a competitor and crosses the 250-employee threshold becomes essential, and a financial entity expanding into crypto-asset services may trigger DORA obligations it did not previously face. Reassess classification after any material corporate transaction and document the rationale, because supervisors will ask for it.

Step 2: Conduct an Email Security Gap Assessment

Once classification is confirmed, audit existing email security controls against the specific obligations in NIS2 Article 21 and the DORA Regulatory Technical Standards. Article 21 mandates ten categories of cybersecurity risk-management measures, several of which map directly to email infrastructure. The assessment should produce a written finding for each mapped obligation rather than a general posture score.

On encryption, NIS2 Article 21(2)(h) requires policies and procedures regarding the use of cryptography and, where appropriate, encryption. Map the current state across three layers: encryption in transit with TLS 1.2 or higher for all SMTP connections, encryption at rest for mailboxes and archives, and encryption in use where sensitive data is processed. Under DORA, Commission Delegated Regulation (EU) 2024/1774 specifies encryption as part of the ICT risk management framework.

Authentication protocols represent the most concrete and testable email security baseline. Audit SPF, DKIM, and DMARC configurations on every owned domain and subdomain, confirm whether DMARC is set to p=reject, and verify DANE and MTA-STS deployment for transport-layer authentication. Flag any domain where SPF uses a permissive all mechanism or where DKIM keys fall below 1024 bits, because both are as good as absent in a supervisory review.

Access controls fall under Article 21(2)(i), covering human resources security, access control policies, and asset management. Confirm that MFA is enforced on all email accounts without exception, noting that SMS-only MFA is considered insufficient by NIS2 enforcement authorities. For DORA entities, the RTS further requires documented access control policies with role-based permissions and periodic access reviews.

On data loss prevention, assess whether DLP rules exist for outbound email scanning, whether they cover regulated data types including personal data, financial data, and credentials, and whether policy violations generate alerts that reach a human responder. On incident response, verify that procedures explicitly cover email-borne incidents and map to the three-phase reporting timeline of 24-hour early warning, 72-hour notification, and one-month final report.

Step 3: Prioritize Implementing Email Security Controls

Treat compliance with the NIS2 and DORA email requirements as a phased program rather than a big-bang deployment. Start with quick wins that close the largest gaps fastest, then layer in progressively more demanding controls as the evidence base matures. Each phase should conclude with a documented review rather than rolling straight into the next.

Phase 1, quick wins across 30 days: Move DMARC to p=reject on all domains, deploy SPF and DKIM on every sending domain including subdomains used by marketing, human resources, and third-party vendors, and enforce MFA on all email accounts with priority given to privileged users and executives. These three controls address the most frequently cited deficiencies in early NIS2 enforcement actions and produce immediate, demonstrable evidence of compliance activity.

Phase 2, medium-term across 90 days: Upgrade transport encryption throughout all mail infrastructure, enforcing TLS 1.2 minimum with forward secrecy. Deploy DLP rules tuned to specific regulated data types, with financial entities prioritizing rules that catch unencrypted transmission of account numbers and transaction details. Implement a data classification scheme that tags emails containing sensitive content and applies handling rules automatically.

Phase 3, longer-term across 6 to 12 months: Evaluate end-to-end encryption for high-sensitivity communications, particularly where DORA entities exchange data with critical ICT third-party service providers. Implement recipient authentication mechanisms that verify the identity of external recipients before delivering sensitive content, and deploy proof-of-delivery logging that creates a non-repudiable record of who received what and when. Consider a zero-access architecture for archived email, where even the platform operator cannot decrypt stored messages without customer-controlled keys.

Each phase must produce documentation covering configuration snapshots, policy documents, test results, and change management records. A perfectly configured DMARC record without the corresponding policy document is a gap in a NIS2 audit.

Step 4: Establish Ongoing Monitoring and Evidence Collection

Compliance is a continuous obligation with no end date, and both frameworks require ongoing monitoring. Supervisory authorities inspect the evidence produced during routine operations, which means collection cadence matters as much as control design.

For NIS2, Article 21(2)(f) requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures. In practice, this means running quarterly vulnerability scans against email infrastructure, conducting annual penetration tests that specifically target email-borne attack paths, and logging every configuration change to DMARC, SPF, DKIM, or MFA settings with a timestamp and approver name. A log that exists and cannot be produced within 48 hours of a supervisory request is effectively a missing log.

DORA adds operational resilience testing obligations. Financial entities must maintain a digital operational resilience testing program that includes vulnerability scans, network security reviews, and scenario-based tests at least annually. For entities designated for threat-led penetration testing, the testing scope must include email systems supporting critical or important functions, and every test result, remediation action, and residual risk acceptance decision must be documented.

Documentation expectations are high. The ECSO NIS2 Directive Transposition Tracker reports that 23 of 27 EU Member States have transposed NIS2 into national law, and supervisory authorities in those jurisdictions are actively requesting evidence of compliance.

At minimum, entities should expect to produce a current email security policy signed by management, an encryption and key management policy, MFA deployment records with exception justifications, DMARC, DKIM, and SPF configuration evidence, incident response test results, and a risk register mapping email-specific cyber threats to mitigating controls. Build evidence collection around the principle that anything not written down and timestamped does not exist.

Evidence collected only when an inspection is announced reads exactly as it was assembled. Adaptive Security generates continuous compliance records from live employee activity.

Explore the platform

Penalties, Enforcement, and the Cost of Non-Compliance

Organizations that fail to meet the NIS2 and DORA email requirements face seven-figure administrative fines calculated as a percentage of global annual turnover, personal management liability including temporary bans from holding director positions, and mandatory public disclosure of compliance violations. The NIS2 Directive mandates that member states impose the two-tier fine ceilings described in the classification section above, applied to worldwide turnover. Under DORA, financial institutions risk penalties of up to 2% of total annual worldwide turnover, while critical ICT third-party providers face periodic penalty payments accumulating daily for up to six months.

The NIS2 Penalty Framework

The NIS2 Directive establishes a two-tier penalty structure distinguishing essential from important entities. For essential entities, covering organizations in energy, transport, finance, health, water, digital infrastructure, and public administration, member states must impose administrative fines of at least €10 million or 2% of total worldwide annual turnover, whichever is higher. Important entities face fines capped at €7 million or 1.4% of global annual revenue, covering sectors such as food production, chemicals, postal services, waste management, and manufacturing.

Financial penalties are only one dimension of enforcement. National supervisory authorities hold broad powers including issuing binding instructions, ordering security audits, and temporarily suspending certifications that entities rely on to operate. For essential entities, repeated violations can result in a temporary ban preventing named individuals from holding management positions.

Management personal liability represents the sharpest departure from previous EU cybersecurity regulation. NIS2 explicitly authorizes member states to hold senior management personally liable for gross negligence following a cyber incident, extending to public statements identifying the individuals responsible, mandatory disclosure of compliance failures to affected customers, and criminal sanctions under national law in the most severe cases.

That liability shift is already visible in governance data. According to the World Economic Forum's 2026 Global Cybersecurity Outlook, 30% of board members in high-resilience organizations hold personal liability for cyber breaches, compared with only 9% in low-resilience organizations. Email security failures have become a board-level accountability issue that has outgrown the IT department.

The DORA Penalty Framework

DORA layers additional consequences on financial institutions and their critical ICT third-party providers. Financial entities face administrative fines of up to 2% of total annual worldwide turnover for the most serious violations, including failure to implement an ICT risk management framework and failure to report major incidents. Individual senior managers can face personal fines of up to €1 million, with criminal sanctions possible in severe cases depending on the member state.

For critical ICT third-party providers designated under DORA, the European Supervisory Authorities hold direct oversight and enforcement powers. The lead overseer can impose periodic penalty payments of up to 1% of the provider's average daily worldwide turnover for each day of non-compliance, accumulating for up to six consecutive months.

That mechanism is designed to make protracted non-compliance financially unsustainable, because for a large cloud or SaaS provider, daily penalties turn every day of delay into a balance-sheet event. DORA enforcement also includes non-financial measures that can be more damaging than fines, including unannounced on-site inspections, public warnings naming the non-compliant entity, mandated corrective action plans with fixed deadlines, and suspension or restriction of the entity's authorization to operate.

Beyond Fines: The Business Cost of Email Security Non-Compliance

Fines make headlines, though the downstream business consequences of failing the NIS2 and DORA email requirements often exceed the penalties themselves. Both frameworks empower regulators to require public disclosure of violations, which makes a compliance failure visible to customers, partners, and competitors simultaneously. For organizations that rely on supplier security assessments to win and retain contracts, a public enforcement action can disqualify them from procurement processes overnight.

Cyber insurance carriers have taken note. Underwriters increasingly require evidence of regulatory compliance as a condition of coverage, and a documented enforcement action can trigger premium increases or outright denial of renewal. Organizations that integrate compliance-mapped cybersecurity awareness training into their email security programs create a documented audit trail satisfying both regulatory examiners and insurance underwriters.

The operational cost of remediation after an enforcement action dwarfs the cost of proactive compliance. Once a supervisory authority issues binding instructions, the organization must fund a mandated remediation program on the regulator's timeline, often requiring external consultants, forensic audits, and accelerated technology deployments while absorbing reputational damage, lost business, and management distraction.

The economics are straightforward, because building aligned email security controls before enforcement arrives costs a fraction of what fixing them under a consent order will. As regulatory scrutiny intensifies across the EU, the window for voluntary compliance narrows with each passing quarter.

Personal liability moves compliance failure from a budget line to a career consequence for named executives. Adaptive Security gives boards defensible proof of workforce readiness.

Take a self-guided tour

How Cybersecurity Awareness Training Supports Email Compliance

Both frameworks name cybersecurity awareness training as a mandatory risk-management measure because email is the primary cyberattack vector against which technical defenses alone cannot provide sufficient protection. NIS2 Article 21(2)(g) requires basic cyber hygiene practices and cybersecurity training as one of ten minimum measures, while DORA Article 13(6) mandates ICT security awareness programmes and digital operational resilience training as compulsory modules for all employees and senior management. The legislative logic is direct: an organization that deploys advanced email filtering and never trains its people to recognize a well-crafted spear phishing message has not managed its ICT risk.

The Regulatory Basis for Cybersecurity Awareness Training

NIS2 Article 21 embeds cybersecurity awareness training within an all-hazards risk-management framework applying to essential and important entities across 18 sectors. The text does not present training as a best practice. It lists training alongside incident handling, supply chain security, and cryptography as a non-negotiable control.

The directive also makes training a governance obligation under Article 20, which holds management body members personally liable for approving and overseeing cybersecurity risk-management measures, including the training program itself. That places program design inside the same accountability structure as capital adequacy or financial reporting.

DORA reinforces this expectation for the financial sector. Article 5(4) requires management body members to keep up to date with sufficient knowledge and skills to understand and assess ICT risk through regular, specific training, while Article 13(6) extends that obligation to every employee with complexity calibrated to each individual's function.

The regulation pulls ICT third-party service providers into scope as well, requiring financial entities to include them in relevant training schemes under Article 30(2)(i). Neither instrument treats the human layer as optional, because email-borne cyber threats succeed when people misjudge urgency, authority, or authenticity, and technical controls stop only the messages they can classify.

A parallel gap is now opening around AI tooling. According to the National Cybersecurity Alliance's 2025–2026 Oh Behave! The Annual Cybersecurity Attitudes and Behaviors Report, 58% of employed participants reported receiving no training on the security or privacy risks of AI tools. That gap persists even as 65% now use AI at work and 43% admit to sharing sensitive work information with those tools.

How Cybersecurity Awareness Training Reduces Email Compliance Failures

The behavioral data that cybersecurity awareness training programs generate solves a critical compliance problem, which is demonstrating due diligence to supervisory authorities. A national competent authority does not simply ask whether training exists. It samples records showing who completed which module, when, and how that module maps to a specific Article 21(2) measure.

Phishing simulation data adds a deeper evidentiary layer. When an organization can show that phishing susceptibility trended downward quarter over quarter over twelve months of continuous training, it is proving the program worked, which carries far more weight than arguing that it tried. Business email compromise simulation results, misaddressed email incident logs, and reporting-rate metrics create the audit trail that transforms training from a compliance checkbox into a documented risk control.

Training that drills the incident reporting reflex also supports the aggressive notification timelines both regulations impose. Employees who have rehearsed the escalation path in scenario-based exercises recognize a significant incident and start the notification chain immediately, which a completion certificate alone does not produce.

The volume of inbound pretexts explains why that reflex matters. According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, phishing and spoofing generated 191,561 complaints, the highest number of reports in any category.

Connecting Training to Broader ICT Risk Management

Email security controls and cybersecurity awareness training form a single defense-in-depth posture rather than separate workstreams. The email gateway blocks known-malicious payloads, the trained employee reports the well-crafted BEC attempt that bypassed the gateway, and both layers generate data feeding the ICT risk management framework both regulations require.

Continuous, role-specific training produces the human risk scoring and phishing simulation results that make compliance reporting auditable. A finance team member who fails three consecutive BEC simulations represents a measurable risk gap a competent authority can evaluate, and a procurement team whose phishing susceptibility drops quarter over quarter demonstrates proportional risk management in action.

This data, integrated with email security incident logs, creates the governance evidence NIS2 Article 21(f) demands, covering policies and procedures that assess the effectiveness of cybersecurity risk-management measures. DORA Article 6(5) requires the ICT risk management framework to be reviewed at least once a year or after major incidents, and NIS2 imposes equivalent obligations.

Organizations that present training data trends alongside email security metrics demonstrate continuous improvement, moving beyond static compliance. Early inspection cycles have concentrated on exactly that trajectory.

Regulators no longer accept a completion certificate as proof that a workforce is prepared. Adaptive Security demonstrates competence through measured behavior at every reporting cycle.

Book a demo

Meeting NIS2 and DORA Email Requirements With Adaptive Security

Regulated entities do not get credit for controls they cannot evidence. The outcome supervisory authorities reward is a documented, trending reduction in email-borne risk across the workforce, supported by records that connect each activity to a named article obligation. Adaptive Security is built to produce that outcome, generating audit-ready evidence from live employee behavior rather than from completion logs that prove attendance and nothing else.

The mechanism is a cybersecurity awareness training platform that combines AI-generated phishing simulations spanning email, voice, and SMS with role-specific training calibrated to the risk each function carries. Compliance Training maps every module to the specific obligations inside the NIS2 and DORA email requirements, so evidence assembles continuously rather than being reconstructed under inspection pressure. Phish Triage turns employee reports into measurable reporting-rate data that satisfies incident response testing obligations under both frameworks.

Two newer capabilities extend that coverage into the gaps native platforms leave open. Cloud Email Security inspects inbound and outbound mail flow through an API-based layer that preserves existing routing, addressing the encryption downgrade and partial DLP scanning gaps documented earlier. AI Governance gives compliance teams visibility into how employees use generative AI tools with regulated data, closing an exposure that neither NIS2 nor DORA anticipated and both now capture through their data management provisions.

Supervisory authorities assess whether the workforce demonstrably improved, and most programs cannot answer that question. Adaptive Security answers it with continuous behavioral evidence.

Book a demo

Frequently Asked Questions About NIS2 and DORA Email Requirements

What Is the Difference Between NIS2 and DORA for Email Security?

NIS2 (Directive EU 2022/2555) is a horizontal cybersecurity directive covering essential and important entities across energy, transport, health, and digital infrastructure. DORA (Regulation EU 2022/2554) applies exclusively to financial entities. For email, NIS2 Article 21 requires state-of-the-art risk-management measures including encryption and authentication while leaving technical specifics to implementing acts. DORA is far more prescriptive: its Regulatory Technical Standards mandate encryption in transit, at rest, and in use, data classification by sensitivity, recipient authentication, and cryptographic key management under Articles 6 and 7. DORA operates as lex specialis, so its detailed provisions override the broader NIS2 baseline for financial sector entities, and organizations under both frameworks must meet DORA's higher bar.

Does NIS2 Require DMARC for Email Authentication?

NIS2 never names DMARC, DKIM, or SPF anywhere in its text. Article 21 nevertheless requires entities to implement state-of-the-art cybersecurity measures including cyber hygiene and supply chain security. The NIS2 Implementing Act references internationally agreed and interoperable modern email communications standards, which regulators interpret to include DMARC, DKIM, and SPF. Organizations cannot demonstrate compliance with Article 21's email authentication obligations without deploying these protocols, and ENISA has reinforced this expectation in its implementation guidance. Multiple EU member states including Czechia, Denmark, and the Netherlands already mandate DMARC for public bodies and critical infrastructure, establishing a clear enforcement precedent. DMARC at p=reject is the expected baseline.

What Are the Penalties for Failing the NIS2 and DORA Email Requirements?

Under Article 34 of the NIS2 Directive, essential entities face administrative fines of up to €10 million or 2% of total worldwide annual turnover, whichever is higher, while important entities face fines of up to €7 million or 1.4% of global annual turnover. These penalties apply to all cybersecurity risk-management failures under Article 21, including email encryption, authentication, and incident response. Beyond fines, supervisory authorities can issue binding instructions, suspend certifications, and impose temporary bans on management. The directive introduces management personal liability, meaning executives can be held directly accountable for compliance failures. Email security failures that result in a personal data breach can trigger simultaneous GDPR penalties.

Is Microsoft 365 Compliant With DORA Email Requirements Out of the Box?

No. The default email security configuration does not satisfy DORA's prescriptive requirements. The platform relies on opportunistic TLS by default, which silently downgrades to plaintext transmission when the receiving server does not support encryption, falling short of DORA's mandate for guaranteed encryption in transit. Purview Message Encryption lacks DANE enforcement and does not ensure TLS across the full delivery path. Additional gaps include no built-in misaddressed email prevention, no recipient multi-factor authentication enforcement, no message revocation after delivery, and no zero-access encryption architecture. Microsoft offers a DORA contractual addendum for financial services customers, though this addresses contractual obligations without delivering technical compliance, so financial entities must layer supplementary controls on top of the baseline.

How Do DORA's Email Encryption Requirements Differ From GDPR?

DORA mandates encryption as a compulsory operational resilience control for financial entities, while GDPR treats encryption as a recommended safeguard for personal data. Under DORA's Regulatory Technical Standards, financial entities must implement encryption in transit, at rest, and in use, maintain cryptographic key management policies, classify email data by sensitivity, and verify recipient identity before delivering sensitive content. GDPR requires appropriate technical and organisational measures to protect personal data and cites encryption as an example without ever mandating it. DORA's framework is system-resilience driven, protecting ICT infrastructure continuity regardless of data type, whereas GDPR is data-rights driven, protecting individuals' personal data regardless of the system. Meeting either standard demands more than correctly configured technical controls, because the human factor in email communications remains a compliance variable encryption alone cannot address.

Encryption, authentication, and classification controls all assume the sender made the right decision first. Adaptive Security strengthens the judgment every other email control depends on.

Take a self-guided tour