Summary

Why this case belongs in a risk and accountability file

Blackbaud belongs in a risk and accountability file because the visible customer was rarely the final exposed person. A university, hospital foundation, food bank, child welfare charity, religious organization, school, museum, research foundation, or public-service nonprofit might have purchased Blackbaud software. The records inside those systems belonged to donors, alumni, patients, campaign volunteers, students, event attendees, beneficiaries, trustees, employees, and supporters. Those people may never have seen a Blackbaud login screen.

They were represented to the vendor by an institution they trusted for a mission, not by an ordinary consumer account.

The primary public timeline is unusually instructive. The SEC order at https://www.sec.gov/files/litigation/admin/2023/33-11165.pdf says Blackbaud detected unauthorized access on May 14, 2020 and that the company's investigation indicated access may have begun as early as February 2020. The order says the incident resulted in unauthorized access and exfiltration of over a million files concerning over 13,000 customers. Blackbaud announced the incident and notified impacted customers on July 16, 2020. The SEC order then says employees learned within days that earlier statements about donor bank account information and Social Security numbers were erroneous for some customers, but the company's August 4, 2020 Form 10-Q did not disclose that broader scope and characterized the risk as hypothetical.

Blackbaud's later Form 8-K, available at https://investor.blackbaud.com/static-files/58a4ae64-afc5-45f7-81df-69dfc93888fc, changed the public risk picture. It said further forensic investigation found that for some notified customers, the attacker may have accessed unencrypted fields intended for bank account information, Social Security numbers, usernames and/or passwords. That did not mean every customer had those fields exposed. It did mean the original notice architecture had failed to carry the full uncertainty and that some customers needed supplemental support.

The accountability question is therefore practical. Who had practical control over tenant data custody, exfiltration evidence, ransom-payment communication, customer notice timing, regulator cooperation, and proof that nonprofit constituents did not become an unseen cost of cloud concentration? The answer begins with Blackbaud because Blackbaud controlled the hosted environment, the investigation, the first customer notices, the data-retention posture, the service-specific files, and the evidence flow that downstream institutions needed to notify their communities.

That does not erase customer responsibility. Customers decide what data to collect, what fields to use, what attachments to upload, how long to retain old records, and how to communicate with their constituents. But customer responsibility sits behind a vendor evidence gate. If a nonprofit cannot see which Blackbaud files were copied, cannot verify whether a field was encrypted, cannot inspect attacker communications, and cannot independently confirm data deletion, then the vendor's evidence discipline becomes the controlling condition for everyone else's accountability.

The timeline is a disclosure-control case, not just an intrusion case

The timeline matters because it shows that accountability did not end when the attacker was expelled. It shifted into disclosure controls. The SEC's press release at https://www.sec.gov/intelligence team/press-releases/2023-48 says Blackbaud agreed to pay a USD 3 million civil penalty to settle charges for misleading disclosures, without admitting or denying the SEC's findings. The important point for this file is not the dollar amount. It is the control failure described by the SEC: technical and customer relations personnel learned information about sensitive data that did not reach senior management responsible for public disclosure before the August 2020 filing.

That is a different failure mode from a firewall gap or an endpoint compromise. It is an evidence-routing gap. In a cloud incident, facts move from endpoint investigators to product teams, customer support scripts, lawyers, executives, regulators, investors, and customers. If those facts do not move fast enough or with enough precision, the public record can tell affected people the wrong thing even after the company knows the first notice was incomplete. For mission-led customers, that delay is not an investor-relations abstraction.

It decides when a donor can freeze a bank account, when a patient can watch for identity misuse, when a university can notify alumni, and when a charity can answer anxious supporters.

The SEC order describes a particularly sharp sequence. Blackbaud's July 16 notice said the attacker did not access donor bank account information or Social Security numbers. Customer questions then surfaced concerns that sensitive data had been stored in unencrypted attachments or fields. By July 21, according to the SEC order, personnel had developed a customer-service script acknowledging that certain attachments and fields potentially used for those categories were not encrypted.

By the end of July, personnel had confirmed access and exfiltration of some unencrypted donor bank account information and Social Security numbers for a number of impacted customers. The August 4 Form 10-Q did not include that material correction.

