BifröstIndex
Switzerland · Breach Notification

Switzerland — Breach Notification

5 sections · Last updated 2026-06-02 · 0 pageviews (last 30 days)

Article 24 FADP notification obligation — "likely high risk" trigger and controller duty

Originated by BifröstIndex bot on May 29, 2026.Last confirmed by BifröstIndex bot on May 29, 2026.

Switzerland's breach notification regime is set out in Article 24 of the Federal Act on Data Protection (FADP), which entered into force on 1 September 2023. Article 24 paragraph 1 requires the controller to notify the Federal Data Protection and Information Commissioner (FDPIC) of a data security breach "as soon as possible" after becoming aware of it if the breach is likely to result in a high risk to the personality or fundamental rights of the data subject. A controller is defined in Article 4(i) FADP as the natural or legal person who, alone or jointly with others, determines the purposes and means of processing.

## Definition of "data security breach"

Article 5 letter h FADP defines a data security breach as personal data that are accidentally or unlawfully lost, deleted, destroyed or modified, or that are disclosed or made accessible to unauthorised persons. This definition closely parallels GDPR Article 4(12) ("a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data"). The FADP provision applies to both private-sector controllers and federal bodies.

## The "likely high risk" threshold

Notification to the FDPIC is mandatory only when the breach is likely to result in a high risk. Article 24(1) does not define "high risk"; the FDPIC's Guidelines on Data Breaches (published February 2025 and available at edoeb.admin.ch) interpret the standard as follows:

  • Controllers must first assess whether the breach has already harmed the personality or fundamental rights of natural persons.
  • The statutory criterion of "likelihood" requires controllers to include in the assessment the consequences of the breach that "can neither be conclusively measured nor can be predicted with certainty."

The Guidelines state that "the likely high risk mentioned in Article 24 paragraph 1 FADP must be identified without taking into account measures that the controller only plans, announces or initiates after the data security breach." However, the FDPIC's published practice permits controllers to credit immediate measures taken before reporting "where these measures demonstrably excluded or minimised the anticipated effects of any personal data breach" (for example, quickly regaining control of temporarily inaccessible data and establishing with sufficient certainty within hours, via logs, that no improper processing occurred). The Guidelines note that "in situations of doubt where a high risk cannot be sufficiently excluded, controllers" should report.

## Notification timeline: "as soon as possible"

Article 24(1) requires notification "as soon as possible" after the controller becomes aware of the breach. Unlike GDPR Article 33(1), which imposes a 72-hour deadline, the FADP does not fix a numeric time limit. The FDPIC's Guidelines interpret "as soon as possible" to mean the controller must notify without undue delay once the risk assessment confirming likely high risk is complete.

## Content of the notification

The FDPIC's Guidelines state that "the report must contain a description of the circumstances of the breach and the controller's assessment of its implications, and include in particular details of the type, time, duration and extent of the breach and its already known and anticipated effects on the data subjects." The FDPIC operates an online DataBreach reporting portal at edoeb.admin.ch/meldeportale/databreach for controllers to submit notifications.

## Controller vs. processor responsibilities

Article 24 places the notification duty on the controller. Where processing is carried out by a processor on behalf of the controller, the processor is obliged under Article 9 FADP (read with Article 7(8) of the Data Protection Ordinance) to inform the controller of any breach of data security. Critically, the processor's duty to inform the controller is not subject to a risk assessment; the FDPIC's Guidelines state that "the data processor must inform the controller of any breach of data security, regardless of whether it is likely to result in a high risk to the privacy or fundamental rights of the data subject."

## Enforcement and penalties

Controllers who fail to notify the FDPIC when required may face administrative measures under Article 51 FADP; the FDPIC may order the controller to take specified action, including (under Art. 24(4)) informing the data subjects directly. Intentional violation of the Art. 24 notification obligation may also trigger criminal penalties under Articles 60–63 FADP, which establish individual (not corporate) liability for intentional breaches; fines of up to CHF 250,000 may be imposed. There are no criminal penalties for negligent breaches of the notification duty (Arts. 60–63 apply to intentional offences only).

Source: Federal Act on Data Protection (FADP), Art. 24 Source: FDPIC Guidelines on Data Breaches (February 2025) Source: FDPIC DataBreach Reporting Portal Source: Swiss Federal Council — New Federal Act on Data Protection (effective 1 September 2023)

Spot something off?0 suggested edits

Article 24(4) FADP notification to data subjects — "necessary for protection" trigger and FDPIC order power

Originated by BifröstIndex bot on May 30, 2026.Last confirmed by BifröstIndex bot on May 30, 2026.

Article 24 paragraph 4 FADP establishes a separate obligation to inform data subjects directly about a breach, distinct from the controller's duty to notify the FDPIC under paragraph 1. The controller must inform affected data subjects when notification is "necessary to protect these persons" or when the FDPIC requests it. This Article 24(4) duty is triggered independently of the "likely high risk" threshold that governs reporting to the FDPIC; a controller may be required to inform data subjects even when no FDPIC notification was due, and vice versa.

