Blackbaud’s breach exposed patient data that fundraising never needed

The week

In July 2020, Blackbaud, a cloud software provider widely used by nonprofits, universities and hospital foundations for fundraising and donor management, disclosed that it had been hit by ransomware in May. Ransomware is malicious software that criminals use to lock up or steal an organization’s data, then demand payment to unlock it or to keep it private. A “cloud” provider runs its software on its own computers and lets customers use it over the internet, which means the customers’ data sits on the provider’s systems.

Blackbaud is a publicly traded company based in South Carolina. Its customers included charities, schools, universities, arts organizations and health system foundations, in the United States and abroad, so the incident reached well past health care. Customer notices later set out the timeline as Blackbaud had described it to them. One health network, The Christ Hospital in Cincinnati, said the intrusion had occurred intermittently between February 7 and May 20, 2020. It said Blackbaud told it on July 16 that it had discovered and stopped the attack. Blackbaud’s first public statement, that same day, said the attacker had not accessed bank account information or Social Security numbers.

The company said it had paid the attackers in exchange for assurances that a copied subset of data had been destroyed. The criminals had taken a copy of some data, and Blackbaud paid them in return for their promise to delete it. Whether such a promise can be relied on is a question every executive should ask.

In the late summer of 2020, many patients and donors opened a letter from a hospital where they had been treated. It was not about a bill or an appointment. It said that some of their information, held by the hospital’s charitable foundation, may have been caught up in a cyberattack on a company they had never heard of.

Through August and into September, a steady stream of customers, including many health system foundations, notified donors, and in some cases patients, that their information had been in the affected backup files. A backup is a copy of data kept so it can be restored if the original is lost.

The work behind each notice followed a similar sequence. A health system received Blackbaud’s notice, opened its own investigation with outside experts, and tried to establish whose information had been in the files. The Christ Hospital, for example, said it determined on August 28 that the removed information included names, addresses, dates of birth, phone numbers, provider names and hospital departments for some patients. It said Social Security numbers, financial account information and its electronic health record system were not involved. It published its notice in mid-September.

The clock mattered. Under the HIPAA Breach Notification Rule, a covered entity must notify affected individuals without unreasonable delay and no later than 60 days after it discovers a breach. A breach affecting 500 or more people must also be reported to the Department of Health and Human Services. Where more than 500 residents of a state are affected, prominent media outlets must be notified too. Foundations also had to work through state breach notification laws, which can apply to donor data whether or not HIPAA does.

The notices differed in what they listed. Several health systems reported that the files included some patient information held for fundraising, such as names, addresses, dates of service or department of service. Blackbaud later said in a regulatory filing that more sensitive fields, such as bank account information and Social Security numbers, may also have been accessed for some customers.

That filing, made on September 29, said further forensic work had found that the attacker may have accessed certain unencrypted fields holding bank account information, Social Security numbers and usernames or passwords. Blackbaud said the finding applied to only some of the customers it had notified, and that in most cases fields intended for sensitive information were encrypted and not accessible. The wording implied that much of the exposed sensitive data had been stored where it was never meant to be, which is the pattern of drift this article examines.

For hospital leaders, the more uncomfortable discovery went beyond the vendor breach itself. Patient information they thought of as living in clinical systems had traveled, over years and largely unnoticed, into a fundraising database and its backups.

Coverage of the Blackbaud incident centered on the ransom payment and on how long notification took. Both deserved scrutiny. For health system leaders, a plainer question mattered more. Why was patient information sitting in a fundraising vendor’s backup files at all, and how much of it did fundraising use?

That question deserves a CEO’s or board member’s attention. It reaches beyond one vendor or one attack, to how sensitive information spreads inside and beyond an organization, and to a simple safeguard that keeps protecting people even when every other defense has failed.

Foundations, HIPAA and grateful patients

A few terms make the rest of this story easy to follow.

