The Chain of Custody Donors Don’t See
Trace a single $25 monthly gift through the sector’s plumbing. Almost every link in the chain is a vendor — and most of them are us.
Picture a recurring donor. She’s 62, gives $25 a month to a regional food bank, has done so since 2019. To her, the relationship is simple: a logo she trusts, a checkout page she’s used a hundred times, a tax letter every January. She’d guess that her information is held by the food bank.
She’d be mostly wrong. Not because the food bank is careless, but because the food bank is small, and small organizations don’t run their own infrastructure. Almost every step in the operational journey of her gift is performed by a third party. Some of those third parties have direct contractual relationships with the food bank. Many do not — they are subcontractors of subcontractors, downstream processors, vendors of vendors. Today we’d like to walk through what that journey actually looks like, because we think the field talks about it less than it should.
The donation form
Her gift starts on a donation form embedded in the food bank’s website. The form is almost certainly hosted by a fundraising platform — not by the food bank. The platform sees her name, email, address, gift amount, designation, payment method, IP address, browser, and (depending on configuration) a tracking pixel that ties this transaction to a campaign or ad. Before she even clicks ‘Donate,’ she has shared a meaningful slice of her identity with at least one vendor she has never heard of.
The payment rail
Her card details move through a payment processor. If the processor is well-implemented, the food bank and the fundraising platform never touch the raw PAN; they hold a token. If it’s not well-implemented, more of the payment data persists in places it shouldn’t. Either way, the processor itself holds the full payment record, often for years, and is governed by a different regulatory regime (PCI-DSS) than the rest of the chain.
The donor management system
Once the gift is captured, her record lands in a donor management system. The DMS is where she becomes a longitudinal subject — a row that grows over time. Her giving history accrues. Notes from staff are added: ‘attended gala 2022,’ ‘asked about planned giving,’ ‘lost husband last year.’ Pastoral, useful, and intensely personal. The DMS is also where wealth screening data is often appended — third-party-supplied estimates of her real estate, philanthropy at other organizations, board affiliations, and inferred capacity to give. None of that data is collected from her. It is purchased about her.
The downstream environments
From the DMS, her record fans out. A direct marketing vendor receives a slice of it to power the next appeal. An analytics tool ingests another slice for retention modeling. A grant reporting tool aggregates her gift into a funder report. An email service provider stores the deliverability metadata that determines whether next month’s appeal lands in her inbox. If the food bank uses a CRM, parts of her record sync there too. If they have a peer-to-peer fundraising tool, that tool may have its own copy.
By the time she sees an acknowledgment letter, her information has been touched by anywhere from four to twelve distinct vendor systems — and the food bank itself has only operated one or two of them.
Where the responsibility actually sits
Two things follow from this map. The first is that the nonprofit is, in most cases, a small node in a much larger custodial graph. The food bank’s IT team — if it has an IT team — can reasonably influence two or three of the systems in the chain. The rest is shaped by us. By our default settings. By the data we choose to retain. By the integrations we offer. By the audit logs we expose. By the export formats we make easy. The donor’s experience of trustworthiness is, downstream of her checkout click, almost entirely a function of vendor product decisions.
The second is that the conventional language of ‘data processor’ undersells what we are. We are not, in practice, neutral conduits acting on instructions from the data controller. We are the architects of the operational environment in which the data lives. Our defaults become the sector’s defaults. Our retention windows become the sector’s retention windows. Our incident response timelines become, by extension, the timelines that determine when a 62-year-old donor finds out a stranger has her giving history.
What this changes about the work
It doesn’t change the work as much as it reframes it. It means the security review you do on a new feature isn’t only a question of ‘does this expose data we hold?’ It is also a question of ‘does this make the chain of custody longer or shorter? More or fewer hands? More or fewer copies?’ It means data minimization isn’t a privacy compliance line item; it is a structural choice about how much trust the sector has to underwrite to use your product. It means that the integrations you make easiest to enable are, in effect, votes about which downstream environments donor data is most likely to reach.
We’re not arguing for any particular product change today. We’re arguing that the chain of custody is something the sector talks around more than it talks about, and that the people best positioned to draw the map are the people who built the systems on the map. That’s us. Tomorrow we’ll look at how the infrastructure got this big, this fast, and what we think follows from that.
