Hacked Website and Customer Data: A UK Business Response Guide

Organise the first decisions around people and evidence

Nominate an incident lead and involve the person responsible for data protection early. Technical staff should investigate access and preserve evidence, while business and privacy staff assess consequences for affected people. Keep a single incident chronology so changing technical findings do not produce contradictory statements to customers, partners and regulators.

Record when the organisation became aware of a possible personal data breach and the evidence supporting that assessment. Do not substitute the time of the first suspicious web request for the awareness decision without considering the circumstances. Equally, do not wait for a complete forensic report before escalating a credible incident internally. The response needs a decision process that works while uncertainty remains.

Restrict harmful functionality and secure trusted access without unnecessarily destroying logs or records. Preserve relevant database exports and access evidence under controlled permissions. A response copy can itself contain personal information, so give access only to people who need it and use an agreed retention plan.

Define which information and processing were affected

Map what the website actually does: enquiry collection, customer accounts, order history, appointment notes, document uploads and connections to other business systems. Do not assume that payment-card data is stored locally simply because a checkout exists, and do not assume a hosted payment page makes every other customer record irrelevant.

The ICO's guidance explains that a personal data breach can concern confidentiality, integrity or availability, not only a confirmed download of records. Apply that distinction to the facts. An attacker changing delivery details or a destructive incident making important records unavailable may require assessment even where there is no evidence of exfiltration.

Keep facts separate from hypotheses. “The attacker could read the database” and “the attacker downloaded every record” are different statements. Record the evidence for each finding, what remains unknown and the next action that may reduce the uncertainty.

Assess notification duties without assuming every hack is reportable

Under the ICO's current guidance, notify the ICO without undue delay and, where feasible, within 72 hours of awareness when a personal data breach meets the reporting threshold. Notification is not required where the breach is unlikely to result in a risk to individuals' rights and freedoms. Document the assessment and decision, including a decision not to notify.

Where the breach is likely to create a high risk to individuals, they must also be informed without undue delay. If the organisation acts as a processor for another business, escalate promptly through the agreed controller relationship; do not leave the customer's decision-maker waiting for a finished cleanup. Obtain appropriate privacy advice where roles, jurisdictions or sensitive information make the decision complex.

Prepare a useful account of what happened

Build a concise working brief covering the nature of the incident, the information and people potentially affected, the likely consequences, the containment already completed and the next investigation steps. Include a contact person who can coordinate follow-up questions. Track revisions so an early estimate is not mistaken for a confirmed final total.

• Describe the affected service and the period under investigation using dates and times that the recipient can understand.
• Explain practical consequences for people, such as suspicious communications or changed account information, rather than focusing only on business embarrassment.
• State which facts are confirmed and which are still being investigated.
• Record the reasons for missing information and the plan for providing updates through the appropriate route.
• Keep copies of communications and approval decisions with the restricted incident record.

Avoid asking customers to email passwords, identity documents or payment-card information as a precaution. If an action is necessary, direct them to a trusted channel that they can reach independently. Review any proposed customer message for clarity and the risk that attackers could imitate it.

Repair the service and close the investigation responsibly

Consider a hypothetical appointment website whose administrator account was abused. The investigation finds unauthorised changes to customer contact details but incomplete evidence about record viewing. Restoring the original records addresses an operational failure; the organisation still needs to assess the consequences of the unauthorised changes and the remaining uncertainty about access.

Run recovery work alongside the privacy assessment: rebuild compromised components, close the initial access route, revoke inappropriate access and verify business workflows using synthetic information. Avoid declaring that no data was affected simply because the website looks normal again. Likewise, a browser warning disappearing does not settle the data protection investigation.

At closure, record the established scope, evidence limitations, decisions, responsible owners and improvements. Review whether log retention, access controls and staff escalation arrangements were sufficient. CyberXperts can support technical scoping and evidence-led recovery, while the organisation and its advisers retain responsibility for its regulatory and customer communication decisions.