• HIPAA is the federal law that governs how health care organizations handle patients’ health information. Its Privacy Rule sets out when that information can be used or shared, and for what.
• Protected health information is the law’s term for information about a patient’s health, care or payment that can identify them. A name plus a date of hospital treatment counts.
• A covered entity is an organization the law applies to directly, such as a hospital or health plan.
• A business associate is an outside company that handles protected health information on a covered entity’s behalf, such as a billing service or a software vendor. It must sign an agreement promising to protect the data.
• Data minimization means collecting and keeping only the information you actually need, for only as long as you need it.

Hospital foundations, the charitable arms that raise money for new wings, equipment and research, often run “grateful patient” programs. The idea is straightforward: people who had a good experience at a hospital are more likely to give to it. To find those people, foundations receive some information about patients from the hospital’s systems.

How the foundation relationship is structured

Health system foundations come in several forms, and the form shapes the privacy analysis. Some are departments of the hospital itself, and their staff are part of the covered entity’s workforce. Others are separate nonprofit corporations whose charter ties them to supporting the hospital. HIPAA calls these institutionally related foundations and lets the covered entity disclose the permitted fundraising information to them. A third model has no foundation at all: the hospital’s own development office runs fundraising, often with an outside vendor.

The vendor’s position differs in each model. Where the hospital or its development office contracts directly, the vendor is the hospital’s business associate. Where a separate foundation contracts, the analysis depends on how the foundation is organized and what agreements connect it to the hospital. The answer determines who signs the business associate agreement, who receives the breach notice and who sends letters to patients. Many health systems found in 2020 that these questions had been settled informally years earlier, if at all. Counsel should confirm the structure for each foundation and vendor.

Academic medical centers add a further layer. A university advancement office may run one donor database for alumni, parents and grateful patients. Patient information falls under HIPAA, donor financial data under state law, and some alumni data may derive from education records covered by FERPA. A single platform holding all three turns every incident into a multi-regime legal analysis, and makes separation of fields and records inside the platform more important.

How a vendor breach reaches a hospital

It can seem strange that an attack on a software company would end with a hospital writing to its patients. The path is worth tracing, because the same path exists for almost every outside service a health system uses.

Step one: the data leaves the building. When a foundation adopts a cloud fundraising platform, it no longer keeps its donor database on its own computers. The vendor stores it, along with the data of many other customers, and makes it available over the internet. That is efficient and often more secure than a small foundation could manage alone. But it means the foundation’s data now lives wherever the vendor keeps it, including in the vendor’s backups.

Step two: the attacker gets in. Ransomware groups typically find a way into a company’s systems, look around for valuable data, and copy some of it before locking things up. Copying first gives them a second threat: pay, or the stolen data may be published or sold. This is sometimes called double extortion.

Step three: the vendor decides what to do. In Blackbaud’s case, the company said it paid in exchange for assurances that the copied data had been destroyed. A paying victim has no way to verify that criminals kept their word, which is one reason many security professionals and law enforcement agencies discourage payment.

Step four: customers inherit the problem. Under HIPAA, a business associate that suffers a breach must tell the covered entity, and the covered entity is generally responsible for deciding whether and how to notify affected patients. So the vendor’s incident becomes the hospital’s obligation. The hospital must work out what data the vendor held, whose it was, and whether it was in the affected files.

Step five: the hospital looks for its own records. This is where many health systems discovered the gap. They knew they had a fundraising vendor. Fewer knew precisely which patient fields had been sent over the years, or how long the vendor kept them.

Outsourcing a service does not outsource accountability for the data inside it. Every vendor that holds patient information extends the organization’s boundary. The more data each vendor holds, the further that boundary reaches, and the more work any single incident creates.

The decisions a hospital faces after the vendor’s notice

Once the vendor’s notice arrives, a health system has to make a series of decisions quickly. Most depend on records it may not have.

