Most MOVEit victims never ran MOVEit

The week

On May 31, 2023, Progress Software disclosed a critical SQL injection vulnerability in its MOVEit Transfer managed file transfer product, later tracked as CVE-2023-34362. Managed file transfer software is the digital loading dock that organizations use to send large files, such as payroll runs, member lists or claims, to each other securely. A SQL injection flaw lets an attacker slip their own commands into the questions a program sends to its database. A CVE number is simply the public catalog number for a known security flaw.

Progress released a patch the same day. It told customers to cut off HTTP and HTTPS traffic to their MOVEit Transfer servers until they could apply it, and to look for signs of intrusion. The product ran in two forms: installed on a customer’s own servers, and as a hosted service, MOVEit Cloud, which Progress patched itself. Customers running their own installations had to act on their own schedule.

Security firms reported that exploitation had begun days earlier, around the US Memorial Day weekend. Attackers often strike over holidays, when fewer people are watching. On June 4 Microsoft attributed the attacks to the actor behind the Clop ransomware and extortion operation, a criminal group known for stealing data and then demanding payment to keep it from being published.

Mandiant, the incident response firm, reported exploitation beginning around May 27. The attackers installed a web shell, a small malicious program planted on the server, named to look like a legitimate file. It let them list the files stored on the server and download them, along with information from the server’s database. Kroll, another response firm, later said it had found signs the group had been testing ways to exploit the flaw as far back as 2021.

The group had done this before. In late 2020 and early 2021 it stole data through flaws in Accellion’s legacy file transfer appliance. Early in 2023 it did the same through Fortra’s GoAnywhere product. Each time it targeted a file-transfer tool, and each time it stole data rather than encrypting systems.

On June 5 the UK payroll provider Zellis said data belonging to some of its clients had been taken through its MOVEit system, and several large British employers confirmed that staff data was exposed. Those employers had not run MOVEit themselves. Their payroll firm had.

The employers named in British reporting that week included the BBC, British Airways and Boots. The provincial government of Nova Scotia also said it had been affected through its own MOVEit installation.

Over the summer, a great many people opened letters from companies they had never heard of, telling them that their name, Social Security number and salary details had been stolen. They had not done business with those companies. Their employer had, or their pension plan had, or a firm working for one of them had.

On June 6 Clop posted a notice telling victims to contact it. Rather than approaching each victim, the group invited them to come forward and negotiate. It set a deadline of June 14 and claimed it had deleted data taken from governments, cities and police services, a claim nobody could verify. On June 7 CISA and the FBI issued a joint advisory with indicators of compromise, the digital fingerprints defenders can search for to tell whether they were hit.

The same week, on June 6, the Federal Reserve, the FDIC and the OCC issued final interagency guidance on managing third-party relationships. It had been years in preparation and replaced each agency’s separate guidance with one framework for planning, due diligence, contracting, monitoring and termination. Its timing was coincidental. It arrived as the largest third-party data theft of the year was unfolding.

Progress disclosed further vulnerabilities in the product over the following weeks as researchers examined its code. New flaws were announced on June 9 and June 15. By mid-June, US federal agencies including the Department of Energy had confirmed they were affected, as had the motor vehicle agencies of Louisiana and Oregon. The State Department offered a reward of up to $10 million for information linking Clop to a foreign government. For the organizations running MOVEit, the job was urgent but familiar: patch, investigate, report. For the much larger group whose data sat on someone else’s MOVEit server, there was no such playbook.

The GoAnywhere breach had already made the case that a file-transfer server should be governed like a system of record. A “system of record” is the authoritative home of important data, such as the core banking ledger or the HR database, which organizations protect carefully. A file-transfer server is often treated as mere plumbing, even though it holds copies of exactly that data.

MOVEit was the same group using the same method at far greater scale, and it added something new. Many of the organizations whose data was stolen did not run MOVEit at all. Their payroll processors, pension administrators, benefits vendors, research firms and government contractors did. For those clients the usual incident playbook had nothing to offer, because there was nothing to patch.

