Why a file-transfer server belongs on the list of systems that hold PHI

The week

On February 13, 2023, Community Health Systems, one of the largest US hospital operators, disclosed a breach in an SEC filing. Patient information had been exposed. But the attackers had not broken into the hospitals’ medical records system. They had gone through Fortra, maker of a product called GoAnywhere.

GoAnywhere is a managed file transfer product. Managed file transfer, often shortened to MFT, is software that moves large files securely between organizations. Hospitals use it constantly: to send claims to insurers, receive lab results, exchange eligibility lists, and share data with billing services and state registries. It carries the heavy, sensitive traffic that email cannot, and it runs mostly out of sight.

Fortra itself was a new name. The company had been called HelpSystems until it rebranded in late 2022, and many customers still knew the product under the old corporate label. GoAnywhere was widely deployed in banking, health care, retail and government, usually installed on the customer’s own servers, with a vendor-hosted version also on offer.

Fortra had warned customers in early February about a zero-day remote code execution flaw in the GoAnywhere administrative console. A zero-day is a flaw attackers are exploiting before the maker has a fix ready, so defenders have had zero days to prepare. Remote code execution means an outsider can run their own commands on the affected computer, effectively taking control of it. The administrative console is the control panel administrators use to manage the product.

The first warning went out as a notice behind the customer login, and it reached the wider public around February 2, when the security journalist Brian Krebs published it. The interim advice was to change a configuration file to switch off the vulnerable component and to restrict who could reach the console. Within days, researchers had published technical analyses and proof-of-concept exploit code, which meant any capable criminal could now try the attack.

The flaw was later tracked as CVE-2023-0669, its entry in the public catalog of known vulnerabilities. It sat in a licensing component of the console, and it could be triggered without logging in, because the software trusted data it should have checked. Fortra released a patch on February 7. On February 10, CISA, the federal cybersecurity agency, added the flaw to its catalog of vulnerabilities known to be exploited. That listing gave federal civilian agencies until March 3 to fix it.

The Clop extortion group claimed it had used the flaw to steal data from about 130 organizations, without deploying ransomware. Clop did not lock anyone’s systems. It took copies of the files and threatened to publish them, a method less visible and faster than ransomware and, for the victims, no less damaging.

The group had done this before. In late 2020 and early 2021, data stolen through flaws in Accellion’s legacy file transfer appliance, an older product of the same kind, appeared on Clop’s leak site. Victims then included universities, law firms, a grocery chain and government bodies. GoAnywhere was the second time the group had turned a file-transfer product into a mass data-theft operation.

CHS said the incident occurred at Fortra rather than in its own systems and that the affected data included personal and health information. Its filing estimated that approximately one million individuals may have been affected. It said its own systems and patient care had not been disrupted, and that it would notify patients and regulators and offer identity theft protection.

The filing used a general disclosure item, because the SEC’s specific cyber incident disclosure rule did not yet exist. Other healthcare and financial organizations disclosed related exposures in the following weeks, among them Hatch Bank, a bank serving fintech companies, and several health-benefit and behavioral-health firms. Fortra later said the attackers had been active from mid-January, before any customer was warned. For many health system executives, it was the first time they had heard the name of the product that carried so much of their patients’ data.

Ask a hospital chief executive to name the systems that hold patient data, and the answer will start with the electronic health record. The EHR is the digital chart doctors and nurses use every day. It may go on to the billing system, the data warehouse and the lab system. It is unlikely to include the file-transfer server. That omission is what the GoAnywhere incident exposed.

Managed file transfer rarely appears in architecture reviews. It is treated as plumbing: the way files move between a hospital and its payers, labs, clearinghouses, pharmacy benefit managers, billing services and state registries. The GoAnywhere incident showed that this plumbing often holds a health system’s most sensitive data in bulk, and for longer than anyone intended.

A file-transfer platform deserves system-of-record treatment, the same care given to the core systems that hold an organization’s official data. There are three reasons: where it sits in the network, what data rests on it and for how long, and who is accountable when someone else runs it.

