Telling customers about a data breach by text

If a personal data breach is likely to put people at high risk, the UK GDPR says you must tell them, directly and "without undue delay". That's article 34. It sits beside a separate duty in article 33 to report the breach to the regulator within 72 hours of becoming aware of it, where feasible, unless it's "unlikely to result in a risk" to anyone. The ICO's guide to personal data breaches explains why the first duty exists: "One of the main reasons for informing individuals is to help them take steps to protect themselves from the effect of a breach."

A text is often the fastest way to reach the people affected, because it lands on the phone they carry. It's also exactly the channel criminals use after a breach. The NCSC warns that criminals "may even send messages pretending to be from an organisation that has suffered a recent data breach". So a breach text has two jobs at once: carry what the law requires, and be easy to check as genuine.

When do you have to tell people?

Article 4(12) defines a personal data breach as "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data". Then there are two thresholds, and the second is higher than the first.

Reporting to the regulator is triggered by risk. Article 33(1) says the controller notifies "unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons". Telling the people themselves is triggered by high risk: article 34(1) applies "When the personal data breach is likely to result in a high risk". The ICO's guide gives examples either side of the line. A hospital that accidentally discloses patient records has to tell the patients. A university whose staff member deletes alumni contact details, which are then re-created from a backup, doesn't need to tell anyone, and the guide adds that you "would not normally need to notify the ICO" about "the loss or inappropriate alteration of a staff telephone list".

Article 34(3) lists three ways out of telling people individually: the data was protected by measures such as encryption that "render the personal data unintelligible" to anyone unauthorised; later steps mean the high risk "is no longer likely to materialise"; or contacting everyone "would involve disproportionate effort", in which case there must be "a public communication or similar measure" instead. And article 34(4) lets the regulator require you to tell people if it disagrees with your assessment. Whatever you decide, write it down. Article 33(5) says the controller "shall document any personal data breaches", including the effects and the remedial action, and the ICO's guide says that if you decide not to report, "you need to be able to justify this decision".

How tight are the 72 hours?

Article 33(1) gives the deadline as "without undue delay and, where feasible, not later than 72 hours after having become aware of it", and a late report "shall be accompanied by reasons for the delay". Since 30 September 2026 the article has named the Commission as the body to notify, the Information Commission having taken over from the ICO; the guidance quoted here is still the ICO's, on the ICO's website. The ICO accepts that you won't know everything in three days. Article 33(4) lets you provide information "in phases without undue further delay", and the guide's advice is to report within 72 hours, say what you don't yet know, and give a date for the rest. If your SMS provider or any other processor has the breach, article 33(2) requires it to tell you "without undue delay after becoming aware".

The ICO's incident-level data shows how often organisations miss the window.

In calendar year 2025, by our count of the ICO's data, 8,531 of the 13,456 breach reports were made within 72 hours of discovery and 4,925 took longer, 2,557 of them more than a week. The ICO cautions that its system records midnight where it's given a date but no time, so some reports that were on time show as late. Taken at face value, that's more than a third of reports arriving after the deadline. Failing to report a notifiable breach can bring a fine of "up to £8.7 million or 2 per cent of your global turnover", in the guide's words.

How many breaches does the ICO see?

The ICO's annual report for 2025/26 counts 17,431 breach reports received, up from 12,412 the year before, "an increase of 40%". It notes that the July to September quarter alone brought over 6,000 reports, "a significant number of which related to a single incident, with each affected organisation submitting their own report". The highest reporting sectors remained health, education and childcare, and the most common kind of incident was "sending personal information to the wrong person by email, post or fax", at just over 20% of breaches. (The incident-level download counts 13,456 reports for calendar 2025. It runs on calendar years, and the ICO says it leaves out cases transferred to a separate system for review.)

What does the message have to say?

Article 34(2) says the communication must "describe in clear and plain language the nature of the personal data breach" and contain at least three things from article 33(3): the name and contact details of a contact point "where more information can be obtained", the "likely consequences of the personal data breach", and the "measures taken or proposed to be taken" to deal with it, including steps to mitigate its effects.

