They Never Became Customers. Their Identity Data Was Still in the Breach.
Heights Finance says an intruder reached a third-party cloud platform containing customer data, not its loan-management systems or wider network. That boundary did not protect the people whose information was stored there.
The affected population may include borrowers, applicants, people who only enquired about a loan and former customers of related brands. In other words, some of the people exposed may never have become Heights Finance customers at all.
That is the defining security issue. The breach is not only a story about a cloud supplier. It is a story about how identity data can outlive the business purpose that caused an organisation to collect it.
What Heights Finance has confirmed
In a notice dated 11 August 2026, Heights Finance Holdings Co. said it discovered on 7 May that an unauthorised actor had accessed a cloud platform hosted by a third party. The company used that environment to store certain customer data.
Heights said the activity was limited to the cloud platform and did not affect its loan-management systems, other computer systems or networks. It activated its incident-response process, engaged external specialists and reported the matter to federal law enforcement.
The investigation concluded that the actor may have viewed or copied information from the platform. The data varied by person, but the company listed:
- names, addresses, phone numbers and email addresses;
- account details, bank names, bank-account numbers and routing numbers;
- Social Security numbers, tax identifiers, driving-licence numbers and state identity-card numbers;
- dates of birth; and
- personal circumstances voluntarily shared during customer-service interactions.
This is a particularly useful collection for identity fraud. It can connect a person’s identity, contact channels, financial relationships and government identifiers in one record set.
Heights said the affected cloud platform had been secured and that it had found no ongoing threat. It also said a specialist monitoring dark-web services had not found evidence, as of the notice, that information from the incident had appeared there.
Those are relevant findings, but they do not reverse the exposure. Absence from monitored forums is not evidence that copied data has been deleted, has not been traded privately or will not be used later.
The affected population extends beyond current customers
The most consequential sentence in the company notice describes who may be involved.
Heights said information may be affected if a person received a loan, enquired about or applied for a loan, including through a third party, or was a former borrower of Curo Management or one of its current or former related brands.
This creates several distinct groups:
- current borrowers whose data supports an active account;
- former borrowers whose relationship has ended;
- unsuccessful applicants whose information was collected for a decision but never became an active loan record;
- people who only made an enquiry; and
- people whose information entered the process through a partner or related brand.
Each group can have a different legal basis, retention requirement and operational owner. If they are all held in the same long-lived platform, the technical architecture can conceal those differences.
The organisation sees one customer-data repository. The people inside it may see five very different relationships, including no relationship at all.
The reported scale should be described carefully
The company’s public notice does not provide one global victim total. Separate state notifications have supplied numbers that, when combined in public reporting, exceed 1.2 million people. SecurityWeek reported that the Texas notification covered 734,828 residents and the South Carolina notification covered 486,463, with smaller numbers reported in New Hampshire and Vermont.
That supports a minimum scale above 1.2 million across those filings. It should not be presented as a final worldwide total because state counts can change, additional notifications may appear and the company has not published one consolidated number.
The distinction matters. A precise-looking number can create false confidence when the underlying population is still being reconciled across brands, platforms and jurisdictions.
“Not our core system” is not a containment argument
Heights’ statement that its loan-management environment was unaffected is useful for understanding the attack path and operational continuity. It does not make the third-party platform peripheral.
A system becomes important when it contains valuable data, not when it appears in the centre of an architecture diagram.
Cloud repositories, customer-service platforms, application pipelines, document stores and marketing systems often sit outside the transaction engine. They can nevertheless contain everything an attacker needs to impersonate a person or target a bank account.
This is why asset criticality should include confidentiality impact and data concentration. Availability-centric classifications can rank the loan system as critical while treating an adjacent data platform as supporting infrastructure. The attacker may make the opposite choice.
Retention is part of the attack surface
Every retained record increases the value of a successful compromise. The risk is not only that a system is reachable. It is also that the system still holds people and fields that no longer serve a necessary purpose.
Financial organisations cannot simply delete all historical information. Lending, fraud prevention, complaints, tax, accounting and regulatory obligations can require retention. But “we may need some records” is not the same as “we need every field, in every platform, for the same period”.
A defensible retention programme should be able to answer:
- Which data was collected for an enquiry, an application and an active loan?
- Which fields are required after a person does not proceed?
- Which records must be retained by law, and for exactly how long?
- Can high-risk identifiers be removed or tokenised before the rest of a record expires?
- Does a former brand’s data still sit in an inherited repository?
- Can the organisation prove that deletion occurred in backups, exports and third-party systems?
These are security questions because deletion reduces blast radius. A record that no longer exists cannot be stolen in the next breach.
Third-party intake can obscure responsibility
The notice includes people who enquired or applied through a third party. That expands the governance problem beyond one lender and one cloud provider.
Lead generators, brokers, comparison services and related brands can all pass data into a lending workflow. The person may know which website they visited but not every company or platform that received the form.
For security teams, the relevant map is therefore a data-flow map, not only a vendor inventory. It should show where each field originates, which organisations receive it, where it is copied, how long each copy remains and who can order its deletion.
Contractual language is necessary, but it is not evidence that a record was removed. Evidence comes from technical controls, deletion logs, sampled verification and the ability to reconcile what a supplier holds with what the organisation believes it holds.
What lenders and other data-heavy organisations should do
The practical response is broader than reviewing one cloud supplier.
First, segment applicant, prospect, customer and former-customer data. Do not let a shared repository erase the distinction between them.
Second, define field-level retention. A contact record, bank-account number, government identifier and customer-service narrative should not automatically inherit one retention period.
Third, make high-risk repositories visible to detection and response teams. Cloud storage and SaaS platforms that hold identity data need logging, anomaly detection, export monitoring, strong administrator controls and tested isolation procedures.
Fourth, include inherited data after acquisitions, rebrands and platform migrations. Historical records can survive long after the business context that created them has disappeared.
Fifth, test deletion as a control. A policy document is not enough. Security and privacy teams should be able to demonstrate that expired records disappear from production stores, analytics copies, support exports and supplier environments.
Finally, communicate populations precisely after an incident. Current customers, former customers, applicants and people who merely enquired need different explanations. Grouping all of them under “customers” hides the very governance failure defenders need to understand.
The durable lesson
The Heights Finance incident did not need to interrupt lending operations to create serious harm. The exposed cloud platform held a map from identity to location, bank relationship and government identifiers.
Some people in that map never received a loan. Their data still reached a third-party platform, remained there and entered the breach population.
Security leaders should treat that as a design failure to prevent, not just an incident to notify. Data minimisation is not administrative housekeeping. It is attack-surface reduction.
Sources and further reading
- Heights Finance Holdings Co.: Notice of Data Breach, 11 August 2026, publication time not stated
- SecurityWeek: Heights Finance Data Breach Impacts at Least 1.2 Million Individuals, 18 August 2026 at approximately 13:22 GMT
- The Record: Nearly 750,000 had financial information and Social Security numbers leaked in South Carolina loan-company breach, 17 August 2026, publication time not stated