The argument runs in four steps. Two short sections explain what the platform is and how data piles up on it. Three sections then take the three reasons in turn. A final group covers what getting it wrong costs, what a well-run platform looks like, and what a risk committee should ask.

What managed file transfer actually is

Health care runs on files. Every night, a hospital might send an insurer a file listing thousands of claims. The insurer sends back a file of payments and denials, known as a remittance. A reference lab sends a batch of test results. A state immunization registry expects a weekly upload. A pharmacy benefit manager sends updated drug coverage lists. Many of these exchanges use standard formats and run on automatic schedules.

Email cannot do this job. The files are too large, too sensitive and too frequent. Managed file transfer software fills the gap. It provides a secure drop-off point where partners can deposit and collect files, and it encrypts them in transit. It keeps a record of who sent what and when, and it can trigger automated workflows, such as moving a received file into the billing system.

The platform works like a secure loading dock. Trucks arrive from outside, unload, and the goods are carried into the warehouse. The loading dock is not the warehouse, and it is not supposed to store anything for long. But it has to face the street, because that is where the trucks come from.

The formats and the channels

Much of what crosses the dock follows the HIPAA transaction standards. These are electronic formats that federal rules require for certain exchanges between providers and health plans. Claims travel as 837 transactions. Payments and remittance advice come back as 835s. Eligibility questions and answers are 270s and 271s, and health plan enrollment files are 834s.

Each of these is a structured text file, and each carries identifiers by design. A claim names the patient, the subscriber, the provider, the diagnosis and the service. An enrollment file can list every member of an employer’s health plan. Lab results and registry submissions often use a different family of formats, HL7, but they carry the same kinds of detail.

The channels vary as much as the formats. Partners connect using secure file transfer protocols such as SFTP, web-based uploads, or AS2, a protocol built for business-to-business document exchange. Some files are encrypted with the partner’s own keys before they are sent, and decrypted on arrival. Each channel and key adds configuration that someone must maintain.

Who runs it

Some organizations run the software on their own servers. Others use a version hosted by the vendor or a service provider. Many also exchange files with partners who run their own MFT products. A single health system may touch several different file-transfer platforms without anyone having drawn the full picture.

The number tends to grow through acquisition. A health system that buys a physician group or a community hospital inherits that organization’s transfer server, its partner connections and its habits. Integration plans rarely list the transfer server as something to consolidate, because it keeps working and nobody complains about it.

The life of one claims file

A single file’s journey through a typical night shows the problem. At 11 p.m., the hospital’s billing system produces a claims file for one insurer. It contains patient names, dates of birth, insurance numbers, diagnosis codes and the services provided. An automated job places it in an outbound folder on the file-transfer server.

At 1 a.m., the insurer’s system connects, authenticates and collects the file. In an ideal world, the transfer server confirms the pickup and deletes its copy. In practice, it may keep the original in an archive folder, keep a second copy because the first attempt failed, and log the whole exchange. Each of those habits is defensible on its own. The problem is that nobody decides how long any of it should stay.

At 6 a.m., the insurer sends back a remittance file listing payments and denials. It lands in an inbound folder. The hospital’s billing system collects it and loads the data. Again, a copy may remain on the transfer server.

Multiply that by dozens of partners and hundreds of nights, and the picture becomes clear. The transfer server holds, in neat, well-organized folders, a large share of the organization’s patient and financial data. It is, functionally, a database, but it has none of the governance a database would get: no data owner, no retention review, no privacy assessment.

Where the copies hide

The obvious folders are the start, not the end. Transfer products commonly keep files in several less visible places, and each needs its own retention decision:

• Retry and error folders, where a file lands when a partner rejects it or a connection drops. These are rarely cleaned, because each one represents a problem someone meant to investigate.
• Workflow working directories, where a file is unpacked, decrypted, renamed or split before it moves on. If an automated job fails halfway, the decrypted copy can stay behind.
• Audit logs and the product’s own database, which record file names, partner names and sizes. File names sometimes include a patient identifier or account number, so even the logs can hold sensitive data.
• Backups of the server itself, which capture every folder on the day they run. A file deleted from the server can live on in backups for months.

