Data Processing Agreements for Cloud Storage: The Article 28 Clauses That Actually Matter

A DPA with empty annexes is not a DPA

Store personal data in the cloud as an EU business, and GDPR Article 28 requires a written contract with your provider before you upload a single byte. Most providers hand you a template, and the template is usually fine. The annexes stapled to the back are usually blank, and under Article 28(3) a DPA with empty annexes is not a valid contract no matter how clean the boilerplate reads.

That is the failure mode almost nobody checks for. The eight mandatory clauses get copied verbatim from the regulation, everyone signs, and the appendices that should describe your processing, the provider's security measures, and the sub-processors touching your data sit blank, with [to be completed] still inside them. The European Data Protection Board put it plainly in its 2020 guidelines: a DPA "should not merely restate the provisions of the GDPR." It has to say, concretely, how each requirement is met. The annexes are where that happens, and where compliance quietly dies.

The eight clauses Article 28(3) actually requires

Article 28(1) sets the rule: you may only use a processor offering "sufficient guarantees" of appropriate technical and organisational measures. Article 28(3) then lists the eight things the contract must contain. Drop one and the DPA is non-compliant. In plain English:

1. Documented instructions. The processor acts only on your documented instructions, including for any third-country transfer, unless the law forces its hand.
2. Confidentiality. Anyone the processor lets near the data is bound by a duty of confidence, contractual or statutory.
3. Security. The processor takes the measures required by Article 32, appropriate to the risk rather than the marketing budget.
4. Sub-processors. No sub-processor without your prior written authorisation, the same Article 28(3) obligations flowed down by contract, and the processor staying liable for its failures.
5. Data-subject rights. The processor helps you answer access, erasure and portability requests with appropriate technical measures.
6. Compliance assistance. The processor helps you meet Articles 32 to 36: security, breach notification, impact assessments.
7. Deletion or return. At the end of the service the processor deletes or returns the data at your choice and deletes existing copies, unless the law demands retention.
8. Audit. The processor makes available the information needed to prove compliance and submits to audits by you or your appointed auditor.

A provider that has done this before will have all eight in the document. None of it is the part that gets gamed. The gap is downstream.

Why are the annexes the part that actually fails?

Because the clauses are generic and the annexes are specific, and specificity is work. The Commission's standard contractual clauses ship with four appendices covering the parties, the processing, the security measures, and the sub-processors. Most cloud DPAs fold those into three you fill in yourself.

• Annex 1, processing details. Subject matter, duration, nature, purpose, the categories of data subjects and of personal data. Article 28(1) demands all of it explicitly. "Cloud storage services" in this box is not a description; it is a confession that nobody read it. Write what you actually store, in plain terms, with real retention periods attached.
• Annex 2, security measures. The technical and organisational measures the processor implements under Article 32. This is the annex that should send you into the provider's architecture rather than its homepage.
• Annex 3, sub-processors. Every other company that touches the data. If this box is blank and the provider runs on AWS, the box is lying. A sub-processor swapped in without telling you is a breach of clause 4 waiting to surface in an audit.

An auditor, or a regulator working through a complaint, opens these three first. A signed cover page over hollow appendices is a policy that says "we take security seriously" and stops there.

How does zero-knowledge change the security annex?

For a conventional provider, Annex 2 has to enumerate a long list of organisational controls precisely because the provider can read your files: who has access, how it is logged, how keys are managed, how a hostile administrator gets contained. They hold the keys, so the trust model rests on those operational promises holding.

With a zero-knowledge processor the annex gets shorter and harder to argue with, because the most dangerous risk is closed by maths rather than policy. We hold ciphertext. Files are encrypted with AES-256-GCM under keys derived on your device with Argon2id at a 256 MiB memory cost and exchanged via X25519; login runs over OPAQUE, so your password never reaches the server; keys are zeroized from memory after use. The server never sees a plaintext file, a readable filename, or a key. "Personnel access to file contents," the line that anchors most Annex 2 tables, is structurally none. What we can see sits on our security page: encrypted blobs and the metadata needed to bill and route them.

The limit, before a critic reaches for it: zero-knowledge narrows this annex, it does not empty the DPA. You still need the other seven clauses, Annex 3 filled in honestly, and a deletion clause that means what it says. Encryption removes the "the provider can read your files" risk; it does not remove the contract. One detail here owes nothing to crypto: the data lives in Falkenstein, Germany, which keeps the arrangement inside the EU and shrinks the third-country-transfer paragraph in clause 1 to almost nothing.

What to check before you sign

Read the three annexes before anything else. If Annex 1 describes your processing in a sentence you could have written, if Annex 2 names mechanisms instead of adjectives, and if Annex 3 lists real companies with a stated process for notifying you of changes, the DPA is doing its job. If any one of them is a placeholder, the clauses above it are decoration. So ask the provider one question: can your staff read my files? A conventional provider answers with access controls and logging. A zero-knowledge provider answers no, and can point at the architecture that makes the answer hold.

The rest of what we ship, including encrypted sharing with expiry and revocation, file versioning with configurable retention, file requests, TOTP and passkeys, is on the features page, and the product clients are open source, so you can check those claims rather than take them on faith. A DPA defines what your provider may do with other people's data, and the annexes are the only part of it that touches reality.