Data Processing Agreements for Backup Resellers

Your customers don't care about GDPR. They care about risk. When a customer hands you their backup data, they're handing you payroll records, customer databases, and ten years of email, and the document that turns that trust into something enforceable is the Data Processing Agreement. This post covers what a DPA (in Germany: AVV) actually is, what yours needs to contain, and how to set up the full contract chain from your customer down to your backup vendor.

What a Data Processing Agreement Actually Is

A Data Processing Agreement (DPA) is a contract that governs what a service provider is allowed to do with personal data it handles on behalf of someone else. In the DACH region you'll usually hear the German term: Auftragsverarbeitungsvertrag, or AVV. Same thing. Article 28 of the GDPR (in Germany, the DSGVO) makes it mandatory: if you process personal data on a customer's behalf, a written agreement must exist, and it must contain specific clauses.

The regulation defines three roles, and getting them straight is most of the battle:

Your customer is the data controller. They decide what data exists and why it gets backed up. You, the MSP or reseller, are the data processor: you handle that data on their instructions. And the vendor hosting your offsite Proxmox Backup Server targets is a sub-processor, one layer further down, doing a defined job on your instructions.

That structure produces a chain of two separate agreements:

A lot of resellers assume their backup vendor handles all of this. The vendor handles exactly half: the agreement between the vendor and you. The agreement between you and your customer is yours to put in place, and no vendor contract can substitute for it.

Why This Lands on You, Not Your Vendor

Some resellers treat the DPA as the customer's problem ("they're the controller, they should bring the contract") or the vendor's problem ("the data sits on their servers"). The GDPR sees it differently. Article 28(3) puts the obligation on both controller and processor to have the agreement in place, and Article 28(4) makes you responsible for flowing equivalent obligations down to your sub-processors. If a sub-processor fails, you remain fully liable to your customer.

In practice, your obligations as the processor in the middle are:

• Have a signed DPA with every customer whose data you process. No exceptions for small customers or "just a homelab" setups that turn out to contain a company's file server.
• Have a DPA with every sub-processor: your backup vendor, and any other party that touches customer data (a datacenter where you colocate, a monitoring provider that sees hostnames and account names).
• Maintain a sub-processor list and tell customers when it changes. Most DPAs use a general authorization with a notification period, so you don't need fresh signatures for every change.
• Document your data flows. Know which customer data lands on which Proxmox Backup Server datastore, in which country, under which retention policy. If you can't answer that in five minutes, start there.
• Support your customers' obligations. When their customer files a deletion request or a subject access request, the controller may need your help to honor it on the backup tier. How pruning and retention work in PBS determines what you can realistically promise here.

Day to day this is less work than it sounds. The data flow documentation is a half-page per customer. The sub-processor list is a table you update twice a year. The hard part is starting.

What Belongs in a Good DPA

Article 28(3) prescribes the content, so every serious DPA covers the same ground:

• Subject matter and duration: what service you provide and for how long.
• Nature and purpose of processing: storing encrypted backup data for disaster recovery. Spell out that you do not access, analyze, or use the data for anything else.
• Type of personal data: in a backup context this is honest shorthand for "whatever is inside the customer's systems": contact data, contract data, payroll, communications.
• Categories of data subjects: the customer's employees, customers, and suppliers, typically.
• Documented instructions: you process only as instructed; the service contract counts as the standing instruction.
• Confidentiality: everyone on your team with access is bound to confidentiality.
• Technical and organizational measures (TOMs): encryption, access control, network isolation. This is where your actual stack earns its keep. Client-side encryption in Proxmox Backup Server means backup content is encrypted before it leaves the customer's site, which makes the TOM annex short and credible.
• Sub-processor authorization: your current sub-processor list and the notification process for changes.
• Assistance obligations: helping the controller with data subject rights, breach notification, and impact assessments where the backup tier is involved.
• Deletion or return at contract end: what happens to backup data when the customer leaves, and within what timeframe. Be specific: "datastores deleted within 30 days of termination, confirmed in writing."
• Audit rights: the controller may verify your compliance. In practice this clause is usually satisfied with documentation and existing certifications rather than on-site visits.

Data Residency: Where the Backups Physically Live

For many EU customers, the first question is not "are you certified" but "where is my data". Finance, healthcare, legal, and public-sector customers often have internal policies or sector rules that require data to stay in the EU, sometimes specifically in Germany.

Backup data is no exception, and it's often forgotten because it's invisible. The production database lives in the customer's documented infrastructure, but the backup copy quietly sits wherever the reseller's offsite target happens to be. If that target is outside the EU/EEA, you've created a third-country transfer that needs its own legal basis (Standard Contractual Clauses, adequacy decisions) and you probably never told the customer.

State it plainly in the DPA: storage location by country, and a commitment not to move data outside the EU/EEA without prior agreement. Our infrastructure runs in German and EU datacenters, which keeps this clause to a single sentence; the compliance breakdown for GDPR, SOC 2, and ISO 27001 covers how the technical controls underneath map to auditor questions.

Common Mistakes Resellers Make

After enough partner conversations, the same gaps show up repeatedly:

1. No DPA with end customers at all. The vendor relationship is papered, the customer relationship runs on an invoice and a handshake. This is the most common and the most serious gap.
2. A DPA that no longer matches reality. Signed in 2021, never touched since, while the backup target moved providers twice. An outdated DPA can be worse than none in a dispute, because it documents commitments you're visibly not keeping.
3. Invisible sub-processors. The customer has no idea which companies actually hold their data. The sub-processor list exists so they can assess their own risk; keep it current and name names.
4. Unstated storage locations. "Cloud backup" with no country attached. Compliance-conscious customers will eventually ask, and "let me check" is not a good look.
5. Assuming the vendor's DPA flows upward. It doesn't. Two relationships, two agreements.
6. Signing commitments you don't operate. If the DPA promises deletion within 30 days but your retention setup keeps pruned snapshots for 90, fix one of the two before a customer tests it.

How to Put the Chain in Place

Compliance as a Sales Tool

Here's the part that makes the effort pay for itself: a clean DPA practice wins deals. Larger customers, and any public-sector tender, will request your AVV, your sub-processor list, and your TOMs before signing. The reseller who sends three tidy PDFs the same afternoon beats the one who goes quiet for two weeks.

It also changes the conversation with smaller customers. "All backup data is encrypted on your systems before transfer and stored exclusively in German datacenters, here's the agreement that guarantees it" is a stronger pitch than any feature list. Resellers and MSPs in our partner program use exactly this framing, and the white-label program lets you make those guarantees under your own brand, backed by our infrastructure and our paper.

Wrapping Up

A Data Processing Agreement is not a legal formality to survive; it's the document that makes your backup service trustworthy on paper, not just in practice. The structure is simple: one DPA upward with each customer, one DPA downward with each sub-processor, both reflecting what actually happens to the data. Start with a single customer this week: map the data flow, fill in a template, get it signed. The second one takes a quarter of the time.