Letting agency data breaches: a 72-hour response workflow

A letting agency that discovers a possible personal data breach should open an incident log, record when it became aware, appoint a response lead and contain the problem without destroying useful evidence. It should then assess the likely risk to people. A breach that is likely to risk their rights and freedoms must be reported to the Information Commissioner's Office (ICO) without undue delay and, where feasible, within 72 hours of awareness. Every personal data breach needs a record, including one the agency decides not to report.

The 72 hours are not a waiting period. They are the outer reporting window for a notifiable breach, and the clock starts when the organisation becomes aware of it rather than when the incident first occurred. The response should run as one managed case: protect people, establish the facts, make the risk decision and keep updating the record.

Recognise what counts as a personal data breach

A cyberattack can cause a breach, but hacking is not required. ICO's personal data breach guide defines a breach as a security incident leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. It can affect confidentiality, integrity or availability.

Examples in a property operation include emailing an applicant's identity documents to the wrong person, losing access to repair records during an outage, altering a tenant's bank details without authority, exposing guarantor information through a supplier, or leaving a former employee's account active. A mistaken email may be contained quickly and still needs assessment and a record. A system outage may be a personal data breach even if nobody outside the agency saw the information. ICO's first 72 hours guide says to start a log even if the incident may not need to be reported.

Use one response route for staff and suppliers

Staff need a simple route for reporting a mistake or suspicious event immediately, without first deciding whether it is serious enough for ICO. The incident lead can then bring in the right people from operations, data protection, IT, the relevant branch and any affected supplier. ICO's audit framework supports documented escalation, internal timescales and clear criteria for assessing severity and high risk.

If a technology provider processes information for the agency, the processor must notify the controller without undue delay after becoming aware of a breach. The contract should explain how the provider will assist. Confirm who will supply the facts, preserve logs and implement containment. Do not assume the supplier will make the agency's ICO decision or submit the notification for it.

Contain the incident without losing the trail

Choose containment for the incident rather than applying a generic shutdown. The first actions might include disabling an exposed account, ending sessions, changing credentials, restricting a shared folder, isolating a device or asking an unintended recipient to delete or return a message. Where supported, remote wiping may help. Record each action and result. Preserve relevant messages, access logs and configuration details before routine retention or cleanup removes them.

Containment can reduce the risk, but it does not erase the event. Confirm whether an unintended recipient opened, copied or forwarded the information, and whether deletion can be evidenced. Check connected systems and delegated accounts rather than focusing only on the screen where the problem appeared.

For supplier incidents, identify the legal entity and service affected, the time it became aware, the tenants, landlords, applicants, guarantors or staff involved, and the provider's immediate controls. Our AI supplier data checklist explains the contract and data-route evidence to collect before a pilot. Those records make an incident easier to investigate later.

Assess the likely risk to people

Build the assessment from the people affected, not just the number of rows in a database. Note the type, sensitivity and volume of information; the vulnerability of the people involved; who may have obtained it; the likelihood of misuse; the consequences if it is misused; and what the containment has genuinely changed. ICO's breach assessment guidance also points to the number of people affected and the effectiveness of containment.

Property files can combine identity evidence, addresses, contact details, financial information, repair photographs and messages about health or household circumstances. A single misdirected right-to-rent document may create a different risk from a temporary outage affecting thousands of routine maintenance entries. Assess the actual incident and plausible consequences; do not label every breach high risk or dismiss one because it concerns only one person.

Make the ICO decision before 72 hours expires

Notify ICO when the breach is likely to result in a risk to people's rights and freedoms. If that risk is unlikely, a notification is not required, but the agency must document the breach and its reasoning. If the assessment is incomplete, do not wait for a perfect forensic report. ICO allows information to be provided in phases when it cannot all be supplied at the same time, without undue further delay.

A notification should describe the nature of the breach, the categories and approximate numbers of people and records concerned, a contact point, the likely consequences, and the measures taken or proposed. Use the current ICO reporting service and keep the submission, reference and every later update in the incident record. If the agency reports after 72 hours, it should explain the reason for the delay.

Tell affected people when the risk is high

Where the breach is likely to result in a high risk to people's rights and freedoms, tell them without undue delay. Use clear language to explain what happened, the likely consequences, what the agency has done, who they can contact and practical steps they can take. The communication is a protective action, not a generic apology or marketing message.

Tailor the advice. A compromised password may call for an immediate reset and a warning about reused credentials. Exposed bank details may require vigilance for impersonation or payment diversion. An identity-document exposure may need different support. Coordinate the message with the incident facts, but do not delay useful advice solely to finish the full root-cause review.

Keep one breach record that supports the decision

Article 33 requires controllers to document the facts, effects and remedial action for personal data breaches. A compact, searchable record also lets an agency hand over between shifts without losing the reasoning behind the decision.

Protect the incident record itself. It may contain more sensitive detail than staff need for normal property work. Define who can view and amend it, keep a change trail and apply a justified retention period. Log near misses separately so the agency can learn from them without confusing them with confirmed personal data breaches.

Close the case by fixing the failed control

Closure should cover recovery as well as reporting. Review how the event entered the workflow, whether escalation was fast enough and whether the same access or process exists elsewhere. Actions may include changing permissions, tightening supplier terms, correcting a branch handover, testing backups or improving staff practice. Give each action an owner and review date.

Access failures often start before an incident is noticed. Review branch roles and permissions in the multi-branch agency setup guide, and use the bank-detail change workflow for a separate control against payment diversion. For a wider operational review, see the Tekniti agency offering.

ICO marks parts of its audit guidance as under review following the Data (Use and Access) Act 2025. Check the linked ICO pages and the reporting service at the time of an incident. This article is a practical workflow for UK operations, not legal advice or a substitute for incident-specific data protection and security advice.