Each of these locations is ordinary, and each follows from a reasonable engineering choice. Together they mean that the honest answer to “how much patient data is on the transfer server?” usually requires someone to go and look.

The people who set up these flows are usually integration specialists or interface analysts. Their job is to make the connection work and keep it working. They are measured on whether files arrive on time rather than on how long copies linger afterward. That is a reasonable focus for their role, and it is exactly why leadership has to set the retention and exposure rules from above.

Where file transfer sits

File transfer servers exist to accept connections from outside, so they are internet-facing by design. The flaw Clop used was in the administrative console rather than the file exchange service, and many affected installations had that console reachable from the internet. Fortra’s mitigation advice centered on restricting that access. To return to the loading dock: the dock door has to face the street, but the office that controls the locks, the delivery schedule and the inventory should not.

Why consoles end up exposed

Many transfer products run the partner service and the administrative web interface on the same server. Exposing one is easy to do by accident when exposing the other. Small integration teams also like to administer the system from anywhere, and an internet-reachable console saves a trip through the VPN.

The GoAnywhere flaw showed why that convenience was costly. It could be triggered before any login, so strong administrator passwords and multifactor authentication offered no protection. The only control that mattered on the day was whether an attacker could reach the console at all. Network placement, a decision usually made once during installation, decided who was exposed.

A sound design separates two planes:

• The partner plane, where outside parties exchange files, can be exposed, with strong authentication, allow-listed partner addresses where practical and a narrow set of protocols. An allow list means only pre-approved partner locations can connect at all; protocols are the agreed technical languages used to transfer files.
• The administrative plane controls users, keys, workflows and stored files. It should be reachable only from an internal management network through privileged access controls, the extra checks placed on accounts with powerful permissions.

Gateways, egress and alerts

Many products support a gateway pattern. A lightweight relay is placed in the network zone that faces the internet, and the server that stores files and runs workflows stays inside. Partners connect to the relay, which holds no files. An attacker who compromises the relay finds an empty room rather than a full archive.

Outbound controls matter as much as inbound ones. Extortion attacks end with data leaving the network. A transfer server that may only send files to known partner addresses is far harder to empty than one that can reach any address on the internet. Large, unexpected outbound transfers from the platform are worth an automatic alert.

Account monitoring closes the loop. Fortra later reported that the attackers had created unauthorized user accounts in some customer environments. New administrator or partner accounts, changes to workflows and new outbound destinations are rare events on a stable platform. Each should generate an alert that a person reviews the same day.

For vendor-hosted services, the customer should ask how the administrative plane is exposed and get the answer in writing. “It’s secure” is not an answer; “the console is reachable only from our internal network, through these controls” is.

Placement also means putting the platform into the processes that govern other critical systems. That means vulnerability scanning, privileged access management, log forwarding to the security operations center, and a named owner. Integration teams often install file-transfer tools to get a partner connection working by a deadline, and the security review arrives later, if at all. Adding the platform to the critical-asset register is a small administrative step with large consequences for how it is patched and watched.

Large systems and small hospitals

The right placement depends on who will run the platform. A large health system with a security operations center can run its own transfer server well, with a gateway, segmented administration and round-the-clock monitoring. A critical access hospital with a handful of IT staff often cannot.

For the smaller hospital, a vendor-hosted service may be the safer choice, because the vendor patches faster than a two-person team can. The trade-off is visibility. The hospital must then rely on contract terms and attestations for what it used to see directly. Hosting moves the work, not the accountability, and the hospital still sends the breach letters.

What data rests on it, and for how long

File transfer is meant to be transient. A file arrives, the receiving system collects it, and the copy is deleted. In practice files pile up. Retention settings stay at defaults. Failed transfers leave copies behind. Archive folders are kept “for troubleshooting.” A server meant to hold a day of files ends up holding months or years of eligibility files, claims extracts, lab results and remittance data.