The ICO's guide adds that, where possible, you "should give specific and clear advice to individuals on the steps they can take to protect themselves, and what you are willing to do to help them". Its examples are "forcing a password reset", "advising individuals to use strong, unique passwords" and "telling them to look out for phishing emails or fraudulent activity on their accounts".

That won't fit in 160 characters, and it doesn't have to. The text is the alert. The full notice, with everything article 34(2) asks for, can live on a page of your own website, in an email or in a letter, and the text tells people where to find it. What the text itself should carry is the minimum someone needs to act: who it's from, what happened in a sentence, what kind of data was involved, what to watch for, and how to reach you through a route they already trust.

Why a breach text can look like a scam

The NCSC's guidance for individuals on data breaches describes the scam a genuine notice has to avoid resembling. "In a typical scam, you might receive a message claiming to be from an organisation that has suffered a recent data breach. The message could ask you to log in and verify your account because 'fraudulent activity has taken place', or similar." The links lead to "websites that look genuine, but which store your real details once you've typed them in".

Its advice to the public follows from that, and your customers may well have read it. Find out if you've been affected "by contacting the organisation using their official website or social media channels. Don't use the links or contact details in any messages you have been sent." It tells people to watch for "official-sounding messages about 'resetting passwords', 'receiving compensation', 'scanning devices' or 'missed deliveries'" and for "being urged to act immediately or within a limited timeframe". It also warns that scam messages "may be sent some time after the breach is made public", and that if phone numbers were stolen, people "might receive a suspicious call".

Read that list as a specification and the shape of a genuine breach text is fairly fixed. Send it from the sender name or number customers already know. Don't include a link that asks anyone to log in, and don't ask for anything back. Point people to your website by its name, so they can type it themselves or use a bookmark, and to a phone number already printed on your letters. Say plainly what you will never ask for. Keep the tone level: urgency is the thing the NCSC tells people to distrust. Our posts on links in texts and what scam texts copy go into the detail.

A worked example

Say a hypothetical dental practice in Leicester finds that someone got into its booking system and copied patients' names, phone numbers and appointment times. No payment or medical records were involved, but those patients could now get convincing scam calls and texts, so the practice decides the risk to them is high. A first text might read:

Example Dental: someone accessed our booking system on 14 Oct and saw patient names, phone numbers and appointment times. No medical or payment details. Expect possible scam calls or texts using your name. We will never ask for bank details or passwords by text or phone. Full details: the News page at example.co.uk, or call 01632 960123.

That's 339 characters, so it goes as three parts (our character limit guide explains the sums), and for a message like this the extra parts are money well spent. It names the practice first, says what happened and what data was involved, gives the likely consequence, says what the practice will never ask for and offers two routes to more information without a link. The full notice on the website then covers the rest of article 34(2): the contact point, what has been done to secure the system and what patients can do.

A second text, a week or two later, can say what has changed. It should come from the same sender and follow the same pattern, and that consistency is what makes it believable.

Sending it to the right people

A breach notice is a service message, so the marketing rules on consent don't apply and STOP lines aren't needed. The accuracy and security rules still do. Send only to the people affected, because a notice to everyone on the list tells people their data was exposed when it wasn't. Keep a record of who was sent what and when, and whether it was delivered, because article 33(5) documentation is what the regulator will ask for. And expect replies. The ICO warns that after a breach "an organisation may experience a higher volume of data protection requests or complaints, particularly in relation to access requests and erasure", and those requests still run to their usual deadlines.

CaptiFi Connect brings replies into a two-way inbox, keeps a delivery report for every text, imports the affected list from CSV, and has staff review sender names before they're used, so a breach notice can go out under your own business name instead of an unfamiliar number. The delivery reports page shows what's recorded. The record of who was told, and when, belongs in the breach log alongside the decision to tell them.