1. Establish whether HIPAA applies. The analysis depends on whether the affected records were protected health information held by or for a covered entity. Donor-only records may fall under state law alone.
2. Assess the probability of compromise. Under the Breach Notification Rule, an impermissible disclosure is presumed to be a breach unless a documented risk assessment shows a low probability that the information was compromised. The assessment weighs the nature of the data, who obtained it, whether it was actually acquired or viewed, and how far the risk was mitigated.
3. Weigh the vendor’s assurance. Blackbaud said it had paid for the copied data to be destroyed. Each hospital had to decide how much weight a criminal’s promise could carry in its own risk assessment, and many evidently concluded it could carry little, because they notified.
4. Identify whom to notify. This means matching the affected files to individuals, which is where field-level records of past extracts matter most.
5. Coordinate the message. The foundation, hospital communications, the privacy office and legal counsel must agree on who sends the letter, what it says and who answers the phone.

Each step takes longer when the organization cannot reconstruct what it sent. The vendor can tell the hospital which of its files were taken. Only the hospital can say whose data those files should have contained.

What the ransom payment did and did not settle

Blackbaud’s decision to pay raised questions that every health system now faces with its own vendors. On October 1, 2020, weeks after these notices went out, the Treasury Department’s Office of Foreign Assets Control issued an advisory on the sanctions risks of facilitating ransomware payments. It warned that paying a sanctioned party can violate federal law even when the victim is under duress. FinCEN issued a companion advisory the same day on how financial institutions should spot and report ransomware payments.

Payment also does not settle HIPAA obligations. HHS guidance on ransomware, published in 2016, treats a ransomware attack on electronic protected health information as presumptively a breach unless the organization can show a low probability of compromise. A criminal’s promise to delete copied data is weak evidence for that showing. Health systems should therefore expect to notify after a vendor ransomware event whether or not the vendor pays, and should plan their contracts and budgets on that basis.

What HIPAA allows for fundraising

The HIPAA Privacy Rule lets a covered entity, or an institutionally related foundation, use a limited set of protected health information for its own fundraising without patient authorization. The set covers demographic information, dates of care, department of service, treating physician, outcome information and health insurance status. The notice of privacy practices, the document patients receive explaining how their information may be used, must tell patients they may be contacted. Every fundraising communication must offer a clear way to opt out, and opt-outs must be honored.

The permission is narrow by design. It lets a foundation know that someone was a cardiology patient last spring with a good outcome. It does not cover diagnoses or clinical detail. A vendor that holds this data for the foundation is a business associate and needs an agreement that says so. Structures vary, and organizations should confirm with counsel how the rules apply to their own foundation and vendors.

Notice what the rule permits, not what it requires. Being allowed to use six categories of information does not mean a foundation needs all six, or needs them forever. The legal ceiling is not the same as the practical need, and the gap between the two is where risk accumulates.

Where the permission came from, and where it stops

The six categories date from the HIPAA Omnibus Rule of 2013, which widened the earlier fundraising permission. Before that change, covered entities could use only demographic information and dates of care for fundraising without authorization. The 2013 rule added department of service, treating physician, outcome information and health insurance status. HHS explained at the time that outcome information could help screen out patients who had a poor outcome, so that they would not receive appeals.

The same rule tightened the opt-out. Each fundraising communication must give a clear and conspicuous chance to opt out, and the method cannot impose an undue burden or more than a nominal cost. Treatment and payment cannot be conditioned on the patient’s choice. A covered entity may offer a way to opt back in.

Some uses fall outside the permission altogether. Diagnosis is not on the list, so targeting patients by condition requires their authorization. Marketing a third party’s products is treated separately under HIPAA and has its own authorization rules. State health privacy laws can be stricter than HIPAA, and some limit uses that HIPAA would allow. A foundation that wants richer segmentation has to obtain authorization or work with less.

How philanthropy data grows beyond the permission

Donor databases drift. Four forces push them to hold more than fundraising uses, for longer than anyone needs.

