GDPR for Subscription Businesses: Managing Recurring Billing and Customer Data
Subscriptions are different from one-off transactions. When a customer signs up for a SaaS product, a media service, or a software tool, they enter a long-term data relationship with you. They pay every month. You store their payment token. You track their usage. You analyse their behaviour. You send renewal reminders. You try to win them back if they churn.
Each of those activities involves personal data. And GDPR creates specific obligations for each of them.
This guide covers the subscription-specific GDPR picture — the questions that general GDPR guides don't answer, and the compliance gaps that subscription businesses consistently miss.
What Subscription Businesses Collect
GDPR subscription businesses need to understand the scope of their data collection before they can manage it. A typical SaaS or subscription business collects far more than it realises:
- Billing data: name, email address, company name, billing address, VAT number, invoice history
- Payment method tokens: not the card number itself, but the token returned by your payment processor
- Usage data: which features are used, how often, when, for how long, and from what device or location
- Feature access logs: what was enabled or disabled, when plans were upgraded or downgraded
- Support history: conversations, tickets, feature requests, complaints
- Renewal history: whether the customer renewed, downgraded, paused, or cancelled — and when
- Behavioural data: in-app behaviour, click patterns, onboarding completion rates, session recordings
- Communication preferences: email opt-ins, notification settings, marketing consent flags
This is substantial. Most subscription businesses collecting this data across a customer lifetime that spans years — and that time dimension is exactly what GDPR subscription businesses need to manage carefully.
Lawful Basis for Subscription Data Processing
Not all processing activities use the same lawful basis. GDPR subscription businesses need to map each processing activity to the correct basis:
Contract (Article 6(1)(b))
The contract basis covers processing that is necessary to deliver the service the customer signed up for. This includes:
- Processing billing data to charge the subscription fee
- Storing the payment token to enable automatic renewal
- Sending receipts, invoices, and service notifications
- Maintaining access logs for account management and support
You do not need separate consent for these activities. They are inherent to the subscription contract.
Legitimate Interest (Article 6(1)(f))
Legitimate interest can cover processing activities that benefit the business but are not strictly necessary for the contract, provided those interests are not overridden by the subscriber's rights. This typically includes:
- Aggregated usage analytics to improve the product
- Renewal reminder emails sent before billing (these are expected and non-intrusive)
- Internal churn analysis and cohort reporting
- Fraud detection and abuse prevention
You must conduct a Legitimate Interest Assessment (LIA) to document your reasoning. It is not a rubber stamp — if the processing is intrusive or unexpected, legitimate interest will not hold.
Consent (Article 7)
Consent is required for activities where the subscriber would not reasonably expect their data to be used. This includes:
- Marketing emails promoting your other products or services
- Upsell campaigns targeting users on lower tiers
- Sharing data with advertising networks for retargeting
- Optional product research surveys or user interviews
Consent must be freely given, specific, informed, and unambiguous. A pre-ticked box or buried terms don't qualify.
The Contract Renewal Question
One of the most common questions for GDPR subscription businesses: does the original contract or consent cover renewals indefinitely?
The short answer is yes — for contract-basis processing. If the lawful basis for billing is the contract, and the subscription auto-renews under the same terms, you don't need the subscriber to re-consent to each billing event. The ongoing contractual relationship covers it.
The longer answer: terms matter. If you change your data practices — what you collect, what you share, how long you retain — you need to notify subscribers and, where consent is the basis, obtain fresh consent. Auto-renewal doesn't equal blanket permission for new processing.
Free Trial to Paid Conversion
Free trials create a specific data challenge. When someone signs up for a trial, what lawful basis applies? And what happens to their data when the trial ends?
During the trial: You typically collect the same data you would for a paid subscriber. The most defensible basis is a pre-contractual arrangement — the trial is a step toward a potential subscription contract. You can also use legitimate interest for product analytics during the trial period.
If they convert: The trial data — usage history, support interactions, account details — naturally flows into the paid subscription relationship. No re-collection is needed.
If they don't convert: This is where GDPR subscription businesses often go wrong. Once the trial ends without conversion, the contractual basis disappears. You need to either:
- Delete the personal data promptly (within 30–90 days is common practice)
- Have specific consent to retain it (e.g. for re-engagement marketing)
- Rely on legitimate interest for a limited period (e.g. basic account data retained for 30 days in case they return)
Keeping ex-trial users in your marketing lists indefinitely without valid consent is a common violation. If you run re-engagement campaigns to lapsed trial users, those users need to have opted in to marketing when they signed up.
Cancellation and Retention: How Long Can You Keep Data?
When a subscriber cancels, your lawful basis for most processing ends — but retention obligations and legitimate interests can justify holding some data for defined periods.
Here is the general framework for GDPR subscription businesses:
Billing records (invoices, payment history, VAT records): Retain for 7 years. Tax and accounting regulations require this in most jurisdictions. This is a legal obligation basis (Article 6(1)(c)).
Contractual data (account details, subscription history): Retain for 1–2 years after cancellation. You need to be able to handle billing disputes, chargebacks, and support queries that arrive after cancellation. This is legitimate interest.
Usage data (feature logs, session data, behavioural analytics): Retain for 1–2 years if needed for product analytics. After that, anonymise or delete. Personally identifiable usage data should not be kept indefinitely.
Marketing data (email opt-ins, campaign engagement): Delete on cancellation, unless the subscriber has affirmatively opted in to continued marketing. Cancellation is a clear signal of intent — continuing to market to cancelled subscribers without explicit consent is high-risk.
Support history: Retain for 1–2 years. You may need this to handle returning customers or disputes. After that, anonymise or delete.
Document your retention schedule and enforce it. Unlimited retention "in case it's useful" is not compliant.
The Win-Back Email Problem
Can you email lapsed subscribers who cancelled months or years ago?
It depends on two things: how they left, and whether they opted out of marketing.
Scenario 1: The subscriber cancelled but never unsubscribed from marketing emails. You may have a case for soft opt-in (in the UK and some EU jurisdictions) — but it's limited in time and scope. Using their email address for marketing to similar products or services, within a reasonable period after cancellation (typically 6–12 months), may be defensible. Beyond that, consent is stale.
Scenario 2: The subscriber cancelled and explicitly unsubscribed from marketing. Any win-back email is a direct violation. There is no legitimate interest that overrides an explicit opt-out.
Scenario 3: The subscriber's account was deleted following a deletion request. You should have no email address to contact — any win-back campaign that reaches them means you failed to honour a data subject right.
The practical rule for GDPR subscription businesses: if someone has been gone more than 12 months and hasn't been engaged in your marketing communications, delete their marketing data. Win-back campaigns work best within the first few weeks of churn anyway.
Usage Data and Product Analytics
Usage analytics is where GDPR subscription businesses most commonly invoke legitimate interest — and where they most often get the balance wrong.
Aggregated, anonymised analytics are low risk. Knowing that 60% of users who reach Step 4 of onboarding convert to paid is not personal data. Knowing that a specific user identified by email address has logged in 47 times from Paris and opened the export feature 12 times is personal data.
The legitimate interest test requires that the processing is necessary, proportionate, and not overridden by the data subject's interests. For product analytics, this means:
- Collect what you actually use. If you're capturing 40 event types but only analysing 8, you're collecting more than necessary.
- Anonymise at the earliest point you can. If your analytics only need user-level trends, aggregate before storing.
- Give users visibility and control. Your privacy policy should explain what you track and why.
Session recording tools (like FullStory or Hotjar) are a particular compliance risk — they capture high-fidelity individual behaviour and often require explicit consent rather than legitimate interest.
Payment Method Data and GDPR
GDPR subscription businesses often assume that because Stripe (or another processor) stores the card data, they have no GDPR obligations around payment data. This is incorrect.
You don't store the raw card number — Stripe does. But you store:
- The payment token that references the card
- The last four digits and card type (displayed in your UI)
- The billing name and address
- The payment method status (active, expired, failed)
These are all personal data. They are associated with an identified individual. And you control how they are retained and deleted.
Under GDPR, your responsibilities include:
- Deleting payment tokens for cancelled subscribers within your documented retention period
- Ensuring your Stripe DPA (Data Processing Agreement) is in place — Stripe provides this, but you need to actively sign it
- Including payment data in DSAR responses where the subscriber requests their data
- Handling payment data deletion requests under the right to erasure (subject to your legal retention obligations for billing records)
Customer Portals: Self-Service Data Rights
The most practical way to handle data subject rights for GDPR subscription businesses is a self-service customer portal. This is both a compliance mechanism and a customer experience improvement.
Your customer portal should ideally support:
- Data access: The subscriber can see and download their account data — profile, usage history, billing history, communication preferences
- Data correction: The subscriber can update incorrect personal data directly
- Marketing preferences: Granular opt-in/opt-out controls for different communication types
- Account deletion: A clear, one-click path to request account deletion, with a documented fulfilment process
If you can't build a full portal, you need a documented process for handling DSARs via email. You have 30 days to respond. You should not charge for this. And you should respond to the request even if you believe the person's identity is uncertain — in which case you can ask for reasonable verification.
Churn Analytics and Behavioural Prediction
Predicting churn is a core subscription business activity. You analyse usage patterns — declining session frequency, reduced feature engagement, increasing support contacts — to identify at-risk subscribers before they cancel.
Is this GDPR-compliant? Generally yes, if done correctly.
Legitimate interest covers using customer data to analyse churn patterns — it's clearly in the business's interest, and subscribers generally expect that a SaaS business will monitor engagement to improve its product and service.
The line is drawn at automated decision-making with legal or significant effects (Article 22). If your churn model automatically triggers a discount offer, account intervention, or pricing change without human review, you may need to disclose this to subscribers and offer a right to object.
In practice, most subscription businesses use churn scores to prioritise human outreach — a customer success manager follows up with at-risk accounts. This is a human decision with data support, which is substantially different from automated decision-making.
Upsell and Cross-Sell Targeting
When can you use subscriber data to target upsell or cross-sell campaigns?
The answer depends on what you're promoting and how you're targeting.
Promoting features or plan upgrades within your existing product: This can typically be done on a legitimate interest basis. It's expected behaviour in a subscription relationship, and the subscriber can easily opt out.
Promoting a separate product or service: This is marketing, and in most interpretations requires consent — especially if you're using behavioural data to decide who to target.
Third-party offers or data sharing for advertising: Requires explicit consent. Full stop.
The principle for GDPR subscription businesses: the closer the offer is to the existing service, and the less intrusive the targeting method, the more defensible the legitimate interest basis. The further afield you go — separate products, aggressive behavioural targeting, third-party data sharing — the more clearly you need consent.
Practical Checklist: 8 GDPR Requirements for Subscription Businesses
Map your lawful bases — Document which basis applies to each processing activity: contract for billing, legitimate interest for analytics, consent for marketing. Don't apply consent everywhere as a lazy default.
Set and enforce retention schedules — Define how long each data category is kept: 7 years for invoices, 1–2 years for usage data, delete marketing data on cancellation unless consented otherwise.
Handle trial data correctly — Establish a clear process for deleting or obtaining consent for non-converting trial users within 30–90 days of trial expiry.
Manage cancellation data flows — When a subscriber cancels, trigger a data handling workflow: anonymise usage data, delete marketing preferences, retain billing records, process any deletion requests.
Sign your DPA with Stripe — If you use Stripe for billing, sign the Data Processing Agreement. Do the same for every tool that processes subscriber personal data.
Build DSAR-ready data exports — Know what data you hold and be able to compile it within 30 days. Test this process before you receive a live request.
Audit your win-back list — Check your re-engagement marketing list against cancellation dates and opt-out records. Remove anyone who cancelled more than 12 months ago without active marketing consent.
Disclose usage analytics in your privacy policy — Describe what you track, why, and for how long. If you use session recording tools, assess whether consent is needed.
Scan Your Subscription Sign-Up Flows for Compliance Gaps
GDPR compliance for subscription businesses isn't a one-time project. It requires ongoing attention as you add new tools, launch new features, and change your marketing approach.
The best starting point is understanding what data your sign-up flows and subscription pages are actually collecting — not what you think they collect, but what trackers, cookies, and third-party scripts are actually firing.
Custodia scans your website and sign-up flows automatically, identifying compliance gaps in your cookie consent, privacy policy, and data collection. It's free to start, and results take 60 seconds.
Scan your subscription pages for GDPR compliance gaps at Custodia →
Last updated: March 27, 2026. This post provides general information about GDPR compliance for subscription businesses. It does not constitute legal advice. Requirements vary by jurisdiction and sector — consult a qualified privacy professional for advice specific to your business.
Top comments (0)