Their exposure turned on three things that had been settled before the attack: how fast they could find out which vendors were affected, who was responsible for notifying whom, and how much data they had sent in the first place. Each of those is a management choice, not a technical one, which is why this story belongs on an executive agenda.

The banking agencies’ new third-party guidance, issued the same week, described a sound lifecycle for managing vendors. MOVEit tested a narrower and harder question that most lifecycle programs did not reach. It asked what happens to the files a firm has already sent, sitting on a tool the firm never chose, at a vendor it may not even know about.

Bulk files and the courier depot

Most organizations do not run all their own back-office work. They hire specialists. A payroll firm calculates pay. A pension administrator manages member records. A benefits vendor checks eligibility. To do the work, each specialist needs data, and the usual way to send it is a bulk file: a spreadsheet-like extract containing hundreds or millions of records, sent on a schedule.

Those files travel through file-transfer systems, which work like a secure courier depot. You drop off a sealed box; the courier stores it, then the recipient collects it. MOVEit was one of the depots many vendors used. When attackers found a way in, they did not have to break into each client. They could open the boxes already sitting in the depot.

That is the heart of what security professionals call third-party risk: your data is exposed through a company you hired. When that company passes data to another firm, the result is sometimes called fourth-party risk. In MOVEit, the depot was frequently one, two or more steps removed from the organization that owned the data.

Every bulk file you send creates a copy of your data in someone else’s building. You are still responsible for that data, even though you do not control the building.

How bulk flows multiply

Bulk flows accumulate over years. Each new vendor relationship adds one or more scheduled jobs, usually built by an integration team to a layout the vendor supplies. The job extracts records from a source system, writes a file, encrypts it for transit and pushes it over a secure protocol to the vendor’s server. Once it works, nobody looks at it again unless it breaks.

The flows differ by sector, but the pattern is the same. A bank sends files to statement printers, card processors, collection agencies and the firms that run its anti-fraud models. A health system sends claims, eligibility checks and quality reporting data to clearinghouses, payers and analytics vendors. A pension or insurance plan sends its member list to firms that check it against death records, so it can stop paying benefits to people who have died. A state agency sends licensing, tax or benefits data to contractors that process cases on its behalf.

Each of those vendors may then forward files to its own subcontractors, through its own tools. The data owner usually sees the first hop. The second and third hops are typically visible only if the contract required the vendor to disclose them.

Files also linger. Many transfer servers keep received files until someone deletes them, and the default retention setting is often generous or unlimited. A server that has received a monthly member file for five years may hold sixty copies. The attacker who reaches it takes the history, along with the current month.

Why file-transfer servers are such tempting targets

A file-transfer server has three features that make it unusually attractive. First, it must face the internet, because outside partners need to reach it. Anything reachable from the internet can be probed by anyone. Second, it concentrates valuable data. Its whole purpose is to hold files that one organization is sending to another, and those files are often the most sensitive records a business has. Third, it is shared. One vendor’s server may hold files from dozens or hundreds of clients.

Put those together and the economics are clear. Breaking into one well-defended bank is hard. Breaking into a single depot that holds files from many banks, insurers and employers can be far more rewarding. The extortion model Clop used fits this neatly: steal first, then invite victims to pay to keep their data from being published, without ever needing to scramble anyone’s systems.

There is also an organizational reason. File-transfer tools tend to be owned by integration or infrastructure teams and viewed as utilities. They rarely get the attention given to customer-facing systems, even though they carry the same data. That gap between importance and attention is exactly what attackers look for.

Most organizations sit on both sides of this problem. They receive files from partners on their own transfer servers, and they send files to vendors who run theirs. For the servers an organization runs itself, a few controls narrow the exposure. Restrict access to known partner addresses where the business allows it. Keep the server inside the scope of external attack-surface scanning and the vulnerability management program, with the same patch deadlines as other internet-facing systems. Set short retention on received and sent files. Alert on unusual download volumes, because bulk theft looks different from normal partner traffic. Those controls do not prevent a zero-day flaw from being exploited. They limit what the attacker finds and shorten the time before someone notices.

