Email compliance in Germany, Austria and Switzerland: laws, technical measures and reliable evidence

Email security starts with how you actually operate

Sources as at 27 September 2026. First identify which domains actually send or receive mail, which systems and service providers are involved and what data passes through them. An invoicing platform, a newsletter service and individual mailboxes may have different sending paths and risks.

Then identify the applicable obligations: do they concern the security of a legally covered service, personal data protection, a financial business or a contractual requirement? Documentation should make actual implementation traceable. A neatly filled evidence file does not replace an effective measure.

Legal dates: distinguish entry into force, application and subsequent deadlines

Primary sources: Swiss FADP, DORA, Article 64, ISA and commencement notes for Articles 74a–h, German implementation act, Article 30, section 33 BSIG, NISG 2026, section 51.

NIS2: keep Germany and Austria separate

For the international context, see the NIS2 EU introduction and country guidance with official sources. This email guide continues to focus on the explicitly named legal contexts.

Germany

Section 28 BSIG and Annexes 1–2 combine specific entity types with size criteria and special rules. An arbitrary company with 50 employees is not automatically covered. For general classification as an important entity, the relevant activity must be accompanied by at least 50 employees, or by both annual turnover exceeding EUR 10 million and an annual balance sheet total exceeding EUR 10 million. Linked enterprises may need to be counted. Certain providers, such as providers of DNS services to third parties, are subject to rules regardless of size. Owning a domain is not enough. Section 28, section 2 no. 8 BSIG.

Registration under section 33(1) is generally required no later than three months after first or renewed coverage, including for the domain name registration service providers named there. This particularly means registrars and corresponding registration services, not every domain owner. Section 34 additionally applies to certain digital providers. Operators of critical installations must observe the additional information requirements and transitional provisions of section 66; the transition to the new Critical Infrastructure Ordinance does not remove existing obligations. Sections 33, 34 and 66 BSIG.

Section 30 requires risk management in ten areas. An email configuration may contribute, for example, to secure communication, cryptography or vulnerability handling. The statutory obligation extends beyond DNS and transport. Special rules for certain energy, telecommunications, financial and telematics entities under section 28(5)–(7), and overriding requirements of Implementing Regulation (EU) 2024/2690, must be assessed separately. NIS2 checklist.

For significant incidents, section 32 generally requires an early initial notification within no more than 24 hours and a subsequent notification within no more than 72 hours, each without undue delay and running from awareness of the same significant incident. Failure to register does not postpone an existing reporting obligation. Trust service providers also have separate eIDAS notifications within 24 hours; these do not apply to every email or certificate user. The NIS2 incident reporting guide explains the criteria, recipients, further reports and these special rules.

Austria

The NISG 2026, Federal Law Gazette I no. 94/2025, was promulgated on 23 December 2025. Under section 51, its main substantive obligations apply from 1 October 2026; sections 1–31 of the NISG 2018 cease to apply at the same time. Matters up to and including 30 September 2026 are generally assessed under the NISG 2018 as applicable until then. Preparatory provisions have applied since 24 December 2025. Specific transitions must be observed, such as those for the existing national CSIRT under section 51(6) and previously qualified bodies under section 51(7). Promulgation, NISG 2026, section 51.

Section 29(3) requires entities already covered when the act enters into force on 1 October 2026 to register within three months of that date; Austria’s Federal Office for Cybersecurity (BCS) states 1 January 2027 in principle and, under section 33(2) AVG, 4 January 2027 at the latest. Entities covered later must register as soon as possible, and no later than three months after meeting the criteria. Section 34 requires reports to the competent sector-specific CSIRT or, if none is available, the national CSIRT, which forwards them to the cybersecurity authority. A German portal address or description of deadlines is therefore not a complete Austrian reporting plan.

In a specific case, the law applicable at the event date, actual services and national exemptions are decisive. For example, the education rule in section 24(6) NISG 2026 expressly excludes trust service providers; the sector matrix below explains this limit.

GDPR: risk, accountability and personal data breaches

Article 32 GDPR requires controllers and processors to implement appropriate technical and organisational measures. It takes account of the state of the art, costs, the nature and scope of processing, and risks to individuals. Confidentiality, integrity, availability, recovery and regular testing of effectiveness are relevant security objectives. The provision does not specify a fixed list of email protocols. GDPR, Article 32.

Articles 5(2) and 24 require accountability and demonstrable implementation. Secure transmission does not establish a legal basis, an erasure policy, a data processing agreement or the conditions for a third-country transfer. A service provider’s European location does not, by itself, prove full GDPR compliance either. These questions require separate assessment, particularly under Articles 6, where applicable 9, 28 and 44 onwards.

