GDPR Requirements - Compliance Frameworks | OneNoughtOne

0/273

System Design (HLD)Compliance Frameworks

Compliance Frameworks

LevelAdvanced

Duration120 mins

TopicCompliance Frameworks

1 / 5

GDPR Requirements

The Regulation That Changed Everything

On May 25, 2018, the General Data Protection Regulation (GDPR) went into effect, fundamentally transforming how organizations worldwide collect, process, store, and protect personal data. This European Union regulation didn't just create new rules—it established a global standard for data privacy that has influenced legislation from California (CCPA) to Brazil (LGPD) to Japan and beyond.

For system designers and architects, GDPR represents a paradigm shift. Privacy is no longer an afterthought to be bolted on after launch—it must be embedded into the very foundations of system architecture. Understanding GDPR isn't just a legal necessity; it's an architectural discipline that shapes how we design databases, APIs, data flows, and entire distributed systems.

High Stakes Compliance

GDPR violations can result in fines up to €20 million or 4% of global annual revenue—whichever is higher. In 2023, Meta was fined €1.2 billion for data transfer violations. This isn't theoretical risk; it's operational reality for any organization processing EU residents' data.

Understanding GDPR Fundamentals

Before diving into implementation details, architects must understand the foundational concepts that GDPR establishes. These concepts form the vocabulary of compliance and the constraints within which all technical decisions must be made.

Core GDPR Terminology

•Personal Data — Any information relating to an identified or identifiable natural person. This includes obvious identifiers (name, email, SSN) but also IP addresses, cookie identifiers, device fingerprints, and even pseudonymized data if it can be re-linked to an individual.
•Data Subject — The individual whose personal data is being processed. Under GDPR, data subjects have extensive rights that systems must support.
•Data Controller — The entity that determines the purposes and means of processing personal data. As the controller, you bear primary responsibility for GDPR compliance.
•Data Processor — An entity that processes personal data on behalf of the controller (e.g., cloud providers, analytics services). Processors have their own obligations under GDPR.
•Processing — Any operation performed on personal data: collection, recording, organization, structuring, storage, adaptation, retrieval, consultation, use, disclosure, erasure, or destruction. Nearly everything you do with data is 'processing.'
•Consent — One of several legal bases for processing. When used, it must be freely given, specific, informed, and unambiguous—with demonstrable proof of the data subject's agreement.

The Scope Question: Does GDPR Apply to My System?

GDPR applies if:

Your organization is established in the EU (regardless of where processing occurs)
You process personal data of individuals in the EU (regardless of where your organization is located)
You offer goods/services to EU residents or monitor their behavior

This extraterritorial reach means that a startup in San Francisco processing data from French users must comply with GDPR—not as a courtesy, but as a legal requirement enforceable through EU-US mutual legal assistance treaties.

Special Categories of Data

GDPR distinguishes 'special category data' (Article 9) which requires additional protections: racial/ethnic origin, political opinions, religious beliefs, genetic data, biometric data (for identification), health data, sex life, or sexual orientation. Processing this data requires explicit consent and additional safeguards.

The Seven GDPR Principles

GDPR's Article 5 establishes seven foundational principles that govern all data processing. These principles are not merely aspirational—they are legally binding requirements that must be demonstrable in your system design.

GDPR Article 5 Principles and Architectural Implications
Principle	Legal Requirement	System Design Implication
Lawfulness, Fairness, Transparency	Process data lawfully, fairly, and transparently	Clear consent UIs, privacy policies, audit trails showing legal basis for each data point
Purpose Limitation	Collect data for specified, explicit, legitimate purposes only	Data flow documentation, purpose tagging in databases, access controls based on purpose
Data Minimization	Process only data that is adequate, relevant, and limited to what is necessary	Schema reviews, no 'just in case' data collection, field-level necessity justification
Accuracy	Keep personal data accurate and up to date	Data validation pipelines, user self-service update portals, data freshness SLOs
Storage Limitation	Keep data in identifiable form only as long as necessary	Automated retention policies, deletion workflows, archival procedures
Integrity & Confidentiality	Ensure appropriate security through technical and organizational measures	Encryption at rest/transit, access controls, audit logging, incident response
Accountability	Be able to demonstrate compliance	Comprehensive logging, documentation, Data Protection Impact Assessments (DPIAs)

The Accountability Principle: The Game Changer