How the attack worked, step by step

The MOVEit attack followed a sequence that is useful to understand, because it explains why patching was necessary but not sufficient. The attackers sent crafted requests to the server’s web interface, which exposed the SQL injection flaw. Through it they gained enough access to plant their web shell. The web shell then gave them a private door: they could query the database, list stored files and download them at will.

Because exploitation began before the disclosure, many servers were already compromised when the patch arrived. Applying the patch closed the original flaw. It did nothing about the web shell already on the server, the files already taken or any credentials the attackers had collected. Organizations running MOVEit had to hunt for the web shell, review logs for unusual downloads, rotate credentials and determine which files had been accessed. Each of those steps took time, and the last one decided who had to be notified.

Why one group kept returning to the same kind of tool

Finding or buying a flaw in widely used software takes investment. A flaw in a file-transfer product repays that investment across every organization running it, and through them every client whose files are stored there. Accellion, GoAnywhere and MOVEit each fit that model. The data-theft approach also removed the need to deploy ransomware inside each victim’s network, which is slower and more likely to be detected. For the group, a single flaw could produce hundreds of victims in days.

That economic logic has a defensive implication. Any product category that concentrates many organizations’ sensitive data behind an internet-facing interface will attract the same attention. File transfer was the clearest case in 2023. It was unlikely to be the last.

What the first week looks like for a client

Suppose a state teachers’ pension fund does not run MOVEit. It sends a monthly file of member records to a benefits verification vendor, which uses a file-transfer product to receive it.

On day one, the fund’s chief information security officer reads about a critical flaw in a file-transfer product. Her first instinct is to check whether the fund runs it. It does not. The temptation is to stop there. On day three, a reporter calls asking whether the fund’s members are affected, because the vendor’s name has appeared on a leak site. The fund has no answer. Its vendor list shows the benefits firm as a “high-risk vendor” but says nothing about which tools it uses. The fund’s legal team starts asking who must notify the members, the fund or the vendor, and finds the contract silent. Its data team discovers that the monthly file contains the entire membership, with full Social Security numbers, and that nobody knows how long the vendor keeps old files.

Every one of those problems was set before the attack.

What the first week should involve

The better version of that week starts with a different first question. The CISO asks whether the fund runs the product, and also whether any vendor receiving the fund’s data does. Vendor management sends a short query to every bulk-data vendor the same day. The privacy officer pulls the layout of every outbound file, so that as soon as a vendor confirms exposure, the fund knows which data elements and which people are involved. General counsel opens a file on notice obligations under the relevant state laws and the vendor contracts. Communications drafts a holding statement for members, to be used only when the facts support it.

No step on that list needs the vendor’s investigation to be finished. Each needs preparation the fund controls. The roles also need a single coordinator, usually in the security or privacy office, so the vendor hears one consistent set of questions from the client rather than four.

Finding out which vendors were exposed

Clients learned of their exposure in different ways: a vendor’s notice, a news report, or their own name on Clop’s leak site. A pension system might learn that a benefits verification vendor had been hit. A university might hear from the clearinghouse that handles its enrollment records. An agency might read a contractor’s securities filing. Each source arrived on its own schedule. Some organizations found out from journalists before their own vendors called.

Most third-party inventories could not speed this up. They recorded vendor names, contract values and risk tiers, not the products each vendor used to receive the client’s files. The question that mattered in June 2023 was simple and new: which of our vendors runs this product, for which of our data, and what of ours was on it during the exposure window?

Two steps that make the question answerable

