GDPR compliance is one of those topics that founders treat as a checkbox until an EU enterprise customer hands them a 200-line Data Processing Addendum (DPA) and a Transfer Impact Assessment (TIA) demand. At that point, the architectural decisions made during the past year determine whether the deal closes in two weeks or six months. This post is for founders trying to get the architecture right before that moment.
GDPR Scope and What It Actually Requires
GDPR applies to organizations that process personal data of EU residents — regardless of where the organization is based. "Personal data" is broadly defined: anything that can identify a natural person, including IP addresses, device identifiers, and behavioral patterns. The territorial scope catches almost every B2B SaaS company with EU customers.
The core obligations:
Lawful basis for processing. Every processing activity must have a documented lawful basis: consent, contract performance, legal obligation, vital interests, public task, or legitimate interests. Consent is the most-cited but actually narrowest basis; legitimate interests is the most useful for B2B SaaS but requires balancing-test documentation.
Data subject rights. Individuals have rights to: access (DSAR), rectification, erasure (right to be forgotten), restriction of processing, data portability, objection, and protection from solely automated decision-making. Each right has architectural implications. Erasure is particularly hard architecturally because it requires knowing where personal data lives across all systems.
Data Processing Agreements (DPAs) and processor chains. When you use third-party services that process personal data on your behalf (every B2B SaaS does), you need a DPA with each processor. Each processor that uses sub-processors requires those sub-processor relationships to be disclosed and contractually flowed-down.
Cross-border transfer mechanisms. Transferring personal data outside the EEA (e.g., to US-based servers or US-based subprocessors) requires an adequate transfer mechanism: EU-US Data Privacy Framework (DPF) self-certification, Standard Contractual Clauses (SCCs), Binding Corporate Rules, or one of the limited derogations. SCCs require a Transfer Impact Assessment (TIA) post-Schrems II.
Privacy by design and default. Article 25 requires that systems be designed for data minimization, purpose limitation, and storage limitation by default. This is an architectural principle, not just a documentation exercise.
Breach notification. Notify the supervisory authority within 72 hours of becoming aware of a breach; notify affected data subjects without undue delay if high risk. Operationally, this requires monitoring that can detect breaches in something close to real time and incident-response runbooks that can produce notifications quickly.
Where Most Startups Go Wrong
No personal data inventory. Most companies don't have an accurate inventory of where personal data lives across their systems — production databases, analytics warehouses, customer support tools, marketing automation, observability tools, log aggregation. Without an inventory, DSAR fulfillment becomes a manual archaeological dig per request.
Cookie banners as compliance theater. A cookie banner that loads non-essential cookies before user consent fails Article 7 consent standards. Most US-based companies have implementations that don't meet EU consent standards (the bar is genuinely higher). EU enterprise customers notice.
Lawful basis = "we have a Privacy Policy." Article 6 lawful basis isn't satisfied by having a Privacy Policy. Each processing activity needs documented lawful basis. Most B2B SaaS companies use legitimate interests for the bulk of processing — but the balancing test must be documented.
DPA chains incomplete. A typical SaaS company has 80+ vendors processing personal data. Many DPAs are unsigned, expired, or don't reflect the current sub-processor list. EU enterprise customers will ask for the full processor list and verify DPAs on a sample.
No DSAR fulfillment pipeline. Companies handle the first few DSARs manually, then become overwhelmed when volume scales. The architecture for programmatic DSAR fulfillment requires identifying data stores, retrieving and aggregating, redacting third-party data, and delivering — all within the 30-day statutory window. Building this after volume hits is expensive.
Cross-border transfer mechanisms missing or out of date. Privacy Shield was invalidated in July 2020 (Schrems II); the EU-US Data Privacy Framework replaced it in 2023. Companies that didn't update their transfer mechanism between 2020 and 2023 had no valid mechanism for that period — a real exposure.
What a Fractional CTO Owns
For GDPR-relevant startups, fractional CTO work covers:
- Personal data inventory across all systems — production, analytics, observability, customer support, marketing
- Architectural decisions for DSAR fulfillment and right-to-erasure — identification, retrieval, aggregation, redaction, deletion patterns
- Lawful basis documentation and balancing-test work — for legitimate interests-based processing
- DPA chain audit and remediation — vendor inventory, DPA status verification, sub-processor disclosure
- Cross-border transfer mechanism implementation — SCCs, TIAs, DPF self-certification eligibility
- Privacy-by-design architecture — data minimization, purpose limitation, storage limitation as architectural principles, not policy text
- Breach detection and notification readiness — monitoring, incident response runbooks, communication templates
- Hiring or appointing a DPO when the threshold is crossed
Pricing and Engagement Length
Standard tiers: Advisory $8K, Fractional $15K, Embedded $25K per month. GDPR-heavy engagements typically run at the Fractional or Embedded tier during the readiness phase (months 1–6) and scale back afterward. Total engagement is often 12–18 months for a B2B SaaS startup going from US-only to EU enterprise sales readiness.
When You Don't Need a Fractional CTO for GDPR Specifically
If you have a senior engineer or VP of Engineering who has implemented GDPR for a previous company, you may not need a fractional CTO specifically for this work. Compliance automation tools (Drata, Vanta, Secureframe) cover policy templating and evidence collection; Privacy-management platforms (OneTrust, Ethyca) handle DSAR pipelines. The fractional CTO adds value when the company doesn't have internal experience or when GDPR work is colliding with parallel architectural decisions.
How We Engage for GDPR Work
Our fractional CTO services cover GDPR as part of broader engineering and compliance leadership. For founders specifically working through compliance posture, our SOC 2 post above is the natural companion piece, and our fintech industry page covers PCI + GDPR overlap for payments-adjacent companies.
Need help thinking this through?
EU enterprise sales conversations make GDPR architecture concrete fast. The decisions you make in the months before that conversation determine the velocity of those deals. Book a 30-min call — no pitch. Book a Free 30-Min Strategy Call →