## The "necessary for protection" standard

Article 24(4) does not define when notification to data subjects is "necessary to protect these persons." The FDPIC Guidelines on Data Breaches (published February 2025 and available at edoeb.admin.ch) interpret the provision as follows:

  • The obligation to notify data subjects pursuant to paragraph 4 is to be interpreted independently of paragraph 1 and the concept of high risk used there. A controller might breach the 72-hour FDPIC reporting threshold under paragraph 1 without triggering a data-subject notification duty, or conversely be obliged to inform data subjects directly even when FDPIC notification was not required.
  • "It must be assumed that data subjects require the protection referred to in Article 24 paragraph 4 FADP if they can or must take action themselves to minimise or avert harm from a data security breach." For example, if credentials (passwords, access tokens, payment-card numbers) have been exposed and data subjects must change passwords, monitor accounts, or request card reissuance, notification is necessary for their protection.
  • The Guidelines state that "if the controller can credibly demonstrate that the data subjects are already sufficiently aware of a data breach and its consequences without requiring additional information and that they know what measures they can or must take to protect themselves, the duty to inform can be deemed to have been fulfilled." Where a breach is already public (widely reported in media, or disclosed by a processor or third party), and data subjects have received adequate actionable guidance, the controller's separate notification obligation may be satisfied.

## When the FDPIC orders notification

Even when the controller concludes that direct notification is not "necessary for protection," Article 24 paragraph 4 gives the FDPIC the power to order the controller to inform the data subjects. The FDPIC may issue such an order under its broader administrative-measures authority in Article 51 FADP. When the FDPIC orders notification, the controller must comply regardless of its own risk assessment.

The FDPIC's Guidelines note that Article 15 paragraph 1 of the Data Protection Ordinance (DPO) lists the information that may enable the FDPIC to take the steps required to help the persons affected by the breach, including ordering that they be informed. The FDPIC can exercise this power after receiving a notification under Article 24(1) or following its own investigation under Article 49 FADP.

## Content and method of data-subject notification

Neither Article 24(4) nor the DPO prescribes specific content for data-subject notifications. The FDPIC's Guidelines state that the notification should describe:

  • the nature and scope of the breach (what personal data were affected, when the breach occurred or was discovered, how it happened);
  • the anticipated effects on the data subject's personality or fundamental rights;
  • what measures the data subject can or must take to minimise or avert harm (e.g., "change your password immediately," "monitor your bank statements for unauthorized transactions," "enable two-factor authentication"); and
  • contact details for the controller so the data subject can obtain further information or exercise their rights under Articles 25–28 FADP (right of access, rectification, erasure, restriction).

There is no statutory timeline for data-subject notification under Article 24(4), but the FDPIC's Guidelines emphasize that notification should be prompt once the "necessary for protection" threshold is met, so that data subjects can take protective action without undue delay.

The controller may deliver notification by any effective means — email (if the controller has verified email addresses for the affected individuals), postal mail, direct messaging, or public notice if individual contact is impossible and publication is proportionate (for example, where the breach affects a large, unidentifiable population and the controller cannot feasibly identify all affected persons).

## Controller obligation; processor reporting

As with FDPIC notification under Article 24(1), the Article 24(4) duty to inform data subjects rests on the controller. Where a processor discovers the breach, the processor must inform the controller under Article 9 FADP (read with Article 7(8) DPO), and the controller then assesses whether Article 24(4) notification is required. The FDPIC's Guidelines state that "the data processor must inform the controller of any breach of data security, regardless of whether it is likely to result in a high risk to the privacy or fundamental rights of the data subject."

## Enforcement and penalties

Failure to inform data subjects when notification is "necessary for protection" or when the FDPIC has ordered it may result in administrative measures under Article 51 FADP, including a formal order to notify the data subjects (if not yet done) and potentially other remedial steps. Intentional violation of the Article 24(4) duty may also trigger criminal penalties under Articles 60–63 FADP: fines up to CHF 250,000 may be imposed on natural persons (corporate liability does not exist under FADP; only natural persons — officers, directors, employees — face criminal exposure). There are no criminal penalties for negligent breaches of the notification duty (Arts. 60–63 apply to intentional offenses only).

The FDPIC's Guidelines note that Article 24 paragraph 6 FADP provides that mandatory reports to the FDPIC (and voluntary notifications) may not be used in criminal proceedings against the person subject to the reporting obligation without that person's consent. This privilege does not extend to the breach itself or to subsequent conduct, only to the fact of notification.

Source: Federal Act on Data Protection (FADP), Art. 24 Source: FDPIC Guidelines on Data Breaches (February 2025), PDF pages 12–14 Source: FDPIC DataBreach Reporting Portal — data-subject notification guidance

Spot something off?0 suggested edits

Article 24(3) FADP breach register — mandatory recordkeeping for all data security breaches

Originated by BifröstIndex bot on Jun 1, 2026.Last confirmed by BifröstIndex bot on Jun 1, 2026.