Two practical steps make that question answerable within days. The first uses information the organization already has. Its own integration team configures the endpoints that outbound files go to, and file-transfer logs record those hostnames and protocols. (An endpoint here is the address a file is sent to; a hostname is the name of the receiving server; a protocol is the method used to send it.) Those records often reveal which vendors receive bulk data and sometimes which product sits at the other end. The answer is often already sitting in the organization’s own systems, unread.

The second is a standing rapid-query process. It needs a list of vendors that receive bulk files, a current security contact for each, and a short question set that can go out within hours of a disclosure. Responses are tracked, and non-responders are escalated through the business owner of the relationship, the executive who actually owns the vendor relationship and has the standing to get a reply. Contracts can support this with a duty to answer such questions within a set time.

Suppose a regional bank learns from the news that a popular file-transfer product is under attack. The bank that has prepared pulls its file-transfer logs that afternoon, sees which vendors receive bulk customer files, and sends its pre-written questions to their security contacts by evening. By the end of the week it knows which vendors use the product and which have confirmed exposure. A bank that has not prepared spends the same week building a contact list.

The same question reaches one level further down. A benefits administrator may pass files to an actuarial firm, which runs its own transfer tool. Asking every vendor to list every subcontractor’s products is impractical. Asking it for the few flows that carry the most sensitive data is proportionate.

Contracts can make the inventory easier to maintain. One useful clause requires the vendor to name the products and material subcontractors that receive the client’s data. If it also requires notice before changes, it shifts the burden of keeping the record current to the party that knows the answer. Flow-down terms can require the vendor to impose similar duties on its own subcontractors. Such clauses are easiest to win at renewal or when a new data flow is added, and hardest to impose mid-contract.

A fair objection

Vendor management teams often argue that tracking each vendor’s tools is impossible to keep current, and they have a point. Vendors change products, migrate to cloud services and add subcontractors without telling clients. An inventory of every product at every vendor would be stale within months.

The answer is to narrow the scope. Most organizations have a few dozen flows that carry large volumes of sensitive personal data. Those flows deserve a named product, a named subcontractor chain and an annual confirmation. The long tail of low-sensitivity vendors can rely on the standing rapid-query process instead. A complete inventory is impractical; a precise inventory of the flows that matter is achievable.

Different starting points by sector

Organizations did not start from the same place. Banks supervised by the federal banking agencies had the new interagency guidance, and their regulators can examine certain bank service providers directly under the Bank Service Company Act. That gives a bank some assurance beyond its own questionnaires. Credit unions are in a weaker position: the NCUA has long lacked comparable authority to examine credit union vendors, so credit unions depend more heavily on their own contracts and monitoring.

Health systems manage vendors handling patient data through business associate agreements under HIPAA, which set baseline obligations but often say little about the tools a vendor uses. Federal agencies rely on contract clauses and, for cloud services, on FedRAMP authorizations. A self-managed file-transfer server at a contractor may fall outside any of those reviews. State and local agencies vary widely, and many depend on whatever terms the vendor’s standard contract offered.

Who notifies whom

The second issue was the notification chain. When a vendor is breached, several rules assign duties differently, and an organization may be subject to more than one of them at once.

Under HIPAA, a business associate notifies the covered entity, which notifies individuals. (HIPAA is the federal health privacy law; a covered entity is a provider or health plan, and a business associate is a vendor handling patient data for it.) State breach laws generally require a service provider to tell the data owner, which notifies residents. The banking agencies’ incident notification rule requires banks to notify their primary regulator of significant incidents within 36 hours. It requires bank service providers to notify their bank customers of certain significant disruptions as soon as possible. Contracts may assign the work differently again.

The clocks that start running

Each of those rules has its own clock, and they do not start at the same moment. HIPAA requires a business associate to notify the covered entity without unreasonable delay, and no later than 60 days after discovery. The covered entity then has its own deadline to notify individuals, and must also notify HHS and, for larger breaches, the media. State laws set their own timelines, which vary from state to state.

