GDPR, SOC2, and the B2B SaaS Checklist That Unblocks Procurement

When a buyer asks "are you GDPR-compliant?", they are not asking a yes-or-no question. They are asking whether your company can produce the ten documents, four registers, and one audit log that their procurement officer needs to attach to the contract. The checklist below is the one we hand to a B2B prospect when they want to verify.

The ten documents

These are not legal opinion, but they map the typical EU B2B procurement checklist to the engineering and policy work that backs each item:

1. A signed Data Processing Agreement (DPA). Counter-executable template on request. Reflects GDPR Art. 28.
2. A record of processing activities. Internal ROPA listing purposes, data categories, recipients, retention, and legal basis.
3. A sub-processor list. Every vendor that touches buyer data, with names and a change-notification process.
4. A transfer impact assessment (TIA). For any data leaving the EEA — even a US SaaS vendor with a sub-processor on the West Coast.
5. A breach notification process. 72-hour deadline to supervisory authority; without-undo-delay deadline to data subjects on high-risk breaches.
6. A data subject rights process. DSAR intake, identity verification, response SLA (30 days), and the engineering work to fulfill a deletion or export request.
7. A retention schedule. What we keep, how long, how it is deleted, and which system owns the deletion.
8. A cookie and tracking policy. What runs on the marketing site, the product app, the admin dashboard, and why each cookie exists.
9. A security overview document. Encryption in transit, encryption at rest, key management, access control, incident response.
10. An availability posture. Uptime commitments, what is excluded (a fair SLA), and the disaster-recovery story.

The engineering work that backs each item

A buyer who reads the ten documents will then ask the engineering team to walk them through the implementation. The non-obvious items, in order of how often they actually come up:

Data Subject Access Request (DSAR) fulfillment

The buyer wants to see your deletion and export endpoints, audit-logged, with identity verification enforced. The engineering work:

• A DELETE /api/users/{id} that cancels the account, purges personal data, and keeps an audit log entry without the personal data itself.
• A GET /api/users/{id}/export that returns a machine-readable archive of every entity that referenced the user.
• Identity verification on both — bcrypt timing-equalized even when the email does not exist (so the response time does not leak the user enumeration).

Sub-processor management

The buyer wants a list and a change-notification process. Engineering work:

• A versioned sub-processor list in the documentation, with an RSS feed or webhook for changes.
• A code path that rejects dependencies that send data outside the documented list (a CI check or a runtime allowlist).

EU residency for inference and storage

Many B2B buyers will not buy a SaaS whose primary database sits in the US. The engineering work:

• Pin the MongoDB region to the EU (eu-west-1 or similar).
• Pin any third-party inference provider to an EU endpoint, and surface this in the DPA.
• Document data-residency in the security overview.

Retention enforcement

Most startups can produce a retention policy. The harder question is "is it enforced?" Engineering work:

• A scheduled job that scans for records past their retention deadline and deletes them.
• A log of the job, accessible to the buyer on request.
• An explicit test that the job runs (not just a CI assertion that it compiles).

Audit logging

Almost every security questionnaire asks for it. Engineering work:

• A central audit log entity, append-only, fed by an interceptor or middleware.
• Retention: longer than the buyer expects (90 days default, configurable up). Never shorter.

Access control on the admin dashboard

Buyers want to know who at your company can see their data. Engineering work:

• A documented access policy that names the roles, the humans in each role, and the audit trail of access.
• A short TTL on production access (we use 4-hour TTL issued on demand with a justification comment).

The trap: SOC 2 as a destination vs a continuous practice

The mistake most early-stage B2B SaaS companies make is treating SOC 2 as a finish line. It is not. SOC 2 audits are point-in-time; the buyer will read your continuous-control posture, not just the most recent audit report. Engineering work that makes this continuous:

• The retention scheduler runs in CI as a verification job (does the query return non-stale results?).
• The audit log writes feed a dashboard that someone actually watches.
• The sub-processor list is auto-regenerated from the dependency lockfile on every release.

A buyer reads these signals directly. They will ask, "show me the dashboard." Have the dashboard.

What the buyer actually cares about

In our experience across five B2B procurement cycles, the buyers care about three things in this order:

• Visibility. "When something changes, can I see it?" (sub-processor changes, breach notifications, policy updates).
• Reversibility. "When I leave, can I get my data and can you delete it?" (data export, data deletion, retention schedule).
• Proportionality. "Is the security posture proportional to the data we are entrusting to you?" (encryption, access control, audit log).

Anything in the checklist above that does not serve one of these three is decoration. Cut it.