FAQ - GDPR for Software Builders

> Disclaimer: This content is for educational and reference purposes for software builders only. It does not constitute medical, legal, financial, or regulatory advice. Consult a qualified professional before making decisions based on this content.

Store at minimum: subject_id, purpose_id, lawful_basis, consent_given (boolean), consent_timestamp (UTC with timezone), consent_ip, consent_method (e.g., "web-form-v2.1"), consent_text_hash (SHA-256 of the exact consent wording shown), and withdrawn_at (nullable). Keep consent records immutable; do not update rows - append new rows when consent changes. Index on (subject_id, purpose_id, consent_given) for fast lookup during request processing. (GDPR Art. 7, EUR-Lex 2016/679)

How do I implement the 72-hour breach notification workflow in my system?

Implement a breach detection pipeline with three phases: (1) Detection - alert rules in your SIEM or observability platform triggering on anomalous data access patterns, exfiltration indicators, or integrity violations; (2) Triage - an on-call runbook with a 4-hour decision gate to classify the breach by severity and determine whether personal data was affected; (3) Notification - if personal data is likely affected, notify the supervisory authority within 72 hours of the controller "becoming aware" (not of the breach occurring). Track breach_id, detected_at, controller_aware_at, dpa_notified_at, and subjects_notified_at in your breach register. Set alerting SLOs at 24h, 48h, and 68h from controller_aware_at. (GDPR Art. 33, EUR-Lex 2016/679)

When is a DPIA required for my software project?

A DPIA is required before starting high-risk processing. Mandatory triggers include: systematic and extensive evaluation of personal aspects using automated processing (profiling), large-scale processing of special category data, systematic monitoring of publicly accessible areas at large scale, and any processing on the national supervisory authority's mandatory DPIA list. As a builder, assess against the EDPB's nine criteria (WP248 rev.01): novel technology, processing at large scale, systematic monitoring, sensitive data, vulnerable subjects, data matching, denial of service risk, profiling, and transfer to third countries. Two or more criteria = DPIA recommended. (GDPR Art. 35(3), EUR-Lex 2016/679)

How should I handle a DSAR where the user requests all their data and I have many data stores?

Build a DSAR fulfillment workflow: (1) Identity verification - authenticate the requester to prevent fraudulent disclosure; (2) Data inventory - query a central data map identifying all systems holding data for that subject_id (relational DB, search index, cache, analytics, logs, backups, third-party processors); (3) Data extraction - run per-system extraction scripts that return subject data in structured format; (4) Compilation - aggregate into a portable format (JSON or PDF); (5) Review - redact third-party data or legally privileged information; (6) Delivery - send securely to the verified requester. Record the request receipt date; the response deadline is one calendar month from receipt. Automate the status tracking. (GDPR Art. 15, EUR-Lex 2016/679)

GDPR applies to any structured operation on personal data of EU/EEA residents, regardless of where the controller/processor is established. Operations include: reading a user record from a database, logging a request with an IP address, sending an email, storing a cookie, running a recommendation algorithm on behavioural data, and generating analytics reports. Even if your servers are outside the EU, GDPR applies if you offer goods or services to EU residents, or monitor their behaviour. (GDPR Art. 3, 4(2), EUR-Lex 2016/679)

How do I implement an automated data retention and deletion workflow?

Design a retention service that: (1) defines a RetentionPolicy per data_category with retention_days and disposal_action (DELETE, ANONYMISE, ARCHIVE); (2) runs nightly or weekly as a background job; (3) queries each data store for records where (created_at + retention_days) <= now() AND legal_hold = false; (4) applies the disposal action atomically; (5) records the deletion in a deletion_log table (what was deleted, when, policy applied). Legal hold flags must block automatic deletion for records involved in ongoing litigation or regulatory investigation. Test deletion propagation to read replicas and backup restore paths. (GDPR Art. 5(1)(e), EUR-Lex 2016/679)

What is the difference between a controller and a processor, and why does it matter for building SaaS?

A controller determines why and how personal data is processed; a processor only processes data on the controller's instructions. In a typical SaaS model: the SaaS vendor is the processor, and each enterprise customer is the controller. The SaaS vendor must: (a) sign a DPA with each controller customer; (b) process data only on documented instructions; (c) not engage sub-processors without authorization; (d) assist the controller with DSARs and DPIAs; (e) delete or return data on contract termination. For multi-tenant architectures, data segregation between controller-tenants must be technically enforced. (GDPR Art. 28, EUR-Lex 2016/679)

How do I structure a privacy notice to comply with Art. 13/14?

For Art. 13 (data collected directly): provide at the time of collection - controller identity and contact, DPO contact (if applicable), purposes and lawful basis for each processing activity, legitimate interests (if relied upon), recipients or categories of recipients, third-country transfer details, retention periods, all data subject rights, right to withdraw consent, right to lodge a complaint with a supervisory authority, and whether providing data is statutory/contractual. For Art. 14 (indirectly obtained data): provide within one month. Use a layered approach: short-form notice at point of collection, full privacy policy linked from it. (GDPR Art. 13-14, EUR-Lex 2016/679)

