# Reporting a Data Breach to the FDPIC, 5-Step Guide

> Reporting a data breach to the FDPIC in five steps: detection, assessing the high risk, notification under Art. 24 FADP and informing data subjects.

- Source: https://www.sidd.swiss/en/insights/data-breach-reporting-fdpic/
- Language: en
- Published: 2026-05-24
- Last updated: 2026-05-24
- Author: Marc Grob
- Publisher: SIDD Institute for Data Protection and Data Security, a brand of Priverion GmbH, Zugerstrasse 32, 6340 Baar (ZG), Switzerland

## Introduction

A data breach is no longer a hypothetical stress test. Since the DSG entered into force in 2023, the Federal Data Protection and Information Commissioner (FDPIC / EDÖB) has recorded more than 1,200 notifications per year, and the figure keeps rising, ransomware, mis-sent communications, compromised cloud accounts and insider incidents drive the volume. The legal duty derives from Art. 24 DSG and differs from Art. 33/34 GDPR in important respects: the threshold is likely high risk (not any risk), the deadline is as soon as possible (not a fixed 72 hours), and the recipient is the FDPIC (not a cantonal authority).

This article walks through the full workflow in five operational steps and provides:

- the trigger logic: what counts as a security breach and when it becomes high-risk;
- a tested template for internal escalation in the first 24 hours;
- the minimum contents of the FDPIC notification under Art. 24(2) DSG;
- the triggers for additional information to data subjects (Art. 24(4) DSG);
- the interplay with GDPR notifications, FINMA obligations and BACS/NCSC reporting;
- typical pitfalls that the FDPIC tends to treat as breaches of due care.

The target audience is data protection officers, CISOs, IT leads and executive boards who must keep their heads in an incident and deliver a documented, auditable process, not explain after the fact why there was none.

## What counts as a notifiable breach

Art. 24(1) DSG defines a security breach as *any breach of security that leads to personal data being lost, deleted, destroyed or modified accidentally or unlawfully, or disclosed or made accessible to unauthorised persons*. Three categories of loss are covered: confidentiality (data leak), integrity (unauthorised modification) and availability (data loss, e.g. through ransomware encryption).

A breach becomes notifiable only when it *is likely to result in a high risk to the personality or fundamental rights of the data subject*. This is a deliberately high threshold, materially higher than the GDPR standard of risk in Art. 33 GDPR. In practice you assess the risk along:

- **Data category:** Sensitive personal data (health, religious/philosophical beliefs, sexual life, biometric, genetic, criminal prosecution) raises the risk almost automatically. So do financial, access and authentication data.
- **Number of data subjects:** A thousand-person threshold is not a statutory value but a de-facto triage indicator.
- **Identifiability and linkability:** Cleartext vs. encrypted / pseudonymised.
- **Whereabouts of the data:** Published on the dark web vs. internal mis-send with confirmed deletion.
- **Likely consequences:** Identity theft, discrimination, reputational harm, financial loss, physical danger.

Encrypted data without access to the key generally drops the risk below the notification threshold, but only where encryption is state of the art and the key is verifiably uncompromised. Document the reasoning in writing even when you conclude that no notification is required.

## Step 1, Detection and escalation

The as soon as possible clock starts running when the controller *becomes aware* of the breach. Awareness is not the detection of an IDS alert but the consolidation of facts into a reasonably probable conclusion that a notifiable breach has occurred. In practice that is 24 to 72 hours after first detection, but only if internal escalation works.

Operationally, the first 24 hours should cover:

1. **Activation of the incident response team:** CISO/ISB, DPO, Legal, IT operations, external forensics (on call), Communications. A RACI matrix is a prerequisite, not a nice-to-have.
2. **Evidence preservation:** Freeze logs, isolate affected systems (but do not wipe prematurely, that destroys evidence), timestamp everything.
3. **Initial risk assessment:** What data categories, what population size (order of magnitude is enough), what consequences are conceivable. A one-pager *incident brief* is sufficient.
4. **Escalation to executive management:** In writing, with timestamp. The board takes the notification decision, not the IT lead.
5. **Check parallel triggers:** BACS/NCSC notification if critical-infrastructure status applies (see Art. 74a et seq. ISG, 24h), FINMA notification for supervised institutions, GDPR notification if EU data subjects are affected (72h from awareness).

Failing to work through these five points within 24 hours risks the later FDPIC notification being judged as late. The authority scrutinises the steps that lay between detection and notification.

## Step 2, Documenting the high-risk assessment

The likely high risk assessment is legally central and should be captured in a short, structured note, even when you conclude that no high risk exists. The documentation protects you in FDPIC proceedings and in access requests.

We recommend a simple scoring grid on five axes, each 1–4 points:

1. **Data sensitivity** (1 = anonymous metadata, 4 = health, finance, authentication, children).
2. **Number of data subjects** (1 = single individual, 4 = > 10,000).
3. **Identifiability** (1 = strongly encrypted, 4 = cleartext with name + ID).
4. **Whereabouts** (1 = confirmed destruction, 4 = publicly published / dark web).
5. **Likelihood of harm** (1 = abstract, 4 = concrete financial or physical harm materialising).