• Grateful patient feeds. Extracts from registration or clinical systems are configured once and rarely reviewed. An “extract” or “feed” is an automated transfer of selected data from one system to another, often nightly or weekly. A field added for one campaign stays in the feed for years.
• Retention by default. Fundraisers value long giving histories. Many platforms keep every record indefinitely unless someone sets a rule, and nobody is assigned to set it.
• Copies. Even when the live database is trimmed, older exports, backups, test environments and analyst spreadsheets keep the fuller version. A test environment is a copy of a system used to try out changes safely, and it often contains real data. The Blackbaud exposure involved backup files, which is where this tends to surface.
• Split ownership. The foundation owns the donor relationship. The health system owns the patient data. The privacy office may never see the extract that joins them, because it was set up as an IT ticket.

Wealth screening and analytics copies

Two further practices widened the trail at many foundations. The first is wealth screening: sending donor and prospect lists to an outside service that matches them against property records, public filings and other sources to estimate capacity to give. Each screening run creates another copy of the list with another vendor. If the list was built from a grateful patient feed, patient-derived names and dates of service travel with it unless someone removes them first. Whether such a disclosure fits within the fundraising permission and the business associate arrangements is a question for the privacy office and counsel, and it is often never asked.

The second is analytics. Foundations increasingly model which prospects are likely to give. Model building favors long histories and many fields, which pulls against minimization. Training extracts often land in data science environments with looser controls than the production platform. Where analysts need history, a pseudonymized copy with direct identifiers removed reduces exposure. It may still count as protected health information if it can be linked back, so it needs the same retention rules.

Mergers and platform migrations

Consolidation adds another source of drift. When health systems merge, their foundations often merge too, and donor databases are combined. Migration projects tend to move everything, because deciding what to leave behind takes time the project plan does not include. Legacy feeds from an acquired hospital’s registration system may keep running into the new platform for years. A platform migration is the cheapest moment to minimize, because every field has to be mapped anyway. It is also the moment most often missed.

The result is that a breach at a fundraising vendor can expose patient information the privacy office assumed lived only in clinical systems. That failure existed long before the attacker arrived. The breach simply made it visible, and it made the health system notify patients about data it had not been tracking.

Why notification got harder

Notification itself became harder because of the drift. To decide whom to notify, and about what, a health system needed to know which fields had been sent to the vendor and when. Without a field-level record of extracts, that history has to be rebuilt under deadline from interface specifications and old tickets. A record that shows which fields were sent, and when, turns weeks of reconstruction into a query. When absence cannot be proven, the cautious choice is to notify broadly.

Broad notification has costs of its own. It means more letters, more call center volume, more worried patients and donors, and a larger headline. It also means telling people about exposure that may not have affected them, because the organization cannot show that it did not.

A useful extract record is short. It names the source system, the query or interface definition, each field, the date each field was added or removed, the recipient and the person who approved it. Interface engines and integration platforms already hold most of this. The gap is usually that nobody exports it into the privacy office’s inventory, so the record exists only in the integration team’s configuration and memory.

Patients, donors, regulators and the bill

A fundraising database can feel peripheral to a health system’s core mission. Blackbaud showed how quickly it can move to the center.

Patients. Some donors learned from a breach letter that details of their hospital care sat in a fundraising vendor’s backup. That is a poor way to discover how data was used, even when the use was lawful. The hospital’s relationship with that person changes, whatever the legal analysis says.

Donors. Grateful patient programs depend on goodwill. A donor who feels their trust was taken for granted may give less, or stop giving.

Regulators. Health privacy regulators expect organizations to know where protected health information goes and to limit it to what is needed. An incident that exposes more than was necessary invites questions about why it was there.

Cost. Investigations, legal advice, notification letters, call centers and credit monitoring offers all add up. Every unnecessary record held is a record that may have to be investigated and notified about.

Reputation. Local news coverage of a hospital breach rarely draws a careful distinction between the hospital, its foundation and a vendor. To the public, it is the hospital’s breach.

Operations. A notification campaign is an operational project. HIPAA requires each letter to describe what happened, the types of information involved and the steps individuals should take to protect themselves. It must also say what the organization is doing in response and how to reach it, including a toll-free number or another contact route. Behind the letter sit address cleansing, mail vendors, a call center with scripts, and staff to handle questions the scripts do not cover. Every record that did not need to be there adds to each of those workloads.