How does the right to portability work technically, and what format should I export in?

Right to portability applies to data the subject actively provided and where processing is based on consent or contract, and is automated. Implement a /api/v1/users/{id}/export endpoint that: authenticates via JWT (owner only), compiles all directly-provided data (profile fields, uploaded content, explicit inputs), formats it as a structured machine-readable file (JSON or CSV, not PDF), and delivers it via a secure download link with a short TTL. Exclude derived/inferred data (scores, segments) from the portability export - that data was generated by the controller. (GDPR Art. 20, EUR-Lex 2016/679)

What are the technical requirements for implementing Data Protection by Design?

Implement Art. 25 compliance through: (1) Data minimisation at API boundaries - validate that each request field has a documented necessity; (2) Default-to-private settings - new user accounts default to private/opt-out for optional data sharing; (3) Access control - principle of least privilege for each service accessing the database; (4) Encryption - at rest (AES-256) and in transit (TLS 1.2+); (5) Pseudonymisation - replace direct identifiers with tokens in analytics/logging pipelines; (6) Retention automation - automated deletion of data past its retention period; (7) Consent signals - all processing systems receive and honour consent flags before processing. (GDPR Art. 25, EUR-Lex 2016/679)

How should I handle international data transfers in my application architecture?

Classify each data flow by transfer type: (1) EEA-to-EEA - no restriction; (2) EEA-to-adequate country - no additional safeguards required (check EDPB adequacy list); (3) EEA-to-non-adequate country - requires appropriate safeguard (SCC, BCR, derogation). For SCC transfers, conduct a Transfer Impact Assessment evaluating the legal framework of the destination country. Use module selection: C2P SCCs when a controller transfers to a processor, C2C for controller-to-controller. Implement technical supplementary measures for high-risk destination countries (e.g., end-to-end encryption where only the EEA party holds the keys). (GDPR Art. 44-49, EUR-Lex 2016/679)

What information must be captured in the Record of Processing Activities (RoPA)?

For controllers: (a) controller name and contact details; (b) DPO contact details; (c) purposes of processing for each activity; (d) description of categories of data subjects; (e) categories of personal data; (f) categories of recipients; (g) transfers to third countries and their safeguards; (h) retention periods; (i) description of technical/organisational security measures. Implement RoPA as a database table or structured document with one row per processing activity. Link each RoPA entry to a lawful basis record, relevant DPAs, and DPIAs. (GDPR Art. 30, EUR-Lex 2016/679)

How do I implement an erasure request that cascades across all data stores?

Build an ErasureOrchestrator that: (1) receives a validated erasure request with subject_id; (2) checks for legal holds in a legal_hold_register table - reject if any active hold exists; (3) identifies all data stores from the data map (primary DB, analytics, search, cache, CDN, logs, backup jobs); (4) issues deletion commands to each store in a fan-out pattern; (5) waits for confirmation from each store; (6) sets erasure_completed_at in the DSR tracking table; (7) notifies downstream processors of the erasure obligation. Logs must record what was deleted and when. Backup erasure must be scheduled (mark backup as containing deleted-data, purge on next backup rotation). (GDPR Art. 17, EUR-Lex 2016/679)

Art. 32 requires technical and organisational measures appropriate to the risk, including as examples: (a) pseudonymisation and encryption; (b) ability to ensure ongoing confidentiality, integrity, availability, and resilience of processing systems; (c) ability to restore availability and access after a physical or technical incident; (d) process for regularly testing, assessing, and evaluating effectiveness of measures. Translate to implementation: TLS 1.2+ for data in transit; AES-256 for data at rest; RTO/RPO documented and tested; WAF and DDoS protection; penetration testing schedule; annual security review. (GDPR Art. 32, EUR-Lex 2016/679)

When a user withdraws consent: (1) record withdrawn_at timestamp on the consent record (immutable log); (2) set consent_given = false in the active consent cache; (3) propagate withdrawal signal to all processing systems that depend on this consent - use an event bus (Kafka, RabbitMQ, or similar) publishing a ConsentWithdrawnEvent{subjectId, purposeId, withdrawnAt}; (4) each downstream consumer must stop processing for that purpose within a reasonable time; (5) data collected solely on the basis of the withdrawn consent must be deleted (unless another lawful basis applies); (6) confirm withdrawal to the user. (GDPR Art. 7(3), EUR-Lex 2016/679)

Two fine tiers under Art. 83: Tier 1 (up to €10M or 2% global turnover) covers processor/DPO/certification body obligations; Tier 2 (up to €20M or 4% global turnover) covers core principles, data subject rights, lawful basis, and transfer rules. Factors affecting fine amount: nature/gravity/duration; intentional vs. negligent; mitigation measures taken; technical/organisational measures; DPO cooperation; prior infringements; data categories; notification to supervisory authority. The "whichever is higher" rule means the percentage cap is binding for large corporations. (GDPR Art. 83, EUR-Lex 2016/679)