Email sent to the wrong recipient: is it a data breach?

Email sent to the wrong recipient: is it a data breach?

An email sent to the wrong recipient is a data breach under the Swiss FADP when personal data leave your control to someone who should not see them. That alone is a security incident. You must report it to the FDPIC only if a high risk for the people concerned is likely. In Switzerland the clock is “as fast as possible”, not 72 hours like the GDPR. You still document what happened even when you do not report.

This guide is for owners, HR and the person who handles IT in a Swiss company with about 20 to 250 staff. You may have just heard “I sent the payslip to the wrong person” or “the attachment had last year’s customer list”. It is practical orientation, not legal advice.

• Wrong personOften yes

  Personal data disclosed to someone without a need to know counts as a breach.

• FDPIC reportHigh risk

  Only when a high risk for data subjects is likely (Art. 24 FADP).

• DeadlineAs fast as possible

  Swiss law, not a fixed 72-hour EU rule.

• BACS cyber dutyUsually no

  Critical infrastructure reporting is separate from FADP breach rules.

When a wrong email is a breach and when it is not

A breach is a breach of security that leads to accidental or unlawful loss, disclosure or access to personal data. Typing the wrong name in Outlook, choosing the wrong thread, replying to all instead of one person, or attaching the wrong file can all do that. If the message contained only internal lunch plans with no personal data, data protection law may not be engaged. If it contained names, salaries, health notes, customer files or applicant CVs, assume you are in breach territory until someone competent says otherwise.

Password-protected PDFs change the risk picture but do not erase the incident. If only your firm could read the file and the wrong recipient could not guess the password, risk may stay low. If the mail was readable on a foreign phone, or the password sat in the same thread, treat it more seriously.

Typical mix-ups in daily office work

Outlook and webmail autocomplete often suggest the last contact with a similar name. Private and business addresses sit side by side. A colleague named “Mueller” and a customer “Mueller Ltd” look the same in the dropdown until someone checks the domain.

Forwarding rules are a second risk. Mail lands with the wrong recipient because a mailbox forwards everything to an assistant who is not on the project. Shared mailboxes (“info@”, “hr@”) also make it hard to tell later who saw the data.

If EU customers or employees in the EU are involved, the GDPR may apply on top. The Swiss “high risk” threshold and EU deadlines are not identical. For a purely internal error in Zurich, follow the FADP first. For data about people in the EU, a second assessment with counsel is often worth it, without delaying containment.

Does every mistake require a report to the FDPIC?

No. The FDPIC guide on reporting security breaches states that the controller notifies the FDPIC when a high risk for the personality or fundamental rights of the data subjects is likely. Examples that often push toward reporting include sensitive health data, large lists of customers or employees, financial identifiers combined with names, or a recipient you cannot reach or trust to delete.

A one-line mail to a colleague with a customer’s first name only may stay below the threshold. A spreadsheet with 200 debtors sent to a competitor’s domain usually does not. Borderline cases need a short written risk note and often external advice.

Do affected people have to be informed?

Not always. Art. 24 FADP requires informing affected people when that is needed to prevent damage, or when the FDPIC orders it. In practice: inform when the person should act (change a password, block an account, watch for fraud) or when they cannot limit the damage without a hint. If the recipient cooperates, the data are deleted, and no misuse is plausible, information can still be sensible but is not a duty in every small case. When in doubt, write down your reasoning.

What to do in the first hour

1. Stop the spread

   Ask the sender to recall if your system allows it. Phone the wrong recipient if you know them. Ask them to delete without forwarding and to confirm in writing.

2. Contain the mailbox

   Check whether the message was auto-forwarded, saved to a local file, synced to a private device, or caught by archive rules.

3. Describe the data

   Which categories, how many people, whether especially sensitive data, passwords, or access details were included.

4. Log the facts

   Time, sender, intended recipient, actual recipient, systems involved. You need this for documentation even if you do not report.

5. Decide on FDPIC notification

   If high risk is likely, prepare a report via databreach.edoeb.admin.ch as fast as possible. Inform affected people when they must act.

Do not wait for a perfect investigation before you stop further disclosure. You can update the log when you learn more.

What this is not

It is not the same as reporting phishing to BACS. Fraud and malware have their own paths. It is not the April 2025 cyberattack reporting duty for critical infrastructure operators, which most SMEs do not have. It is also not a reason to punish the employee in public before you understand whether training or process failed.

German blog posts that mention GDPR fines in euros or a strict 72-hour deadline describe EU law. Swiss companies still follow the FADP first, and may also follow the GDPR when they target people in the EU.

Who can skip a formal playbook

A five-person firm that mis-sent a single appointment time to the wrong internal address and fixed it in minutes may only need a one-line log entry. A regulated office with health or legal data should treat every wrong attachment as serious until reviewed.

A made-up example: payroll in the wrong thread

A made-up example: a services firm near Bern with 45 staff. On Thursday morning HR sends payslips as PDFs. Autocomplete picks an external consultant who once used the same surname as an employee. The consultant opens the mail on a phone before HR notices. HR calls within twenty minutes, the consultant deletes the mail and sends a short email confirmation. The PDFs contain AHV numbers and gross pay. Management writes a half-page risk note: special category not involved, but financial identity data for twelve people, recipient known and cooperative, no evidence of forwarding. They document internally, notify the twelve employees the same day with a dedicated contact, and file an FDPIC report the next morning because a high risk of misuse is still plausible if the phone were compromised. They schedule a data protection session for HR on safe sending rules.

The story is invented. The sequence is what auditors ask for: contain, assess, document, notify if needed, fix the process.

Internal documentation either way

Art. 15 para. 4 of the Data Protection Ordinance expects you to record breaches, including those you do not report, with facts, effects and remedial measures, and to keep that record for at least two years from notification or from when you decided not to notify. A simple table is enough: date, data types, count, cause, decision on FDPIC, actions taken.

Reduce repeats without blaming individuals

Train people on autocomplete, Bcc versus To, and checking attachments. Use role-based access so payroll exports are not available to everyone. For large files, use a link with access control instead of a static attachment. These points fit a live data protection session for staff; see data protection awareness training for what Aurum covers in one to two hours after a short needs conversation.

If you are comparing providers for security training as well, our note on choosing a security awareness provider explains how live sessions differ from tests alone.

The full FDPIC reporting path is in report a data breach to the FDPIC. For staff training on everyday handling of personal data, data protection awareness training walks through DSG and GDPR in daily work, breach awareness and safe sharing.