Add to WordPress

Data Processing Agreement (DPA)

This Data Processing Agreement (“DPA”) forms part of the agreement (“Principal Agreement”) between:
  • [CUSTOMER / CHARITY LEGAL NAME] (“Controller”); and
  • A Latty trading as “Cheerful Give”, of Ashburnham Place, Battle, TN33 9NF (“Processor”, “Cheerful Give”),
each a “party” and together the “parties”, and governs the Processor’s processing of Personal Data on the Controller’s behalf when the Controller uses the Cheerful Give plugin and platform (“the Services”).

1. Definitions

“UK GDPR”, “controller”, “processor”, “data subject”, “personal data”, “processing”, “personal data breach” and “supervisory authority” have the meanings in the UK GDPR and the Data Protection Act 2018 (“Data Protection Laws”). “Sub-processor” means any third party engaged by the Processor to process Personal Data.

2. Roles and scope

2.1 For the Personal Data described in Annex 1, the Controller is the controller and the Processor is the processor. 2.2 The Processor will process Personal Data only to provide the Services and only as set out in this DPA and the Controller’s documented instructions.

3. Processor obligations (UK GDPR Art 28(3))

The Processor shall:
  • (a) Instructions — process Personal Data only on the Controller’s documented instructions (including as to international transfers), unless required by law, in which case it will inform the Controller first unless the law prohibits this;
  • (b) Confidentiality — ensure persons authorised to process the Personal Data are under an appropriate duty of confidence;
  • (c) Security — implement the technical and organisational measures in Annex 3 (Art 32);
  • (d) Sub-processors — engage sub-processors only under clause 4;
  • (e) Data subject rights — taking into account the nature of the processing, assist the Controller by appropriate technical and organisational measures, insofar as possible, to respond to data subjects exercising their rights;
  • (f) Assistance — assist the Controller in ensuring compliance with its obligations under Articles 32–36 (security, breach notification, data protection impact assessments and prior consultation), taking into account the information available to the Processor;
  • (g) Deletion/return — at the Controller’s choice, delete or return all Personal Data at the end of the Services and delete existing copies, unless law requires storage;
  • (h) Audit/information — make available to the Controller the information necessary to demonstrate compliance with Article 28 and allow for and contribute to audits, including inspections, conducted by the Controller or an auditor it mandates (subject to reasonable notice, confidentiality, and no more than once a year absent a breach or regulator request).
The Processor shall immediately inform the Controller if, in its opinion, an instruction infringes Data Protection Laws.

4. Sub-processors

4.1 The Controller gives the Processor general authorisation to engage the sub-processors listed at getcheerful.org/sub-processors (see Annex 2). 4.2 The Processor will impose data-protection terms on each sub-processor that are no less protective than this DPA and remains liable for its sub-processors’ acts and omissions. 4.3 The Processor will give the Controller at least 30 days’ notice of any intended addition or replacement of a sub-processor (e.g. by updating the sub-processor list and/or email). The Controller may object on reasonable data-protection grounds; if the parties cannot resolve the objection, the Controller may terminate the affected Services. 4.4 Mailsync and the Controller’s own email provider. Where the Controller enables the Mailsync add-on, the Controller connects its own account with a third-party email provider (currently Mailchimp or MailerLite) using its own API credentials. The Plugin transmits opted-in donors’ contact details to that account on the Controller’s instruction. That provider is the Controller’s own processor and is not a sub-processor of the Processor; the Controller is responsible for its contractual and data-protection arrangements with that provider, for its mailing-list consent, and for honouring unsubscribe requests within that tool.

5. International transfers

The Processor shall not transfer Personal Data outside the UK unless it has taken measures necessary to make the transfer lawful under Data Protection Laws (e.g. the UK IDTA or SCCs with the UK Addendum, or an adequacy regulation). Current transfer mechanisms for each sub-processor are described in the sub-processor list.

6. Personal data breach

The Processor shall notify the Controller without undue delay and in any event within 72 hours of becoming aware of a personal data breach affecting the Controller’s Personal Data, and provide information reasonably required for the Controller to meet its own breach-notification obligations.

7. Liability and precedence

