Since 1 April 2025, Switzerland has had a statutory duty to report cyberattacks on critical infrastructure to the Federal Office for Cybersecurity (BACS). The legal basis is the Information Security Act (ISG) in its revised form; the operational details follow from the accompanying ordinance. Hospitals are among the explicitly covered operators of critical infrastructure in the healthcare sector, provided they meet the thresholds defined in the ordinance (such as bed count or significance to provision of care).

For hospital management, this is a paradigm shift: a ransomware incident that disrupts the emergency department or the clinical information system is no longer just an IT problem but a reportable event with its own deadline. This article explains what is reportable, how the clock runs, what BACS expects, how to avoid liability exposure, and how all of this differs from the EU NIS2 Directive.

Important note up front: the precise deadlines, thresholds and the catalogue of reportable incidents are set out in the ordinance and may change. Verify the detailed deadlines applicable to your hospital on a case-by-case basis. This article provides the structure, not a binding cut-off date.

Reportable is a cyberattack that jeopardises the functioning of the critical infrastructure, that has led to manipulation or exfiltration of information, or that went undetected over a longer period or is linked to extortion, threat or coercion. For a hospital these are typically: ransomware encrypting production systems, a confirmed unauthorised access to the clinical or laboratory information system, the compromise of remote access (VPN, maintenance access of medical-device suppliers), or a successful attack on the email infrastructure with data exfiltration.

The ISG/BACS report must be distinguished from two other reporting channels that may run in parallel: first, the data-protection notification to the FDPIC under Art. 24 nFADP, where the incident leads to a breach of data security of personal data and a high risk exists; second, for particularly sensitive health data, informing the affected individuals. A single ransomware incident in a hospital can therefore trigger three reporting duties, with different recipients, deadlines and thresholds. Anyone thinking only of the FDPIC overlooks the ISG/BACS report, and vice versa.

The ISG provides for a short initial reporting deadline after becoming aware of the cyberattack. The ordinance specifies the deadline (a 24-hour initial report is in discussion and implementation) and provides for a supplementary, more detailed follow-up report within a few days. What matters is the moment of becoming aware, not the moment of the attack. That shifts the critical question from technology to organisation: when exactly does the hospital "know" that a reportable incident has occurred? As soon as the on-call IT lead has a credible indication, or already when the helpdesk reports three encrypted wards?

Verify the exact deadlines for your hospital on a case-by-case basis, since they follow from the version of the ordinance in force at the relevant time. What matters in practice is this: the clock is short, and it starts before the full picture is clear. An initial report must explicitly be filed even where not all details are yet known. Anyone waiting for "complete forensics" misses the deadline. That is precisely why you need a prepared, rehearsed reporting process rather than an ad-hoc decision at three in the morning.

BACS does not want finished forensics but a structured, honest initial picture. Typically expected are: details of the reporting organisation and the contact person, the nature and time of the incident (or of becoming aware), the systems affected and the foreseeable impact on care provision, the immediate measures already taken, and whether extortion is involved. The report is filed via the reporting form or reporting platform provided by BACS. BACS uses this information to build the national situational picture and can return support and technical pointers (e.g. on known indicators).

Important for hospital management: the BACS report is not a self-incrimination and triggers no supervisory penalty for the attack itself. What is subject to sanction is the breach of the reporting duty, not the fact of having become a victim. The message to executive management and the board is therefore: reporting protects, silence exposes. BACS is a partner for the national situational picture, not a prosecuting authority. That lowers the threshold to file an initial report even when the situation is still unclear.

You should not read the following flow for the first time during the real event but play it through in a tabletop exercise. Step 1, Detection: anomaly reported (helpdesk, monitoring, external tip-off). Step 2, Triage: is there a cyberattack that jeopardises functioning, data integrity or care provision? Yes → continue. No/unclear → document, observe, re-check the threshold. Step 3, Record awareness: log the date/time of the first credible indication. This is when the deadline starts.

Step 4, Check parallel duties: (a) ISG/BACS report required? (b) nFADP notification to the FDPIC (personal data affected, high risk)? (c) Informing affected individuals? Step 5, File the BACS initial report with the known state, without waiting for complete forensics. Step 6, Internal escalation: crisis team, CISO/vCISO, legal, communications, executive management, and where necessary the board chair. Step 7, Coordinate external parties: activate the designated external incident-response provider and the cyber insurer per the prepared contact list. Step 8, BACS follow-up report within the prescribed deadline; document lessons learned. Each branch should have a named responsible person and a deputy.

The reporting duty is an organisational duty, and organisational duties end at the top governing body. The board or hospital council must ensure that a reporting organisation exists, that responsibilities and deputies are defined, that the reporting process has been rehearsed, and that the necessary external contracts (incident response, cyber insurance) are in place. This is part of the statutory duty of care and supervisory oversight. A member of the top body who tolerates an obvious gap in the crisis arrangements risks personal liability, independent of the ISG sanction against the organisation.

Concretely, we recommend the board obtain three pieces of evidence: first, an approved incident-response and reporting concept with clear deadlines and roles; second, the minutes of at least one tabletop exercise run with the reporting duty as the scenario; third, an up-to-date contact and escalation list including external IR provider, cyber insurer and the BACS reporting channel. These three documents turn an abstract duty into auditable governance evidence, and they are precisely what, in a real event, makes the difference between a timely report and a missed deadline.

Hospitals often hear "NIS2" and "24-hour reporting" in the same breath and conflate the two regimes. That is dangerous, because they have different recipients and triggers. NIS2 is an EU directive (2022/2555) that Switzerland has not transposed. It binds a Swiss hospital only where that hospital has an establishment or relevant activity in the EU, for instance a subsidiary, a place of business or material service provision in an EU member state. A hospital operating purely within Switzerland does not fall under NIS2.

For the hospital operating purely in Switzerland, the ISG/BACS reporting duty is and remains the relevant mechanism. NIS2 does also have a staggered reporting system (early initial report, follow-up report, final report), but to a national EU authority (CSIRT) of the respective member state, not to BACS. Anyone touching both worlds (a Swiss hospital group with an EU site) must meet both duties separately and may not offset one against the other. Keep the two regimes cleanly apart in your crisis manual, with a clear mapping of which site reports to which authority.

SIDD is a legally led data-protection and information-security consultancy, not a Security Operations Center. We start clearly where governance makes the difference: we design and document your reporting concept along the ISG/BACS requirements, build the decision tree, define roles and deadlines, prepare the interfaces and escalation paths to an external incident-response provider, the cyber insurer and BACS, and rehearse the whole thing with your leadership in a tabletop exercise. As a vCISO we support the ongoing reporting organisation and the annual update of the playbooks.

The boundary is drawn deliberately: the technical handling in a real event, forensics, containment, recovery, the round-the-clock live incident handling, is delivered by a specialised incident-response provider whom we engage in advance and with whom we prepare the interfaces. SIDD coordinates the preparation and the governance, but does not itself operate a SOC and does not take on managed incident response in live operation. More on our services at vCISO, ISMS / ISO 27001 and data protection advice (nFADP). To arrange a first conversation about your hospital's reporting organisation, use the contact form; for a proposal for a reporting-concept mandate, use our quote form.