An employee clicks a booby-trapped link, a mailbox is hijacked, a client file ends up in the wrong hands. The first question that comes up in the crisis meeting is almost always the same: do we have to report it, and within what deadline?
This article answers point by point. It complements your FADP obligations by focusing solely on the reporting procedure set out in Article 24 of the Data Protection Act.
The principle: high risk, and nothing else
Article 24 para. 1 FADP is short. The controller reports to the Federal Data Protection and Information Commissioner, as soon as possible, data security breaches that are likely to result in a high risk to the personality rights or fundamental rights of the data subjects.
Three words carry the full weight of the rule.
Data security breach covers a lot of ground: loss, destruction, unauthorised alteration, but also mere access or disclosure to people who should not have seen the data. An attachment sent to the wrong recipient is a breach, just as much as a ransomware attack.
Likely means you are reasoning on a probability, not a certainty. You do not have to wait for proof that harm has occurred.
High risk is the decisive filter, and this is where Switzerland differs markedly from Europe.
The 72-hour myth
This is the most widespread misconception on the subject, including among IT providers and advisors.
The text says "as soon as possible." It does not say 72 hours, nor 24 hours, nor 5 days. The 72 hours come from the European GDPR, which only applies to your SME if you actively target the EU market. Confusing the two regimes makes you either panic needlessly, or apply a rule that is not yours.
This absence of a countdown does not mean time does not matter. “As soon as possible” remains a serious requirement. It is assessed on a case-by-case basis: the more immediate the risk to the data subjects, the faster the report must be made. A delay of a few days spent correctly assessing the incident is easily justified. Three weeks of silence, much less so.
The practical consequence is rather favourable to SMEs. You are entitled to take the time to understand what happened before reporting, which avoids half-wrong reports sent in a rush.
The Swiss threshold is higher than under the GDPR
A second major difference, and it sharply reduces the number of incidents concerned.
The GDPR requires reporting unless the risk is unlikely. The default there is therefore to report, and the exception is to stay silent. Swiss law does the opposite: it only requires reporting if the risk is high. The default is therefore not to report, and the exception is to report.
In concrete terms, far fewer incidents must be reported in Switzerland. A lost encrypted laptop, with no possible access to the data, generally triggers no reporting obligation at all. The same device, unencrypted and containing health records, triggers it almost certainly.
This point is developed further in our comparison GDPR and FADP.
Should I report? Decision tree
This table restates the logic of Article 24 as a series of successive questions. It provides an initial orientation, not a definitive legal answer.
| Step | Question | If yes | If no |
|---|---|---|---|
| 1 | Is personal data involved (loss, access, disclosure, alteration)? | Go to step 2 | No report required under the FADP |
| 2 | Are you the controller, or a processor acting for a principal? | Processor: report to your principal, with no threshold condition (Art. 24 para. 3). Controller: go to step 3 | Clarify your role before continuing |
| 3 | Was the data protected so as to remain unusable (strong encryption, uncompromised keys)? | High risk is in principle ruled out; document your analysis | Go to step 4 |
| 4 | Is it sensitive data, financial data, login credentials, or a large number of people? | High risk likely; go to step 5 | Assess the risk case by case |
| 5 | Do the data subjects risk identity theft, fraud, reputational harm, or discrimination? | Report to the FDPIC as soon as possible | Document the decision not to report |
| 6 | Is informing the data subjects necessary for their protection, or does the FDPIC require it? | Also inform the data subjects | Report to the authority only |
Note step 6. Reporting to the FDPIC and informing the data subjects are two different obligations, which are not triggered under the same conditions. One can exist without the other.
How do you report, and what must the report contain?
The report is submitted through the FDPIC’s online portal, at databreach.edoeb.admin.ch/report. The form guides you through the expected sections. Make sure you have on hand the name of a contact person within your company, the timeline of the incident, and the list of data categories affected.
Article 24 para. 2 FADP sets out the minimum content:
- the nature of the breach, meaning what happened, when, which categories of data, and how many people are affected;
- the consequences for the data subjects, actual or probable;
- the measures taken or planned, both to fix the flaw and to limit the effects of the incident.
Nothing requires you to have a complete file before reporting. If elements are missing, say so and complete the report afterwards. A prompt, partial report serves the data subjects better than a late, exhaustive one.
Article 24 para. 6 FADP is explicit: the report cannot be used in criminal proceedings against the person required to report, without their consent. The legislator deliberately neutralised the risk of self-incrimination, so that fear of the consequences would not push companies into silence. This is the argument to bring up when someone internally suggests saying nothing "just in case."
Two reports not to be confused. The FDPIC handles the data protection aspect. The National Cyber Security Centre, for its part, receives cybersecurity incident reports, under a separate framework. The NCSC received 64,733 voluntary reports in 2025, against 62,954 in 2024. Depending on the nature of the incident and your sector, both steps may be required together.
Should you notify the data subjects?
This is the most delicate question, because it touches your client relationship.
The rule: you inform the data subjects when this is necessary for their protection, or when the FDPIC requires it.
The criterion is a practical one. Information is necessary when it allows the data subjects to act: change a password reused elsewhere, monitor a bank statement, be wary of fraudulent calls claiming to be from your company. If the data subjects cannot do anything with the information, the obligation does not automatically arise.
Good notification is short, factual, and ends with concrete actions. It states what happened, which data is affected, what you have done, and what the person should do now. It avoids jargon and defensive wording.
After an email account compromise, attackers often write to your contacts in your name. Your clients will learn about the incident one way or another. Hearing it from you, early and clearly, preserves the relationship; hearing it through a fraudulent email destroys it. The question is almost never "should we say it," but "how do we say it."
What happens after you report?
The classic worry is that an audit will automatically follow. That is generally not how it works.
The FDPIC records the report and reviews it. It may request clarification, recommend measures, require you to inform the data subjects, and, in the most serious situations, open an investigation and issue binding decisions. A report made in good faith, accompanied by credible corrective measures, is treated as what it is: a sign of seriousness.
On your side, the incident does not end with the report. You still need to document the timeline, preserve technical evidence, fix the cause, and verify that the fix holds. These steps are detailed in our guides on the first hours after an attack and on your legal obligations after an incident.
Prepare beforehand, not during
A report is best prepared in advance. Three elements are enough for an SME.
- A one-page decision sheet. Who assesses the incident, who decides to report, who drafts the report, who talks to clients. Without names written down, everyone waits for someone else to decide.
- An inventory of your sensitive data. You cannot assess a high risk if you do not know what your systems contain. This is the same inventory described in our articles on data theft and leaks.
- An incident log. Including for those you decide not to report. The written record of your reasoning is your best defence if the decision is challenged later.
Every situation has its particularities, and assessing high risk can be open to debate. For an incident involving sensitive data or a large number of people, seek support from a specialised lawyer rather than deciding alone.
To gauge your level of preparedness in three minutes, the cyber check-up gives you a score and your three priorities. Other obligations applicable to Swiss companies are grouped in the Regulations pillar.