Skip to content
../services/security

RISK · DATA BREACH

Preventing data breaches

The data you do not keep is the data that cannot leak.

What it is

A breach does not always involve a sophisticated intrusion. A cloud storage bucket left open, a database exposed without a password, a former employee whose access was never closed, a client file sent to the wrong address: most of the breaches we see come from there. The harm, however, is identical — loss of trust, notification obligations and sometimes lost contracts.

How data actually gets out

  1. 01

    Accidental exposure

    A storage service made public to unblock someone, an admin interface reachable from the internet, a test database filled with real customer data.

  2. 02

    Access that should have been closed

    Employee departures, finished contractors, service accounts created for a project and never disabled.

  3. 03

    Uncontrolled copies

    Exports to a spreadsheet, sends to a personal mailbox, backups on unencrypted media.

  4. 04

    Late discovery

    The breach is often reported by a third party — a researcher, a client, a journalist — rather than detected internally.

The signals that should raise a flag

These situations do not prove a breach happened, but they show nothing would prevent one.

  • Nobody can say precisely what personal data you hold
  • Full exports of the customer base circulate as spreadsheets
  • Former employees’ accounts still appear in your tools
  • Test environments contain real data
  • No alert exists for bulk downloads

The layers that genuinely limit the risk

01

Minimisation and retention limits

The most effective measure remains not keeping what you no longer need. It is also a direct obligation under privacy law.

02

Compartmented access

Each person accesses what their role requires, and nothing more. Broad "for convenience" access is the most frequent cause of exposure.

03

Encryption at rest and in transit

An encrypted file that leaves remains unreadable. It does not remove the duty to notify, but it radically changes the actual harm.

04

Periodic account review

A quarterly access review catches forgotten departures, finished contractors and orphaned service accounts.

05

Detection of abnormal exports

A bulk download at three in the morning or from an unusual country should raise an alert.

If a breach is confirmed

Privacy law requires keeping a register of confidentiality incidents and, in some cases, notifying. These steps are prepared before you need them.

  1. 01Close the affected access and preserve the logs before they are overwritten
  2. 02Determine precisely what data left, and over what period
  3. 03Assess the risk of serious harm, which governs the duty to notify
  4. 04Record the incident in the register, whether or not notification is required
  5. 05Notify the affected individuals and the regulator if the threshold is met

Five questions to place yourself

These are the questions a client or an insurer will eventually ask you.

  • Can you list the places where personal data sits?
  • Do you know how many active accounts belong to former employees?
  • Do your test environments use anonymised data?
  • Is there a retention period defined and actually applied?
  • Do you keep a register of confidentiality incidents?

What we put in place

A breach is prepared for beforehand, not at notification time.

We map where your personal data genuinely sits and who can reach it today.

Map our data