Foundry data processing agreement
Version 2.0. Last updated: 29 October 2026
Between:
- the charity that accepts this agreement when it signs up to Foundry, as shown in its acceptance record (the Controller);
- Giftease Solutions Limited, a company registered in England and Wales (number 12192220), whose registered office is 86 Beaver Road, Maidstone, Kent, ME16 0FN (the Processor).
Date: the date of acceptance. Version: 2.0. Supplements: the Foundry terms the Controller accepted when it signed up (the Foundry terms). The Services means Foundry as provided to the Controller under the Foundry terms. The end of the Services means the date the Controller's Foundry account is closed, by either party, under the Foundry terms.
1. Roles and the law
1.1 The Controller decides why and how personal data is used. The Processor processes it only on the Controller's behalf, to provide Foundry.
1.2 Both parties comply with the UK GDPR and the Data Protection Act 2018 ("Data Protection Law"). Defined terms have their Data Protection Law meanings.
1.3 This agreement may be accepted electronically by a person authorised by the Controller. The Processor keeps a record of who accepted it, their role, the version and when.
2. What is processed (Article 28(3) particulars; Schedule 1 has the detail)
- Subject matter: providing Foundry to the Controller. That means:
- collecting Gift Aid declarations from its supporters through the channels the Controller switches on (letters with personal codes, email links, the Controller's website, the hosted Gift Aid page, its own forms, our API);
- recording each declaration with its evidence;
- holding the Controller's supporter records;
- receiving supporters' follow-up queries and passing them to the Controller;
- reporting to, returning to and deleting for the Controller.
- Duration: for as long as the Services run, then clause 9.
- Retention while the Services run:
- (a) supporter records with no declaration and no activity for 24 months are deleted automatically. A supporter record that holds a declaration (made or cancelled) is never deleted automatically while the Services run;
- (b) campaign working files (upload files, letter batches, print files made for a send) are deleted 30 days after the campaign ends;
- (c) declarations and their evidence are kept for as long as the Services run, because they are the Controller's Gift Aid records.
- The Controller may delete any record earlier.
- Nature and purpose: collection, storage, matching, display (to a supporter only after they verify themselves), recording, confirmation by PDF/email, reporting to the Controller, return and deletion. No other purpose: no marketing by the Processor, no profiling, no sale, and no use to train any AI model.
- Types of personal data: Schedule 1.
- Categories of data subjects: the Controller's supporters (and anyone they name in a follow-up query, e.g. a deceased partner); the Controller's staff who use Foundry.
3. Instructions
3.1 The Processor processes personal data only on the Controller's documented instructions (this agreement, and the Controller's settings and actions in Foundry), including on transfers outside the UK, unless the law requires otherwise. In that case it tells the Controller first, unless the law forbids that.
3.2 The Processor tells the Controller straight away if it thinks an instruction breaks Data Protection Law.
3.3 The Controller's part. The Controller is responsible for: having a lawful basis for the personal data it gives the Processor or asks it to collect; telling its supporters, in its own privacy notice, that it uses a service provider to collect and hold their Gift Aid declarations; sending email through Foundry only to supporters who have agreed to hear from it by email, where the law requires that; the accuracy of the records it uploads; and, where it instructs the Processor to read its data from another system (for example its CRM or Cascade), having the right to give that instruction.
4. People
Everyone authorised to process the data is bound by confidentiality and sees only what their role needs.
5. Security (Article 32)
5.1 The Processor keeps appropriate technical and organisational measures, set out in Schedule 2.
5.2 These include, as a minimum:
- a supporter's details are shown to them only after they verify themselves;
- limits on repeated attempts;
- encryption in transit and at rest;
- least-privilege, logged access;
- no payment card or bank data collected from supporters;
- free-text follow-ups ask supporters not to include medical or financial details.
6. Sub-processors
6.1 The Controller authorises the sub-processors in Schedule 3.
6.2 The Processor gives 30 days' written notice of any addition or replacement. The Controller may object on reasonable data-protection grounds, and may then end the Services without penalty.
6.3 Each sub-processor is bound by written terms giving the same protection as this agreement. The Processor stays liable for them.
7. International transfers
No transfer outside the UK unless Schedule 3 lists it, and then only with a lawful mechanism (UK adequacy regulations, the UK International Data Transfer Agreement or Addendum, or the UK Extension to the EU–US Data Privacy Framework).
8. Helping the Controller
8.1 Data-subject rights: Foundry lets the Controller find any supporter and view, export, correct or delete their data at any time, whatever its plan or credit balance. The Processor passes any request it receives from a supporter to the Controller within 5 working days, and helps the Controller answer it.
8.2 Breaches: the Processor tells the Controller without undue delay, and within 24 hours of becoming aware of a personal data breach. It gives what it knows (nature, categories and numbers, likely consequences, measures taken), then updates as more is known. The Controller decides on any notice to the ICO or to supporters.
8.3 DPIA / ICO consultation: the Processor gives reasonable help.
8.4 HMRC: if HMRC asks the Controller for its declaration records, Foundry lets the Controller export them at any time, whatever its plan.
9. End of processing
9.1 At the end of the Services, the Processor returns all of the Controller's records as a download for the Controller's administrators:
- every declaration, including any not yet viewed on the Controller's plan, each with the confirmation PDF its supporter received;
- the evidence and history of each declaration;
- supporters, suppressions, queries, campaigns and letters;
- a record of earlier exports;
- a manifest of counts and checksums.
The download is available to the Controller's administrators, each behind their own sign-in with multi-factor authentication, for 30 days, and every download is recorded. The Processor emails every administrator when the download is ready and again before deletion. If the Controller has no administrator able to sign in, it can appoint a new one through a request confirmed by a trustee or its chief executive, which the Processor verifies.
9.2 The Processor then deletes all of the Controller's personal data, within 30 days of the end of the Services, the only exception being retention the law requires (limited to that purpose).
9.3 Copies that age out on a schedule are deleted by then:
- database backups within about 8 days of the deletion;
- hosting request logs within 30 days of the Controller's last request;
- email-provider records within 37 days of the last email sent for the Controller.
9.4 The Processor confirms in writing what it returned, when it deleted, and the date by which the last copy is gone.
9.5 The Processor keeps a record that the return and deletion happened (dates, counts and checksums, no personal data about supporters) for 6 years. It also keeps its own billing and VAT records for the Controller's account (amounts, dates, plans and payment references; no personal data about supporters) for 6 years after the end of the Services, as the law requires.
9.6 The Controller keeps its own Gift Aid records for as long as HMRC requires. The returned download is that record.
10. Audit
The Processor makes available the information needed to show compliance with this agreement, and allows audits or inspections by the Controller or its auditor on 30 days' notice, at most once a year unless after a breach.
11. Liability and precedence
Liability follows the Foundry terms. If this agreement and the Foundry terms conflict on data protection, this agreement wins.
12. Law
This agreement is governed by the law of England and Wales, and the courts of England and Wales have jurisdiction.
Schedule 1: the data
| Category | Fields | Source | Why |
|---|---|---|---|
| Identity | title, first name, surname, supporter reference | the Controller's file, connector or API; or the supporter | to address the supporter, and so they can confirm who they are |
| Contact | home address, postcode; email (only where the supporter has agreed to email from the Controller, or gives it themselves) | the Controller / the supporter | a declaration requires a home address; the confirmation |
| Personal code | a code per supporter, derived by keyed hash (only a hash is stored) | generated by the Processor | to open the supporter's own declaration |
| Identity check | the year of first gift (year only); segment | the Controller | the "Have you moved?" check, and which letter to send |
| Gift information (only if the Controller uploads it) | the amount a supporter's eligible gifts could be worth in Gift Aid since a given date (the "worth amount"); gift totals | the Controller | to personalise the ask with the Controller's own figure; never shown as a promise |
| Declaration | made / declined / cancelled, the reason chosen (including "I don't pay enough UK tax", "not me", "has died"), the wording version shown, timestamps, channel, any new home address given, the confirmation PDF sent | the supporter | the Controller's Gift Aid record and evidence, and its suppression list |
| Technical evidence | a keyed fingerprint of the network address (no address stored); the browser description | the supporter's device | evidence of how the declaration was made |
| Charity users | name, role, work email, sign-in and audit records; DPA acceptance records | the Controller's staff | to run Foundry and show who did what |
| Follow-up | category, free text (asked not to contain medical/financial details); possibly that a named person has died | the supporter | to pass the query to the Controller |
Not collected: National Insurance numbers, tax references, bank or card details of supporters, special-category data. A free-text follow-up may say that someone has died, or occasionally mention a health detail; such text is only passed to the Controller.
Where supporters come from: a file the Controller uploads; the Controller's CRM through a connector it authorises; our API; supporters who make a declaration themselves on the Controller's page; or, for Cascade clients, a read of the Controller's Cascade data that the Controller instructs in writing.
Schedule 2: security measures
- Hosting: Google Cloud. The web service and the database run in the UK (London), on a production instance reachable only through Google's authenticated access, by the service and the Processor's authorised operators.
- Encryption: all traffic over HTTPS (TLS); data and backups encrypted at rest by Google. Application secrets are held in Google Secret Manager, never in code.
- Separation between charities: row-level security per charity on every table holding the Controller's data; an isolation test suite checks it on every change.
- Access control: named accounts; multi-factor authentication for every Foundry user and every human administrator; service credentials in a secrets manager.
- Supporter access: each supporter reaches only their own declaration, with a personal code derived with a secret key and never stored (only a keyed hash is kept). Nothing about the supporter is shown until they verify themselves. Unknown codes and wrong answers get the same reply. Repeated wrong attempts are limited.
- The page: the form is shown only on the Controller's registered web addresses; strict browser security rules; never indexed by search engines; no personal data in web addresses.
- Network addresses: a supporter's network address is never stored in the Foundry database; only a keyed fingerprint, under a key held in the secrets manager. Hosting request logs, which include network addresses, are kept for 30 days in Google Cloud Logging.
- Evidence and integrity: each declaration keeps the exact wording shown (version + fingerprint), the confirmation PDF exactly as sent, when and how it was made, and an append-only history.
- Backups: daily, with point-in-time recovery, kept 7 days, held in the UK and the EU; covered by clause 9.3.
- Return and deletion: as clause 9, with a test on every change that deleting one charity leaves every other charity's data untouched.
- Staff: bound by confidentiality and trained on this agreement.
- Incidents: clause 8.2.
- No secondary use: no marketing, profiling, sale, or use of the Controller's data to train any AI model.
Schedule 3: authorised sub-processors
| Sub-processor | What it does | Where | Transfer mechanism |
|---|---|---|---|
| Frametric Limited (company number 16991542) | builds and operates the Foundry systems for the Processor | UK | none needed (UK); a written processing agreement between the Processor and Frametric Limited giving the same protection as this agreement (being finalised with our solicitors) |
| Google Cloud (Cloud Run, Cloud SQL, Secret Manager, Logging) | hosting, database, secrets, logs | London (service and database); Secret Manager and Logging in Google's global locations | none needed for the service and database (UK); Google's Cloud Data Processing Addendum, including its UK transfer terms for anything processed outside the UK |
| Cloudflare, Inc. (US) | protects and routes sign-in traffic for the Controller's staff (the central sign-in on frametric.ai) | Cloudflare's global network | Cloudflare's Data Processing Addendum: EU SCCs + the UK Addendum; the EU–US DPF with the UK Extension |
| Resend, Inc. (US) | sends confirmation emails and account emails | United States (storage); content and delivery logs kept 30 days + 7 days of backups | EU SCCs Module Three + the UK Addendum; the EU–US DPF with the UK Extension as an additional mechanism |
| Google Cloud Vertex AI (Anthropic models made available by Google) | sorts email sent to Giftease's shared mailboxes (subject, sender and the first part of the message), so a person at Giftease can route it; this can include a message from one of the Controller's supporters, which is forwarded to the Controller and not answered by Giftease | europe-west1 (Belgium) | UK adequacy (EEA). Called through Vertex AI's regional endpoint in Belgium and served by Google under its Cloud Data Processing Addendum and its terms for third-party models on Vertex AI. Not the separately contracted Anthropic API: a move to it would be a change of sub-processor under clause 6.2. |
AI: the only AI processing is the email sorting above. No AI model is given the Controller's supporter records, declarations or evidence, and no data of the Controller's is used to train any model.
Accepted electronically for the Controller by an authorised person at sign-up (clause 1.3); the Processor keeps the acceptance record. For the Processor: Giftease Solutions Limited.
Address lookup and print and post: if the Controller switches on address lookup, or asks Giftease to arrange printing and posting, we add the provider to Schedule 3 under clause 6.2 before any data goes to them.