7.1 Each party’s liability under this DPA is subject to the limitations and exclusions in the Principal Agreement. 7.2 If there is a conflict, this DPA prevails over the Principal Agreement on data protection matters; and any applicable Standard Contractual Clauses / IDTA prevail over this DPA.

8. Term

This DPA takes effect when the Controller starts using the Services and continues while the Processor processes Personal Data on the Controller’s behalf.

Annex 1 — Description of the processing

  • Subject matter: processing donor Personal Data to take payment for, and record, donations made through the Controller’s Cheerful Give donation forms.
  • Duration: for the term of the Services (see clause 8).
  • Nature and purpose: collecting donor details from the donation form; relaying them to the payment processor (Stripe) as payment metadata; receiving confirmed-payment data and returning it to the Controller’s site; supporting recurring donations, receipts and refunds; and, where the Controller enables the Mailsync add-on, transmitting opted-in donors’ contact details to the Controller’s own email provider.
  • Types of Personal Data: donor first/last name; email address; Gift Aid declaration and home address (address lines, town/city, postcode) where Gift Aid is claimed; donation amount, any optional tip, frequency and campaign; marketing/mailing-list consent flag; Stripe customer/payment/subscription identifiers; IP address (used transiently for abuse prevention, not stored). Card/bank details are entered directly with Stripe and are not processed by Cheerful Give.
  • Storage and retention: donation records are stored in the Controller’s own WordPress database. The Plugin automatically anonymises donor Personal Data once the Controller’s chosen retention period has elapsed, retaining the figures required for the Controller’s accounts and UK Gift Aid records.
  • Diagnostic logs: an optional diagnostic log, disabled by default, may capture PHP error output containing Personal Data. It is transmitted to the Processor only when the Controller’s administrator actively sends it, is used solely for support, and expires automatically after one week.
  • Categories of data subjects: the Controller’s donors and prospective donors.
  • Special category data: none intended. (A donation may imply an affiliation; the Controller should assess this for its own purposes.)

Annex 2 — Approved sub-processors

As listed in the current sub-processor list (getcheerful.org/sub-processors) — at the date of this DPA: Stripe (payment processing), Cloudflare (backend hosting/edge and data stores), Resend (transactional email). See that document for purpose, location and safeguards.

Annex 3 — Technical and organisational security measures

The Processor maintains measures appropriate to the risk, including:
  • Encryption in transit — Personal Data is encrypted (TLS/HTTPS) between the donor, the Controller’s site, the Cheerful Give backend and Stripe;
  • No card data held — card/bank details are handled solely by Stripe (PCI-DSS Level 1) and are never seen or stored by Cheerful Give;
  • Signed, replay-protected relay — donation events are delivered using per-site secret keys and HMAC signatures with a signed timestamp, so an event cannot be forged, altered or replayed, and can only be delivered to the correct site;
  • Server-side validation — donation amounts, fees and the destination account are computed and validated on the Processor’s servers, not in the browser, and cannot be altered by a manipulated request;
  • Fraud and abuse prevention — the donation form applies rate limiting, a hidden honeypot and automated bot-blocking, supports Stripe Radar and an optional CAPTCHA (Cloudflare Turnstile, hCaptcha or Google reCAPTCHA), and alerts the Controller to bursts of suspicious activity;
  • Access control — least-privilege access to production systems and secrets; connection tokens and per-site secrets are stored in hashed or access-controlled form and are kept out of the autoloaded configuration cache;
  • Audit logging — sensitive actions on the Controller’s site (connecting or disconnecting the payment account, exporting donor data) are recorded in an activity log, and production access is logged and monitored;
  • Software integrity — Processor-hosted plugin updates are verified against a published checksum before installation;
  • Secret management — API keys and signing secrets are never exposed in plugin code, in the browser or in source repositories, and are automatically scanned for accidental exposure; source code and dependencies are checked by automated security tooling and monitored for known vulnerabilities;
  • Data minimisation and retention — automatic anonymisation of donor Personal Data after the Controller’s chosen retention period, and automatic one-week expiry of any diagnostic log sent to the Processor; diagnostic logging is disabled by default and transmitted only on the deliberate action of the Controller’s administrator;
  • Resilience — retry-with-back-off delivery and an out-of-band reconciliation poll to avoid losing donation records;
  • Staff confidentiality obligations.