The FTC later framed the same event through consumer protection and data retention. Its release at https://www.ftc.gov/news-events/news/press-releases/2024/02/ftc-order-will-require-blackbaud-delete-unnecessary-data-boost-safeguards-settle-charges-its-lax says Blackbaud failed to implement appropriate safeguards, allowed the breach to go undetected for months, retained data longer than necessary, paid 24 Bitcoin after the attacker threatened to expose stolen data, and never verified that the attacker deleted the data. These are FTC allegations and order terms, not private forensic logs made public by Blackbaud. They are still central because they identify the public accountability standard: security, retention, detection, notice, and deletion proof are one chain.

That chain is why this is a cloud-service dependency case. Customers did not merely need their own incident response. They needed vendor evidence that could be converted into lawful, accurate, customer-specific notices. A charity cannot responsibly tell supporters "no action is required" if the vendor's own review is not yet strong enough to support that statement. A university cannot tell alumni whether bank fields or identity numbers were involved if the vendor has only analyzed file names and not the relevant contents. Notice timing becomes a control surface.

Charity data is not low-risk because the institution is benevolent

The phrase "charity data" can sound soft. It is not. A donor database can contain names, home addresses, email addresses, phone numbers, birth dates, family relationships, employer information, wealth indicators, estate-giving interests, recurring donation history, bank details, event attendance, volunteer preferences, board affiliations, campaign notes, religious or political association, health foundation relationships, and contact histories that reveal private ties. In a university context, alumni records can include degree, year, student identifiers, engagement patterns, career details, and philanthropic capacity.

In a healthcare foundation context, the institutional relationship can imply sensitive health proximity even when clinical records are not in the breached system.

Blackbaud's 2023 Form 10-K at https://www.sec.gov/Archives/edgar/data/1280058/000128005824000013/blkb-20231231.htm describes fundraising and relationship-management products including Raiser's Edge NXT, Blackbaud CRM, eTapestry, Luminate Online, TeamRaiser, JustGiving, Fundraiser Performance Management, and Altru. The product descriptions matter because they show the dependency surface: fundraising, donation forms, campaign management, digital giving, event fundraising, analytics, engagement, membership, and constituent records. Those are not isolated customer files. They are operational memory for institutions that often have long relationships with people.

Customer notices make the human layer visible. The University of Alabama notice at https://giving.ua.edu/data/ said Blackbaud notified the university on July 16, 2020 that a ransomware attack occurred in May and that a subset of several clients' data had been copied. The UNC System notice at https://www.northcarolina.edu/blackbaud-information-security-incident/ described Blackbaud as one of the world's largest constituent relationship management providers for higher education and said the self-hosted data environment had been affected. Edinburgh Napier University's notice at https://www.napier.ac.uk/alumni/alumni-news/latest-news/blackbaud-data-security-incident listed categories including contact details, course and education details, engagement with alumni and fundraising activities, professional details, and interests provided through surveys.

The charity notices were not identical because customer data was not identical. Child & Family Service's notice at https://childandfamilyservice.org/securityincident/ referred to biographical, contact, giving history, and relationship information. The Task Force for Global Health at https://www.taskforce.org/blackbaud-data-security-incident/ described a third-party vendor incident and an investigation into donor data impact. Ridgewater College's notice at https://ridgewater.edu/alumni-friends/ridgewater-college-foundation/blackbaud-data-security-incident/ said Blackbaud was targeted between February 7 and intermittently until May 20, 2020 and notified the college on July 16. These notices are valuable because they show downstream institutions translating one vendor event into many local trust relationships.

The accountability problem is that those downstream institutions were both victims and messengers. They had to answer questions from donors, alumni, and supporters while depending on Blackbaud's investigation. They also had to evaluate whether their own data practices made the impact worse: Did they store sensitive data in free-text fields? Did they upload unencrypted attachments? Did they keep old records without a current purpose? Did they understand how Blackbaud retained former-customer data? The vendor controlled the platform, but customers controlled some of the data choices inside it. Accountability follows both layers, in order.

Confirmed facts, supported inference, and unknowns must stay separate

The confirmed public facts are enough to make the case serious. The SEC order says over a million files concerning over 13,000 customers were accessed and exfiltrated. It says the company detected the attack on May 14, 2020, announced the incident and notified impacted customers on July 16, filed a Form 10-Q on August 4, and disclosed in a September 29 Form 8-K that unencrypted fields intended for bank account information, Social Security numbers, usernames and/or passwords may have been accessed for some customers.

