Data breach in your online store: what to do in 72 hours

What a data breach is

Under the GDPR, a personal data breach is a breach of security leading to the accidental or unlawful destruction, loss or alteration of personal data, or its unauthorized disclosure or access. In an online store, the typical cases are:

• A skimmer on the checkout copying cards, names and addresses (how to detect one).
• An attacker who has accessed the customer and order database, even if you do not know whether they downloaded it.
• A vulnerable module or plugin that exposed customer or order data to anyone.
• A database backup left publicly accessible on the server.
• Ransomware that encrypts the store and makes the data inaccessible, even if it does not take it.

The 72 hours: when they start and what they require

Article 33 of the GDPR says the controller (you, as the store owner) shall notify the breach to the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless it is unlikely to result in a risk to the rights and freedoms of people. Four important details:

• The 72 hours run from when you become aware, not from when the cleanup ends or when you know every detail.
• If you do not make it in time, you can notify later, but explaining the reasons for the delay.
• If you do not have all the information, you can provide it in phases: a first notification and additions later.
• Even if you decide there is no risk and do not notify, you must document the breach (what happened, its effects and the measures taken). That documentation is what shows you assessed it.

If your agency, your hosting provider or your developer runs the store and detects the breach, they are processors and must tell you without undue delay. Notifying the authority is your job.

Which authority: if you are established in the EU, the one of the country where you have your only or main establishment (the EDPB lists every national authority: the DPC in Ireland, the AEPD in Spain, the CNIL in France…). If you have no establishment in the EU but sell to people there, you deal with the authority of each EU country where there are affected people. A UK business reports to the ICO under the UK GDPR.

Hour 0 to 24: contain it and find out what happened

1. Stop the leak: disable the affected payment method, put the store in maintenance mode or block the access the attacker is using.
2. Keep evidence before cleaning: a full copy of files, database and server logs. Many hosting providers only keep logs for a few days.
3. Change credentials: back office, hosting, database, payment provider.
4. Write down the time you became aware and everything you learn, with dates. It is the start of the record Article 33 requires.
5. Tell your payment provider or bank if cards are involved.

Hour 24 to 48: assess the risk

With the technical work under way, it is time to answer the questions the notification asks: what data (identity, contact, payment, passwords), roughly how many people, since when and with what possible consequences. You do not need to have everything settled to notify.

Several authorities publish free self-assessment tools that walk you through the decision with questions: in the UK, the ICO's self-assessment and breach reporting page; in Spain, the AEPD's Asesora Brecha (in Spanish). Look for your own authority's equivalent. They are aids, not rulings: whether to notify is still the controller's decision.

As technical guidance: theft of card data, passwords or data that lets someone impersonate a person will almost never be “unlikely to result in a risk”. Neither will an exposed customer database.

Hour 48 to 72: notify the authority

Notification is usually done online with your authority's form: for example, the ICO's report a breach page in the UK, or the breach form on the AEPD's e-office in Spain. Under Article 33(3), it must include at least:

• The nature of the breach, with the categories and approximate number of people and records affected.
• The name and contact details of the data protection officer or another contact point.
• The likely consequences.
• The measures taken or proposed to address it and mitigate its effects.

Notifying does not automatically lead to a fine. Authorities such as the AEPD point out that notifying properly and on time shows diligence, while not notifying when you had to is an infringement in itself.

What to tell your customers

Article 34 of the GDPR requires communicating the breach to the people affected, without undue delay, when it is likely to result in a high risk to them.

The GDPR asks for clear and plain language. Data protection authorities recommend a message addressed to the people affected, preferably directly (email, phone, text message or post), and include at least:

• Contact details of the data protection officer or a contact point.
• A general description of the incident and when it happened.
• Its likely consequences.
• Which data is affected.
• What you have done so far to limit the damage.
• Recommendations so they can protect themselves: for example, telling their bank and watching for charges if cards are involved, changing their password if they reused it elsewhere, and being wary of emails that use their order details.

Article 34(3) lists cases where you do not need to tell them: if the data was protected so as to be unintelligible to anyone not authorized (for example, encrypted), if you have taken measures that remove the high risk, or if it would involve disproportionate effort, in which case it is replaced by an equally effective public communication.

The technical side you need

To notify properly you need a technical report that answers, with evidence:

• How they got in (the vulnerable module or plugin, the stolen credential) and since when they had access.
• What data was within reach: which tables, which fields, whether there was card data (a properly built store should not store it) and how many records.
• What was taken or could have been taken: access logs, database requests, scripts that sent data out and to which domain.
• What has been done: cleanup, closing the way in, changing credentials, measures so it does not happen again.

If you still do not know whether the store is compromised, the free scan is a first filter from the outside, although it does not replace a check from the inside: that is what the website security audit is for, reviewing files, database and users with a read-only connector. The technical report is what I deliver at the end of a hacked PrestaShop cleanup or a WooCommerce store cleanup, written so your lawyer can use it in the notification. The technical cleanup steps are in what to do if your PrestaShop is hacked and how to recover a hacked website.

Other notifications

• Payment provider or bank: if cards are involved, they have their own procedures and may require an investigation.
• Police report: if there has been data theft or fraud, you can report it to the police or to your country's cybercrime reporting service.
• Your national cybersecurity agency: in the US, CISA takes incident reports; in the UK, the NCSC; in Spain, INCIBE runs the free 017 helpline. They do not clean your store, but they can guide you and use your report to warn others.

Outside the EU: the UK, the US and other countries

For US stores, the FTC's Data Breach Response: A Guide for Business notes that all states, the District of Columbia, Puerto Rico and the Virgin Islands have breach notification laws, and that what the notice must say varies from one to another. Other countries have their own law and authority, so use this table as a starting point for your search.

If you need the technical side

If the breach comes from the store being hacked, cleaning up PrestaShop or WooCommerce costs €349 excluding VAT ($349 outside the EU) and includes guidance on the notification and a report of what was there, since when and what was done. Prioritized over other work: +€100. The cleanup comes with a 90-day guarantee. More in hacked PrestaShop repair, WordPress malware removal (WooCommerce is a WordPress plugin) and WooCommerce security.

Sources

• Regulation (EU) 2016/679, GDPR, Articles 33 and 34 (EUR-Lex, English text).
• EDPB: members, the national data protection authorities of the EU and EEA.
• ICO: personal data breaches, self-assessment and reporting (UK).
• FTC: Data Breach Response, A Guide for Business (US).
• AEPD: notifying personal data breaches to the supervisory authority (Spain; in Spanish).
• AEPD: communicating personal data breaches to the people affected (Spain; in Spanish).
• AEPD: Asesora Brecha (Spain; in Spanish).