That accumulation is what made extortion-only attacks profitable. The attackers did not need to reach the EHR or the data warehouse. They took what was sitting on the transfer server, and the size of each victim’s breach was set largely by its retention settings. A loading dock with a week of boxes on it is a small loss if robbed. A loading dock that has gradually become a warehouse is a very large one.

Suppose a regional health system installed its file-transfer server to move nightly claims files to five insurers. Over the years, thirty more partner connections were added. Nobody changed the default retention setting, which kept everything. When someone finally checks, the server holds several years of claims and eligibility files covering most of the system’s patients. Not a single file is needed there; every file was already loaded into the billing system the morning it arrived.

Why the defaults drift

Vendors ship conservative defaults because losing a customer’s file is the worst support call they can get. Interface teams keep copies because a payer may reject a batch days later and ask for it again. Auditors and payment-dispute teams occasionally want proof of what was sent and when. Each reason is legitimate for some files, for some period.

The failure is that one setting, chosen once, ends up serving all of them indefinitely. A good retention standard separates the reasons. Files needed for resending can be kept for the partner’s resubmission window and no longer. Proof of transmission can usually be kept as metadata, such as a file name, size, time and checksum, rather than as the full file.

The fix is to manage the platform as a data tier with an explicit retention standard:

• Delete files on confirmed pickup.
• Move anything that must be kept to a governed archive with its own access controls.
• Report monthly on the volume and age of files actually stored, by partner flow.

Encryption, keys and the breach safe harbor

Encryption at rest, meaning files are scrambled while stored, helps. But if the transfer server holds the keys, an attacker who controls the server can usually read the files. A useful metric is the oldest file on the platform; if it is more than a few days old, someone should be able to explain why. It is a number any executive can ask for and understand.

The key question also has a legal edge. Under the HIPAA breach notification rule, notification duties attach to “unsecured” health information. HHS guidance treats information encrypted to its specified standard as secured, but only if the key was not compromised with it. A server that stores both files and keys may not earn that protection when it is taken over.

Some organizations go further and keep files encrypted end to end. The sending system encrypts with the recipient’s key, and the transfer server never sees the contents. The trade-off is real. A server that cannot read files also cannot scan them for malware, check their format or route them by content. Each organization should decide flow by flow which matters more.

Sending less in the first place

Retention is one lever; content is another. Extract files tend to grow over time, because adding a column is easier than arguing about whether a partner needs it. An eligibility file may carry full Social Security numbers that the partner never uses.

The HIPAA minimum necessary standard asks covered entities to limit disclosures for payment and operations to what the purpose requires. Treatment disclosures are exempt, and standard transactions have their own required content. For custom extracts, though, a periodic review of which fields each partner receives is cheap, and every field removed is a field that cannot be stolen.

Clinical and revenue-cycle teams belong in that conversation. They know which partners will resend a file on request, which makes long retention unnecessary. They also know which flows genuinely need an archive for audit or payment disputes, and those archives can then be governed properly.

Retention also affects breach response. A platform that holds only a few days of data produces a short, well-bounded notification list. One holding years of files produces months of forensic and legal work to establish whose information was exposed. Every extra month of stored files adds patients to notify, letters to mail, call-center staff to hire and regulator questions to answer.

Who is accountable when someone else runs it

The third issue is accountability across a chain of vendors. A hospital may run its own transfer server, use a vendor-hosted service, or exchange files with a business associate that runs a product of its own. Under HIPAA, the federal health privacy law, a business associate is a vendor that handles protected health information, or PHI, on a provider’s behalf. HIPAA requires business associate agreements with vendors that create, receive, maintain or transmit PHI on a covered entity’s behalf. Business associates need equivalent agreements with their subcontractors.

Those agreements require safeguards and breach notification. They do not tell the hospital which products its vendors run, where, or how they are configured. A hospital can have a perfectly signed agreement with a billing company and still have no idea that the billing company stores its patients’ files on an internet-facing transfer server.

The clock and the chain

The breach notification rule gives a business associate up to 60 days from discovery to notify the covered entity. It must act without unreasonable delay, and 60 days is an outer limit rather than a target. The covered entity then has its own deadline to notify patients, and, for breaches affecting 500 or more people, HHS and the media.

