Heights Finance, a US consumer lender, says that on 7 May 2026 it discovered an unauthorized party had gained access to a cloud-based platform run by a third party and used to store customer information. By 18 August 2026, when Malwarebytes published a guide for affected customers, a filing with Texas regulators reportedly listed 734,828 Texas residents. The reporting cautions that this should not be read as a nationwide total.
Your own core systems can be untouched and you can still be the one writing the notification letters. This playbook is for the day a supplier tells you its environment, not yours, was breached.
What's affected
According to the Malwarebytes write-up, the data in the third-party platform included names, addresses, phone numbers and emails, account details, bank names, bank account and routing numbers, Social Security numbers, tax IDs, driver's license or state ID numbers, dates of birth, and personal circumstances shared during customer service calls.
The platform was not named in the coverage. The exposure came from where the company kept customer data, not from a flaw anyone has attributed to its own applications.
How to check if you're exposed
Before any vendor calls you, you should already be able to answer these. If you cannot, that is the first job.
- Which vendors store or process personal or confidential data for us?
- What fields does each hold, and could any be removed or masked?
- How long does each vendor keep data after we stop needing it?
- What does each contract say about breach notice: hours, content and cooperation?
- Who is the named contact on both sides?
A vendor register with these five columns is enough. Review the top ten vendors every quarter.
What to do now
When a supplier reports an incident, work this list in order.
- Open your own incident. Treat it as yours from the first call. Start the log, assign a lead and record the time you were told. Many notification clocks start on your awareness.
- Ask for facts in writing. Use the request below.
- Stop the bleeding on your side. Rotate API keys, tokens and credentials the vendor holds, and revoke unused integrations.
- Map the data. Which of your records sat in that environment? Do not wait for the vendor's list; produce your own from your schema and exports.
- Check the clocks. Work out which laws apply and when each started. Do this with counsel and in parallel with the investigation, not after it.
- Prepare customer communications. Draft a plain statement of what happened, what data, what you are doing and what people should do next.
- Decide on the relationship. Record what you will ask for in remediation, and whether you need an exit plan.
Subject: Security incident, request for information, response needed by ___
1. Date and time you first detected the incident, and when you notified us.
2. Which of our data and which fields were in the affected environment.
3. Whether data was viewed, copied or deleted, and the evidence for that.
4. The access path and whether it is closed.
5. Which logs you hold and for how long, and a copy of the relevant entries.
6. Your forensic firm, law enforcement contact and notification plans.
7. When you will send your next update.
How this could have been avoided
The public detail is limited, so these controls follow from what the reports say about the data and the platform.
- Keep less data in outside platforms. The data set included Social Security numbers and bank account numbers, and tokenizing or leaving out fields you do not need cuts the impact of any breach.
- Set deletion rules for vendor copies. Data that no longer supports a business purpose should not remain in a cloud store.
- Hold the vendor to a notice SLA and log-sharing duty in the contract, so you learn quickly and can say what was accessed.
- Require MFA and least privilege on third-party platforms, and review their access logs for your tenant on a schedule.
- Keep a current register of where customer data sits, so scoping takes days, not weeks.
Why it matters
Heights said it discovered the access in May, and the customer-facing guidance appeared in August. A gap of more than three months gets scrutiny. The reason is often the work of finding which records were affected and who they are. That work is much faster with a register.
A vendor breach is still your breach in the eyes of customers and regulators. The better question is how quickly you can scope it.
Try it yourself
Pick your most data-heavy vendor. In ten minutes, list the fields it holds about your customers and mark the ones you could delete or mask. Then check the contract for the breach notice clause.
Click through it at your own pace, or open it full screen.
Quick check
Why start your own incident log when a vendor reports a breach?
Because notification duties often run from your awareness, and your records of what you knew and when are what regulators and customers will ask for.
What is the cheapest control against this kind of exposure?
Storing fewer sensitive fields with vendors and deleting copies you no longer need.
