GDPR and Data Retention for Payment Recovery Systems

Payment recovery touches personal data by definition — a name, an email, a phone number, and a transaction history. GDPR does not forbid this; it requires you to be precise about what, why, and for how long. Precision is cheaper than the alternative.

# Legal basis: contract, not consent

Recovery communications are performed under the contract legal basis (GDPR Art. 6(1)(b)), not consent. The customer has an active subscription; contacting them about a failed payment is necessary to perform the contract.

Practical implications:

• You do not need marketing consent to send a "your card failed" email.
• You cannot then send them promotional content in the same email — that reverts to consent basis.
• You must offer opt-out from non-essential recovery channels (e.g., WhatsApp reminders when email would suffice) but not from the recovery notification itself.

Document the legal basis in your Article 30 records. Every data-processing activity is either contract, consent, legitimate interest, legal obligation, vital interest, or public task — pick the right one and stick to it.

# Data-retention matrix

Retention should be a matrix by data category, not a single "delete after N years" policy. A defensible matrix for a recovery system:

Two rules that make this defensible:

1. Every row cites a specific basis, not "business need."
2. Every row has an expiry job that actually runs. A retention policy that never fires is worse than no policy.

# Data minimization

GDPR Art. 5(1)(c): personal data must be adequate, relevant, and limited to what is necessary for the purposes.

Minimization checklist for a recovery system:

• Store hashed email if you can (SHA-256 with pepper); look up the plaintext from the auth system when needed.
• Store the last four card digits and brand; never store the PAN (see the PCI article).
• Store phone numbers in E.164 format; do not store multiple normalizations.
• Do not store the full recovery email body — store the template ID and the substitution values. The body can be re-rendered if needed.
• Do not store IP address more than 12 months. Fraud-defense value drops sharply after 90 days; the risk of holding it does not.

# Subject rights

Data subject rights in the recovery context:

• Access (Art. 15) — provide the transaction history, communication log, and current recovery status.
• Rectification (Art. 16) — correct email or phone if wrong.
• Erasure (Art. 17) — usually not applicable during an active subscription; kicks in after cancellation + retention period expires.
• Restriction (Art. 18) — pause processing during a dispute over accuracy.
• Portability (Art. 20) — export their data in a machine-readable format.
• Object (Art. 21) — customer can object to legitimate-interest processing (e.g., IP-based fraud checks); contract-basis processing continues.

Implement all seven. The rights framework is not just compliance — a customer who exercises a right and gets a professional response is more likely to stay a customer.

# DPIA when it's required

A Data Protection Impact Assessment is mandatory under Art. 35 when processing is likely to result in a high risk to individuals. For a recovery system, that threshold is triggered when:

• The system does automated decision-making with legal or significant effects (e.g., automatically cancelling a subscription based on failure signals — probably not you).
• Systematic monitoring on a large scale (large-scale IP fingerprinting — potentially).
• Processing sensitive categories (health, biometric — not you, unless your product is in one of those verticals).

For most recovery systems, a DPIA is not strictly mandatory, but you should still document a risk assessment. When a regulator asks, "did you consider the risks," having a two-page document that says "yes, and here's what we did" is dramatically better than "no."

# Cross-border transfers

If your recovery system stores EU personal data in the US, you rely on one of:

• The EU-US Data Privacy Framework (in force but under litigation).
• Standard Contractual Clauses + a transfer impact assessment.
• Binding Corporate Rules (only large enterprises).

For SaaS companies, EU-US DPF is the practical answer. Have your US processor (PSP, ESP, analytics) self-certified under DPF. If they're not, budget a transfer impact assessment and SCCs.

For UK, use the UK IDTA or the UK addendum to SCCs.

# Data processor obligations

Your PSP is a processor of payment data on your behalf. Your ESP is a processor of communication data. Your recovery vendor is a processor of the combined data.

Every processor requires:

• A Data Processing Agreement (DPA) signed with your entity.
• Sub-processor list published and updated.
• Breach notification within 72 hours (from processor to controller).
• Deletion or return of data at end of contract.

Vendors that resist signing a DPA are not vendors you should be using for regulated data.

# The RRLabs default

The Revenue Recovery Labs system ships with a Article 30 records template, a retention matrix aligned to the one above, per-tenant sub-processor lists, and automated erasure jobs that respect legal-obligation retention floors. Every field in the data model has a documented retention basis. Your DPO can review it in an afternoon — and, importantly, they can defend it to a regulator in an hour.