Timing gets more complicated when a vendor counts as the covered entity’s agent. HHS has said that in that case the vendor’s knowledge of a breach can be treated as the covered entity’s, which starts the patient clock earlier. Whether a particular vendor is an agent depends on the facts, and organizations should check with their counsel before an incident, not during one.

Roles in the chain are not always obvious. A health care clearinghouse, which converts claims into standard formats, is itself a covered entity under HIPAA. When it processes claims for a hospital, it also acts as that hospital’s business associate. Health plans are covered entities too, so a claims file moving from a hospital to an insurer passes between two organizations with their own HIPAA duties. A county-run hospital adds state public records and breach laws on top. Each role carries different notification duties, and the data-flow map should record which role each partner plays.

The chain can be long. A hospital contracts with a revenue-cycle company. That company uses a clearinghouse, which uses a hosted transfer service, which runs on a commercial product. The hospital has a direct agreement with only the first link. Each later link is governed by agreements the hospital has never read.

CHS’s own disclosure illustrated the point: the breach happened at Fortra, yet the hospital operator carried the disclosure and the patient relationship. Patients do not distinguish between a hospital and its software vendor’s vendor. The letter comes from the hospital, and so do the headlines.

Building the data-flow map

Health systems that maintained a data-flow map could act quickly. Such a map records each partner, the files exchanged, the channel, the product and the operator. Those relying on contract inventories alone spent weeks reconstructing it under pressure. When a vulnerability in a product is announced, the first question is “do we, or does anyone handling our data, use this?” A data-flow map answers that in an hour. A pile of contracts answers it in a month.

The map does not need to start from scratch. The transfer platform’s own configuration lists every partner profile, schedule and folder. Firewall rules show which outside addresses connect. The business associate inventory and accounts-payable records show who is paid to handle data. Reconciling those four sources finds most flows, and the gaps between them are usually the riskiest ones.

Ownership matters more than tooling. The map should have one owner, often in the privacy or third-party risk office, and an update trigger. A new partner connection, a new business associate agreement or a vendor’s change of product should each require an update before go-live.

Contract terms that close the gap

Contracts can close part of the gap. Health systems can require business associates to disclose the file-transfer products they use for the hospital’s data and to keep administrative interfaces off the internet. Notice of a vendor-side incident should be required within days rather than at the outer limit HIPAA allows. Retention limits on transferred files belong in the agreement too. Each clause adds negotiation time, so they belong in the standard template, where they need not be argued deal by deal.

Bargaining power over vendors is uneven. A large health system can insist on its own template. A small physician group signs the clearinghouse’s standard terms or does without the service. For smaller organizations, the practical path is to ask the questions in writing and record the answers, even where the contract cannot be changed. A documented answer is still evidence of diligence.

Letters, regulators, bills and stalled claims

The cost of getting this wrong shows up in four places.

Patients and reputation. Patients trust the hospital rather than its vendors. When a breach letter arrives, it carries the hospital’s name. Explaining that the problem sat with a software supplier’s product does little to restore that trust.

The letter is rarely the end of it. Breaches reported to HHS that affect 500 or more people are listed on the agency’s public breach portal, by the covered entity’s name. That listing is searchable for years. Local media coverage follows the state-level notices, which come with their own content rules and deadlines.

Regulators. Health privacy law makes the provider responsible for protecting patient information, including when it is in a business associate’s hands. Breach notifications to patients and regulators bring questions about what safeguards were in place and why so much data was stored.

Federal investigators commonly ask for the organization’s security risk analysis. An analysis that never mentions the transfer server is hard to defend after the transfer server was the source of the breach. State attorneys general can bring their own cases under HIPAA and state law, and several states have specific data security statutes of their own.

Cost. Each breach brings forensic investigators, outside lawyers, notification mailings, call centers and credit monitoring offers, and the bill tends to grow with the number of people affected. Retention settings, a decision nobody thinks about, directly drive that number.

