What counts as a personal data breach
A personal data breach is a breach of security that leads to personal data being accidentally or unlawfully destroyed, lost, altered, disclosed or accessed. It is not only an attack. Sending a file to the wrong person, giving a user the wrong permissions, losing a laptop, or data becoming unavailable when it is needed can all be breaches.
This procedure also covers security incidents that put personal data at risk even if no data was reached. We record those too.
Our two roles
For most data in the Service, the agency is the controller and we are its processor. Article 33(2) of the UK GDPR requires us to tell the agency without undue delay after we become aware of a breach. The agency then decides whether to report to the Information Commission (the ICO) within its own 72 hours and whether to tell the people affected. We give it what it needs to do that.
For our own business data, such as agency contacts, users' sign-in details, website enquiries and billing records, we are the controller. We decide whether to report to the ICO and whether to tell the people affected.
The Director leads every incident. If the Director cannot be reached, the contractor who found the incident starts containment and keeps trying to reach the Director.
How to report a suspected breach
Contractors: tell the Director straight away by phone, then confirm by email. Do not wait to be sure, and do not investigate beyond what is needed to stop harm.
Agencies, users and anyone else: email terry@hilliernet.co.uk or call 07789 938284. Outside working hours, email and put URGENT in the subject line.
Say when you noticed the problem, what you saw and what you have done. Keep any evidence, such as the email sent in error.
The procedure, step by step
The clock starts when we become aware of a breach, which means when we are reasonably sure that a security incident has affected personal data. We record that moment, because every deadline below runs from it.
- Step 1. Detect and record (at once). Whoever finds the incident tells the Director. The Director opens an entry in the breach log with the time we became aware, what is known so far and who is involved.
- Step 2. Contain (within hours). Stop the harm: end affected sign-in sessions, reset passwords, suspend accounts, withdraw access, ask a wrong recipient to delete what they received and confirm they have, correct the setting at fault, or roll back to the previous release. If data has been lost or damaged, restore it from the last checked backup. Keep logs and audit trail entries as evidence.
- Step 3. Assess the risk (within 24 hours of becoming aware). Establish what data is involved, whose, how many people and records, which agencies, and whether it includes identity documents, right-to-work evidence, criminal-record certificates, health information, bank details or other sensitive data. Decide how likely and how serious harm to people could be: unlikely to be a risk, a risk, or a high risk.
- Step 4. Tell each affected agency (without undue delay, and within 24 hours of becoming aware). We tell the agency by email and by phone even if we do not yet have all the facts, so that it can meet its own 72-hour duty to the ICO. We say what happened, the kinds of data and roughly how many people and records are affected, the likely consequences, what we have done and will do, and who to contact. We send updates at least once every working day until the breach is contained, and straight away when we learn anything significant.
- Step 5. Report to the ICO where Templace is the controller (within 72 hours of becoming aware). If the breach affects data we control and is likely to result in a risk to people's rights and freedoms, the Director reports it to the ICO through ico.org.uk. If we do not yet have every detail, we report what we know and send the rest in stages. If a report is late, we give the reasons.
- Step 6. Tell the people affected where the risk is high (without undue delay). For our own data, we tell each person directly, in plain language, what happened, what it may mean for them, what we have done and what they can do to protect themselves. For agency data, the agency decides and tells its people under its own name; we help with lists of those affected, the facts and the wording.
- Step 7. Keep the breach log (throughout). Every breach is logged, including those we decide not to report: the facts, the effects, what we did, what we decided and why, with times and dates. Article 33(5) of the UK GDPR requires this record, and the ICO may ask to see it.
- Step 8. Review (within 20 working days of containment). The Director finds the root cause, decides what to change, and checks that the change works. Where the fix is in the software, a test is added so that the fault cannot return unnoticed. Each affected agency receives a written summary.
Entering an agency's system during an incident
A security incident is one of the reserved grounds on which we may enter an agency's system without an invitation. Every entry is recorded in the agency's audit trail against the named Templace person, and the agency is emailed. We look only at what the incident requires.
What agencies should do
Agencies have duties of their own. If a breach happens in your use of the Service, for example a user sends a candidate's documents to the wrong client, you are the controller and must decide whether to report it. Tell us if the Service was involved or if you need our help, for example to end sessions, check the audit trail or restore data.
Keep our contact details in your own breach plan, and tell us who at your agency should receive our breach notices.
Keeping this procedure current
The Director reviews this procedure at least once a year and after every breach review. Contractors read it when they start and whenever it changes.
Personal data breach and incident response · version 1.0 · approved 27/10/2026 · next review 27/10/2027. Templace is a trading name of TWH Holdings Limited, company number 10663539, Meadway, Mill Road, Writhlington, Radstock, BA3 5TY.