A customer on your 12-month enterprise plan stops paying in month four. Your dunning sequences run, the account is suspended, and two months later the outstanding balance is sitting at 4,800 pounds. Finance wants to hand the debt to a collection agency. Your ops lead sets up the handover, exports a CSV of the customer's name, email, phone, address, invoice history, and failed payment codes, and sends it over. Done.
Except that CSV export just created a UK GDPR problem. You have transferred personal data to a new party without a processor contract in place, without updating your privacy notice, and potentially without the data minimisation checks UK GDPR expects. If the customer complains to the ICO, you are answering questions about Article 28, Article 13, Article 5(1)(c), and possibly Article 6. None of which you wanted to spend Thursday afternoon on.
This article walks through what UK GDPR actually requires when you involve a debt collection agency in recovering unpaid subscriptions, with the ICO's expectations as the benchmark.
General information only, not legal advice. If you are setting up a collections process, get it reviewed by a qualified data protection lawyer before you run it.
The basic shape of the problem
Collecting an unpaid debt is lawful. Transferring personal data to a third party to help you collect it is processing personal data, and that sits firmly inside UK GDPR. The question is not whether you can do it, but how you do it in a way that meets the regulation's requirements.
Three questions define the answer.
- Is the third party a processor or a joint controller, or do they become an independent controller? The answer determines what contracts you need.
- What is your lawful basis for sharing? For contract-based dunning, it is usually 6(1)(b) or 6(1)(f) depending on how the collection relationship is set up.
- What did you tell the customer when you collected their data? If your privacy notice does not mention debt collection, you have a transparency problem.
Get these three right and the rest of the obligations flow logically.
Controller, processor, or something else
UK GDPR distinguishes between controllers (who decide the purposes and means of processing) and processors (who process on behalf of a controller). The classification matters because it determines your contract requirements and allocation of liability.
Debt collection agencies acting as processors. Some collection work is straightforward processor work. You tell the agency who to contact, what to say, how often to contact them, and when to stop. The agency is executing your instructions. In that setup the agency is a processor and Article 28 requires a written contract with specific clauses (processing only on documented instructions, confidentiality, security, sub-processors, assistance with data subject rights, deletion or return of data, audit rights).
Debt collection agencies acting as independent controllers. More often in practice, agencies act as independent controllers. They decide their own contact methods, retain the debt on their own books if the debt is sold, make their own decisions about litigation, and set their own retention periods. In that setup the agency is a controller in its own right and Article 28 does not apply. Instead, you have a controller-to-controller disclosure, which needs a different kind of agreement (often called a data sharing agreement) and careful handling of the lawful basis for the disclosure.
Sold vs assigned debt. If you sell the debt outright to a third party, they become the controller of that data from the point of transfer. They inherit collection rights and responsibilities. You remain responsible for any processing you did before transfer and for the lawfulness of the transfer itself.
The ICO's guidance on data sharing and the ICO Data Sharing Code of Practice both cover this distinction. When in doubt, ask the agency directly in writing which role they consider themselves to be in, and do not assume "processor" just because the commercial relationship looks like a service engagement.
Article 28 in practice
If the agency is a processor, Article 28 sets the minimum contract terms. A compliant DPA between you and the agency must cover:
- Subject matter and duration. What data, for how long
- Nature and purpose. Debt recovery on your behalf
- Types of personal data. Identity, contact, financial, account history
- Categories of data subjects. Your customers with outstanding debt
- Your obligations and rights as controller
- Processing only on documented instructions. No using the data for the agency's own purposes
- Confidentiality. Staff with access are bound by confidentiality
- Security. Article 32 measures, spelled out
- Sub-processors. Written authorisation, either specific or general with notification
- Data subject rights. The agency must assist you in responding to access, rectification, erasure, and other rights requests
- Breach notification. The agency tells you about any breach without undue delay
- Return or deletion at end of processing. Usually deletion after a defined retention period
- Audit rights. You can audit compliance or receive audit reports
The contract must also reflect the ICO's expectations around international transfers if the agency operates outside the UK, including IDTA or UK Addendum to the EU SCCs where appropriate.
Transparency: your privacy notice has to cover this
Article 13 requires you to tell data subjects, at the point of collection, who you share their data with and why. If your privacy notice never mentions debt collection, and then you send a customer's details to a collection agency, you have likely breached Article 13.
The fix is prospective and specific. Update your privacy notice now, before you ever need to use an agency, with language like:
Where subscription invoices remain unpaid after our internal recovery process has concluded, we may share account holder contact details, invoice history, and outstanding balance information with a third-party debt collection agency. Our lawful basis for this sharing is Article 6(1)(f) of the UK GDPR, our legitimate interest in recovering amounts contractually owed to us. You have the right to object to this processing under Article 21.
Adapt the basis if you prefer contractual necessity (6(1)(b)), and keep the language plain enough that a reasonable customer can understand what happens to their data.
Changing the privacy notice after the fact does not retroactively cover past sharing. You can only rely on Article 13 disclosures the customer could have seen before the processing started.
Lawful basis for the sharing itself
Sharing with a collection agency is a new processing activity that needs its own lawful basis under Article 6. Two options work for most SaaS situations.
Legitimate interests (6(1)(f)). Your interest is recovering money you are contractually owed. The customer's interests and rights must not override that. For straightforward commercial debt, the balancing test usually comes out in your favour, but you need to document it in a Legitimate Interests Assessment (LIA). The ICO's LIA template is a good starting point.
Contractual necessity (6(1)(b)). If your subscription terms and conditions explicitly state that unpaid accounts may be referred to a collection agency, you can argue that the sharing is necessary to perform the contract (specifically, to collect what the contract entitles you to). This is a cleaner basis if your ToS supports it, because it sidesteps the balancing test and Article 21 objections.
Either way, keep the basis documented in your RoPA and privacy notice, and match the two.
Data minimisation: send only what the agency needs
Article 5(1)(c) is the data minimisation principle. "Adequate, relevant and limited to what is necessary." When you hand a case to an agency, the temptation is to send everything you have. The obligation is to send only what the agency needs to do its job.
A sensible minimum dataset:
- Customer name
- Business name (for B2B)
- Primary contact email
- Phone number (if collection by phone is part of the agency's service)
- Postal address (if letters are part of the agency's service)
- Outstanding balance and currency
- Invoice numbers and dates
- Contract start date and term
- Brief description of the service contracted
What you should not include by default:
- Usage data or analytics
- Support tickets unrelated to payment
- Marketing preferences
- Password hashes or authentication data
- Payment method details beyond the minimum needed for identification (never send full PANs or tokens)
- Information about other users in the same account unless they are personally liable
If the agency needs additional information to pursue a specific case, they can ask, and you can share on a case-by-case basis with a clear audit trail.
Data subject rights do not pause during collection
Customers retain all UK GDPR rights even while a debt is in collection. Specifically.
- Article 15 access. They can ask you for a copy of their data, including data you shared with the agency. The agency must assist you in responding.
- Article 16 rectification. If any data is inaccurate (for example, the balance), you must correct it and notify the agency.
- Article 17 erasure. This one is contested. Erasure does not apply where processing is necessary for the establishment, exercise or defence of legal claims (Article 17(3)(e)). Active debt collection usually falls under this exception. Once the debt is resolved, erasure obligations kick back in.
- Article 18 restriction. Particularly relevant if the customer disputes the debt. They can ask you to restrict processing while the dispute is being resolved.
- Article 21 objection. Applies if you rely on legitimate interests. You must stop unless you can show compelling legitimate grounds.
Your Article 28 contract with the agency must include provisions for the agency to assist with these requests. The ICO expects controllers to maintain practical mechanisms for handling rights requests even when data is in the hands of processors or recipient controllers.
Retention after the debt is settled or written off
Once a debt is resolved (paid, settled, or written off as uncollectable), the original justification for processing weakens. You should have a retention policy that defines how long you keep collection-related data after closure. A common pattern.
- Resolved debts: retain for 6 years after settlement for tax, audit, and limitation-period reasons under UK law (Limitation Act 1980)
- Written-off debts: same retention, plus a note in your records showing the write-off date and reason
- Agency-held data: the agency's Article 28 contract or data sharing agreement should require deletion or return within a defined period after case closure
Document the policy, apply it, and note it in your RoPA and privacy notice.
How Rekko fits in the collection workflow
Rekko's job ends before the debt collection stage. Rekko handles the automated email and SMS sequences that try to recover the failed payment directly from the customer over the first days or weeks. For most failures, that is enough, and no collection agency involvement is ever needed.
When a customer does not respond and the debt escalates to agency handover, that is a human process, not a Rekko automation. But Rekko does help the compliance side of the handover in three ways.
- Message logs. Rekko keeps a timestamped log of every message sent, which becomes evidence that you made reasonable internal recovery attempts before escalating. Useful for the agency's case file and for any ICO questions.
- Opt-out records. If a customer has opted out of email or SMS, Rekko suppresses them. The agency's contract should respect the opt-out for channels within its scope, but you should not assume it will automatically know. Flag opt-outs clearly on handover.
- Lawful basis continuity. Rekko's processing is based on contractual necessity. If you escalate to collections using the same basis (or a documented LIA), the customer journey is legally coherent start to finish.
Start your 14-day free trial, no credit card required. Or compare Rekko to other tools on alternatives.
Sources
- UK GDPR Articles 5, 6, 13, 17, 21, 28
- ICO Data Sharing Code of Practice
- ICO guidance on controllers and processors
- Limitation Act 1980
This article is general information. Collections workflows have real legal exposure. Get qualified advice before you run them.