GDPR compliance is not a checkbox exercise. It is a set of engineering decisions that affect how you store data, handle user requests, manage consent, and design your entire data architecture. After implementing GDPR compliance across multiple SaaS platforms serving EU and UK customers, we have distilled the technical patterns that make compliance achievable without crippling your product development velocity.
Data Residency: Where Your Data Lives Matters
GDPR does not prohibit storing data outside the EU, but it does impose strict requirements on international transfers. The simplest way to avoid transfer complications is to keep personal data within EU/UK data centres.
Choose your cloud regions deliberately
When setting up infrastructure, default to EU regions (eu-west-1, eu-central-1 for AWS; West Europe for Azure). This applies not just to your primary database but to every service that touches personal data - queues, caches, search indices, logging systems, and backup storage.
// Infrastructure configuration - EU-first data residency
const config = {
database: { region: 'eu-west-1', backup_region: 'eu-central-1' },
cache: { region: 'eu-west-1' },
search: { region: 'eu-west-1' },
storage: { region: 'eu-west-1', replication: 'eu-central-1' },
logging: { region: 'eu-west-1' } // Logs contain personal data too
};The logging line is important. Many teams carefully localise their database but send application logs containing user IDs, email addresses, and IP addresses to a US-hosted logging service without thinking about it.
Consent Management: Getting It Right Technically
Consent under GDPR must be freely given, specific, informed, and unambiguous. This has direct technical implications for how you build registration flows, cookie banners, and marketing preferences.
Store consent as an immutable audit trail
Every consent decision a user makes should be recorded with the exact text they agreed to, the timestamp, and the mechanism (checkbox, banner click, API call). This record must be immutable - you need to prove what the user consented to and when.
// Consent record schema
const consentRecord = {
userId: 'usr_abc123',
consentType: 'marketing_email',
granted: true,
timestamp: '2026-01-15T14:32:00Z',
version: 'privacy-policy-v3', // Which version they agreed to
mechanism: 'settings_page', // How consent was collected
ipAddress: '192.168.1.x', // Pseudonymised
text: 'I agree to receive product updates and newsletters...'
};When a user withdraws consent, do not delete the original consent record. Instead, append a new record showing the withdrawal. You need both records for your audit trail.
Right to Deletion: The Technical Challenge
Article 17 gives users the right to request deletion of their personal data. This sounds simple until you consider that personal data may exist in your primary database, search indices, caches, backups, log files, analytics systems, and third-party integrations.
Build a data map first
Before implementing deletion, document every system that stores personal data. For each system, identify what data it holds, how to delete it, and what the retention policy is. This data map becomes the specification for your deletion pipeline.
Implement soft delete with scheduled purge
Immediate hard deletion from all systems simultaneously is technically impractical. Instead, implement a two-phase approach: immediate soft delete that makes the data invisible to the application, followed by a scheduled purge job that removes data from all backing stores.
// Two-phase deletion pipeline
async function handleDeletionRequest(userId) {
// Phase 1: Immediate soft delete (user-facing)
await db.users.update(userId, {
status: 'deletion_pending',
personalData: null, // Clear from primary store
email: generateTombstone(), // Replace with non-reversible hash
deletionRequestedAt: new Date()
});
// Phase 2: Queue background purge (system-level)
await deletionQueue.enqueue({
userId,
systems: ['search_index', 'cache', 'analytics', 'email_service'],
deadline: addDays(new Date(), 30) // GDPR allows up to 30 days
});
}Privacy by Design: Architecture Decisions
GDPR Article 25 requires data protection by design and by default. This means privacy considerations should influence your architecture from the start, not be retrofitted later.
Minimise data collection
Only collect personal data that you actually need for the stated purpose. Every additional field you collect increases your compliance burden - more data to protect, more data to delete on request, more data to include in subject access requests.
Pseudonymise where possible
Pseudonymisation replaces identifying information with artificial identifiers while maintaining the ability to re-identify when necessary. Use it for analytics, logging, and any system that does not need to display personal data directly.
// Pseudonymisation for analytics events
function pseudonymiseEvent(event) {
return {
...event,
userId: hash(event.userId + PEPPER), // One-way hash with secret
ip: event.ip.replace(/\.\d+$/, '.0'), // Truncate last octet
email: undefined // Strip entirely
};
}Subject Access Requests: Automating the Response
Under Article 15, users can request a copy of all personal data you hold about them. You have 30 days to respond. For a SaaS platform with data spread across multiple systems, manually assembling this data for every request is unsustainable.
Build an automated SAR pipeline
Create an automated system that can query all data stores for a given user ID and compile the results into a downloadable format. This should be a self-service feature in your application, not a manual process handled by your support team.
Breach Notification: Be Prepared
Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach. Article 34 requires notification to affected individuals if the breach poses a high risk to their rights and freedoms.
72 hours is not a lot of time to investigate a breach, assess its impact, and prepare a notification. Have your incident response plan, notification templates, and communication channels ready before you need them. Run a tabletop exercise at least annually to identify gaps in your response process.
Making Compliance Sustainable
GDPR compliance is not a destination - it is an ongoing operational requirement. The patterns described here - EU data residency, immutable consent records, automated deletion pipelines, pseudonymisation, and self-service SARs - make compliance manageable at scale. Build them into your platform architecture early, and compliance becomes a natural byproduct of good engineering rather than a burden imposed from the outside.
Back to insights