GDPR readiness for technology companies

GDPR reaches technology companies through two doors, and most walk through both. As processors, SaaS companies inherit obligations through the Article 28 data processing agreements every EU enterprise customer requires: documented processing, subprocessor management with notification rights, security measures, breach notification to controllers without undue delay, and audit rights that procurement teams increasingly exercise. As controllers of their own user, marketing, and analytics data, the same companies owe the full controller stack: lawful bases, transparency, data subject rights handling, and records of processing. The regulation's extraterritorial scope means offering services to people in the EU triggers coverage regardless of where the company or its servers sit.

For technology companies specifically, GDPR compliance is inseparable from architecture. Data minimization and purpose limitation are engineering constraints; retention schedules require systems actually capable of deletion, including from backups and analytics stores; data subject access requests require knowing where personal data lives across microservices and third-party tools; and international transfer compliance after Schrems II means mapping every flow to the US and elsewhere, with standard contractual clauses and transfer impact assessments behind each. A privacy program that lives in the legal department while the data lives everywhere else fails at the first serious DSAR, audit, or breach. Readiness work joins the two: a data map that reflects production reality, and controls embedded where the data actually moves.

Key considerations for technology teams

• The controller/processor line must be drawn per processing activity. Product telemetry, customer-content processing, marketing analytics, and AI model improvement each carry different roles and lawful bases; using customer data to train models without a clear contractual basis is a live enforcement and commercial risk.

• Deletion has to actually work. Retention policies mean little if architecture cannot execute them; deletion pipelines that reach replicas, caches, logs, backups (or documented, time-bounded backup expiry), and downstream processors are what regulators and enterprise auditors now ask to see.

• International transfers need a current map. Every EU-to-third-country flow, including to your own US infrastructure and subprocessors, needs a transfer mechanism (adequacy, SCCs with transfer impact assessments) and the map goes stale with every new vendor; DPAs promise customers this is handled, so it must be.

• Breach notification clocks are short and layered. Controllers notify supervisory authorities within 72 hours of awareness where risk exists; processors notify controllers without undue delay, and your enterprise DPAs frequently promise 24-48 hours; incident response must be built against the contractual clock, which is usually the tightest.

• Privacy by design is an audited expectation, not a slogan. DPIAs for high-risk processing (including significant AI features), default-off data collection, and privacy review gates in the development lifecycle are what Article 25 compliance looks like in practice, and what enterprise customers' vendor assessments probe.

Frequently asked questions

Related readiness guides