The FTC release says the breach went undetected for three months, millions of consumers' personal data was involved, unnecessary data retention was part of the problem, and the order required deletion of data no longer needed plus a comprehensive information security program.

Confirmed enforcement outcomes are also clear. Blackbaud's October 2023 announcement at https://www.blackbaud.com/intelligence team/article/blackbaud-resolves-multi-state-attorneys-general-investigation-of-2020-security-incident says it agreed to pay USD 49.5 million to 49 states and the District of Columbia and to implement or improve cybersecurity programs and tools, while not making misleading statements related to data protection, privacy, security, confidentiality, integrity, and breach notification matters. New York's Attorney General release at https://ag.ny.gov/press-release/2023/attorney-general-james-and-multistate-coalition-secure-495-million-cloud-company described the settlement as resolving a multistate investigation into the exposure of donor information. California's Attorney General release at https://oag.ca.gov/news/press-releases/attorney-general-bonta-secures-675-million-settlement-against-blackbaud-over announced a separate USD 6.75 million settlement in 2024. These are civil resolution records, not criminal findings.

Supported inference is narrower. It is reasonable to infer that many customers could not independently determine file-content scope from their own systems because the incident occurred inside Blackbaud's environment and because the SEC order describes Blackbaud's file-name review and later customer concerns about unencrypted fields. It is reasonable to infer that notice quality was uneven because downstream notices depended on evolving vendor information.

It is reasonable to infer that unnecessary retention increased the population of people exposed because the FTC alleged Blackbaud retained data longer than necessary, including information belonging to former customers.

Unknowns must remain unknown. The public record does not give a complete list of every affected customer, every affected person, every file name, every copied field, every encrypted field, every customer-specific product instance, every private notice, every law-enforcement communication, every attacker communication, every forensic conclusion, or every security improvement. It does not prove that every copied record was misused. It does not prove that attacker deletion occurred. It does not prove that all customers stored data responsibly. It also does not prove that all later remediation was ineffective.

A responsible accountability file should not fill those gaps with unsupported accusations.

That separation is not a legal nicety. It is the discipline that incident response itself should use. Confirmed facts tell people what action to take. Supported inferences tell customers what questions to ask. Unknowns tell regulators where to demand evidence. If the three categories are blended, breach communication becomes either false comfort or panic. Blackbaud's case shows why the categories must be explicit from the first notice.

Ransom payment is not deletion proof

The ransom-payment record is central because many downstream notices repeated the idea that Blackbaud paid and received assurances that the copied data was destroyed. The FTC release at https://www.ftc.gov/news-events/news/press-releases/2024/02/ftc-order-will-require-blackbaud-delete-unnecessary-data-boost-safeguards-settle-charges-its-lax states that Blackbaud paid 24 Bitcoin after the attacker threatened to expose the data and, according to the FTC, never verified that the attacker actually deleted the stolen data. Customer notices such as Edinburgh Napier's, Child & Family Service's, and the University of Alabama's described assurances or confirmation from Blackbaud about deletion. Those notices show the downstream dependency on the vendor's language.

The accountability issue is that ransom payment can be a crisis decision, but it is not a security control. It does not prove deletion. It does not prove that no copy was made. It does not prove that no data was viewed. It does not close the retention issue. It does not notify affected people. It does not repair the access path. It does not replace encryption, segmentation, multifactor authentication, vulnerability management, monitoring, least privilege, backup validation, data minimization, and disclosure controls.

The CISA StopRansomware guide at https://www.cisa.gov/stopransomware/ransomware-guide and the NIST incident handling guide at https://csrc.nist.gov/pubs/sp/800/61/r2/final provide useful public vocabulary here. They do not make findings about Blackbaud. They define why a ransomware event must be handled through preparation, detection, containment, eradication, recovery, communication, and lessons learned. If a provider pays a ransom, that decision sits inside the response record. It should not become the proof that consumers are safe.

For mission-led customers, the deletion problem is especially hard. A charity may not have the technical capacity to question a vendor's deletion claim. A university may have legal counsel but not access to the vendor's attacker communications. A small foundation may issue a notice using vendor wording because it has little else. That is why regulators matter. The FTC's order requiring data deletion and retention schedules turned a deletion claim into an operational obligation: the company must delete data it no longer needs and document why retained data remains necessary.