Who could hold whom accountable

The enforcement picture differs by type of organization. HHS’s Office for Civil Rights enforces HIPAA against covered entities and business associates, so it can reach a hospital and a fundraising vendor that handles protected health information for it. The Federal Trade Commission’s core consumer protection authority reaches businesses organized for profit. That generally excludes nonprofit hospitals and foundations but includes a commercial software vendor. State attorneys general can act under state consumer protection and breach laws against both. The SEC’s interest arises only where a company is publicly traded and its statements to investors are at issue.

In Blackbaud’s case the SEC, the FTC and state attorneys general all acted against the vendor, as the hindsight below sets out. For a hospital, the practical consequence is that the vendor’s regulators are not its own. A vendor settlement does not discharge the hospital’s obligations to its patients or to HHS.

The contract decides who pays. Business associate agreements and master service agreements allocate the costs of investigation, notification, call centers and credit monitoring when the vendor causes a breach. Foundations sometimes sign fundraising contracts with limited legal review, and their indemnity and liability caps may not contemplate a notification campaign across tens of thousands of patients. A hospital that discovers those terms during an incident has little room to change them.

What a minimization program involves

The fix is not technically hard. It does require the foundation, the privacy office and IT to work from one inventory, and someone to own it.

1. Map every feed. Document each extract from clinical and registration systems to the foundation and its vendors. Record the exact fields, the frequency, the legal basis and the recipient.
2. Cut to the permitted set, then cut again. Start from the HIPAA fundraising categories and remove whatever the foundation does not actively use. Treating physician and outcome fields deserve a hard look, because they are the most sensitive in context. Knowing a person saw a particular specialist can reveal a great deal.
3. Set retention limits. Agree how long patient-derived fields stay useful for prospecting, often far shorter than the donor history itself. Apply the limit to backups, archives and test copies as well as the live system.
4. Make opt-outs suppress extracts. An opt-out recorded in one system should stop future feeds as well as future mailings. Otherwise data keeps flowing for people who have asked to be left alone.
5. Contract for deletion and proof. Business associate agreements should specify retention, deletion on request or at term, and how the vendor will demonstrate it, including for backups.

Who does what, and in what order

A minimization program has four owners. The privacy officer owns the register and the decision about what each feed may contain. The foundation’s donor database manager owns the business need: which fields are used, by whom and for what. IT or the integration team owns the feeds and makes the changes. Procurement or legal owns the vendor terms.

The sequence matters. Start with the feeds, because they are finite and the integration team can list them. Then work outward to copies: backups, test environments, analyst exports and wealth screening files. Contracts come last, at renewal or by amendment, once the organization knows what it wants the vendor to delete and how it wants proof.

The evidence an auditor or regulator would ask for is straightforward. It includes the feed register with field lists and approvals, and minutes of the annual review. It also includes retention rules as configured in the platform, deletion certificates from vendors, and a test showing that an opt-out stops the next extract. A sample test of that last item is cheap and revealing.

Scale changes the shape. A large multi-hospital system may have several foundations, each with its own database and vendors, and needs a central register with local owners. A single community hospital may have one foundation, one platform and one feed, and can finish the exercise in weeks. An ambulatory network or physician group often has no foundation at all. The same logic still applies to patient data sent to marketing, reputation management or patient-experience survey vendors.

Three measures show whether the program is working. The first is the number of patient-derived fields in each feed, which should fall and then hold steady. The second is the share of patient-derived records older than the retention limit, which should approach zero, backups included once they expire. The third is how long it takes to say, from the register alone, whose data a given vendor holds. That last measure is the one that matters in an incident, and a mature program answers it in hours rather than weeks.

One feed, reviewed

Consider a regional health system whose foundation set up a grateful patient feed some years ago. The original request asked for name, address, date of service and department. Later, a campaign for a new heart center added treating physician and outcome. That campaign ended, but the fields stayed in the feed. Nobody set a retention rule, so every patient sent over the years remains in the donor database. Backups are kept on the vendor’s standard schedule, which nobody at the health system has read.