Of these seven principles, accountability deserves special attention. Under GDPR, it's not enough to be compliant—you must be able to prove compliance at any moment. This shifts the burden of proof to the organization and demands comprehensive documentation:

Records of processing activities
Data protection impact assessments for high-risk processing
Documented policies and procedures
Training records for staff
Evidence of consent where applicable
Third-party processor agreements
Incident response logs and breach notifications

Design for Demonstrability

When designing systems, always ask: 'How would I prove to a regulator that we're following this principle?' If you can't answer that question with specific logs, documents, or system capabilities, your compliance posture has a gap.

Data Subject Rights: Technical Requirements

GDPR grants individuals extensive rights over their personal data. Each of these rights translates into specific technical capabilities that your systems must support. These aren't 'nice to have' features—they are legal entitlements that must be fulfilled within strict timelines (typically 30 days).

Mandatory Technical Capabilities

•Right to Access (Article 15) — Data subjects can request a copy of all personal data held about them. Your system needs: global data inventory, cross-service data aggregation, export in machine-readable format (JSON, CSV), automated or semi-automated Subject Access Request (SAR) handling.
•Right to Rectification (Article 16) — Individuals can demand correction of inaccurate data. Requires: self-service update interfaces, data validation, propagation of changes across all systems and backups, audit trail of corrections.
•Right to Erasure / 'Right to be Forgotten' (Article 17) — Data subjects can demand deletion of their data under certain circumstances. The most technically challenging right: requires complete data inventory including backups, archives, caches, logs, third-party processors, and derived data.
•Right to Restriction (Article 18) — Users can request that processing be limited while disputes are resolved. Requires: data 'freezing' capability, restricting access while maintaining storage, clear status tracking.
•Right to Data Portability (Article 20) — Users can request their data in a structured, commonly used, machine-readable format for transfer to another provider. Requires: standardized export formats, API-based data extraction, interoperability considerations.
•Right to Object (Article 21) — Individuals can object to specific types of processing (e.g., marketing, profiling). Requires: granular consent management, processing type tagging, immediate cessation workflows.
•Rights Related to Automated Decision-Making (Article 22) — If automated decisions significantly affect individuals, they have rights to human intervention, explanation, and contestation. Requires: explainable AI/ML, human review workflows, decision audit logs.

The Right to Erasure: A Deep Technical Challenge

The Right to Erasure deserves a detailed examination because it fundamentally challenges how we think about data architecture. When a user requests deletion:

Primary databases must be wiped — Relatively straightforward with proper schema design
Backups present a dilemma — Do you restore and delete across all backups? GDPR allows 'erasure from active systems' with backup deletion upon restoration
Caches and CDNs must be invalidated — TTL-based caches need explicit invalidation mechanisms
Third-party processors must delete — You need contractual commitments and verification procedures
Derived data and analytics may survive — Aggregated, truly anonymized data can remain, but pseudonymized data cannot
Log files require special handling — Structured deletion from append-only logs is complex; many organizations use separate short-retention logs for personal data
Search indexes need updating — Elasticsearch, Algolia, etc., must reflect deletions
ML models trained on data — This is an evolving area; 'machine unlearning' is still nascent

The 30-Day Deadline

Organizations must respond to data subject requests within one month. For complex requests, this can be extended to three months, but the data subject must be notified within the first month. Automating SAR handling isn't optional at scale—it's operational necessity.

Privacy by Design and Default

Article 25 of GDPR codifies 'Privacy by Design' and 'Privacy by Default' as legal requirements. Originally developed by Ann Cavoukian as a framework, these concepts are now binding principles that must influence every architectural decision from the earliest design phases.

Privacy by Design

•Proactive, not reactive — Anticipate privacy risks before they materialize
•Privacy as the default — Maximum privacy without user intervention
•Privacy embedded into design — Not bolted on as an afterthought
•Full functionality — Privacy without sacrificing features (positive-sum)
•End-to-end security — Full lifecycle protection of data
•Visibility and transparency — Open to verification and audit
•Respect for user privacy — User-centric design and controls

Privacy by Default

•Default settings use minimum data necessary
•Optional data fields are not pre-selected
•Data sharing opt-ins require affirmative action
•Marketing communications default to off
•Retention periods default to minimum
•Third-party integrations default to off
•Profile visibility defaults to private where applicable

Architectural Patterns for Privacy by Design

Translating these principles into system architecture requires specific patterns:

Data Minimization at the Schema Level