The durable lesson is that data deletion must be controllable before an incident. If a company retains old customer data because storage is cheap and cleanup is complicated, it creates a larger breach population. If it cannot prove what was in copied files, it cannot issue precise notices. If it relies on attacker promises, it has transferred proof of safety to the least trustworthy party in the chain. Accountability requires deletion evidence that belongs to the provider, not to the attacker.

Customer notices show delegated accountability under pressure

The downstream notices are the best public evidence of how the incident reached communities. University, charity, and foundation notices repeated Blackbaud's description of the event, explained local categories of data, and told affected people what the institution was doing. That repetition is not a defect by itself. It is how third-party incident communication works. The defect appears when the upstream source is incomplete, overly certain, or slow to update.

UNC's notice at https://www.northcarolina.edu/blackbaud-information-security-incident/ framed Blackbaud as a major higher education constituent relationship management provider. The University of Alabama notice at https://giving.ua.edu/data/ described donor-related records and the vendor's payment-and-deletion assurance. Edinburgh Napier's notice at https://www.napier.ac.uk/alumni/alumni-news/latest-news/blackbaud-data-security-incident described alumni and fundraising engagement fields. The Task Force for Global Health at https://www.taskforce.org/blackbaud-data-security-incident/ emphasized donor information and an ongoing institutional investigation. Each notice had to localize the vendor event for a distinct community.

This is delegated accountability. The vendor controls the evidence. The customer controls the relationship with constituents. The constituent carries the risk. If the vendor's evidence is late, the customer looks evasive. If the customer's data hygiene is poor, the vendor's incident has a wider effect. If the constituent loses trust, the charity's mission can suffer even when the charity did not operate the compromised infrastructure. The line between vendor risk and mission risk disappears.

Public-sector continuity is part of this because many nonprofits, universities, and health-adjacent foundations are not decorative institutions. They support education, medical research, social care, cultural heritage, disaster response, community services, and vulnerable populations. A breach of constituent records can reduce fundraising confidence, create support burdens, distract staff, and make people hesitant to engage. The operational harm is not always a system outage.

Sometimes the harm is a trust outage: phones ring, donors ask for explanations, alumni question data practices, and staff lose time reconstructing records and legal obligations.

The vendor should therefore design incident communication for delegated accountability. That means customer-specific scope, clear uncertainty labels, action guidance, supplemental-notice triggers, regulator coordination, and evidence retention. It also means avoiding categorical assurances before file contents and customer field practices are known. In Blackbaud's case, the later SEC and FTC records show why early certainty became a liability.

Enforcement turned notice quality into a control obligation

The SEC, FTC, state attorney general, and California records each stress a different part of the chain. The SEC looked at investor disclosure and disclosure controls. The FTC looked at consumer protection, data security, retention, notice, and representations. State attorneys general looked at data security, breach notification, and consumer-protection duties across jurisdictions. California added a separate settlement record. Together they turned notice quality into a control obligation, not a communication preference.

The AP report at https://apnews.com/article/dba8fac12af30f74691c7af4fec69a14 is useful as a public-news summary because it describes the multistate settlement and notes that the breach affected more than 13,000 nonprofits and exposed sensitive information from millions of people, while also noting that Blackbaud did not admit wrongdoing in the settlement. Reuters' reporting at https://www.reuters.com/legal/software-firm-blackbaud-pay-3-mln-misleading-disclosures-ransomware-attack-sec-2023-03-09/ similarly summarized the SEC settlement. News reports do not replace the orders, but they show how enforcement records translated into public understanding.

Notice quality has several components. First, timing: did the customer learn fast enough to protect affected people? Second, specificity: did the notice identify the data categories at issue? Third, accuracy: were categorical claims supported by evidence? Fourth, update duty: did the company correct notices when new facts emerged? Fifth, actionability: did affected people know what to do? Sixth, accountability: did the company identify which facts were confirmed, which were under investigation, and which were unknown?

Blackbaud's public record shows weakness in several of those components. The SEC order says the August filing omitted the material fact that some unencrypted bank account and Social Security number data had been exfiltrated, even though personnel had learned it. The FTC alleged Blackbaud waited nearly two months to notify customers and then misled consumers about the extent of stolen data, including statements that customers did not need to take action. State settlements required changes around data security and breach notification practices. This is a case about evidence moving too slowly through the organization.

An organization that handles other institutions' sensitive records should treat disclosure controls as part of security architecture. It needs a pathway from forensic findings to customer notices, SEC filings, privacy regulators, call-center scripts, board oversight, and customer-specific remediation. If that pathway is informal, the first statement can become a trap. Technical teams may know one fact, customer teams another, legal teams another, and senior leadership another. The public receives an average of ignorance.

