Handling security incidents and personal data breaches

What counts as an incident

The definition is broader than people assume and does not depend on intent or on there being an attacker. Any unauthorised access, loss, alteration or disclosure of personal data goes into the analysis.

• System intrusion, ransomware or stolen credentials.
• An email sent with recipients visible to each other, or sent to the wrong person.
• A folder, link or file shared with open permissions by mistake.
• Loss or theft of a laptop, a phone or a paper file.
• An employee or former employee extracting customer or payroll databases.
• A breach at a provider processing data on the company's behalf.
• Information wrongly published on the website or on a platform.

The first hours

1. Contain. Close the access, revoke permissions, isolate the compromised system and stop anything still running.
2. Preserve. Capture technical evidence before it disappears, because what happened and when will have to be explained later.
3. Scope. Which data was affected, how many people, which categories, and whether sensitive data or children's data is involved.
4. Characterise. Determine whether the event is a reportable incident and how far it reaches.
5. Decide. Filing with the authority, notice to the affected individuals, and internal and external messaging, in that order and in writing.
6. Document. Record every decision and its reasoning, which is what later holds up the company's position.

We work alongside the technical team, not over it: they fix the cause, we define which obligations were triggered, what is said, to whom and when.

Filing with the authority and notifying individuals

The report to the Superintendence of Industry and Commerce goes through the channel provided for it, and its content matters: an incomplete or inconsistent report tends to open more questions than it closes. Notifying affected individuals is a separate decision, with a different audience and a different tone. We draft both texts and check them against what the company has already said internally, because versions that do not match are the most frequent problem.

Where the incident happened at a provider, the contract also has to be activated: what it had to report, within what time, what information it must hand over and who answers to the individuals affected. If the contract says nothing about any of that, the discussion with the provider becomes harder precisely when speed matters most, and the company still has to answer for the data it decided to collect.

Preparation is cheaper

• A written response protocol, with roles assigned by name rather than by generic job title.
• A decision tree to characterise the incident and to know who authorises each step.
• Baseline texts for the filing and the notice, drafted calmly rather than at two in the morning.
• Incident notification clauses in contracts with providers and processors.
• A short drill with the team that would have to run it, built on a realistic case from the business.

What the client receives

• Support throughout the incident, from the first call to the closing of the matter.
• The legal characterisation of the event and a reasoned decision on filing and notification.
• The texts filed with the authority and those sent to the affected individuals.
• The incident file: chronology, decisions, evidence and owners.
• The remediation plan afterwards, which is the first thing the authority asks about if it revisits the case.

Typical situations we handle

• A company that sent a mass communication with every customer's email address on display.
• A business hit by ransomware that does not know whether to report or whom to notify.
• A company whose cloud or payroll provider suffered a breach affecting its employees.
• An employer that discovers a former employee downloaded the customer database before resigning.