Litigation adds to the bill. Breaches affecting large numbers of patients routinely draw class actions, often against both the provider and the vendor. Cyber insurance can cover part of the cost, as CHS noted in its own filing. Insurers increasingly ask about internet-facing systems and third-party exposure at renewal, so a poorly governed platform can affect premiums before any breach occurs.

Operations. When a file-transfer platform must be shut down or patched urgently, claims stop flowing and payments slow. Knowing which partner flows run through which platform lets the organization switch to a backup channel instead of simply waiting.

The backup channel needs to exist before it is needed. Many payers and clearinghouses offer a web portal or an alternate connection, but setting one up takes credentials, testing and sometimes a new agreement. Payers also set timely filing limits for claims. A long outage that pushes claims past those limits can turn a security problem into lost revenue.

Treating the dock as part of the building

A health system in good shape treats every file-transfer platform it touches as a critical system rather than plumbing. Once a system is labeled infrastructure instead of data, it tends to escape privacy reviews. Each platform is on the critical-asset register with an owner. Its administrative console is reachable only from inside; making the partner service reachable is necessary, making the console reachable is not. Files are deleted once collected, instead of sitting under default retention settings that often keep them indefinitely, and a monthly report shows the age and volume of what remains.

A data-flow map lists every partner exchange, because a business associate agreement sets obligations without showing where the data actually lives. Organizations without their own map depend on vendors to tell them whether they were affected, which can take weeks. The business associate template asks partners to disclose their own transfer products, keep consoles off the internet, notify quickly and limit retention.

Sequencing the work

The order of the work matters, because some steps reduce exposure at once and others take months. A sensible sequence for a health system starting from little:

1. First two weeks. Find every transfer platform the organization runs, and confirm that no administrative console is reachable from the internet. This step needs no partner’s agreement and removes the most direct path an attacker used in 2023.
2. First two months. Measure what is stored, flow by flow. Agree retention periods with revenue-cycle and clinical owners, then purge. Before deleting anything, check with legal that no file is under a litigation hold or a regulatory retention duty.
3. First two quarters. Build the data-flow map, extend it to business associates, and move new contracts onto the updated template. Add the platforms to vulnerability scanning, privileged access management and security monitoring if they are not already there.

The evidence an auditor would ask for

An internal auditor or an outside examiner would expect to see the platform on the asset register with an owner, and a network diagram showing where the console is reachable. They would want the retention configuration, the monthly age report, and evidence that someone acted on it. Access reviews for administrator accounts, the data-flow map and the current business associate template complete the file.

A tabletop exercise is the cheapest test of all. A team that walks through “a flaw in our transfer product was announced this morning” will find the gaps in the map, the contacts and the backup channels in an afternoon.

The case against, and why it falls short

The strongest objection is cost. Transfer platforms are numerous, and giving each one system-of-record treatment adds work to already stretched teams. The answer is that most of the controls described here are configuration and governance, not new technology. Closing a console, changing a retention setting and producing an age report cost little next to a single large notification.

A second objection is that the problem will disappear as health care moves from batch files to real-time interfaces. Those interfaces, such as FHIR, the modern standard for exchanging health data through web services, do reduce the bulk data sitting at rest. But batch files remain the backbone of claims, enrollment and many registry exchanges. They will be for years, and interfaces bring their own exposure.

A third objection is that hosting by the vendor moves the risk to the vendor. It moves some of the operational work. It does not move the patients, the notification duty or the reputational cost. Hosted services can be the better choice, especially for small organizations, but only with the contract terms and evidence described above.

The risk committee should know every file-transfer platform and its oldest file

These need no technical knowledge, and the speed and confidence of the answers is itself useful information. A team that can answer most of them within a day is in good shape. A team that needs weeks has just shown where the work is, better learned now than from an attacker or a vendor’s letter.

1. How many file-transfer platforms move our patients’ data, including those run by vendors and partners, and are they all on our critical-asset list?
2. Can anyone on the internet reach the administrative console of any of them?
3. What is the oldest file sitting on each platform today, and why is it still there?
4. If a flaw in a file-transfer product were announced this morning, could we say by the end of the day whether we, or any business associate, use it?
5. Do our business associate agreements require disclosure of transfer products, prompt incident notice and limits on how long files are kept?