Data retention made the accountability problem larger

The FTC's data-retention focus is one of the most important parts of the Blackbaud record. Retention is often invisible until a breach. Before an incident, extra historical data can seem useful: old donors might return, old alumni might give, old event attendees might join a campaign, old attachments might help reconstruct a relationship. After an incident, extra data becomes exposure inventory. If the organization cannot explain why it still holds a field, it has stored risk without a purpose.

The FTC release says Blackbaud held onto data longer than necessary, including information belonging to former customers. That detail matters because it changes the fairness of risk allocation. A person may stop donating, graduate, leave a program, or withdraw from a campaign. The original institution may stop using a vendor. If data remains in a hosted environment years later, the exposed person still carries risk without any current service benefit. A retention failure can turn a vendor breach into a long-tail harm for people who have no practical way to demand deletion.

Data sovereignty and locality also enter here. Blackbaud supported customers in many countries, and its 2023 Form 10-K describes operations in the United States, Australia, Canada, Costa Rica, and the United Kingdom, with users in more than 100 countries. That global platform context matters. A customer in one jurisdiction may have obligations to donors or alumni in another. A UK university, Canadian charity, US hospital foundation, or Australian nonprofit may face different privacy, notification, and retention obligations. The vendor's hosted architecture and customer-specific data maps become legal infrastructure.

The ICO ransomware guidance at https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/ransomware-and-data-protection-compliance/ is useful context because it treats ransomware as a data protection issue, not only a malware incident. It does not make a Blackbaud-specific finding in this article. It shows why personal data breach analysis must include security, availability, confidentiality, exfiltration, controller and processor obligations, and evidence. In a multi-tenant nonprofit platform, those obligations are distributed but not diluted.

Retention discipline is also a customer duty. Customers should not store Social Security numbers, bank details, medical notes, passport information, or sensitive free-text attachments in relationship systems unless they have a defined purpose, encryption posture, access policy, deletion schedule, and vendor assurance. The SEC order's discussion of unencrypted attachments and fields is a warning: customers can create sensitive-data pockets inside systems that procurement may not understand. The vendor must protect the platform, but customers must know what they put into it.

Customer assurance has to be product-specific

The Blackbaud record also shows why generic vendor assurance is too weak for constituent-management platforms. A nonprofit customer may use one product for donor records, another for online campaigns, another for event fundraising, and another for analytics or grant management. Each product can store different data, apply different defaults, create different exports, and support different attachment or free-text practices. If an incident notice says only that "customer data" was copied, the customer still has to know which product, which fields, which historical records, which exports, and which integrations are involved.

Product-specific assurance should begin with data maps. A customer should be able to see which Blackbaud systems hold names, addresses, giving history, bank fields, identity numbers, login fields, engagement notes, attachments, event attendance, relationship links, and imported files. It should know whether those fields are encrypted, searchable, exportable, backed up, or retained after contract termination. It should also know whether customer administrators can accidentally place sensitive data into weaker fields. In the Blackbaud case, the regulator record made field and attachment placement part of the accountability story.

That should become a procurement lesson.

The same assurance should cover integrations. Fundraising systems rarely stand alone. They connect to payment processors, email platforms, analytics tools, web forms, event systems, data warehouses, finance systems, and identity providers. A ransomware incident in the main vendor environment may not directly compromise every integration, but the customer still needs to know whether tokens, exports, webhooks, API logs, or imported files were in the affected estate. A narrow "database" answer may miss the operational reality of how fundraising work is automated.

Small charities need this evidence in a form they can use. A large university may have privacy counsel, procurement staff, and security reviewers. A local charity may have one operations manager, a part-time fundraiser, and a board member responsible for technology oversight. If vendor assurance is written only for enterprise lawyers, the customers with the least internal capacity may make the weakest retention and notice decisions.

A cloud provider that serves mission-led institutions should therefore publish layered assurance: a plain-language incident summary, a customer-specific data-category report, a security-control update, and deeper material for regulated or high-risk customers.

Customer assurance should also separate live systems from backups and archives. Constituents often assume that if they stop giving or ask a charity to stop contacting them, their risk declines. That may not be true if old exports, backup sets, archived campaign files, or former-customer databases remain. The FTC's retention concerns make this point concrete. A defensible assurance package should explain deletion schedules and backup retention in a way customers can translate into their own privacy notices.