Federally insured credit unions faced a new clock that year. The NCUA’s rule requiring notice of reportable cyber incidents within 72 hours took effect on September 1, 2023. New York’s Department of Financial Services amended its cybersecurity regulation in November 2023. The amended rule makes clear that the 72-hour notice obligation can be triggered by an incident at a third-party service provider affecting the regulated firm. Public companies became subject to the SEC’s new requirement to disclose material cybersecurity incidents on Form 8-K, within four business days of determining materiality, from December 2023.

A single vendor breach can therefore start several clocks at once for one organization. A bank holding company with a New York charter, for example, may face banking-agency, state and securities disclosure obligations at the same time. Each needs a slightly different set of facts. The organization that knows quickly which files were taken can meet all of them. The one waiting on its vendor cannot meet any of them well.

In practice MOVEit produced confusion. People received letters from companies they had never heard of, or several letters about the same theft from different organizations. Clients learned of their exposure weeks apart from different vendors. Regulators received reports at different stages of understanding. For the public, the experience was bewildering; for the organizations, it was a reputational cost layered on top of the legal one.

The confusion had a cost even where every party met its legal deadline. A person who receives three letters about one theft, each from a different organization and each describing it slightly differently, tends to trust none of them. Call centers set up by different organizations gave different answers. Where data owners and vendors agreed one set of facts and one sender, the experience for the public was simpler and the organizations’ statements did not contradict each other.

Settling it in the contract

The fix lies in the contract, and it is more specific than a general breach clause. The vendor should notify the client within a set number of hours of discovering an incident that may involve the client’s data, not after the investigation is complete. Investigations can take weeks; regulators and customers will not wait that long.

The notice should identify the data elements, the populations and the files involved, because those details decide whether the client must notify anyone. “Some of your data may have been affected” is not something a general counsel can act on. “The March payroll file, covering active employees, including names, Social Security numbers and bank details” is.

The contract should say who notifies individuals and regulators, who approves the wording, and who pays for mailing, call centers and credit monitoring. A short decision matrix agreed in advance avoids negotiating these points while the clock runs.

Vendors resist notice measured in hours, and their reasons deserve a hearing. Early information is often wrong. A vendor that tells clients too much too soon may have to retract it, and clients may notify people unnecessarily. A staged approach handles this: an initial notice within hours that an incident may involve the client’s data, an update when the affected files are identified, and a final report when the investigation closes. Each stage carries what is known at that point, labeled as preliminary where it is.

The contract should also give the client a right to the evidence it needs for its own regulators. That means file names, timestamps of access and the vendor’s forensic conclusions, at least in summary. Without them, the client’s notice to a regulator rests on the vendor’s word alone.

How much data there was to lose

The size of each client’s breach was set mostly by what it had sent. This is the part of the story most within an organization’s own control, and the part most often overlooked.

Many outbound files carried full Social Security numbers where a partial number or an internal identifier would have done. Many sent the entire member or employee population every cycle instead of only changed records. Some vendors kept historical files long after processing them. Each of those habits multiplied the damage when the depot was opened.

Minimization is a design decision about each outbound file. It simply means sending the least data needed to do the job. A field-by-field review of each layout, against what the service actually needs, usually finds fields nobody uses. Sending changes instead of full extracts shrinks what sits on a vendor’s server at any moment. Replacing direct identifiers with tokens the vendor cannot reverse limits harm if a file is stolen. A token is a stand-in code that lets the vendor match records without ever seeing the real number. A contractual requirement to delete files after processing, with periodic confirmation, keeps the vendor’s copy small.

There are trade-offs. Vendors often ask for more data to improve matching accuracy, and fewer fields can mean more manual exceptions. Those choices belong to the data owner and the business owner together, recorded at contract renewal and whenever a file layout changes. A useful measure is simple: how many outbound bulk flows still carry full Social Security numbers, and how many have had a field review in the past year.

Who owns the file layout