Not every phishing email is a notifiable personal data breach

An unsuccessful phishing attempt is not yet a personal data breach. If unauthorised persons gain access to a mailbox containing personal data, however, the actual access, data, possible consequences and risks must be assessed. You need not first establish complete certainty about every message read.

Under Article 33, the controller must notify the competent data protection authority of a relevant breach without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to pose a risk to rights and freedoms. A processor must inform the controller without undue delay; this does not give the processor a general 72-hour waiting period of its own. Breaches and their assessment must be documented under Article 33(5). Where a high risk is likely, Article 34 generally also requires informing affected individuals without undue delay, subject to its exemptions. A notification to the BSI does not automatically replace this. GDPR, Article 4(12) and Articles 33–34.

Switzerland: the FADP and ISA have their own thresholds and recipients

Under Article 2, Switzerland’s Federal Act on Data Protection (FADP, German abbreviation DSG) applies to the personal data processing it covers by private persons and federal bodies. Article 3 covers circumstances that have effects in Switzerland. Cantonal public bodies’ own data protection law must be considered separately. Article 7 governs data protection by design and by default; Article 8 requires appropriate data security. Swiss FADP, Articles 2–3 and 7–8.

Article 24 FADP requires the controller to notify the Federal Data Protection and Information Commissioner (FDPIC, EDÖB in German) as soon as possible if a data security breach is likely to result in a high risk to personality or fundamental rights. The provision contains no general 72-hour deadline. Processors must inform the controller as soon as possible. Affected individuals must be informed when necessary for their protection or when required by the FDPIC, subject to the statutory exemptions. Article 24 FADP, FDPIC: Data security breaches.

Under Article 24(5bis), the FDPIC may forward the data protection notification to the National Cyber Security Centre (NCSC, BACS in German) for analysis with the controller’s consent. This is not a promise that any additional reporting obligation under the Information Security Act has been fulfilled on time. Check and document its fulfilment separately. FADP, Article 24(5bis).

Separately, the Information Security Act (ISA, German abbreviation ISG) requires certain cyberattacks to be reported to the NCSC within 24 hours of discovery. This requires a covered authority or organisation under Article 74b, taking account of the exemptions in Article 74c and the Cybersecurity Ordinance, and an attack meeting Article 74d. Examples include threats to critical infrastructure’s functioning, manipulation or leakage of information, attacks that remained undetected for an extended period, or attacks involving extortion, threats or coercion. Not every small business or suspicious email falls within this scope. ISA, Articles 74a–f, NCSC: Who has to report?.

Switzerland does not implement NIS2 as an EU Member State. EU customers may create contractual security requirements, but do not automatically trigger every EU obligation. The GDPR needs a connecting factor under Articles 2–3. For certain digital services without an EU establishment, Article 26 NIS2 provides rules on representatives and jurisdiction; the service and territorial scope must still be assessed specifically. Article 26 NIS2.

BSI guidelines: distinguish transport from authentication

TR-03108, version 2.0 of 1 June 2023, addresses secure email transport for email service providers. TR-03182, version 1.0 of 24 January 2024, addresses email authentication, particularly the interaction of SPF, DKIM and DMARC. Transport protects a transmission path; authentication gives receivers information on authorisation and attribution of sender domains. These are different tasks. TR-03108, TR-03182.

Publishing a technical guideline does not make it law for every domain. Its binding effect and assessment scope arise from the relevant context, such as a specific certification procedure, contract or statutory reference. A DNS finding cannot establish compliance with the entire guideline; internal processing, key management and operational processes require additional assessment.

DORA: deadlines run from different events than under the BSIG

DORA has applied since 17 January 2025 to financial entities covered by Article 2, subject to its exemptions. Article 9 governs protection and prevention; Articles 17–19 address ICT-related incidents. Not every phishing email is a major reportable incident. Classification follows DORA’s specific criteria. The competent recipient is the financial supervisory authority designated under DORA; there is no universal reporting route through Germany’s BSI portal. DORA, Articles 2, 9, 17–19, 46 and 64.

Article 5 of Delegated Regulation (EU) 2025/301 specifies the deadlines:

Unlike section 32 BSIG, the 72-hour period here therefore runs from the first submission. Where timely submission is impossible, Article 5(3) requires the authority to be informed within the deadline, with reasons. Paragraphs 4–6 contain limited weekend and public-holiday rules with important exceptions, particularly for initial notifications and intermediate reports by certain financial entities; there is no general rule that “banks only report on Mondays”. Delegated Regulation (EU) 2025/301, Article 5.

