As CTO, you own more of your company's GDPR exposure than you probably realize. The legal team handles policies and contracts. The DPO manages the register and regulatory relationships. But the actual architecture — how data flows, where it lands, how long it lives, who can access it — that's engineering. That's yours.
This guide covers the technical leadership playbook for owning GDPR compliance at the architecture level.
Your Accountability: Article 25 & Privacy by Design
Article 25 of GDPR establishes data protection by design and by default. This is a design philosophy that should shape how your team builds every feature.
By design means privacy protections are built into systems from the start — not retrofitted after launch. Choose technologies with strong privacy characteristics, design data models that collect only what's necessary, and implement encryption at the architecture level.
By default means your product should collect the minimum data necessary for the stated purpose. Additional data collection requires deliberate user action.
As CTO, you make (or approve) these architectural decisions. The regulator's question won't just be "what happened?" — it'll be "what did you build, and why?"
Conducting a Technical Data Audit
Before you can protect data, you need to know where it is. Map every table and collection in your databases. For each entity, document what personal data fields exist, who created each field and why, which fields are actually used vs. stored, and what the retention period should be.
Trace data flows from entry point to storage to deletion: web forms and API endpoints, internal services, third-party integrations, data exports, backup systems.
Run network analysis to see what your application actually sends to third parties. You'll often find analytics SDKs sending more than expected, session recording tools capturing sensitive form fields, and integrations passing data to vendors you've already stopped using.
The output you need: A Record of Processing Activities (ROPA) — Article 30 requires this for most organisations.
Article 32: Security Requirements
Encryption
- At rest: Sensitive personal data should be encrypted at the field or database level, not just disk level
- In transit: All personal data over TLS — including internal service-to-service communication
- Key management: Document access, rotation procedures, and recovery plans
Access Controls
Apply least privilege rigorously:
- Engineers should not have production database access by default
- Customer support should see only data needed to resolve a ticket
- Departing employees should lose access immediately
Implement RBAC and audit it quarterly.
Breach Detection
You have 72 hours to notify the supervisory authority after becoming aware of a breach. Build detection in:
- Alerting on unusual query patterns or bulk data exports
- Log analysis for unauthorised access attempts
- Anomaly detection on data egress volumes
- Automated scanning of public repositories for accidentally committed credentials
Evaluating Your SaaS Stack for GDPR
Every tool you add is a potential data processor. Questions to ask before adding any tool:
- Where does the vendor process and store data?
- Do they offer an adequate DPA?
- What data do they collect beyond their stated purpose?
- Do they share data with sub-processors? Who are they?
- Can you delete user data via API?
Build a vendor data map: every tool that touches personal data, what data it receives, DPA status, data residency, and review date.
Building a Privacy Engineering Culture
Privacy Reviews in PRs
Add to your PR template:
- Does this change collect new personal data? If so, what's the lawful basis?
- Does this change modify data retention?
- Does this change share data with a new third party?
- Have data minimisation implications been considered?
Threat Modelling for Privacy
For each new feature: What personal data does this create or transmit? Who could access it inappropriately? What happens if it's leaked? How would we detect a problem?
Privacy Champions
Designate a privacy champion on each engineering team — an engineer who takes ownership of privacy review and is the first escalation point for questions.
Data Residency & Architectural Implications
Cross-border transfers from the EU/EEA require a valid transfer mechanism. Since Schrems II invalidated Privacy Shield in 2020, the default is Standard Contractual Clauses (SCCs) with transfer impact assessments.
Your choices:
- EU-only deployment: Simplest. Use EU regions for all personal data processing.
- US-primary with EU data residency: Requires data partitioning. Higher engineering cost, cleaner compliance story.
- Global with SCCs: Needs transfer impact assessments for each country.
Make the residency decision early. Retrofitting is expensive.
Incident Response: The 72-Hour Clock
A "personal data breach" includes any accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access to personal data — broader than a traditional security breach.
Your response plan should cover: Detection → Initial assessment → Escalation (Engineering lead → CTO → Legal/DPO → CEO) → Documentation → Notification decision → Regulator notification (72 hours) → Individual notification if high risk.
Run a tabletop exercise at least annually.
Logging Strategy
Log: Authentication events, authorisation decisions, data exports, administrative actions, security-relevant events.
Don't log: Personal data in query params or request bodies, response bodies with personal data, search queries that may contain personal data.
Define retention periods (30-90 days typical for application logs) and implement access controls on logs.
Technical Documentation for Accountability
Article 5(2) requires you to demonstrate compliance. Maintain:
- ROPA — updated for every processing activity change
- Technical security documentation — your controls and why you implemented them
- DPIA records — mandatory for high-risk processing
- Vendor DPA register — every processor, DPA version, sub-processor approvals
- Incident log — all breaches and near-misses
- Training records — evidence of privacy training
CTO GDPR Compliance Checklist
Architecture & Data
- [ ] ROPA completed and current
- [ ] Data model audited for unnecessary personal data fields
- [ ] Retention periods defined and technically enforced
- [ ] Third-party data sharing audited and mapped
Security (Article 32)
- [ ] Personal data encrypted at rest at field/database level
- [ ] All data in transit over TLS including internal services
- [ ] Key management documented and tested
- [ ] Least privilege access controls enforced and audited quarterly
- [ ] Breach detection in place with alerting
- [ ] Incident response plan documented and tested
Vendor Management
- [ ] DPA in place with every data processor
- [ ] Sub-processor list reviewed for all key vendors
- [ ] Transfer mechanisms in place for non-EU processing
Engineering Culture
- [ ] Privacy review questions in PR template
- [ ] Privacy champions designated per team
- [ ] Privacy threat modelling in design process
- [ ] Annual privacy training completed
Documentation
- [ ] DPIA completed for high-risk activities
- [ ] Security controls documented
- [ ] Incident log maintained
- [ ] Vendor DPA register maintained
Start With a Website Scan
Before you can fix your compliance posture, you need to understand your current exposure. Custodia's free scanner gives you a complete picture in 60 seconds: every cookie, tracker, and third-party request, with plain-English compliance implications — no account required.
This post provides general information about GDPR compliance for technical leaders. It does not constitute legal advice. Consult a qualified data protection professional for advice specific to your organisation.
Top comments (0)