Every field in your schema should have documented justification
Use 'required' sparingly—only for truly essential data
Consider schema reviews as part of design approval process

Encryption by Default

All data at rest encrypted (AES-256 or equivalent)
All data in transit encrypted (TLS 1.3+)
Consider field-level encryption for sensitive data
Key management separated from data storage

Pseudonymization as Standard Practice

Replace direct identifiers with tokens where possible
Separate identity mapping from application data
Consider homomorphic encryption for analytics on sensitive data

Purpose Binding in Data Architecture

Tag data with processing purposes at ingestion
Access control policies bound to purposes, not just roles
Prevent purpose creep through technical constraints

The Privacy Review Checkpoint

Add privacy review as a mandatory checkpoint in your design review process. Before any system goes to development, a privacy engineer should verify: What personal data is collected? Why? How long is it kept? Who has access? How would we handle a deletion request? This prevents costly retrofits later.

Cross-Border Data Transfers

GDPR imposes strict requirements on transferring personal data outside the European Economic Area (EEA). This has profound implications for cloud architecture, vendor selection, and global service deployment.

The Transfer Mechanisms

Data transfers to non-EEA countries are permitted only under specific conditions:

GDPR Transfer Mechanisms
Mechanism	Description	Practical Use Case
Adequacy Decisions	EU Commission has determined the country provides adequate protection	Transfers to UK (post-Brexit), Japan, South Korea, Canada (commercial orgs), Israel, New Zealand, etc.
Standard Contractual Clauses (SCCs)	Pre-approved contract terms that bind the data importer to GDPR-like protections	Most common mechanism for US cloud providers; requires supplementary measures post-Schrems II
Binding Corporate Rules	Internal codes of conduct approved by EU regulators for intra-group transfers	Used by large multinationals for internal data flows
Explicit Consent	Data subject explicitly consents to the transfer with full knowledge of risks	Rarely practical for ongoing system operations; typically for one-off transfers
Contractual Necessity	Transfer necessary to perform a contract with the data subject	E.g., booking an international hotel for a user requires sending data to that country

The Schrems II Ruling and Its Aftermath

In July 2020, the Court of Justice of the European Union (CJEU) invalidated the EU-US Privacy Shield framework in the Schrems II decision. The court held that US surveillance laws were incompatible with EU fundamental rights.

This ruling has major implications:

SCCs alone are not sufficient — Organizations must conduct Transfer Impact Assessments (TIAs) evaluating whether the destination country's laws allow data access by authorities in ways that undermine EU protections.
Supplementary measures may be required — Technical measures (encryption, pseudonymization) or organizational measures to prevent unlawful access.
The EU-US Data Privacy Framework — Adopted in July 2023, this new framework attempts to address Schrems II concerns. US companies can certify to the framework, but its durability is uncertain pending potential legal challenges.

Architectural Responses to Transfer Restrictions

Data Localization Strategies

•EU-region cloud deployment — Deploy services in EU-based data centers (e.g., AWS eu-west-1, Azure West Europe, GCP europe-west1). Many organizations now maintain EU-only clusters.
•Data residency controls — Implement hard constraints ensuring EU user data never leaves EU infrastructure. This requires careful CDN configuration, log management, and support tooling.
•Split architecture — Maintain separate instances for EU and non-EU with controlled synchronization only of anonymized data.
•Encryption with EU-controlled keys — Even if data transits US infrastructure, encryption with EU-held keys (possibly via EU-based HSMs) can serve as a supplementary measure.
•Pseudonymization at the edge — Strip identifiers before data leaves the EU; process only pseudonymized data elsewhere.

Beyond Technical Measures

Technical measures are only part of the solution. Organizations must also maintain legal assessments (TIAs), update processor agreements, and monitor regulatory guidance. The legal landscape continues to evolve—build flexibility into your architecture.

Data Breach Notification

Articles 33 and 34 of GDPR establish strict breach notification requirements. A 'personal data breach' includes any breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure, or access to personal data.

Breach Notification Timeline

•Detection — Your monitoring systems identify a potential breach
•Assessment (immediate) — Determine if personal data was affected and the nature of the breach
•Supervisory Authority Notification (72 hours from awareness) — Notify your lead Data Protection Authority unless the breach is unlikely to result in risk to individuals' rights and freedoms
•Data Subject Notification (without undue delay) — If the breach is likely to result in high risk to individuals, you must notify them directly
•Documentation — All breaches must be documented, regardless of notification requirement

