Non-sensitive data, they said: why the Salt breach means calls for you

In its notice the Prilly-based company said the incident concerned certain personal, non-sensitive data of Salt Mobile SA customers. Sensitive data such as passwords, banking details and customer history could not be affected, according to the operator.

The list of what may have been exposed was given plainly: first name, surname, postal address, mobile phone number, date of birth and email address.

The columnist's argument is that the definition of sensitive data is broader than the habitual one. Card data, biometrics and medical records are the obvious examples. But information that looks innocuous can be extraordinarily valuable, because it lets attackers run targeted campaigns.

The difference between a mass mailing and a targeted attack lies in the details. A letter or call that already knows your name, exact address, date of birth and the number your plan is tied to does not look like fraud. It looks like your operator getting in touch.

The playbook has been documented for years, and every step relies on the supposedly harmless fields.

• Phishing and calls in the operator's name: the details confirm the story, then a code from an SMS or an app install is requested.
• SIM swap: the number, date of birth and address are often the very details used to confirm identity.
• Account recovery elsewhere: an email plus a date of birth answers part of the security questions.
• Correlation with earlier breaches: one email address links records across databases and completes the profile.

If your site has an enquiry form, a customer account or a CRM with a contact history, you are in the same position as the operator, only smaller.

• List every field you ask for and delete the ones the process works without. A date of birth is rarely needed in a website enquiry form.
• Set a retention period. Three-year-old enquiries sitting in the same table as fresh ones only increase the damage.
• Separate storage: contacts in one place, purchase history in another, with joining them a granted right rather than a default.
• Write down what you will tell customers during an incident and keep the text ready. The phrase "non-sensitive data" produces exactly the reaction Salt received.
• Check who else has access: contractors, integrations, exports into mailing tools. Leaks usually happen at the periphery.

There is no point changing a password that did not leak, but caution about incoming contact pays off. Any call or message where the other side knows details about you deserves a callback to the number on the official site. Adding extra confirmation for operations in the operator account helps, and replacing SMS as a second factor with an authenticator app helps more.

The argument about wording is not academic. Calling a breach non-sensitive lowers customers' guard at the exact moment they would benefit from raising it. It is more honest to say what leaked and explain which schemes are now likely.