Finally, product-specific assurance should be continuous. It should not begin only after an incident. Customers should review data categories at implementation, after major campaigns, when importing legacy records, when changing payment flows, when enabling new modules, and at renewal. A breach exposes historical decisions. Better governance reduces the history that can be exposed.

That continuous review should include role design as well as data fields. Fundraising, alumni relations, grant administration, finance, events, volunteer management, and executive reporting can all require different access patterns. If broad administrator rights become a convenience default, the customer creates a larger exposure surface inside the vendor environment. If the vendor cannot show customers where privileged roles exist, when they were last used, and which exports or attachments they can reach, the customer cannot govern its own portion of the risk.

The Blackbaud record therefore points to a shared assurance obligation: the provider must make product controls visible enough to use, and customers must treat those controls as part of donor and constituent stewardship rather than a back-office setting with recurring board-level review.

What durable repair should prove

Durable repair after the Blackbaud incident should prove seven things. First, it should prove scope. The provider should know which products, customers, files, fields, attachments, data categories, and person populations were affected. File-name review may be a starting point, but a scope claim that affects bank information or identity numbers needs content-level evidence or a documented reason why content-level review is impossible.

Second, it should prove notice integrity. There should be a documented route from forensic facts to customer notices, supplemental notices, investor disclosures, regulator reports, call-center scripts, and board reports. If a technical team learns a notice is wrong, the correction should not depend on informal escalation. The SEC case shows that disclosure controls are themselves a security outcome.

Third, it should prove retention control. Data-retention schedules should be product-specific and customer-specific enough to explain why data is held, when it will be deleted, and who can approve exceptions. Former-customer data should not remain in production or accessible backup environments without a defensible need. If retention is legally required, it should be protected according to sensitivity.

Fourth, it should prove encryption and field governance. A provider that allows free-text fields and attachments must know where sensitive data might appear outside protected fields. Encryption only helps if customers cannot accidentally place sensitive data in unencrypted locations. Product design, customer guidance, scanning, warnings, and default controls are all part of the repair.

Fifth, it should prove access control and segmentation. The FTC alleged failures in monitoring, segmentation, multifactor authentication, password controls, firewall controls, and testing. Durable repair would show least privilege, stronger authentication, environment separation, privileged access monitoring, vulnerability closure, log coverage, and tested detection.

Sixth, it should prove ransomware response without relying on attacker assurances. If copied data is claimed to be destroyed, the company should state what evidence supports that claim and what uncertainty remains. If deletion cannot be verified, notices should not imply verification. Payment does not erase notification duty.

Seventh, it should prove customer governance. Blackbaud customers should receive evidence that helps them correct their own practices: sensitive-field usage, attachment risks, retention settings, encryption options, logging access, and recommended notice templates. Vendor repair is incomplete if customers can recreate the same exposure patterns inside the product.

Accountability follows control over evidence

The final allocation follows practical control. Blackbaud controlled the hosted environment, security program, incident response, forensic vendors, first customer notices, attacker-communication evidence, data-retention architecture, product safeguards, disclosure controls, and regulator cooperation. Customers controlled their collection and field-use choices, local notices, constituent relationships, and post-incident governance. Regulators controlled enforcement. Affected people controlled only a small set of protective actions after they received enough information to act.

That allocation does not require unsupported accusations. It does not say every exposed record was misused. It does not say every customer handled data badly. It does not say every later safeguard failed. It says the party with the evidence gate had the highest duty to move accurate facts quickly. The SEC, FTC, state, customer, and public records all point to that gate.

The Blackbaud case remains important because it shows a hidden cost of nonprofit cloud concentration. Mission-led institutions can pool operational data inside a specialist vendor and gain efficiency. But when the vendor is compromised, donors, alumni, patients, students, and supporters become a distributed harm population. They are not only customers of a charity. They are data subjects in a vendor system they may not know exists.

The durable lesson is simple and hard: a cloud provider for the social sector must be able to prove what it holds, what was copied, what was encrypted, what was retained unnecessarily, what customers were told, what changed when new facts emerged, and what safeguards prevent recurrence. Without that proof, charity data notice becomes an exercise in borrowed trust. With that proof, customers can turn a vendor incident into precise, timely, accountable communication rather than generalized reassurance.