Table of content
A data leak in your measurement setup is not fixed by correcting a configuration. As soon as the breach is likely to result in a high risk to the personality or the fundamental rights of the people affected, art. 24 FADP requires you to report it to the FDPIC as soon as possible. And if those people can take steps to protect themselves, you must inform them, even when the risk falls short of that threshold. Swiss law sets no deadline in hours, unlike the 72 hours of the GDPR, but it does not hand you a right to wait either.
In practice, the leaks that hit marketing teams almost never come from a spectacular cyberattack. They come from a form that pushes an email address in clear text into a URL, a server-side container that logs payloads it should never retain, a CRM export dropped in the wrong shared folder. These are quiet, technical incidents, and they are fully covered by the FADP.
The essentials in eight points
Reporting to the FDPIC: mandatory only where the breach is likely to result in a high risk to the personality or fundamental rights of the person concerned (art. 24 para. 1 FADP).
Swiss deadline: as soon as possible. No figure in the statute, in contrast to the 72 hours of art. 33 GDPR.
Minimum content of the report: the nature of the breach, its consequences and the measures taken or planned (art. 24 para. 2 FADP).
Informing the people affected: owed where it is necessary for their protection or where the FDPIC requires it (art. 24 para. 4 FADP). This duty does not depend on the high-risk threshold.
If you are a processor: you report every breach to the controller, with no severity filter (art. 24 para. 3 FADP).
Documentation: breaches must be documented and the record kept for at least two years from the report (art. 15 DPO, the Swiss Data Protection Ordinance).
Penalties: failure to report is not itself a criminal offence under Swiss law. Failure to meet the minimum data security requirements is, upon complaint, with a fine of up to CHF 250,000 (art. 61 let. c FADP).
Real-world volume: the FDPIC reports having received more than 2,000 notifications of potential breaches during the year under review in its 33rd activity report, published at the end of June 2026.
What counts as a data security breach in a measurement setup?
The FADP defines a breach not by its origin but by its effect: a breach of security leading to the accidental or unlawful loss, deletion, destruction or alteration of personal data, or to its disclosure or accessibility to unauthorised persons. No intrusion is required. A misconfiguration is enough.
That is exactly what makes the topic relevant to a tracking setup. A modern measurement stack is a chain: browser, tag manager, server-side container, ad platforms, CRM, dashboarding tools. Every link handles identifiers, sometimes contact data, and every link can leak without anyone noticing.
The most common scenarios in a marketing stack
The email address in clear text in the URL. A form submitted over GET, or a thank-you redirect that copies the form fields into query parameters. The address then travels in the referrer, in the server logs, into the analytics tool and on to every ad platform called from that page.
Over-generous server-side logging. A server-side container left in debug mode for weeks, or a logging service that retains full event payloads. You end up with a history of contact data sitting in a store nobody ever classified as sensitive.
The personalisation parameter that travels too far. A customer reference, a case number or a patient number used as a custom dimension, then forwarded to an ad platform that had no business receiving it.
The misplaced export. A lead file dropped into shared storage, an audience list sent by email, a report exposed through a public link that never expires.
Accidental indexing. The most brutal case, because it turns a configuration error into worldwide publication. In late September 2026, Charlotte Beck and Alain Steinmann analysed on swissprivacy.law a case in which the customer records of several thousand clients of an online shop, including identity, addresses and bank details, ended up indexed by a search engine following a security flaw. The company blocked access and then refused to inform its customers, judging the effort disproportionate.
None of these five scenarios looks like a cyberattack. All of them fall under art. 24 FADP as soon as personal data has been made accessible to unauthorised third parties.
Who must you notify, and how quickly?
There are two distinct obligations, two recipients and two different thresholds. Conflating them is the most common mistake.
Reporting to the authority
Under the FADP: the controller reports to the FDPIC, as soon as possible, breaches that are likely to result in a high risk to the personality or fundamental rights of the person concerned. The threshold is therefore twofold: a risk, and a high one. Below that, nothing is owed.
Under the GDPR: notification to the supervisory authority is owed as soon as there is a risk to rights and freedoms, and it must happen without undue delay and where feasible no later than 72 hours after becoming aware of it. Lower threshold, fixed deadline.
Practical consequence: a Swiss company that also serves customers in the European Union has to plan against the stricter of the two regimes. If you want that interplay in detail, our technical comparison of the FADP and the GDPR works through it point by point.
Mandatory reports to the FDPIC go through its dedicated portal. Sylvain Métille, a lawyer in Lausanne, points out on his blog that this portal is reserved for mandatory reports and that voluntary ones follow a different route. He also notes, rightly, that the absence of a fixed deadline in Swiss law should give the controller time to establish the facts before qualifying the risk.
Informing the people affected
This is where the least understood nuance of art. 24 sits. Paragraph 4 requires the controller to inform the person concerned where this is necessary for their protection or where the FDPIC requires it. David Dias Matos and Célian Hirsch stressed on swissprivacy.law, commenting on the FDPIC's own guidance, that this duty is independent of the high-risk threshold that triggers the report to the authority.
So the test is not abstract severity but concrete usefulness: can the person actually do something to protect themselves? Change a password, block a card, watch an account, treat with suspicion a phishing attempt that reuses the leaked data. If so, you inform them, in clear and plain language, stating at minimum the nature of the breach, the risks involved and the measures taken (art. 15 para. 3 DPO).
And where individual notice becomes impossible or disproportionate, the duty does not vanish: it turns into public communication. That is the lesson of the case discussed on swissprivacy.law at the end of September 2026. The scale of a leak is not an argument for silence.
When is the risk "high" within the meaning of art. 24 FADP?
The statute gives no list. Practice has produced workable markers, which the FDPIC has spelled out and Swiss commentators relay.
Risk is presumed high where the leak involves sensitive data, copies of identity documents or credit cards, or data revealing a particularly intrusive context, for instance criminal proceedings or social assistance measures. Conversely, there is generally no high risk where the data concerned was already publicly accessible before the breach.
For a measurement setup, that yields a useful reading grid:
Which categories of data moved? A pseudonymous advertising identifier does not carry the weight of an email address tied to a basket, let alone a health inference drawn from browsing a medical site.
How many people, and for how long? A few minutes of exposure to a contracted provider is not months of public indexing.
Does the data allow re-identification? An identifier alone, no. An identifier joined to a delivery address, yes.
Can the data be used to cause harm? Impersonation, targeted phishing, payment fraud, disclosure of a membership or a health condition. This is the criterion that most often tips the assessment.
Does the remediation genuinely neutralise the risk? Cutting access does not retrieve what has already been copied, cached or indexed.
This grid maps onto what art. 15 para. 1 DPO expects the report to contain: the nature of the breach, when it occurred, the categories and approximate number of data records and people affected, the consequences and risks, the corrective measures, and a contact point. The ordinance also allows a report in stages where all of this cannot be assembled at once, which is almost always the case in the first few hours.
Web agency, marketing agency: you are probably a processor
This is the point many providers discover too late. Art. 24 para. 3 FADP requires the processor to report every data security breach to the controller, as soon as possible. No high-risk threshold here. No discretion over severity.
In other words: if you run your client's tag manager, server-side container, consent platform or CRM, and you spot a leak, you must tell them. Including when you caused it. And it is the controller who decides on the report to the FDPIC and on informing their own customers.
Three contractual and operational consequences follow:
The processing agreement must set the escalation channel and timing. A bare "we will inform the client" does not hold up: you need a named recipient, a channel that works outside office hours, and an information format that lets the controller qualify the risk.
Logging must be usable. You cannot qualify a leak without knowing what left, where it went and for how long. Art. 4 DPO in fact mandates logging for large-scale processing of sensitive data and for high-risk profiling.
The processing policy is not a formality. Art. 5 DPO requires it in the same situations, and it is the first document an authority asks for. We have set out elsewhere the documents the FDPIC may request during an inspection: breach documentation is one of them.
What is the real exposure in Switzerland?
Precision matters here, because the subject attracts a lot of loose talk.
Failing to report a data security breach is not, in itself, a criminal offence under art. 60 to 62 FADP. Those provisions target failures of the duties to inform under art. 19 and 21, failures connected with the right of access under art. 25 to 27, disclosure of data abroad in breach of art. 16 and 17, engaging a processor contrary to art. 9, and failure to meet the minimum data security requirements issued by the Federal Council under art. 8 para. 3. Art. 24 is not on the list.
That does not mean there is no exposure. It simply sits elsewhere:
The cause of the leak is sanctionable. A breach resulting from failure to meet the minimum security requirements falls under art. 61 let. c FADP, punishable upon complaint by a fine of up to CHF 250,000, which targets the responsible natural person rather than the company.
The FDPIC can open an investigation and order measures. Art. 51 FADP allows it to order the modification, suspension or cessation of all or part of the processing, as well as the deletion or destruction of the data. For a measurement setup, that can mean stopping a collection your campaigns depend on.
The volume of reports shows an active authority. Its 33rd activity report, published at the end of June 2026, records more than 2,000 notifications of potential breaches received during the year under review, 156 interventions with controllers, 22 preliminary examinations and 9 investigations.
Civil and reputational risk remains the most tangible. A damages claim, a group complaint from customers, and above all the loss of trust from a customer base that learns about the leak from someone other than you.
The four reflexes of the first 48 hours
The diagram accompanying this section sets out this sequence in four steps. Here is its content:
Contain, without destroying the evidence. Cut the source, revoke the affected access and tokens, disable the offending tag or stream. But keep the logs, the container versions and the timestamps: they are what you will use to qualify the risk and document the file.
Qualify. Which data, how many people, what exposure window, which recipients, what scope for re-identification and harm. Your role here is investigator, not defence counsel for your own configuration.
Decide and report. Two separate decisions: report to the FDPIC if the risk is likely high, inform the people affected if they can protect themselves. If facts are missing, report in stages rather than wait.
Document and fix. Build the breach file and keep it for at least two years, then address the root cause, not just the symptom. A leak caused by a GET form will recur for as long as the form stays on GET.
How to shrink the leak surface of your measurement setup
The best breach report is the one you never have to file. Three layers of prevention, from the browser down to your data stores:
Collection layer. No contact data in clear text in URLs, page titles or custom dimensions. Forms on POST. Systematic cleaning of query parameters before any transmission. An explicit ban, written into the tagging plan, on pushing a business identifier to an ad platform.
Server layer. A server-side container is the right place to filter, hash and minimise before forwarding, provided it does not become a store in its own right. Time-boxed debugging, no retention of full payloads, API key rotation, and logging sized for investigation rather than archiving. This layer is also where hosting and data location are decided.
Governance layer. A current inventory of what goes where, a processing policy, a breach procedure naming an owner and a deputy, and a periodic review. It is the only way to catch drift before it becomes an incident. Our article on monitoring server-side tracking after launch describes the matching control setup.
One point deserves to be stated plainly, because it is often heard backwards: moving to server-side does not inherently create additional leak risk. It relocates the control point. Configured well, it shrinks the exposed surface by stopping data from leaving your perimeter unfiltered. Configured badly, it centralises in one place everything it should have discarded.
How A-Track can help
Our work is to make your measurement both reliable and defensible. On this particular subject, that takes three forms.
First, a leak surface audit: we inspect what actually travels between your site, your server-side container and your platforms, across the three consent states, and we identify the data that should not be there. Then remediation: tagging plan, server-side filtering, logging policy and a documented breach procedure. Finally, maintenance, because the compliance of a measurement setup does not survive six months of CMS, plugin and ad platform updates on its own.
Our tracking and compliance and data governance services cover this scope for Swiss SMEs, web agencies and marketing agencies.
Next step
If you do not know today which personal data leaves your site for your ad platforms, you will not be in a position to qualify a leak on the day it happens. And that is precisely what art. 24 FADP will ask you to do, as soon as possible.
Start with the simplest thing: open your container logs, search your query parameters for an at sign and an equals sign, and look at what comes back. If something comes back, you already have your first project. If nothing comes back, document it: that is the first item in your compliance file.
Sources
Federal Act on Data Protection (FADP, SR 235.1), in particular art. 8, 24, 51 and 60 to 62.
Data Protection Ordinance (DPO, SR 235.11), in particular art. 1 to 5 and art. 15.
FDPIC, 33rd activity report 2025/2026, published at the end of June 2026.
Charlotte Beck and Alain Steinmann, "Lorsque la mitigation rend la notification impossible", swissprivacy.law, 30 September 2026.
David Dias Matos and Célian Hirsch, "Le PFPDT guide les responsables du traitement quant à leur devoir d'informer des violations de la sécurité des données", swissprivacy.law, 19 February 2025.
Sylvain Métille, "Violations de la sécurité des données personnelles (LPD)", smetille.ch.
