Checklist: data breach — the first 72 hours
For: Swiss SMEs and SaaS providers
Updated: 2026-10
After a data breach: contain immediately, secure facts and timing, form a decision team, assess the risk to data subjects, notify the FDPIC as soon as possible where risk is high and, under the GDPR, the supervisory authority within 72 hours, inform data subjects where needed, involve processors and document everything.
A data breach is an exceptional situation where much happens at once: technology must contain, management must decide, communication must be prepared, and deadlines are running. Clarifying who does what only during the incident loses time you do not have.
This checklist describes the first 72 hours for Swiss companies subject to the revised FADP and, depending on their activities, also to the GDPR.
The checklist
- 01
Contain
Stop or limit the incident: lock compromised accounts, rotate credentials and keys, isolate affected systems, recall misdirected data or request deletion. Do not destroy evidence in the process.
Done when: The leak or access is stopped or limited, and the measures are logged with time stamps.
- 02
Secure facts and timing
Record when the incident was discovered, what is known, which systems and data may be affected and which logs exist. The time of awareness matters for deadlines.
Done when: An incident log with discovery time, known facts and open questions is created and kept current.
- 03
Form a decision team
Bring together a responsible member of management, technical leadership, the person responsible for data protection and, where needed, communications and external advisers. Clarify roles and availability.
Done when: The team is named, one person holds decision responsibility, and a fixed coordination rhythm is agreed.
- 04
Assess the risk to data subjects
Assess type and volume of data, sensitive data, number of people affected, encryption or pseudonymisation, the circle of recipients and possible consequences such as identity theft, fraud or reputational harm.
Done when: A reasoned risk rating — no risk, risk, high risk — with the criteria considered is on file.
- 05
Check and meet notification duties
Where a high risk is likely, notify the FDPIC as soon as possible (Art. 24 FADP). Where the GDPR applies, notify the competent supervisory authority where feasible within 72 hours of awareness, unless a risk is unlikely (Art. 33 GDPR). Incomplete information may be supplemented later.
Done when: The decision on notification is documented with reasons, and notifications made are filed with confirmation of receipt.
- 06
Inform data subjects where needed
Notify data subjects where necessary for their protection or where the FDPIC requests it; under the GDPR where a high risk is likely. The notice explains in plain language what happened and what people can do, such as changing passwords.
Done when: The decision is documented, and notices sent are filed with date, recipients and wording.
- 07
Involve processors and partners
Inform affected service providers or request their report, ask for information on cause and scope, and inform customers for whom you act as processor — they have their own notification duties.
Done when: All parties involved are informed, and their responses are recorded in the incident log.
- 08
Follow up
Analyse the cause, implement lasting measures, adjust technical and organisational measures, update the record of processing activities and improve the process for the next incident.
Done when: A closing report with cause, measures, owners and dates exists, and open measures are tracked.
Common mistakes
- —Evidence is destroyed during clean-up, so cause and scope can no longer be determined.
- —Notification is delayed because the full scope is not yet known, although information may be supplemented later.
- —Under the GDPR, the 72-hour deadline is counted from the end of analysis instead of from awareness.
- —The decision not to notify is not documented.
- —Customers for whom you are a processor are informed too late and miss their own deadlines.
What this checklist does not cover
- —This checklist is not legal advice. For larger incidents, sensitive data or multiple jurisdictions, seek specialised advice.
- —It does not replace a forensic investigation; for attacks, incident response specialists should be involved.
- —Sector-specific notification duties, for example to FINMA or, for cyberattacks on critical infrastructure, to the Federal Office for Cybersecurity, are not fully covered.
- —Criminal complaints, insurance notifications and employment law questions are covered only in passing.
Parent service: Data Protection Consulting
Matching offers
revFADP implementation for SMEs: from status quo to evidence
A bounded package that takes a Swiss SME from uncertainty to a documented state: capture data flows and providers, determine obligations, review contracts and international transfers, provide privacy-policy groundwork and set clear procedures for data breaches and access requests.
GDPR & revDSG audit for SaaS
A data protection audit for SaaS checks whether data flows, processing agreements, deletion concept, and technical measures are GDPR- and revDSG-compliant. The output is a concrete finding with prioritised fixes — from people who run SaaS themselves.
FAQ
Must every data breach be reported?
No. In Switzerland, notify the FDPIC where a high risk to data subjects is likely. Under the GDPR, notify unless a risk is unlikely. Every incident should, however, be assessed and documented.
When does the 72-hour deadline start?
Under the GDPR, from the moment the controller becomes aware of the breach. The revised FADP has no fixed hour limit but requires notification as soon as possible.
What applies if we are a processor?
Processors notify the controller of the breach as soon as possible. Notifying the authority and informing data subjects is the controller’s responsibility.
Does encryption reduce the duty to notify?
It can substantially lower the risk to data subjects if data was encrypted to the state of the art and keys were not compromised. That feeds into the risk assessment.
More checklists
Checklist: security before a SaaS launch
Before launching a SaaS product, eight points must hold: tested tenant isolation at data level, secure authentication with multi-factor, secrets outside the code, up-to-date dependencies, backups with tested restoration, logging of security events, abuse protection and a prepared process for security incidents.
Checklist: an AI usage policy that people actually follow
An effective AI usage policy sets out, briefly and clearly: which tools are approved, which data may go into them and which may not, that people check and own outputs, when AI use is disclosed, how new tools are approved, what training exists, how incidents are reported and when the policy is reviewed.
Checklist: vetting AI vendors and AI features before use
Before using an AI service, clarify ten questions: is your data used for training, where is data processed, how long are inputs stored, is there a data processing agreement, how is security evidenced, what is your role under the AI Act, what documentation does the vendor provide, how are model changes announced, how are costs capped and how do you exit.