An email service provider does not itself become a DORA financial entity merely by having a financial entity as a customer. Contractual requirements under Articles 28–30 and designation as a critical ICT third-party service provider under Article 31 are separate questions. A blanket DORA fine for missing DMARC would also be misleading: Article 50 refers to national sanction arrangements; supervisory periodic penalty payments under Article 35 concern a different situation.

ISO and PCI DSS: standards with their own purposes

ISO/IEC 27001 concerns an information security management system. A certificate within its defined scope is neither a guarantee for every message nor automatic fulfilment of NIS2. An existing ISMS can organise risks, responsibilities and effectiveness checks. Verify that all relevant email services, suppliers and operational processes are actually covered. ISO’s original overview, NIS2 and ISO 27001.

PCI DSS protects payment card data and is not a general email law. Whether email forms part of a covered payment data environment depends on actual data flows and the agreed validation procedure. A newsletter without card data and a process transmitting card data require different assessments. PCI DSS establishes neither a universal list of email protocols for every company nor compliance through a domain check. PCI SSC: PCI DSS.

Sector guidance does not replace assessing the entity

Sources: BSIG Annex 1, DORA Article 2, NISG 2026 section 24(6), NCSC on the reporting obligation.

One measure can support several security objectives

A maintained sender inventory, appropriate domain authentication and secure transmission can be useful under several applicable frameworks. The benefit comes from actual effectiveness within the relevant scope. No single technical core fully satisfies NIS2, data protection, DORA, PCI DSS and a BSI guideline.

For example, a business introduces a new invoice-sending service. Approval may combine technical sender checks, a provider assessment, data protection contract questions and an incident contact. One SPF record does not answer these different questions. Combine shared evidence where the same facts are being assessed, and document the remaining requirements for each framework.

Place technical topics within a useful chain of evidence

This mapping describes partial technical contributions. It assigns no blanket compliance percentages. For SPF, DKIM and DMARC, the standards and actual message paths are decisive; the current DMARC specification expressly leaves treatment by the receiver as a separate decision. RFC 9989, especially sections 4.4, 4.7 and 5.4, BSI TR-03182.

The transport and reporting mechanisms are described in RFC 8461, sections 1–3 and RFC 8460, sections 1 and 3. RFC 8617, sections 1–2 explains ARC; the BIMI Group confirms discretion over logo display. None of these sources certifies the operation of a specific domain that has not been measured here.

Management and sanctions: identify the specific breach

For covered German entities, section 38 requires implementation and supervision of the section 30 measures, together with regular training for management itself. Paragraph 2 concerns liability to the entity itself for culpable breach of the implementation and supervision duty; the law applicable to the entity’s legal form takes priority. This is not an automatic personal payment obligation after every phishing email.

Separately, section 65 BSIG defines administrative offences. Certain failures in measures and reporting carry maximum fines of up to EUR 10 million for particularly important entities or EUR 7 million for important entities; for undertakings with worldwide total turnover exceeding EUR 500 million, the prescribed turnover-based alternatives are up to 2% or 1.4% respectively. Registration has its own maximum of EUR 500,000. Responsibility, fault and the specific infringement must be assessed in each case. Missing DMARC alone proves none of these offences. Sections 38 and 65 BSIG, detailed management liability guide.

A work plan based on urgency and dependencies

A plan spanning several months can organise work. It creates no grace period for obligations already in force, and a rigid DNS sequence does not suit every entity. Instead, arrange the work into four connected phases:

How long the steps take and what can run in parallel depend on size, starting point and risk. Critical gaps do not wait until “month six”. A rescan checks only the repeated measurement scope and does not replace the other controls.

What the Email Security Check observes

The Wolf-Agents Email Security Check examines publicly observable domain configuration and selected SMTP properties. A result can document initial technical findings. What could actually be measured in the specific report is decisive.

A detected DKIM configuration does not confirm complete signing of every message. An inbound SMTP probe is not an outbound delivery test, account access or message reading. Missing or unmeasured values are neither automatic passes nor automatic critical infringements. The domain check is not continuous monitoring or full evidence of compliance with NIS2, the GDPR, ISO or BSI guidelines.

Save relevant results with their target and timestamp, and connect them to how the finding was addressed. Compare scores only where the measurement scope and scoring model are demonstrably comparable; the particular observation that changed matters more.

An evidence file combines technical and organisational records

A useful collection combines a reasoned assessment of the entity with measures actually implemented. Technical findings are one input alongside internal controls and operational evidence, not the sole starting point for a complete compliance assessment.

An auditor, the data protection authority, the BSI and an internal data protection officer have different tasks and powers. The file is not automatically sent to all of them; scope, recipients and protection needs follow the specific procedure. It contains only necessary information, with appropriate access rights and justified retention. This overview establishes neither a universal seven- or ten-year retention period nor a general quarterly scanning schedule.