Swiss Cyber Incident Reporting in 2026: The Regulatory Landscape Every Security Team Needs to Understand

Part 1 of 3 - This post covers the regulatory framework: FINMA, the ISG/ISA mandatory reporting regime, the Swiss FADP, and why NIS2 and DORA are relevant even for Switzerland-headquartered organisations.

Three things have shifted significantly enough in the past twelve months to make a full update worthwhile. The mandatory cyberattack reporting regime under the ISG/ISA is now fully operational, with sanctions enforceable since 1 October 2025. FINMA's guidance on cyber risk has become more prescriptive. And EU requirements - NIS2 and DORA - are no longer abstract for Swiss groups with an EU footprint; they are live obligations being actively enforced.

The core insight running through all of this: incident response is not just a technical process. In Switzerland in 2026, it is a compliance process with real timelines, real reporting obligations, and real personal liability for the executives involved.

Switzerland: Three Overlapping Regimes

FINMA - Supervised Institutions

For banks and most FINMA-supervised institutions, the anchoring documents are FINMA Circular 2023/1 (Operational risks and resilience - banks) and Guidance 03/2024 on cyber risks. Together they cover three interrelated areas: systematic cyber risk management (including timely logging and detection), rapid response and recovery, and incident reporting without delay when ICT or cyber events become materially relevant for supervision.

Two operational details from FINMA's guidance that tend to be underappreciated:

The clock starts earlier than most institutions expect. For outsourced functions, the 24h/72h reporting cadence begins at provider awareness - not when the bank is informed. A supervised institution that waits for its supplier to brief it before notifying FINMA is already late.

Outsourcing does not transfer accountability. FINMA is explicit: a supervised institution is responsible for outsourced functions "as if" they were internal - including when the incident originates entirely with the provider. This has direct implications for how contracts with critical third parties should be structured, and what evidence the institution must be able to produce.

ISG/ISA + VISG/OVIA - Critical Infrastructure Operators

Switzerland introduced mandatory cyberattack reporting for critical infrastructure operators through the revised Federal Act on Information Security in the Federal Administration (ISG/ISA) and the implementing Ordinance on Reporting Obligations for Cyberattacks (VISG/OVIA). The model is straightforward:

• Initial report to the NCSC within 24 hours of discovery

• Completion within 14 days

• Sanctions enforceable from 1 October 2025

The obligation covers qualifying cyberattacks - disruption of critical functions, data manipulation or leakage, blackmail or coercion - not every IT incident. The distinction matters for playbook design: teams need a classification step that maps incidents to the qualifying criteria before the 24-hour window closes.

One feature of this regime worth building into escalation paths: a report submitted to the NCSC can be forwarded to FINMA or the FDPIC. A late or absent NCSC report does not contain the regulatory risk - it may simultaneously open scrutiny from other authorities.

Swiss FADP - Data Controllers and Processors

The revised Federal Act on Data Protection (nDSG/FADP), in force since 1 September 2023, introduced a formal notification obligation for data breaches under Article 24:

• Controllers must notify the FDPIC "as soon as possible" where a breach is likely to result in high risk to affected persons

• Processors must notify the controller of any breach, without a risk threshold

The FDPIC's 2025 guidance makes one point explicit that incident teams frequently miss: do not wait for a lengthy investigation to conclude before notifying if a likely high risk must be assumed. Ransomware is one of the scenarios the FDPIC specifically discusses. Waiting is itself the compliance failure - and it creates a documented record of that failure.

The practical implication for SOC teams: the high-risk determination needs to be made during the incident, not after forensics closes. Data classification - knowing what categories of data were exposed and in what volume - is what makes that determination credible and defensible.

The EU Dimension: Why Swiss Teams Cannot Ignore NIS2 and DORA

Switzerland is not subject to NIS2 or DORA as a matter of national law. In practice, many Swiss-headquartered groups are living both regulatory worlds simultaneously - through EU subsidiaries, regulated activities in EU member states, cross-border service delivery, or group governance that standardises policies globally.

The operational demands of both regimes are largely the same, and treating them as separate compliance projects creates unnecessary duplication. Both follow the same workflow: classify the incident → early notification without a complete picture → 72-hour update → final report with root cause analysis.

	NIS2	DORA
Early notification	24 hours (early warning)	4 hours after classification, or 24 hours after detection
Intermediate report	72 hours	72 hours
Final report	1 month	1 month
Scope	EU essential and important entities	EU financial entities and ICT third-party providers

DORA's classification-triggered timeline is the tighter one at the front end. For entities subject to DORA's threat-led penetration testing (TLPT) requirements, the framework mirrors TIBER-EU and defines scope, methodology, and supervisory cooperation mechanisms. Advanced testing under DORA is a formal supervisory expectation, not a voluntary exercise.

What This Means for How Teams Operate

The regulatory picture reinforces a single design principle: collect evidence well once, and the rest follows.

FINMA, the NCSC, the FDPIC, and EU supervisors all want different things at different times - but the underlying evidence is the same. An incident team that has a clear narrative of what happened, what data was involved, what was contained, and when each decision was made can feed all of these reporting tracks from a single source of truth.

The alternative - reconstructing the timeline after the fact for each regulator separately - is both operationally painful and legally fragile. Evidence is not just operational hygiene; it is the organisation's legal protection when a regulator asks "who decided not to notify, and when?".

Many organisations still treat incident reporting as a compliance afterthought. In regulated environments, this is backwards: the reporting model should drive the incident response architecture.

Next in this series: Part 2 covers what happens in practice when an organisation fails to report - or reports late, or reports incompletely - across each of the five regimes, including the personal liability dimension that makes this a boardroom question, not just a compliance one.

Sources: FINMA Circular 2023/1; FINMA Guidance 03/2024; ISG/ISA + VISG/OVIA; nDSG/FADP Art. 24 and Art. 60; FDPIC breach reporting guidance 2025; NIS2 (EU Directive 2022/2555); DORA (EU Regulation 2022/2554); EBA joint technical standards on major incident reporting.

Riccardo Resta

Security Engineer LinkedIn