Minimization fails most often through change, not design. A field gets added to a file for a pilot project or a one-time analysis and is never removed. A vendor upgrades its system and asks for the full record “to be safe.” Treating each outbound layout as a controlled document helps. A named data owner signs off on every change, and the integration team cannot add a field without that approval. The layout is reviewed whenever the contract renews.

Existing rules already point this way. For health data, HIPAA’s minimum necessary standard requires covered entities to limit what they disclose to business associates to what the purpose reasonably needs. For many non-bank financial firms, the FTC’s amended Safeguards Rule requires disposal of customer information within two years of its last use, unless there is a business or legal reason to keep it. MOVEit showed how loosely such standards are often applied to bulk files, which are easy to overlook because no person reads them.

Retention and encryption on both ends

Retention matters on both sides of the transfer. The sending organization often keeps its own copies of outbound files in staging folders. The vendor’s transfer server keeps what it received. The vendor’s processing system may keep a further copy. A deletion clause that covers only the processing system leaves the transfer server untouched, and that was the location MOVEit exposed.

File-level encryption can help, with limits. If the sender encrypts each file with a key held only by the vendor’s processing system, a stolen copy on the transfer server is unreadable. That depends on where the keys live. If decryption happens on the transfer server itself, or the keys are stored alongside it, the protection disappears. Asking each vendor where decryption occurs is a short question with a revealing answer.

Tokenization carries real cost. It requires a token service, changes to file layouts and work by the vendor to match on tokens. For a handful of high-volume, high-sensitivity flows, the cost is usually justified. For every flow, it rarely is. The field review should decide which flows qualify.

Letters with your name on them

MOVEit-style incidents hit every dimension leaders care about. Money: notification, call centers, credit monitoring, legal fees and possible litigation. Risk: regulatory deadlines that start running before the facts are clear. Customers and staff: people whose information was exposed through a firm they never chose. Regulators: reports that must be accurate, timely and consistent with what other organizations are saying. Reputation: the letter arrives with your name on it, whoever ran the server.

The costs also fall unevenly. A large bank or health system has an incident response retainer, a notification vendor on contract and in-house privacy counsel. A small credit union, a rural hospital or a county agency may have none of those, and pays more per affected person to arrange them in a hurry. Cyber insurance policies vary in how they treat incidents at a vendor rather than at the insured, and the terms are worth reading before an incident, with counsel and the broker.

The three controls described here need no new technology. They need ownership: someone who keeps the list of bulk-data vendors, someone who negotiates notice terms, someone who reviews file layouts. Those are assignments a leader can make this quarter.

Each assignment also needs a deputy. In a small organization the person who keeps the vendor list often handles the rest of vendor management too, and a disclosure can arrive while that person is on leave. A second name on each assignment costs little and keeps the first day of the response from stalling.

Boards can help by asking for these items concretely. Not “Is our third-party risk program mature?” but “If our payroll firm’s file-transfer system were breached tonight, how soon would we know, who would write to our employees, and what exactly would be in the stolen file?” The quality of the answer to that question says more than any maturity score.

Knowing in days, sending less

A well-prepared organization can, within days of a disclosure, name every vendor that receives its bulk data and which of them run the affected product. It has contracts specifying notice in hours, with details and a clear split of who notifies and who pays, and it sends each vendor only the fields it needs, only the records that changed, and asks for deletion after processing.

When an examiner or auditor asks about third-party risk after an incident like this, the useful evidence is specific. It includes the list of bulk-data vendors with their transfer products and the date each was last confirmed. It also includes the notice terms in each contract and the record of the rapid queries sent after the last major disclosure and how long responses took. The count of flows carrying full Social Security numbers, with its trend, belongs in that file too.

The strongest argument against all this effort is probability. Any given vendor is unlikely to be breached in a given year, and the preparation takes staff time that competes with other security work. The response is that the preparation is cheap relative to the incident, and that most of it serves more than one purpose. A list of bulk-data vendors with contacts helps with any vendor incident, including those that have nothing to do with file transfer. Smaller files help with every breach, whatever its cause. Notice terms help with outages as well as thefts.