Scores from ~14 upwards speak for notification, scores below 10 suggest no high risk. The grid is not law but a reproducible heuristic, what matters is that the reasoning is traceable. If you decide against notification, document in writing:

- facts and timestamps;
- affected data categories and volume;
- immediate measures taken;
- risk assessment with reasoning;
- board decision including date and signature.

If contested, the burden of proving the risk assessment lies with you. Complete documentation is not an end in itself, it is insurance.

## Step 3, File the FDPIC notification

The FDPIC operates an online notification platform reachable via www.edoeb.admin.ch. The platform structures the contents required by Art. 24(2) DSG:

- **Nature of the breach:** confidentiality, integrity, availability, combinations are possible.
- **Categories and approximate number of data subjects and data records.**
- **Consequences** (actual or likely) for the data subjects.
- **Measures** taken or planned to mitigate the consequences.
- **Contact point** at the controller (DPO, CISO or external representative).

Important: if information is not yet fully available at the time of notification, an *initial notification with the available data* and a note that the rest will follow is the better path than waiting. The FDPIC has repeatedly stated in practice that a timely initial notification with a later final notification meets the standard of care, whereas a delayed but supposedly complete notification can be treated as a breach of due care.

For cross-border incidents with an EU nexus, the GDPR notification runs in parallel and independently: to the competent EU lead authority or, where no one-stop-shop applies, to the relevant national authority. Keep the wording of both notifications consistent, contradictions get noticed.

## Step 4, Inform the data subjects

Under Art. 24(4) DSG you inform data subjects where this is *necessary for their protection* or where the FDPIC so requires. The threshold is above the GDPR standard (which is high risk); in practice the assessments often coincide.

The information must be provided in *plain and simple language* and must contain:

- a description of the breach;
- the likely consequences;
- measures the controller has taken or will take;
- measures the data subject can take themselves (e.g. password change, payment card block, increased phishing vigilance);
- contact details for queries.

Exemptions from the duty to inform apply where (a) information would entail disproportionate effort and a public announcement is made instead, (b) a statutory duty of secrecy applies, or (c) criminal-prosecution or secrecy interests prevail. These exemptions are construed narrowly and must be justified in writing.

Practical tip: communication with data subjects is at least as important as the FDPIC notification. A poorly worded message can multiply the reputational damage; a factual, action-oriented message can restore trust. Align wording and timing with Legal, Communications and IT. A prepared template in the incident-response playbook saves hours in a real event.

## Step 5, Post-incident review and lessons learned

Notification does not close the duty chain. The FDPIC may follow up after receiving the notification, order additional measures or open formal investigation proceedings. In parallel you must close the loop internally:

- **Root cause analysis:** What technical, organisational or human cause underlay the incident? Which control failed?
- **Action plan:** Concrete, with owner, deadline and effectiveness measurement. Pure we will look into it items do not survive an FDPIC follow-up.
- **Policy and process updates:** Incident-response plan, training, configurations, processor contract clauses.
- **Update of the processing register and, where applicable, the DPIA:** if the incident surfaced new risks or data categories.
- **Insurance notification:** Cyber policies commonly require notification within 48–72 hours; missing the window can void cover.
- **Tabletop exercise:** Re-run the incident with the executive board after the fact. That exposes residual gaps and hardens the playbook for the next event.

We recommend formally archiving the closed-incident file no later than six weeks after closure, including timeline, decisions, evidence, copies of notifications and impact. In the following year this archive is regularly consulted in an FDPIC audit, an ISO 27001 re-certification audit or a due diligence.

## How SIDD supports you

SIDD supports companies before, during and after a data breach. In prevention mode we draft incident-response playbooks, run tabletop exercises with the executive board and train teams through our format [IT security workshop for SMEs](https://www.sidd.swiss/en/services/it-security-workshop-sme). In an acute incident we deploy a team combining legal and technical expertise within hours, coordinate forensics, advise on the FDPIC notification and, on request, take over direct communication with authorities and insurers.

Through our mandate as [external Swiss data protection advisor](https://www.sidd.swiss/en/services/data-protection-advisor-switzerland) and our [CISO/ISB mandates](https://www.sidd.swiss/en/services/vciso) we know the interfaces between DSG, GDPR, ISG and FINMA obligations from the field. Pentests ([penetration testing](https://www.sidd.swiss/en/services/penetration-test)) and [vulnerability scans](https://www.sidd.swiss/en/services/vulnerability-scan) help expose future incidents before they detonate.

Contact us directly in an acute case, by phone or via the [contact form](https://www.sidd.swiss/en/contact). For a preventive mandate request a tailored proposal via the [quote form](https://www.sidd.swiss/en/quote).

---

This document is the Markdown rendition of the page linked above. Please cite the HTML URL.