Resilience

The Housing Ombudsman Service, which settles disputes between social housing residents and their landlords in England, said on Tuesday, October 13, 2026 that a "third-party IT security incident" had hit its case management system. The system is run by an external supplier that the Ombudsman has not named. Residents cannot submit a new complaint online or view an existing one, and web chat, the webform, the Learning Hub and the landlord portal are all offline. New complaints have to go in by phone or email.

The Ombudsman says the incident is contained and that it is still investigating whether personal information was affected. It has reported the incident to the UK data protection regulator. As of the last update to its statement, on October 16 at 15:00, there is no restoration date, no supplier name and no root cause. If your organisation runs a complaints, casework or customer portal on a provider's platform, you would be in the same position: you own the data and the duty to report, while the systems and the evidence sit with someone else.

What is known so far

• The incident happened at the supplier. The Ombudsman says it is working with "our external supplier" to establish the full facts, describes the incident as contained and took its online services offline as a precaution.
• Whether personal data was affected is still under investigation. Affected people will be contacted directly where required.
• The statement says the incident has been reported to the "Information Commission". That is the regulator's new legal name: under the Data (Use and Access) Act 2025, the Information Commissioner's Office became the Information Commission on September 30, 2026, and it still goes by ICO.
• Nobody has claimed the attack, and no reporting names a vulnerability or a product.

Complaint files at a housing ombudsman can describe disrepair, health conditions and disputes with landlords. Until the investigation says otherwise, residents and landlords who used the service are obvious targets for a scammer posing as the Ombudsman about "your complaint".

The supplier incident playbook

Most of what decides how an incident like this goes for the customer is set beforehand, in the contract, the fallback plan and the integration design.

1. Before it happens: put the clock in the contract

UK GDPR Article 28 requires a written contract between you (the controller, who decides why data is processed) and your supplier (the processor, who handles it for you), and Article 33(2) requires the processor to tell you about a breach "without undue delay". That phrase is too loose to plan with. Write a number into the contract, for example notification within 24 hours of the supplier becoming aware of an incident that may involve your data, with a named contact on both sides and a duty to send updates at agreed intervals.

Add the rights you will need on the day: logs for your tenant, a summary of the forensic findings, the subprocessors in the data path, and help with your breach report and letters to individuals.

2. Hour zero: start your own clock

The ICO expects a notifiable breach to be reported "without undue delay, but not later than 72 hours after becoming aware of it". For a controller, the clock usually starts when the processor tells you about the breach, even while the supplier's investigation is still running. Write down that time, open a breach log entry and get your data protection officer (DPO) in the room.

The ICO accepts a report in phases. If you cannot confirm what was taken within 72 hours, report what you know, say what you are still establishing and when you expect to know it. The Ombudsman's approach, reporting to the regulator while the data question is still open, follows that model. If you decide a breach is not reportable, Article 33(5) still requires you to record the decision and the reasons.

3. Run a degraded service on purpose

Taking a portal offline does not stop the complaints. Decide in advance which channels stay open (phone, a monitored mailbox, post), who staffs them and how cases taken by phone are recorded so they can be loaded into the system later without being lost or duplicated. Statutory and service-level deadlines that depend on the case system need a stated position: whether they are paused, extended or tracked manually.

Publish one status page with a timestamped last update, as the Ombudsman has done, and brief call handlers from it.

4. Warn users before the scammers reach them

Tell people whether you will ever ask for bank details or passwords, which domain your emails come from, and to check a call by ringing back on the number on your website. The Ombudsman's advice to residents, not to disclose personal information unless they are confident of the requester's identity, is the right core message. Point people to the National Cyber Security Centre (NCSC) reporting services for suspicious emails and texts, and put the same warning in your phone queue message.

5. Ask the supplier for evidence, in writing

Ask for the detection time and the earliest confirmed attacker activity, which may be weeks apart. Ask which systems, databases and file stores held your data, whether it was read or copied, and the time window of records involved, because that defines who you may have to write to. Ask for indicators of compromise (IP addresses, file hashes, account names) so you can search your own logs. Ask too whether other customers of the platform are affected.

6. Rotate everything that connects to the platform

Assume any credential the supplier held for you may be exposed until the supplier says otherwise in writing. That means API keys and OAuth client secrets for integrations with your CRM, document store or telephony; SFTP accounts used for exports; single sign-on certificates and the application's assignments in Microsoft Entra ID or your identity provider; and the accounts of your staff on the supplier's admin console. Review your own sign-in and API logs for connections from the supplier's IP ranges outside normal job times since the earliest date the supplier gives you.

7. Restore only on evidence

Before reconnecting, ask the supplier to confirm the root cause is fixed, that the environment was rebuilt or cleaned, and that its monitoring now covers the way the attacker got in. Then re-enable integrations with new credentials, one at a time.

The wider lesson

Citizen-facing services are often a thin front end on a supplier's platform that the customer cannot patch, isolate or investigate alone. What helps is prepared in advance: a notification time in the contract, a rehearsed manual fallback, integration credentials you can rotate in an afternoon, and a scam warning already drafted.

Our compliance and audit readiness work builds supplier clauses and breach runbooks like these, and attack surface management maps which third-party platforms hold your data and credentials. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: Housing Ombudsman Service statement, BleepingComputer, Cybernews, teiss, Inside Housing, Daily Security Review, ICO: personal data breaches guide, Lewis Silkin: ICO becomes the Information Commission, VinciWorks: the ICO becomes the Information Commission.