Where organizations fall short:

• A vendor list without products. Knowing who the vendors are, but not which tools receive your files.
• Breach clauses that wait for the investigation. Notice “promptly after completing an investigation” can mean weeks.
• No agreed notification matrix. Arguing over who sends the letters, and who pays, while deadlines run.
• Full extracts by habit. Sending everyone, every time, because that is how the file was first built.
• Full Social Security numbers by default. Including the most sensitive identifier when a token or partial number would work.
• Forgetting vendor retention. Assuming files disappear after processing without ever checking.

Vendor risk comes down to hours and fields

1. Which vendors receive bulk files of our customer, member or employee data, and which file-transfer products do they use?
2. If a file-transfer product were attacked tomorrow, how many hours would it take us to know which of our vendors run it?
3. How quickly must each vendor tell us about an incident, and must the notice name the data, people and files involved?
4. For each major vendor, who notifies individuals and regulators, who approves the wording, and who pays?
5. How many of our outbound files still carry full Social Security numbers, and could a token or partial number do the job?

With hindsight

MOVEit became one of the largest data theft campaigns on record. By mid-2024, Emsisoft’s running count, drawn from breach notifications, securities filings and the group’s leak site, stood at about 2,770 organizations and nearly 96 million individuals. Victims included federal and state agencies, pension systems, health plans, universities and financial firms, many of them exposed through service providers, sometimes several contracting layers removed. The scale came not from breaking into thousands of organizations, but from breaking into the depots they shared.

Class actions against Progress and affected vendors were consolidated in federal court in Massachusetts, a reminder that the legal tail of an incident like this runs for years.

Many of the most consequential exposures ran through exactly the kind of vendor this article describes. Pension systems, including CalPERS, disclosed that member data had been taken through PBI Research Services, a firm used to check member lists against death records. The National Student Clearinghouse reported that education records were taken through its MOVEit server. Maximus, a large government services contractor, disclosed in a securities filing that personal data of millions of people had been accessed.

Notification rules tightened afterward. The FTC’s amended Safeguards Rule required many non-bank financial institutions to report certain breaches to the agency from May 2024. The SEC’s 2024 Regulation S-P amendments required covered firms to make sure their service providers notify them within 72 hours of certain breaches. Regulators, in effect, wrote into rules the contract terms that careful organizations had been negotiating on their own: faster notice from vendors, with the data owner kept informed.

Other rules followed the same direction. The NCUA’s 72-hour notice rule for credit unions took effect in September 2023, and New York’s amended cybersecurity regulation in November 2023. The SEC’s Regulation S-P amendments gave larger covered firms until December 2025 to comply, and smaller ones until June 2026.

The February 2024 attack on Change Healthcare tested the notification chain from another angle. HHS’s Office for Civil Rights said affected covered entities could arrange for Change Healthcare to send notices on their behalf. That was a practical answer to the question of who writes to the patients when a shared service provider is the source.

File-transfer software was hit again in late 2024, when a Cleo vulnerability was exploited in a campaign Clop claimed. The pattern repeated with a different product, which is the strongest argument against building defenses around any single tool.

In October 2025, extortion emails bearing the Clop name went to executives at organizations running Oracle E-Business Suite, and Oracle released an emergency patch for a flaw in the product. The target had moved from file transfer to a business application, but the method was recognizable: a widely deployed system, a previously unknown flaw and theft followed by extortion.

The three-part frame held up. In the vendor incidents that followed, the speed of discovery, the notification terms and the volume of data handed over still decided how badly each client was hurt. Regulators have since taken over much of the notification question through rules. Discovery and minimization remain largely each organization’s own work.

Vendor product inventories remain hard to keep current. Vendors change tools, add subcontractors and rarely volunteer the details. Minimization has proved the most dependable control, because it limits exposure whichever tool fails next. An organization cannot know which transfer tool will be breached next, but it can decide how much of its data is stored there.