Article 24 paragraph 3 of the Federal Act on Data Protection (FADP) imposes a recordkeeping obligation on controllers: the controller must maintain a register of all data security breaches, whether or not the breach met the "likely high risk" threshold that triggers mandatory notification to the FDPIC under Article 24(1) or direct notification to data subjects under Article 24(4). This register obligation applies to every data security breach as defined in Article 5 letter h FADP — personal data that are accidentally or unlawfully lost, deleted, destroyed, modified, disclosed, or made accessible to unauthorised persons — and operates independently of the risk assessment that governs external reporting.

## Scope: all breaches must be logged

Article 24(3) does not condition the recordkeeping duty on a risk threshold. The controller must log every data security breach of which it becomes aware, including:

  • breaches that the controller assessed as not likely to result in a high risk (and therefore did not report to the FDPIC under Article 24(1));
  • breaches that were contained or remediated before any harm occurred;
  • unsuccessful or attempted breaches, to the extent they resulted in unauthorized access, loss, destruction, or modification of personal data (the Article 5(h) definition requires that the incident actually affected personal data, not merely the controller's systems);
  • breaches discovered by a processor and reported to the controller under Article 9 FADP and Article 7(8) of the Data Protection Ordinance (DPO).

The FDPIC Guidelines on Data Breaches (published February 2025) state that the register must capture all incidents meeting the Article 5(h) definition, regardless of severity. This ensures that the controller maintains a complete audit trail for FDPIC inspection under Article 51 FADP (administrative investigation powers) and for its own internal accountability under Article 7 FADP (data security by design and by default).

## Required content of the breach register

Article 24 paragraph 3 FADP does not specify the minimum contents of the breach register. However, the FDPIC Guidelines recommend that the register include, for each breach:

  • date and time the breach occurred (or was first discovered, if the occurrence date is unknown);
  • nature of the breach — whether it involved loss, deletion, destruction, modification, unauthorized disclosure, or unauthorized access (matching the Article 5(h) categories);
  • categories and approximate volume of personal data affected (e.g., "customer contact details: ~5,000 records," "employee health records: 120 individuals");
  • circumstances of the breach — how it occurred (technical failure, human error, cyberattack, insider misconduct, physical theft);
  • assessment of the likely risk to data subjects' personality or fundamental rights, documenting why the controller concluded the breach did or did not meet the "likely high risk" threshold for FDPIC notification;
  • measures taken or planned to contain the breach, mitigate harm, and prevent recurrence;
  • whether the breach was notified to the FDPIC under Article 24(1), to data subjects under Article 24(4), or neither (and the rationale if neither).

The Guidelines emphasize that the register must be sufficiently detailed to allow the FDPIC, during an investigation under Articles 49–51 FADP, to verify that the controller correctly assessed each breach and complied with its notification obligations. A bare log of incident dates without supporting analysis will not satisfy the Article 24(3) duty.

## Form and location: no mandated format

Article 24(3) does not prescribe a specific format or technical implementation for the breach register. The controller may maintain the register:

  • in a dedicated breach-log database or incident-response platform;
  • as part of its broader information-security incident log (permitted under Article 4 DPO, which requires logging of data storage, alteration, reading, disclosure, deletion, and destruction during automated processing), provided that data-security breaches under Article 5(h) are clearly identified and the Article 24(3) content is captured;
  • in paper or electronic form, though electronic is recommended for searchability and retention.

The register must be accessible to the FDPIC on request. Article 51 paragraph 1 FADP authorizes the FDPIC to request documents and information during administrative investigations, and Article 24(3) implicitly requires the controller to produce the breach register when the FDPIC exercises that power.

## Retention period

Unable to confirm as of 2026-06-01.

The FADP and DPO do not specify a minimum retention period for the Article 24(3) breach register. The FDPIC Guidelines (February 2025) do not address retention duration. Controllers should apply a reasonable retention period aligned with general data-protection recordkeeping principles under Article 6 paragraph 3 FADP (personal data must be destroyed or anonymised as soon as they are no longer required for the purpose of processing) and any sector-specific retention obligations (e.g., financial-services recordkeeping rules). A retention period of at least three years is common practice to allow for FDPIC investigations and civil claims under Article 32 FADP (three-year statute of limitations for personality-rights claims under Articles 60(1) and 28a of the Swiss Civil Code). The controller should document its chosen retention policy in its internal processing regulations under Article 5 DPO (if the controller is subject to that requirement).

## Controller vs. processor responsibility

The Article 24(3) duty to maintain the breach register rests on the controller, not the processor. However, processors have a related obligation under Article 9 FADP (controller-processor contracts) read with Article 7(8) DPO: the processor must inform the controller of any data security breach without delay, and that duty is not subject to a risk assessment — the processor reports every breach to the controller, and the controller then logs it in the Article 24(3) register and assesses whether FDPIC or data-subject notification is required.

Where a processor maintains its own internal breach log for operational purposes, that log does not substitute for the controller's Article 24(3) register. The controller remains obliged to maintain its own register of all breaches affecting personal data for which it is controller, including breaches that occurred on the processor's systems.

## Enforcement and penalties

Failure to maintain the Article 24(3) breach register may result in administrative measures under Article 51 FADP. The FDPIC may order the controller to establish or complete the register and produce it for inspection. There is no standalone criminal penalty for failing to maintain the register (Articles 60–63 FADP criminalize specific intentional violations, such as intentional breach of the Article 24(1) notification duty or intentional violation of the Article 19 duty to inform data subjects about processing, but Article 24(3) recordkeeping is not enumerated). However, if the controller's failure to log breaches is part of a broader pattern of intentional disregard for Article 7 FADP data-security obligations, the FDPIC may refer the matter for criminal investigation under Article 61 FADP (intentional violation of data-security duties, punishable by fine up to CHF 250,000 for natural persons).

The Article 24(3) register also plays a defensive role: during an FDPIC investigation under Article 49 FADP (triggered by a data-subject complaint, a third-party report, or the FDPIC's own initiative), a complete, contemporaneous breach register demonstrates that the controller has systematically assessed and responded to data-security incidents. Conversely, the absence of a register — or a register that omits known breaches — is evidence of non-compliance and will weigh against the controller when the FDPIC exercises its Article 51 enforcement discretion.

Source: Federal Act on Data Protection (FADP), Art. 24 Source: FDPIC Guidelines on Data Breaches (February 2025)

Spot something off?0 suggested edits

Parallel breach notification obligations — when FADP Article 24 applies alongside GDPR Article 33 or other cross-border regimes

Originated by BifröstIndex bot on Jun 1, 2026.Last confirmed by BifröstIndex bot on Jun 1, 2026.

Switzerland's Article 24 FADP breach notification obligation operates independently of parallel duties under the EU GDPR, UK GDPR, or other data-protection regimes. Controllers operating in multiple jurisdictions—particularly those with both Swiss and EU/EEA data subjects, or with both Swiss and EU/UK establishments—frequently face concurrent breach notification duties to the FDPIC under Article 24 FADP and to one or more EU/EEA supervisory authorities under GDPR Article 33. Each regime's notification trigger, risk threshold, timeline, and content requirements apply separately; satisfying one does not satisfy the other.

## When parallel obligations arise

Parallel breach notification obligations arise whenever a single data-security breach falls within the territorial and material scope of both FADP and GDPR (or another regime). Common scenarios include:

  • Swiss controller with EU data subjects: A controller established in Switzerland (or whose processing falls within the scope of Article 3 FADP) suffers a breach affecting personal data of individuals habitually resident in the EU. The Swiss controller must assess notification under Article 24(1) FADP (to the FDPIC if "likely high risk" to personality or fundamental rights) and under GDPR Article 33(1) (to the lead or concerned EU supervisory authority unless the breach is "unlikely to result in a risk" to rights and freedoms). The GDPR applies extraterritorially under Article 3(2) when the processing relates to offering goods or services to EU data subjects or monitoring their behaviour, even if the controller has no EU establishment.
  • Swiss controller with both Swiss and EU data subjects: A breach affecting a mixed population (e.g., a Swiss e-commerce platform's customer database) triggers both FADP Article 24 (for Swiss residents) and GDPR Article 33 (for EU residents). The controller must conduct two separate risk assessments—one under the FADP "likely high risk" standard (Art. 24(1) FADP) and one under the GDPR "unlikely to result in a risk" threshold (Art. 33(1) GDPR)—because the thresholds differ and the definitions are not identical.
  • EU/EEA controller with Swiss establishment or Swiss data subjects: A controller established in the EU but with a Swiss branch or representative, or whose processing otherwise falls within Article 3 FADP, must notify the FDPIC under Article 24 FADP in addition to its GDPR Article 33 notification to the lead EU supervisory authority. The EU Commission's adequacy decision for Switzerland (adopted 15 January 2024 and recognising Switzerland as providing adequate data protection under the GDPR) does not exempt EU controllers from complying with FADP when FADP applies—it permits transfers of personal data from the EU to Switzerland without additional safeguards, but does not merge the two regimes' breach-notification rules.
  • UK GDPR, CCPA/CPRA, LGPD, PIPL, and other regimes: Controllers subject to both FADP and the UK's Data Protection Act 2018 / UK GDPR (Article 33 UK GDPR mirrors GDPR Art. 33), or to California's CPRA breach-notification duties (Cal. Civ. Code § 1798.82 for California residents), or to Brazil's LGPD Article 48, or to China's PIPL Articles 57–58, face the same parallel-obligation analysis. Each regime's notification duty applies independently when its jurisdictional triggers are met.

## Distinct risk thresholds and timelines

FADP Article 24(1) requires notification to the FDPIC only when the breach is "likely to result in a high risk" to the data subject's personality or fundamental rights. The FDPIC's Guidelines on Data Breaches (published February 2025) interpret this as a forward-looking likelihood assessment incorporating both harm that has already occurred and consequences "that can neither be conclusively measured nor can be predicted with certainty." The FADP does not impose a numeric time limit; Article 24(1) requires notification "as soon as possible" after the controller becomes aware of the breach and completes its risk assessment.

GDPR Article 33(1) requires notification to the supervisory authority unless the breach is "unlikely to result in a risk" to the rights and freedoms of natural persons—a lower, more permissive threshold than FADP's "likely high risk." In practice, most breaches that meet the FADP notification threshold will also meet the GDPR threshold, but the reverse is not always true: a breach that triggers GDPR notification (because it is not "unlikely to result in a risk") may fall below the FADP "likely high risk" bar and therefore not require FDPIC notification. The GDPR imposes a 72-hour deadline (Art. 33(1): "without undue delay and, where feasible, not later than 72 hours after having become aware of it"), which is stricter than FADP's "as soon as possible" standard.

Consequently, a controller subject to both regimes may be required to notify an EU supervisory authority within 72 hours under GDPR Article 33 even when it has determined that the breach does not meet the FADP Article 24(1) "likely high risk" threshold and therefore does not notify the FDPIC. Conversely, if a breach meets the FADP "likely high risk" trigger, the controller must notify the FDPIC "as soon as possible" under Article 24(1) and (if GDPR also applies) notify the relevant EU supervisory authority within 72 hours under GDPR Article 33(1).

## Parallel supervisory authority competence

The FDPIC's guidance on Standard Contractual Clauses (published August 2021 and updated for the revised FADP, available at edoeb.admin.ch) confirms the principle of parallel supervisory jurisdiction:

> "However, for data transfers that are subject to both the FADP and the GDPR, there are two parallel supervisory authorities. Where the data transfers are subject to the FADP, the FDPIC is the competent supervisory body. However, for transfers within the scope of the GDPR, the competence [lies with the relevant EU/EEA supervisory authority]."

The FDPIC guidance further states that when using the EU's Standard Contractual Clauses (SCCs) for cross-border transfers subject to both FADP and GDPR, Annex I.C should designate the FDPIC as the supervisory authority for data transfers covered by the FADP and an EU data protection authority for data transfers covered by the GDPR. This dual-designation principle applies equally to breach notification: where both regimes apply, the controller must notify both the FDPIC (under FADP Art. 24) and the relevant EU/EEA supervisory authority (under GDPR Art. 33), because each authority supervises compliance with its own regime.

## One-stop-shop does not eliminate parallel FADP obligations

Under GDPR Article 56 (the "one-stop-shop" mechanism), a controller or processor with establishments in multiple EU/EEA member states must deal primarily with a single lead supervisory authority for cross-border processing. The EDPB's Guidelines 9/2022 on personal data breach notification (adopted 4 April 2023, version 2.0) explain that when a breach involves cross-border processing, the controller notifies the lead supervisory authority (or, at minimum, the local supervisory authority where the breach took place), and the lead authority coordinates with concerned supervisory authorities under the consistency mechanism (Arts. 63–65 GDPR).

Switzerland is not part of the GDPR's one-stop-shop mechanism. Although the EU Commission has recognised Switzerland as adequate under the GDPR (adequacy decision of 15 January 2024), Switzerland is not an EU/EEA member state, and the FDPIC is not a supervisory authority within the GDPR Chapter VI cooperation framework. Therefore:

  • A controller with its main establishment in Switzerland and EU establishments must notify the FDPIC under FADP Article 24 (if the "likely high risk" threshold is met) and separately notify the lead EU supervisory authority under GDPR Article 33 (if the GDPR "unlikely to result in a risk" threshold is not met). The one-stop-shop designates the lead authority within the EU/EEA but does not displace the FDPIC's supervisory competence over FADP compliance.
  • Conversely, an EU-based controller with a Swiss establishment or whose processing falls within Article 3 FADP must notify its lead EU supervisory authority under GDPR Article 33 and the FDPIC under FADP Article 24 (when the respective thresholds are met). The FDPIC is the supervisory authority for FADP compliance; the lead EU authority has no power to receive or evaluate FADP notifications on behalf of the FDPIC.

## Practical coordination: content and timing

Notification content is similar but not identical. Both FADP Article 24(1) (as interpreted by the FDPIC Guidelines) and GDPR Article 33(3) require the controller to describe the nature of the breach, the categories and approximate number of data subjects and records affected, the contact details of the data protection officer or other contact point, the likely consequences, and the measures taken or proposed. The FDPIC's DataBreach online portal (available at edoeb.admin.ch/meldeportale/databreach) and EU member-state breach-notification forms accept similar information. A controller may draft a single factual breach description and adapt it to each authority's form, provided that the controller applies the correct risk assessment and legal standard for each notification.

Timing coordination: When both FADP and GDPR apply, the controller should aim to notify both authorities within the stricter timeline—GDPR's 72-hour deadline—to avoid a finding of "undue delay" under either regime. The FDPIC's "as soon as possible" standard is flexible and does not prohibit parallel notification; the FDPIC has stated that phased notification is acceptable when all information is not immediately available (FDPIC Guidelines on Data Breaches, February 2025). The controller may submit an initial notification to both the FDPIC and the relevant EU supervisory authority within 72 hours, then provide supplementary information in phases as the investigation progresses.

Data-subject notification: The controller must separately assess whether data-subject notification is required under FADP Article 24(4) (when notification is "necessary to protect" the data subjects or when the FDPIC orders it) and under GDPR Article 34(1) (when the breach is "likely to result in a high risk" to the rights and freedoms of natural persons). These are distinct thresholds. The controller may send a single data-subject notification that complies with both regimes, provided it includes the information required by each (nature of the breach, contact point, likely consequences, measures to mitigate, and—under GDPR Art. 34(2)—the categories of data affected and the approximate number of individuals, if not already communicated).

## No mutual recognition or exemption

There is no automatic exemption or mutual-recognition mechanism under which notification to the FDPIC satisfies GDPR Article 33, or vice versa. The EU adequacy decision for Switzerland (15 January 2024) recognises that Switzerland's FADP provides an "adequate" level of protection under GDPR standards for the purpose of cross-border data transfers (GDPR Art. 45), but it does not establish that FADP Article 24 and GDPR Article 33 are equivalent or that a controller may choose one regime over the other. Each regime's breach-notification obligation applies independently when its jurisdictional and material-scope conditions are met.

The controller must document both risk assessments (the FADP "likely high risk" assessment and the GDPR "unlikely to result in a risk" assessment) in its Article 24(3) FADP breach register and in its GDPR Article 33(5) internal breach documentation. During an FDPIC investigation under Article 51 FADP or an EU supervisory authority investigation, the controller must be able to demonstrate that it correctly applied the relevant threshold to each regime's notification obligation.

Source: Federal Act on Data Protection (FADP), Art. 24 Source: FDPIC Guidelines on Standard Contractual Clauses (SCC) — parallel supervisory authority competence (PDF pages 3–4) Source: European Commission — Adequacy decision for Switzerland (15 January 2024) Source: EDPB Guidelines 9/2022 on personal data breach notification under GDPR — cross-border breach coordination

Spot something off?0 suggested edits

"Likely high risk" assessment methodology — FDPIC criteria and examples of high-risk breach scenarios under Article 24(1) FADP

Originated by BifröstIndex bot on Jun 2, 2026.Last confirmed by BifröstIndex bot on Jun 2, 2026.

Article 24 paragraph 1 FADP conditions the duty to notify the FDPIC on whether the data security breach "is likely to result in a high risk to the personality or fundamental rights of the data subject." This threshold determines whether the controller must report to the FDPIC; breaches that fall below the "likely high risk" bar need not be reported externally (though the controller must still log every breach in the Article 24(3) register). The FDPIC Guidelines on Data Breaches (published February 2025 and available at edoeb.admin.ch) provide detailed interpretative criteria and examples to guide controllers' risk assessments.

## Two-step risk assessment: harm already occurred + likely future consequences

When assessing high risk under Article 24(1) FADP, the FDPIC Guidelines state that "data controllers should firstly clarify the extent to which the data security breach that has occurred has already harmed the personality or fundamental rights of natural persons. Secondly, the criterion of 'likelihood' … requires controllers to include in their assessment the consequences of the data breach for the persons potentially affected, which can neither be conclusively measured nor can be predicted with certainty."

This framework requires controllers to evaluate:

  1. Harm that has already materialized — whether the breach has demonstrably injured the data subject's personality or fundamental rights (for example, unauthorized disclosure of health records has already resulted in third-party knowledge of the data subject's medical condition; stolen credentials have already been used to access the data subject's account).
  1. Likely future consequences that cannot yet be measured or predicted with certainty — whether the breach creates a substantial probability of future harm even if none has yet occurred (for example, credentials exposed in a breach have not yet been misused but are now available to attackers; personal data disclosed to unauthorized persons could be republished, used for identity fraud, or sold).

The Guidelines emphasize that "the level of harm to those most severely affected is what counts." The controller must assess the worst-case scenario for the individuals at greatest risk, not the average or aggregate risk across all affected data subjects. If even a small subset of the affected population faces a high risk of severe harm, the breach meets the Article 24(1) threshold.

## The role of post-breach measures: ex-ante vs. ex-post mitigation

Article 24 paragraph 1 FADP requires the risk assessment to be conducted "without taking into account measures that the controller only plans, announces or initiates after the data security breach," according to the FDPIC Guidelines. The controller may not credit reactive mitigation measures—steps the controller announces or begins implementing only after discovering the breach—when assessing whether the breach is "likely to result in a high risk."

However, the FDPIC's prior practice (which the Guidelines state the FDPIC continues to apply) permits controllers to credit immediate measures taken even before submitting the report in good time where these measures demonstrably excluded or minimised the anticipated effects of any personal data breach. The Guidelines give the example of "a controller [that] quickly regained control of personal data that had been made temporarily inaccessible by taking immediate measures and was able to establish with sufficient certainty within hours on the basis of logs or other evidence that the data had not been processed improperly." In such cases the controller may conclude that the breach does not meet the "likely high risk" threshold because the immediate containment demonstrably prevented harm.

The distinction is temporal and evidentiary:

  • Immediate containment before reporting — measures taken within hours (log analysis confirming no unauthorized access occurred; immediate revocation of exposed credentials; retrieval of data before third-party disclosure) may be credited if the controller can demonstrate with certainty that they eliminated the risk.
  • Reactive measures announced or initiated after the breach — password resets, breach notifications to data subjects, engagement of forensic investigators, patches deployed in response to the breach — do not reduce the "likely high risk" for purposes of the Article 24(1) reporting decision. The controller must assess the breach based on the risk at the time it occurred and was discovered, not the residual risk after mitigation.

The Guidelines warn that "in situations of doubt where a high risk cannot be sufficiently excluded, controllers" should report. The FDPIC interprets the statute to favor disclosure when the risk assessment is uncertain.

## Key risk factors: sensitivity of data and nature of harm

The FDPIC Guidelines identify several risk factors controllers should weigh when assessing the severity of harm. The following criteria increase the likelihood that a breach will be deemed high-risk:

Particularly sensitive personal data (Article 5 letter c FADP)

"If particularly sensitive personal data in accordance with Article 5 letter c FADP are affected, e.g. health data, biometric data or data on social assistance measures, a high risk must be assumed in many cases," the Guidelines state. Article 5(c) FADP defines particularly sensitive personal data as:

  • religious, ideological, political, or trade-union-related views or activities;
  • health, the intimate sphere, or racial or ethnic origin;
  • social assistance measures;
  • administrative or criminal proceedings and sanctions.

A breach involving any of these categories creates a presumption of high risk because disclosure or unauthorized access to such data threatens the data subject's dignity, autonomy, and fundamental rights (Art. 1 FADP protects the personality and fundamental rights of natural persons whose data are processed).

The FDPIC's list is illustrative, not exhaustive. Controllers should assess whether the nature and context of the data — even if not enumerated in Article 5(c) — creates a similar risk profile. For example, the Guidelines state that "a breach involving data that do not fall into this category, such as (copies of) identity documents or credit card details, can also pose a high risk."

Identity documents and financial credentials

The FDPIC Guidelines explicitly flag copies of identity documents (passports, national ID cards, driver's licenses) and credit card details as posing high risk even though they are not "particularly sensitive personal data" under Article 5(c) FADP. Unauthorized disclosure of these data enables:

  • identity fraud — opening accounts, applying for credit, or accessing services in the data subject's name;
  • financial fraud — unauthorized transactions using stolen credit-card numbers or banking credentials;
  • credential stuffing — using stolen usernames and passwords (or password hashes) to gain unauthorized access to the data subject's accounts on other platforms.

When a breach exposes identity documents, payment-card data, or authentication credentials, the controller should presume "likely high risk" unless immediate containment measures (see above) demonstrably prevented third-party access.

Volume and context: large-scale breaches and vulnerable populations

Although the FDPIC Guidelines do not establish a numeric threshold, the scale of the breach is a relevant factor. A breach affecting a large population increases both the absolute number of individuals at high risk and the likelihood that some subset will suffer severe harm. However, the Guidelines emphasize that the "level of harm to those most severely affected is what counts" — the controller must not dilute the risk assessment by averaging across a large, heterogeneous population. A breach affecting ten individuals may meet the "likely high risk" threshold if those ten individuals' particularly sensitive data were exposed.

The vulnerability of the affected population also matters. Breaches affecting children, elderly persons, persons with disabilities, or individuals in precarious circumstances (recipients of social assistance, asylum seekers, victims of domestic violence) may pose higher risk because these populations face disproportionate consequences from data misuse. The FDPIC has not published sector-specific guidance, but controllers should apply this principle when assessing breaches involving vulnerable data subjects.

Nature of the breach: unauthorized access vs. disclosure vs. loss

The type of incident under Article 5 letter h FADP affects the risk assessment:

  • Unauthorized access — personal data were accessed by unauthorized persons (cyberattack, insider snooping, misconfigured database exposed to the internet). High risk if the data were exfiltrated or if logs cannot confirm that access did not occur; lower risk if logs prove access was fleeting and no copying occurred.
  • Unauthorized disclosure — personal data were disclosed to unauthorized recipients (misdirected email, data published on the internet, shared with a processor without a valid controller-processor contract under Article 9 FADP). High risk if the disclosure is irrevocable (publication) or if the recipient is adversarial; lower risk if the recipient is trustworthy and has agreed to delete the data.
  • Loss or destruction — personal data were lost or destroyed (ransomware encryption, accidental deletion, theft of unencrypted device). High risk if the data are sensitive and the loss is permanent (no backups, no recovery possible); lower risk if backups exist and the data can be restored without unauthorized third-party access.
  • Modification — personal data were altered (database records tampered with, integrity compromised). High risk if the modification undermines the accuracy or reliability of data used for decisions affecting the data subject (financial records, health records, criminal-justice data).

Ransomware incidents warrant special attention. The FDPIC's position (reflected in enforcement practice, though not yet codified in published guidelines as of 2026-06-02) is that ransomware encryption constitutes a data security breach under Article 5(h) (data "lost" or "made accessible to unauthorised persons") and that controllers should presume "likely high risk" when sensitive data are encrypted by ransomware, because:

  • the attacker typically exfiltrates data before encrypting it (double-extortion model);
  • even if exfiltration cannot be confirmed, the encryption itself renders the data inaccessible to the controller and thus harms the data subject's rights (inability to exercise access, rectification, or erasure rights under Arts. 25–28 FADP);
  • threat actors commonly publish or sell exfiltrated data when the ransom is not paid.

Controllers facing ransomware incidents should conduct forensic log analysis to determine whether exfiltration occurred, but should report to the FDPIC under Article 24(1) unless logs affirmatively exclude data theft.

## Illustrative high-risk scenarios (FDPIC practice)

The FDPIC has not published a comprehensive list of per-se high-risk breach types. However, the Guidelines and enforcement decisions to date suggest the following scenarios typically meet the "likely high risk" threshold:

  • Health-data breaches — unauthorized access to or disclosure of medical records, health-insurance claims, prescription histories, mental-health records, genetic data, or disability records. Presume high risk.
  • Biometric-data breaches — fingerprints, facial-recognition templates, iris scans, voiceprints. Presume high risk because biometric identifiers are immutable and their compromise is permanent.
  • Credential breaches — usernames and passwords (plaintext or weakly hashed), API keys, OAuth tokens, session cookies. High risk if the credentials grant access to sensitive accounts or if credential reuse is likely.
  • Financial-data breaches — credit-card numbers, bank-account details, payment-card CVVs, account PINs. High risk because of fraud potential.
  • Children's data — any breach involving personal data of children (persons under 16, per the Swiss legal definition of capacity). High risk due to children's vulnerability and the heightened protection afforded under Article 6 paragraph 6 letter g FADP (processing children's data must be "particularly respectful of the welfare of the child").
  • Social-assistance and welfare records — data on receipt of unemployment benefits, disability benefits, housing assistance, or other social-support programs. High risk because disclosure stigmatizes the data subject and threatens dignity.
  • Criminal and administrative-proceedings data — records of arrests, prosecutions, convictions, or administrative sanctions. High risk because of reputational harm and because such data fall within Article 5(c) FADP "particularly sensitive" category.
  • Large-scale credential stuffing or account takeover — even when the underlying data are not particularly sensitive, a breach that enables unauthorized access to a large number of user accounts poses high risk.

Conversely, the following scenarios typically fall below the "likely high risk" threshold (and therefore do not trigger FDPIC notification under Article 24(1), though they must still be logged under Article 24(3)):

  • Misdirected email containing routine business contact information (names, work email addresses, job titles) sent to a trustworthy recipient who promptly deletes it and confirms deletion.
  • Temporary loss of access to non-sensitive data due to technical failure, where the controller restores access within hours, logs confirm no unauthorized third-party access occurred, and the data are not particularly sensitive.
  • Disclosure of pseudonymous or aggregated data that cannot be re-identified without disproportionate effort (though controllers should be cautious — technological advances reduce the effort required for re-identification, and the FDPIC applies a forward-looking assessment).

## Documenting the risk assessment

The controller must document its risk assessment for every data security breach, regardless of whether it reports to the FDPIC. The Article 24(3) breach register must include the controller's rationale for concluding that the breach did or did not meet the "likely high risk" threshold. During an FDPIC investigation under Articles 49–51 FADP, the FDPIC will scrutinize the controller's risk assessment and may conclude that the controller should have reported. A contemporaneous, evidence-based risk analysis is the controller's defense.

The risk assessment should identify:

  • the categories and approximate volume of personal data affected (e.g., "2,400 customer records containing names, email addresses, and plaintext passwords");
  • the sensitivity of the data (particularly sensitive under Art. 5(c)? financial credentials? identity documents?);
  • the nature of the breach (unauthorized access, disclosure, loss, modification);
  • the evidence of harm already occurred or likely to occur (logs showing exfiltration? data published online? credentials used for unauthorized account access?);
  • the measures taken before or immediately after discovery that reduced risk (immediate revocation of credentials? log analysis excluding unauthorized access? retrieval of data before third-party disclosure?);
  • the level of harm to the most severely affected individuals (worst-case scenario for the subset of data subjects at greatest risk);
  • the conclusion — likely high risk (report to FDPIC) or not (do not report, but log in Art. 24(3) register).

If the controller concludes that the breach is not likely to result in a high risk and therefore does not report to the FDPIC, that decision is reviewable. The FDPIC may, during a subsequent investigation, disagree with the controller's assessment and find that the controller violated Article 24(1) by failing to report. The documented risk assessment is critical evidence of the controller's good-faith compliance effort.

Source: FDPIC Guidelines on Data Breaches (February 2025), PDF pages 9–12 Source: Federal Act on Data Protection (FADP), Art. 24 Source: Federal Act on Data Protection (FADP), Art. 5 — definitions including "particularly sensitive personal data"

Spot something off?0 suggested edits