Blackbaud’s breach exposed patient data that fundraising never needed
The Blackbaud ransomware incident reached health systems through their foundations. It showed that philanthropy databases held more patient information, for longer, than HIPAA’s fundraising permission required, and that minimization is the control that still works after the others fail.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
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. The company said it had paid the attackers in exchange for assurances that a copied subset of data had been destroyed. 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.
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.
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? We answer in three parts: what HIPAA allows a foundation to use, how philanthropy data grows beyond that, and what a minimization program for fundraising data involves.
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 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.
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. 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. 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.
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.
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. When absence cannot be proven, the cautious choice is to notify broadly.
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.
- 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.
- 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.
- 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.
- Make opt-outs suppress extracts. An opt-out recorded in one system should stop future feeds, not only future mailings. Otherwise data keeps flowing for people who have asked to be left alone.
- 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.
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.
None of this would 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.
Trust matters here as well. Grateful patient programs depend on goodwill. 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.
With hindsight
The incident had a long regulatory tail. In March 2023 the Securities and Exchange Commission charged Blackbaud with misleading disclosures about the breach, and the company settled. In October 2023 it reached a multistate settlement with attorneys general from 49 states and the District of Columbia. In 2024 the Federal Trade Commission finalized an order that required Blackbaud to delete data it no longer needed and to keep a data retention schedule. Regulators had treated keeping data too long as a security failure in its own right.
Third-party exposure in health care has grown since. The 2024 ransomware attack on Change Healthcare showed how one vendor can disrupt providers nationwide. 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.