A minimization review would find all of this in a few weeks. The foundation confirms it uses department and date of service for prospecting, but no longer uses physician or outcome. Those fields are removed from the feed. Patient-derived fields older than an agreed period are purged, and the vendor confirms in writing that backups will age out on a defined schedule. Opt-outs now stop the feed itself. If that vendor were breached the following year, the exposure would be smaller, and the health system could say precisely what had been sent, and when.

The trade-offs

Minimization has costs. Fundraisers lose some prospecting signal, and analytics teams lose history they might have used. Shorter retention can complicate long-term donor stewardship. Those costs are real but bounded. The cost of holding the data is open-ended, because it scales with every system the data reaches and every vendor that might be breached.

A harder trade-off involves backups. Ransomware resilience pushes organizations and vendors toward immutable backups kept for long periods, so that clean copies survive an attack. Immutability also means deletion cannot reach those copies until they expire. A purge of old patient-derived fields in the live system is therefore incomplete for as long as the backup retention period runs. The answer is to set backup retention deliberately, ask the vendor what it is, and count the expiry date, not the purge date, as the point when the data is truly gone.

The safeguard that outlasts the others

Minimization would not have stopped the intrusion at Blackbaud. It would have limited what the intrusion could expose and simplified the notification that followed. Minimization keeps working after access controls, encryption and monitoring have all failed, which is why it belongs at the top of the list for secondary uses of patient data. “Secondary use” means any use of patient information beyond direct care and payment: fundraising, marketing, research, analytics.

Locks, alarms and cameras all reduce the chance of a burglary, but the only sure way to keep a burglar from your grandmother’s jewelry is to keep it out of the house. Data you do not hold cannot be stolen, encrypted, held for ransom or listed in a notification letter.

Encryption is the control most often offered as an alternative, and Blackbaud shows its limits. The company said that in most cases fields intended for sensitive information were encrypted. Encryption protected the data that went where the designers expected it. It did nothing for data placed in ordinary fields, notes or attachments, which is exactly where drifted data tends to end up. Minimization covers both cases, because it acts on what is present rather than on where it was supposed to be.

A well-run program has a single, current register of every feed of patient data to secondary uses, reviewed each year by the privacy office and the foundation together. It has retention rules that reach backups and test copies, and vendor contracts that say how deletion will be proven. Its opt-outs stop data at the source.

The strongest objections

Three objections deserve a direct answer. The first is that the breach was the vendor’s fault, and the fix belongs in vendor security rather than in the hospital’s data practices. Vendor security matters, and the regulators’ later actions targeted it. But a hospital cannot control a vendor’s network. It can control what it sends.

The second is that the data involved was low in sensitivity. Names, addresses and dates of service are not diagnoses. Yet department and treating physician can reveal a great deal in context: a visit to an oncology or behavioral health department says something specific. And the cost of notification depends on the number of people involved more than on the sensitivity of each field.

The third is that minimization hurts fundraising, and philanthropy funds care. The objection holds at the margin. Grateful patient programs mostly run on a few fields used well: who was treated, when and in which department. The fields a review removes are usually those nobody has used since the campaign that requested them. Where the foundation can show a current use, the field stays, with a retention limit.

The failures are familiar:

• Treating the legal permission as a target. Sending every category HIPAA allows, rather than the ones the foundation uses.
• Trimming the live system and forgetting the copies. Backups, exports and spreadsheets keep the old data long after the database is cleaned.
• Setting up feeds as IT tickets. Data transfers created without privacy review, and never revisited.
• Opt-outs that only stop mail. The person stops receiving letters, but their data keeps arriving.
• Contracts silent on deletion. Vendor agreements that say nothing about how long data is kept or how its removal will be shown.

Tracing patient data that has left the clinic

