The day your company is hit, one question comes up very quickly, often before the technical situation has even stabilised: do we need to tell someone, and within what deadline?
The Swiss answer is less frightening than what you usually hear, but it is also more nuanced. This article covers the obligations that actually exist, the ones that don’t, and the ones that appear in no law at all but in your contracts.
Do you really have 72 hours to report?
This is the most widespread mistake on the subject, and it circulates even in professional materials. No, you do not have 72 hours to report a data breach in Switzerland.
The 72-hour deadline is a rule of the GDPR, the European data protection regulation. The Swiss Federal Act on Data Protection (FADP) uses a different formula: the report must be made “without delay.” No number of hours, no number of days.
The absence of a fixed deadline does not give you three weeks. It means the reasonable time depends on the circumstances: the severity, the nature of the data, the speed at which you can establish the facts. An unjustified delay would count against you. The practical rule is simple: report as soon as you have the minimum necessary facts, then complete the picture afterwards.
An important caveat: if you process data belonging to people located in the European Union, for instance because you have clients or employees there, the GDPR can apply in parallel with Swiss law. In that case, the 72 hours become relevant again. Our article GDPR or FADP, which applies details this interaction.
When must you report to the FDPIC?
Article 24(1) FADP sets a single condition. The controller reports to the Federal Data Protection and Information Commissioner (FDPIC) any data security breach that is likely to result in a high risk to the personality or fundamental rights of the persons concerned.
No high risk, no mandatory report. This is a markedly higher threshold than under the GDPR, which requires reporting unless the risk is unlikely. In practice, many incidents that would be reportable in Europe are not in Switzerland.
The content of the report is also set by law. Article 24(2) FADP requires at least three elements: the nature of the breach, its consequences, and the measures taken or planned. Nothing more is required. If some elements are still missing, say so and complete them later. The report is filed online on the FDPIC portal.
Many business owners hesitate for fear that their report will be used against them. Article 24(6) FADP directly addresses this concern: the report cannot be used in criminal proceedings against the person required to report, without their consent. The legislator wanted to prevent the fear of self-incrimination from stopping companies from reporting. This protection does not, however, cover the civil consequences of the incident, nor your contractual commitments.
The real obstacle: qualifying the incident
This is the point that legal guides generally leave out. To decide whether there is a “high risk,” you need to know precisely which data was affected, by whom, for how long, and whether it was copied or merely accessed.
Yet that is exactly what an SME does not know at the moment it has to decide. Three days after the attack, the question is not “is the risk high,” but “what actually got out.” Without retained access logs, without an inventory of what was on the affected server, without the ability to distinguish access from extraction, the honest answer is: we don’t know.
This qualification work is a skill, not a checkbox. It calls for technical analysis (what the traces show), knowledge of the data (a billing file and a health record do not carry the same weight), and legal judgment. This is also why it pays to prepare the ground before the incident: knowing where your sensitive data sits and keeping usable logs completely changes the quality of the decision you will make on the day.
Do I have to report, to whom, and within what deadline?
The table below summarises the most common situations. It gives a general orientation and does not replace the advice of a lawyer on your specific case.
| Situation | Report required? | To whom | Deadline |
|---|---|---|---|
| Personal data exposed, high risk likely | Yes | FDPIC, via the online portal | Without delay, no fixed deadline |
| Personal data exposed, low or no risk | Generally no | No one, but document the decision | Not applicable |
| You are a processor for a client | Yes, always | Your principal | Quickly, so they can act |
| People need to protect themselves (password, bank account) | Yes | The persons concerned | As soon as possible, usefulness comes first |
| Client contract requiring notification | Yes | Your client | As set by the contract, often 24 to 48 hours |
| You operate critical infrastructure | Yes | NCSC, in addition to the rest | As set by the applicable regulation |
Processor, data subjects: two separate cases
If you are a processor, the rule changes completely. Article 24(3) FADP requires you to report any breach to your principal, with no risk threshold. A web agency hosting a company’s customer database, a fiduciary handling payroll, an IT provider managing a server: all must escalate the incident, even a minor one, to the party on whose behalf they work. It is that party who will then decide whether a report to the FDPIC is warranted.
Informing the persons concerned is a separate obligation, triggered in different circumstances. You must inform your clients, employees or suppliers when it is necessary for their protection, for instance so they can change a password reused elsewhere or monitor an account, or when the FDPIC requires it. You can therefore have to report without informing, or inform without reporting.
Your contracts are often stricter than the law
This is the point most often overlooked, and yet the most demanding in practice.
Many client contracts, particularly with large accounts, international groups or European companies, contain an incident notification clause. These clauses regularly impose deadlines much shorter than Swiss law: 24 hours, sometimes less, with a designated contact and a required format. The same clauses often appear in your cyber insurance terms, where a delayed report can affect coverage.
Take an hour, calmly, to extract the notification clauses from your main client contracts and your insurance policy: what deadline, what recipient, what channel. Write them down on a single page, accessible offline. On the day of the crisis, no one will have time to re-read twenty contracts, and that is precisely when the contractual countdown is running.
Are you required to report to the NCSC?
Since 1 April 2025, Swiss law has included a duty to report cyberattacks to the National Cyber Security Centre, backed by sanctions since 1 October 2025. It is regularly presented as applying to every company. That is not the case.
This duty targets only operators of critical infrastructure: energy, water, healthcare, transport, telecommunications, public administrations and a few other designated categories. An ordinary SME, even a sizeable one, is generally not subject to it. Our article on sector-specific obligations covers the particular cases.
You can, however, report voluntarily. The NCSC received 64,733 voluntary cyber incident reports in 2025, against 62,954 in 2024. These reports feed the national threat picture and help warn other companies. It is free, quick, and carries no consequence for you.
Do not destroy the evidence
The natural reflex after an attack is to clean up: reformat, reinstall, start fresh. Do it, but not before preserving the traces.
Connection logs, images of the affected disks, headers of fraudulent messages, and the timestamps of events are the only material that will later let you say what actually happened. These elements are used to qualify the incident, to respond to a client, to justify a decision not to report, to support a claim with your insurer, and where applicable to file a criminal complaint.
Isolate the machines from the network rather than switching them off abruptly when possible, and bring in someone who knows how to collect evidence before rebuilding. The practical steps for the first hours are detailed in the first hours after an attack.
What this article does not replace
The rules described here apply as a general matter. Your situation may fall outside them: regulated activity, health data, European clients, an international group, cascading subcontracting. In these cases, the analysis deserves dedicated legal advice, and it always costs less before the incident than after.
Above all, remember that the difficulty is almost never knowing the rule. It is knowing, on the day, what was actually affected. That is technical work, and it is prepared in advance: mapping your data, keeping usable logs, knowing who to call. The cyber check-up gives you a first benchmark on this point, and the other crisis reflexes are gathered in the Responding to an attack pillar. The reporting procedure itself is detailed step by step in our article on reporting a breach to the FDPIC.