Security, and what a breach means

Field 01The controls a competent operator runs

The security of your account data rests on a small set of well-understood controls. Passwords are stored hashed, not in plain text. Data is encrypted in transit and usually at rest. Access is limited by role, so only the staff who need a record can open it. Activity is logged and monitored, so unusual access is detectable. Data is minimised, so less is exposed if something fails. And the operator runs access reviews and tests its defences. None of this is exotic; it is the baseline a licence generally requires, and a privacy notice or security page should describe it at least in outline.

Field 02Passwords are stored hashed, and you can test the claim

When you set a password, a competent operator stores a hash of it: a value computed by a one-way function, with a per-account salt and a deliberately slow algorithm, so that the stored value cannot be turned back into the password even if it leaks. This is why the operator can reset your password but should never be able to tell it to you. There is a simple test of the claim: a service that can email you your own password in plain text is storing it recoverably, and that is a red flag about the rest of its security. If you want to know what is held, an access request returns the categories of data; the password itself is not something the operator can produce.

Field 03What a personal-data breach actually is

A data breach is any security incident leading to accidental or unlawful destruction, loss, alteration or unauthorised disclosure of personal data — not only a hacker emptying a database. It includes the obvious case of data exposed to the wrong people, and the less obvious ones: a misconfigured storage bucket, a laptop lost with data on it, an insider who reads records they should not, or records altered by a fault. The scale and the sensitivity of what was affected decide how serious it is, and the assessment is the operator’s to make — and to justify if it gets it wrong.

Field 04The notice you should get, and when

Under the general model, an operator must notify its data-protection authority within a short window — commonly 72 hours — of becoming aware of a breach likely to risk people’s rights, unless the breach is unlikely to result in a risk. Where a breach is likely to result in a high risk to you, it must also tell you without undue delay. A good notice says what happened, what categories of data were involved, what the likely consequences are, what the operator is doing and what you can do — and names a contact. A notice that is vague about what leaked, or silent, is the version worth chasing and, if need be, reporting.

Field 05What to do when a breach notice reaches you

Move on the accounts the leaked details touch, not only the one that told you. Change the password on the breached account and on any account where you reused the same email and password, and turn on a second factor. Expect phishing that quotes the breached details convincingly, because the leak is what makes the message credible. If the notice is thin, ask the operator’s data-protection contact the specific questions — what categories, what consequence, what they are doing — and if the answers do not come, the data-protection authority in your country is the route. The financial risk on a gambling account is real, so treat a leaked payment detail as urgent.

• Change it here and everywhere reused The same email/password pair elsewhere is the real exposure.
• Turn on a second factor The cheapest control that survives a leaked password.
• Expect targeted phishing A leak makes a phishing message credible; treat unexpected links with suspicion.
• Ask the specific questions Categories, consequences and remedies — and escalate if unanswered.