Workplace scenarios

These scenarios follow the patterns behind real reported breaches. For each one, decide what you would do before reading on.

Scenario 1: The wrong Sarah

On a busy Tuesday you email a spreadsheet of client contact details and payment histories to Sarah, and autocomplete picks a Sarah at a supplier instead of your colleague. You notice ten minutes later.

What good looks like: report it through the incident route straight away, then attempt a recall and contact the recipient to ask them to delete it and confirm in writing. Do not delete the sent email; it is evidence. Write a short timeline note while the details are fresh. Whether the ICO needs to be told is the response owner's decision, and every hour of delay is an hour off the 72-hour clock.

Scenario 2: The Friday evening laptop

A colleague's work laptop is stolen from her car at 5.30pm on Friday. She thinks it holds case notes about vulnerable service users, and she is not sure the disk was encrypted. She plans to report it on Monday.

What good looks like: report it that evening through the out-of-hours route. The 72-hour clock will not pause for the weekend, IT may still be able to trigger a remote wipe, and sensitive data about vulnerable people points towards a higher-risk assessment. By Monday morning, a large slice of the notification window would already be gone.

Scenario 3: The phished password

A team member enters their login details on a convincing fake sign-in page. Nothing looks wrong afterwards, and they are tempted to change their password quietly and say nothing.

What good looks like: treat this as a breach, not a near miss, because credentials were disclosed and access cannot be ruled out. Report it immediately so IT can force a reset, sign out all sessions, and check for anything the attacker left behind, such as mail forwarding rules. A quiet password change leaves any damage undiscovered and deprives the organisation of facts it may legally need.

Scenario 4: The Bcc that never was

A colleague sends a service update to two hundred external customers with every address visible in the Cc field. He argues that email addresses are not really personal data and wants to move on.

What good looks like: email addresses are personal data, and revealing them to every other recipient is a confidentiality breach. Report it, preserve the sent message and recipient list, and let the response owner assess the risk; the outcome depends on facts such as whether being on the list reveals anything sensitive about the recipients. Log it in the breach register whatever the assessment concludes, and expect the root cause fix to involve better tooling for bulk mail, not just a reminder to be careful.