• Which outside vendors and internal teams receive patient information for purposes other than care and billing, such as fundraising, marketing or analytics, and can we list the exact fields sent, how often, and on what legal basis?
• Which of those fields does the foundation actually use today, and which could we stop sending tomorrow?
• How long do we, and our vendors, keep patient-derived fundraising data, including in backups and test copies?
• When a patient opts out of fundraising, does that stop their data from being sent, or only stop the letters?
• If one of our fundraising or marketing vendors were breached tonight, could we say from our own records exactly whose information was there, and who, by name, owns that inventory across the foundation, privacy office and IT?

These questions are worth asking on a schedule, and before an incident forces them. An annual review timed to the foundation’s campaign planning gives the business a natural moment to say what it needs for the coming year. Anything it cannot name a use for comes out of the feed. A shorter check after any new vendor, campaign or analytics project keeps the register current between reviews.

The answers will tell a leader more about the organization’s real exposure than any assurance about firewalls. Holding less is the simplest form of protection, and it keeps working when other defenses fail.

With hindsight

The incident had a long regulatory tail, and each part of it turned on a different failure.

In March 2023 the Securities and Exchange Commission charged Blackbaud with misleading disclosures about the breach. Its case turned on what happened inside the company after the first statement. On July 16, 2020, Blackbaud had said the attacker did not access bank account information or Social Security numbers. According to the SEC, technology and customer relations staff learned within days that the attacker had accessed and taken such data, but the information did not reach the executives responsible for disclosure. The company’s August 2020 quarterly report described the risk of sensitive donor data being taken as hypothetical. Blackbaud agreed to a $3 million civil penalty without admitting or denying the findings.

In October 2023 Blackbaud reached a settlement with the attorneys general of 49 states and the District of Columbia, paying $49.5 million. It agreed to comply with HIPAA as well as state consumer protection and breach notification laws. California did not join and pursued its own investigation. In May 2024 the Federal Trade Commission finalized an order that required Blackbaud to delete data it no longer needed to provide its services. The order also required it to keep a data retention schedule describing its deletion practices, and to run a comprehensive information security program.

That last step deserves attention. Regulators had treated keeping data too long as a security failure in its own right. It was no longer enough to say that data had been protected with locks and alarms. The question had become why the data was there at all, and for how long. For any organization that relies on vendors to hold sensitive information, that shift turns retention from an administrative detail into a compliance obligation.

The years between the attack and these outcomes also show how long a single vendor incident can stay on the agenda. Securities regulators, state attorneys general and a federal consumer protection agency each took their own action, more than three years after the ransomware itself.

Third-party exposure in health care has grown since. The 2024 ransomware attack on Change Healthcare showed how one vendor can disrupt providers nationwide. Health systems now depend on a dense web of outside companies, and each one that holds patient data is a place that data can be exposed.

The Change Healthcare attack, disclosed in February 2024, became the largest health data breach reported to HHS, with roughly 190 million people affected according to figures UnitedHealth Group reported in 2025. It made the Blackbaud point at far greater scale. A company few patients had heard of held their data, and the organizations that relied on it had to answer for it.

Regulation has moved toward the inventory this article recommends. In January 2025 HHS proposed changes to the HIPAA Security Rule. They would require regulated entities to keep a technology asset inventory and a network map showing how electronic protected health information moves through their systems. The proposal would also require business associates to verify periodically that required safeguards are in place. It concerns security rather than fundraising, but a feed register for secondary uses is the same discipline applied to data that leaves clinical systems.

Some 2020-era responses aged less well. A common reaction to vendor breaches is a longer security questionnaire at onboarding. Questionnaires describe a vendor’s controls at a point in time. They do little to reduce how much data each vendor holds. The more durable gains came from cutting feeds and setting retention, because that change persists whatever the vendor’s next questionnaire says.

The minimization argument has held up. The less patient data sits in secondary systems such as fundraising, marketing and analytics, the less any single vendor incident can expose, and the faster a health system can decide whom to notify. It remains one of the few security measures that costs little, needs no new technology and keeps working whatever else goes wrong.