A customer emails your support inbox. Their Stripe subscription failed three weeks ago, they got four reminder emails and one SMS, and now they want to know what your lawful basis was under UK GDPR for processing their contact data after the card declined. What do you write back?
If your answer is "legitimate interests" or "consent," you are probably choosing the wrong basis and making your life harder. For standard subscription dunning, Article 6(1)(b), performance of a contract, is almost always the cleanest and most defensible ground. This article explains why, how to document it, and includes sample text for a Record of Processing Activities (RoPA) entry you can adapt.
General information only, not legal advice. Confirm your lawful basis choices with a qualified DPO or data protection lawyer.
The six lawful bases, and why most do not fit dunning
UK GDPR Article 6(1) lists six lawful bases for processing personal data. For subscription payment recovery, four of them are non-starters:
- 6(1)(c) legal obligation. Only applies when a specific UK law requires the processing. There is no UK law that forces you to send dunning emails, so this does not fit.
- 6(1)(d) vital interests. Used for life-and-death situations. Not relevant.
- 6(1)(e) public task. For public authorities. Not relevant for SaaS.
- 6(1)(f) legitimate interests. Possible, but requires a Legitimate Interests Assessment (LIA) balancing your interest against the data subject's rights. It is slower to defend and easier to attack.
That leaves two viable candidates.
- 6(1)(a) consent. The customer actively agrees to receive payment reminders.
- 6(1)(b) contract. The processing is necessary to perform a contract the customer is party to, or to take steps at their request before entering into one.
Why consent is a bad choice for dunning
At first glance, consent looks safe. You ask, they agree, you process. The ICO is happy.
In practice, consent under UK GDPR is a high bar. It must be freely given, specific, informed, and unambiguous, and just as easy to withdraw as to give. That last point is the killer for dunning. If a customer withdraws consent, you must stop processing their data for that purpose immediately. A customer whose payment just failed and who does not want to hear from you can withdraw consent before you have a chance to recover the revenue, and you have no lawful basis to continue.
Consent also creates operational friction. You have to capture it, prove it, refresh it, and track withdrawals across channels. You need consent records in your database, a withdrawal workflow, and an audit trail. All for a processing activity that is arguably baked into the subscription contract anyway.
Consent is the right basis for optional marketing. It is the wrong basis for mandatory contract administration.
Why legitimate interests is the second-best option, not the first
Legitimate interests (Article 6(1)(f)) is flexible. It lets you process data where you have a genuine interest, the processing is necessary to achieve it, and your interest is not overridden by the data subject's rights and freedoms.
Payment recovery clearly meets the first two prongs. You have a commercial interest in getting paid, and sending reminders is necessary to do it. The third prong is where legitimate interests wobbles. The data subject has a reasonable expectation to be contacted about their own failed payment, which tilts the balance your way, but you still have to:
- Run and document a Legitimate Interests Assessment (LIA) before you start
- Refresh the LIA if your processing changes
- Respond to Article 21 objections, where the data subject has the right to object to processing based on legitimate interests
- Explain the balancing test in your privacy notice
An Article 21 objection is particularly awkward. If the customer objects to processing, you have to stop unless you can demonstrate "compelling legitimate grounds" that override their rights. For a routine failed payment, that argument is possible but not guaranteed.
Contractual necessity has none of these problems. Article 21 does not apply to processing based on Article 6(1)(b).
Why contractual necessity is the strongest fit
When a customer signs up for a Stripe subscription, they enter a contract. The contract has two sides. You deliver the service. They pay. If the payment fails, administering that failure, including reminding them and asking them to update their card, is part of performing the contract.
The ICO's guidance on contract as a lawful basis makes the standard clear. The processing must be necessary for the performance of the contract, not merely useful or commercially sensible. Necessary means you could not reasonably perform the contract without it.
For subscription dunning, the argument is straightforward.
- The contract requires the customer to pay
- Payment has failed
- To keep the contract alive rather than terminating it, you must notify the customer and give them a chance to remedy the failure
- Sending a reminder email or SMS is the minimum processing needed to do that
That is textbook Article 6(1)(b). No balancing test, no LIA, no Article 21 objections. You just document it and move on.
The limits matter. Article 6(1)(b) covers contract administration, not marketing. The moment your "reminder" includes promotional content, you drop out of 6(1)(b) territory and into the much trickier world of PECR and consent (see our PECR guide for details). Keep dunning transactional and 6(1)(b) holds.
How to document contractual necessity
Documentation is where most SaaS teams fall down. Having the right lawful basis is only half the job. You need to show you thought about it, chose it deliberately, and can explain it on demand. That means three artefacts.
1. Privacy notice
Your privacy notice (or privacy policy) must tell data subjects which lawful basis you rely on for each purpose. For dunning, something like:
We use your contact details (email address and, where provided, phone number) to notify you about failed payments and ask you to update your payment method. Our lawful basis for this processing is Article 6(1)(b) of the UK GDPR: the processing is necessary for the performance of our subscription contract with you.
Keep it plain. The ICO's transparency guidance rewards clarity over legalese.
2. Record of Processing Activities (RoPA)
Under Article 30, most organisations must maintain a RoPA. Here is a sample entry for a dunning workflow that you can adapt.
Processing activity: Failed payment recovery (dunning)
Purpose: To notify subscribers of failed subscription payments and
facilitate payment method updates, as required to perform the
subscription contract.
Categories of data subject: Active paying subscribers whose Stripe
(or similar) payment has failed.
Categories of personal data:
- Identity data: first name, last name
- Contact data: email address, mobile phone number (where provided)
- Transaction data: invoice number, failed amount, currency,
payment method metadata (card brand, last four digits, expiry)
- Account data: subscription ID, customer ID, failed payment timestamp
Lawful basis (Art. 6): 6(1)(b) performance of a contract.
Special category data: None.
Recipients / processors:
- Rekko (dunning automation platform, UK/EU data processing)
- Amazon SES (transactional email delivery)
- Amazon SNS (SMS delivery)
- Stripe (source of failed payment data)
International transfers: Transfers to US processors (AWS, Stripe)
covered by UK IDTA / EU SCCs and adequacy assessments.
Retention: Message logs retained for 24 months for audit and
dispute resolution, then deleted. Opt-out records retained
indefinitely per PECR suppression requirements.
Security measures: Encryption in transit (TLS 1.2+), encryption
at rest (AES-256), access controls, audit logging, OAuth token
encryption, DPA with all processors.
Adapt the processor list to match your stack, swap retention periods to match your policies, and review annually.
3. Internal policy or DPIA-lite note
You do not need a full DPIA for standard dunning (see our DPIA article for when you do), but a short internal note recording why you chose 6(1)(b) over consent and legitimate interests is useful. It takes fifteen minutes to write and saves hours of scrambling if the ICO ever asks.
Defending the basis if challenged
If a data subject objects or the ICO asks questions, your defence comes down to three points.
- The processing is inside the four corners of the subscription contract. Without it, you cannot administer the contract.
- The processing is minimal. You only use contact details to send payment-related messages, not marketing.
- You have honoured opt-out requests for the electronic channel itself (PECR) even though the underlying processing is lawful under UK GDPR.
Point three is subtle. A customer can ask you to stop emailing them under PECR even when your UK GDPR basis is solid. You must honour that. In practice, you switch to a less intrusive channel (a Stripe hosted invoice, a support ticket, or no further contact at all) and let the contract run its course.
How Rekko aligns with contractual necessity
Rekko is built around the assumption that dunning is contract administration, not marketing. Every default in the product reinforces that.
- Message templates focus on failed payment facts, amount, date, invoice, and a payment update link
- No upsell or cross-sell blocks in default templates
- Contract-based lawful basis declared in Rekko's DPA with customers
- Opt-out handling for PECR-level requests, independent of the UK GDPR basis
- Full message logs to support RoPA entries and audit requests
- Data minimisation: Rekko only pulls the fields needed to render the message
Start your 14-day free trial, no credit card required. Or see how Rekko compares to Churnkey and Stunning.
Sources
- UK GDPR Article 6(1)(b) and Article 30
- ICO guidance on lawful basis, contract
- ICO Accountability Framework
- Data Protection Act 2018
This article is general information. Get qualified legal advice before finalising your lawful basis documentation.