GDPR-ready by default: what the label actually means

Go to any B2B SaaS vendor's website. There is a 90% chance of a "GDPR-ready" badge somewhere between the pricing page and the footer. The term itself is not regulated, which means it can mean anything from "we will sign your DPA if you ask nicely" to "we have annual third-party audits of our processing activities".

When you're buying, you want to be able to tell the difference. This is the checklist we use when vetting our own sub-processors — and, by extension, the standard we hold ourselves to.

1. Pre-signed DPA, self-serve

The DPA (Data Processing Agreement) is the contract between you-as-controller and the vendor-as-processor. For a vendor to meaningfully claim GDPR-readiness, the DPA should be:

• Available without having to ask. A public URL, downloadable as PDF.
• Pre-signed by the vendor. You counter-sign and email it back.
• Fully incorporates the current EU Standard Contractual Clauses (2021/914) by reference or inclusion, for any transfers outside the EEA.

Vendors who require you to negotiate the DPA are telling you, in effect, that their default posture is not GDPR-ready — you've got to extract it from them each time.

2. Published sub-processor list

You cannot comply with GDPR transparency obligations if you don't know who processes your users' data. The vendor should publish:

• A complete current sub-processor list.
• The purpose each sub-processor serves.
• The jurisdiction each sub-processor operates from.
• The transfer mechanism for any cross-border transfer (SCCs, adequacy decision, etc.).
• A mechanism to receive 30-day advance notice before they add a new sub-processor.

The notice mechanism is the one most vendors get wrong. Posting to a page you have to remember to check is not notice; proactive email to account admins is.

3. Documented retention

GDPR's storage-limitation principle requires that data not be kept longer than necessary. A vendor claiming GDPR-readiness should publish:

• Retention periods for every category of data.
• What happens to data on account deletion.
• Whether backups are purged, and on what schedule.

Vendors who give you vague answers ("we keep data as long as necessary for business purposes") have not thought about this. Either it's a drafting gap they'll fix, or it's a warning sign about their data-minimisation posture.

4. Data subject rights, operationalised

As a controller using a processor, you need to be able to respond to end-user requests (access, erasure, portability, restriction). The vendor should make this easy:

• Self-serve export tools in the product, so you can fulfil access and portability requests without opening a support ticket.
• Self-serve deletion tools, with clear confirmation that backups will be purged on a stated schedule.
• A documented path to invoke the vendor's assistance for requests the product tools can't fulfil — with a committed response time.

5. Breach notification commitments

GDPR gives controllers 72 hours to notify supervisory authorities of a notifiable breach. That clock starts when the processorinforms the controller. So the processor's commitment to timely notification is critical.

A reasonable commitment looks like: "without undue delay, and in any event within 72 hours of becoming aware." Vendors who hedge — "as promptly as practicable", "within reasonable time" — are punting on a real obligation.

6. Transfer impact assessments

If the vendor uses any sub-processor that results in data leaving the EEA, they should have performed a Transfer Impact Assessment against the EDPB guidelines. You don't necessarily need to see the assessment — but it should exist and be referenceable.

Vendors who say they use EU SCCs but can't produce a TIA when asked are telling you they've done the paperwork but not the analysis. This is the most common gap in vendor GDPR claims.

7. Technical measures, specifically

"We use industry-standard encryption" is not a technical measures commitment. What you want to see is specifics:

• Encryption at rest: AES-256.
• Encryption in transit: TLS 1.2+ with HSTS.
• Password hashing: Argon2id, bcrypt, or scrypt.
• Access controls: least-privilege, logged, reviewed.
• Penetration testing: annual, third-party, summary available.

If a vendor can't tell you specifics, they've outsourced their security posture entirely to their cloud provider. That may be fine for your risk profile, or it may not — but you need to know.

The short version

"GDPR-ready" should mean: pre-signed DPA you can download, published sub-processor list with 30-day advance notice, documented retention, self-serve export and deletion, 72-hour breach notification, TIAs where relevant, and specific technical measures. If a vendor can tick all seven without a sales call, the label is earned.

If not, ask which of the seven are missing and why. The answer is usually revealing.