The 72-Hour Clock: Technical Implications

The 72-hour notification window creates significant technical requirements:

Detection Capabilities

Security Information and Event Management (SIEM) with real-time alerting
Anomaly detection for unusual data access patterns
Data Loss Prevention (DLP) systems
Endpoint detection and response (EDR)
Network traffic analysis for data exfiltration

Incident Response Automation

Automated triggering of incident response workflows
Pre-defined playbooks for common breach scenarios
Rapid forensic capability to assess scope
Communication templates for notifications

Scope Determination

Ability to quickly determine which data subjects were affected
Data lineage tracking to understand what data was in the breached system
Access logs correlating user accounts to data access

Documentation Infrastructure

Immutable logging of incident response actions
Timeline reconstruction capability
Evidence preservation for potential litigation

The Notification Content

Notifications must include: nature of the breach and data affected, name and contact of DPO, likely consequences, and measures taken or proposed. Having pre-drafted templates and automated data aggregation significantly speeds response.

Technical Controls for GDPR Compliance

Bringing together the requirements we've discussed, here's a comprehensive summary of technical controls that GDPR-compliant systems should implement:

GDPR Technical Controls Matrix
Category	Control	Purpose
Identity & Access	Role-Based Access Control (RBAC)	Limit access to personal data to those who need it
Identity & Access	Multi-Factor Authentication	Prevent unauthorized access even with compromised credentials
Identity & Access	Privileged Access Management	Special controls for administrative access to personal data
Encryption	Encryption at Rest (AES-256)	Protect data in storage from unauthorized access
Encryption	Encryption in Transit (TLS 1.3)	Protect data during transmission
Encryption	Field-Level Encryption	Additional protection for highly sensitive fields
Data Management	Data Classification Tagging	Enable differentiated handling based on sensitivity
Data Management	Automated Retention & Deletion	Enforce storage limitation principle
Data Management	Data Portability APIs	Support data subject access and portability rights
Monitoring	Access Logging & Audit Trails	Detect unauthorized access, support investigations
Monitoring	SIEM Integration	Real-time security monitoring and alerting
Monitoring	Anomaly Detection	Identify unusual patterns that may indicate breaches
Subject Rights	Consent Management Platform	Capture, store, and enforce consent preferences
Subject Rights	SAR Request Portal	Enable data subjects to exercise their rights
Subject Rights	Deletion Orchestration	Coordinate erasure across all systems and processors
Third Party	Processor Agreements & Audits	Ensure processors meet GDPR requirements
Third Party	Data Transfer Assessments	Evaluate cross-border transfer mechanisms

Continuous Compliance

GDPR compliance isn't a one-time project—it's an ongoing operational discipline. Implement continuous monitoring, periodic reviews, and automated compliance checks. Treat privacy debt like technical debt: track it, prioritize it, and pay it down systematically.

Summary: GDPR as Architecture Discipline

GDPR fundamentally changed how we approach data architecture. Let's consolidate the key insights:

Key Takeaways

•GDPR has global reach — Any system processing EU residents' data must comply, regardless of where the organization is based.
•Seven principles guide all data processing — Lawfulness, purpose limitation, data minimization, accuracy, storage limitation, integrity, and accountability form the foundation.
•Data subject rights require technical capabilities — Access, rectification, erasure, portability, and objection rights must be supported in your systems.
•Privacy by Design is mandatory — Privacy considerations must be embedded from earliest design phases, not retrofitted.
•Cross-border transfers need careful architecture — Transfer mechanisms, data residency, and encryption strategies must be planned deliberately.
•72-hour breach notification demands preparedness — Detection, assessment, and notification processes must be automated and rehearsed.
•Accountability means demonstrable compliance — Documentation, logging, and audit trails must prove compliance to regulators.

Moving Forward

With GDPR as our foundation, we'll examine other major compliance frameworks. HIPAA governs health data in the US with its own unique requirements, SOC 2 establishes controls for service organizations, and PCI DSS protects payment data. Each has distinct requirements, but the GDPR principles and patterns we've discussed provide a strong foundation for understanding them all.

Page Complete

You now understand GDPR's fundamental requirements and their implications for system design. From the seven principles to data subject rights to cross-border transfer challenges, you have the architectural vocabulary to design privacy-respecting systems. Next, we'll explore HIPAA requirements for health data protection.