The questions work best as a standing item rather than a one-time review. Asked each quarter, they show whether the oldest file is getting younger, whether the platform count is stable, and whether new partners arrive with the right terms. A committee that sees the same numbers move in the right direction knows the program is real.

The GoAnywhere incident did not require attackers to break into a hospital. They found the hospital’s data waiting on a loading dock that had turned into a warehouse. Fixing that means treating the platform as a core system that holds patient data, and running it that way.

With hindsight

GoAnywhere proved to be a rehearsal. At the end of May 2023 the same group exploited a zero-day flaw in Progress Software’s MOVEit Transfer, another file-transfer product. The resulting breaches reached thousands of organizations, including many providers, insurers and business associates. In December 2024 Clop claimed another campaign against Cleo’s file-transfer products. The pattern was now unmistakable: one criminal group, returning again and again to the same category of software.

MOVEit followed the GoAnywhere script closely, at far greater scale. The flaw, CVE-2023-34362, was a database injection weakness that let an outsider into the application’s database without logging in. CISA and the FBI issued a joint advisory in early June 2023 that recounted Clop’s earlier file-transfer campaigns, GoAnywhere among them. Victims included government contractors, pension funds, universities and health plans, and many learned of their exposure from a vendor or partner rather than from their own monitoring. Lawsuits from that campaign were consolidated into a single federal proceeding in Massachusetts.

The Cleo flaws, CVE-2024-50623 and CVE-2024-55956, affected three related transfer products, and CISA added both to its exploited-vulnerabilities catalog that December. GoAnywhere itself returned in September 2025, when Fortra disclosed another critical flaw in the same licensing component, CVE-2025-10035. CISA listed it as exploited and associated with ransomware, and Microsoft attributed exploitation to a group linked to the Medusa ransomware operation. Clop moved on to other bulk-data business software, including an Oracle E-Business Suite campaign in late 2025.

In each case the attackers took data without encrypting anything, and the scale of harm tracked how much data sat on the servers. That is the most useful single fact to hold onto. Organizations that kept only a few days of files had small, bounded incidents. Organizations whose transfer servers had become archives had large ones. The attackers’ skill was the same in both cases; the difference was housekeeping.

Shortening retention and moving consoles off the internet are within a health system’s own control. They require no partner’s agreement and little budget. Data-flow mapping has proved slower, because it depends on partners’ cooperation. Each business associate must disclose what it runs, and some may be reluctant or simply not know.

The hosted-service question also got a clearer answer. Vendor hosting reduced patching delays for many customers, but it did not remove exposure, and it often made the customer more dependent on the vendor’s own account of what happened. Customers that had written notice and evidence terms into their contracts got those answers sooner.

Policy began to catch up. HHS’s voluntary healthcare cybersecurity performance goals, published in January 2024, gave third-party risk a place in the baseline. The Change Healthcare attack that February made the dependency point at far larger scale, showing how much of US health care can rest on a single outside company. UnitedHealth Group later put the number of people affected at about 190 million.

Disclosure rules moved too. In July 2023 the SEC adopted a rule requiring public companies to report material cyber incidents on a dedicated form item, which took effect that December. In January 2025, HHS proposed a major update to the HIPAA Security Rule. It would require covered entities and business associates to keep a technology asset inventory and a map of how electronic health information moves through their systems. It would also make encryption an express requirement, with limited exceptions. The proposal drew heavy comment from providers about cost, and organizations should track its status with counsel.

Those proposals described, in regulatory language, the data-flow map this article argues for. Whatever their final form, an inventory that omits the transfer server would not meet their intent.

The durable practice is to look at where data actually rests, rather than where the diagrams say it should. File-transfer platforms are a reliable place to start, because they were built to face outsiders and tend, unnoticed, to hold more than anyone meant them to.

A simple first step is to ask, this quarter, for the oldest file on each platform. The answer usually shows how much the platform holds that nobody meant to keep.