GDPR for software teams that process EU user data

GDPR compliance is frequently treated as a legal and policy exercise: write a privacy policy, appoint a Data Protection Officer, sign Data Processing Agreements with vendors, and document the lawful basis for each processing activity. These steps are necessary. They are not sufficient.

The legal obligations of GDPR translate directly into engineering requirements. The right to erasure requires a deletion workflow across every system where data exists, not just the primary database. Data residency requirements affect infrastructure architecture. Retention policies require automated enforcement, not just documented intent. Organizations that fail GDPR audits are frequently those whose legal documentation was complete but whose engineering implementation did not deliver on what the documentation described.

IBM’s GDPR compliance documentation is direct: the most serious violations can lead to fines of up to EUR 20 million or 4% of worldwide annual turnover. GDPR regulators can also terminate illicit data processing and compel organizational changes. The stakes are high enough that the engineering implementation of GDPR obligations deserves the same rigor as the legal documentation.

The data subject rights that require engineering implementation

GDPR’s data subject rights are the most engineering-intensive part of the regulation because they require responses to individual user requests across complex data landscapes. IBM’s checklist documents that organizations must respond to all data subject access requests within 30 days.

Right to access (Article 15)

• What it requires in engineering terms: when a data subject requests access to their personal data, the system must be able to retrieve and export all personal data held about that individual across all systems, not just the primary user database, but also analytics databases, logs, backup systems, marketing platforms, and any third-party processors
• The engineering gap: most SaaS applications can export a user’s profile data easily. Exporting all personal data across analytics events, support tickets, email logs, and audit trails requires a data inventory that maps where personal data exists across the full system landscape. Without this inventory, a DSAR response is incomplete and creates regulatory risk

Right to erasure (Article 17)

The EDPB’s CEF 2025 action focused specifically on the right to erasure, with 32 Data Protection Authorities participating across Europe. The EDPB selected this right as it is one of the most frequently exercised GDPR rights and one about which DPAs most frequently receive complaints. The EDPB’s published report identifies the most common compliance challenges in implementing Article 17.

• What it requires in engineering terms: when a verified erasure request is received, the system must delete or anonymize the data subject’s personal data across all systems within the one-month response window. This includes cascading deletion through relational database relationships, removal from search indexes, anonymization in analytics data where true deletion is impossible, and notification to processors
• Anonymization vs. deletion: for audit logs and analytics pipelines where deletion is technically complex, anonymization satisfies Article 17 if the result genuinely cannot be re-identified. The EDPB’s report identifies coordinating deletion across multiple systems as the most common compliance challenge

Data Processing Agreements: the controller-processor relationship in software terms

GDPR requires that every processor of personal data on behalf of a controller has a Data Processing Agreement in place. For software organizations this means DPAs with every third-party service that handles user data, cloud providers, analytics platforms, email services, and support tools.

The German Federal SA’s 2025 fines against Vodafone GmbH, EUR 15 million and EUR 30 million, included violations of Article 28(1) GDPR, which governs the controller-processor relationship and the DPA requirement. The fines reflect how seriously DPAs treat failures in the controller-processor framework, not just data breach events.

• Controller vs. processor: if your organization decides what personal data to collect and why, you are a controller. If a third-party service processes that data according to your instructions, they are a processor. Both roles carry obligations under GDPR, and the DPA is the contractual mechanism that defines the division of responsibility

Data residency: what GDPR actually says about where EU data can live

Microsoft’s GDPR documentation confirms that GDPR strictly regulates transfers of personal data of European residents to destinations outside the European Economic Area. A specific legal mechanism or certification is required to enable these transfers.

• Standard Contractual Clauses (SCCs): the primary mechanism for transferring EU personal data to non-EEA destinations. The European Commission has published updated SCCs that include both controller-to-controller and controller-to-processor variants. US-based SaaS companies processing EU user data typically use SCCs to legitimize the data transfer
• EU-US Data Privacy Framework: the 2023 EU-US Data Privacy Framework provides a certification mechanism for US organizations to self-certify compliance with GDPR transfer requirements. Organizations certified under the DPF can receive EU personal data without SCCs for transfers covered by their certification
• Data residency vs. data localization: GDPR does not require that EU personal data be stored within the EU. It requires that transfers to non-EEA destinations have a valid legal mechanism. Storing EU data on US-region AWS infrastructure is permissible under SCCs or the DPF. Some enterprise customers and specific regulated industries may impose data residency requirements beyond what GDPR mandates
• Engineering implications: the infrastructure architecture decision about where data is stored must account for the DPA and transfer mechanism before deployment. Migrating data from a US region to an EU region after product launch is operationally expensive. Designing the data residency architecture before the first EU customer is the right sequence

Retention policies: the difference between documenting and enforcing

GDPR’s storage limitation principle (Article 5(1)(e)) requires that personal data be kept for no longer than necessary for the purpose for which it was collected. Most organizations document retention periods. Fewer enforce them automatically.

• Retention policy documentation: every category of personal data must have a documented retention period derived from the lawful basis for processing. User account data retained for the duration of the account relationship. Transaction records retained for the period required by tax law (typically 7 years). Support ticket content retained for 3 years. Marketing interaction data retained for 2 years
• Automated enforcement: a retention policy that requires a human to run a database purge script on a schedule is not compliance infrastructure. It is a risk that depends on someone remembering to run the script. Automated retention enforcement, database jobs, data lifecycle management in cloud storage, scheduled anonymization pipelines, removes human dependency from the compliance mechanism
• Retention and the right to erasure interaction: when a data subject requests erasure, the retention policy schedule is irrelevant. The erasure request overrides the retention schedule unless a specific legal ground for continued retention applies (legal obligation, legal claim, public interest). Engineering must support both automated retention expiry and on-demand erasure from the same data stores

WebOsmotic’s GDPR compliance engineering practice builds data residency architecture, right to erasure workflows, DPA coverage audits, and automated retention enforcement for SaaS, fintech, and healthcare clients. These are designed as engineering deliverables at the architecture phase, not added as a compliance remediation after the first DPA or DSAR.

Frequently asked questions

Who does GDPR apply to?

GDPR applies to any organization that operates in the EU or handles personal data of EU residents, regardless of where the organization is based. IBM’s GDPR documentation explicitly states that any company operating in the EU or handling EU residents’ data must adhere to GDPR requirements. A US-based SaaS company whose product is used by EU residents is subject to GDPR for that data. The regulation has extraterritorial scope, and organizations in non-EU countries cannot opt out by incorporation location. The German Federal SA’s 2025 fines against Vodafone GmbH demonstrate that enforcement actions cover both national and multinational operations.

What are the maximum GDPR fines?

GDPR provides for two tiers of administrative fines. The most serious violations, including violations of the basic principles of processing, the conditions for consent, and data subjects’ rights, can result in fines of up to EUR 20 million or 4% of worldwide annual turnover in the previous year, whichever is higher. Less severe violations, including procedural requirements like maintaining records of processing, DPA requirements, and notification obligations, carry fines of up to EUR 10 million or 2% of worldwide annual turnover. The German Federal SA’s 2025 actions against Vodafone GmbH included separate fines of EUR 15 million and EUR 30 million for violations spanning data processing agreements and security of processing.

What does the right to erasure require technically?

The right to erasure under Article 17 GDPR requires that when a verified erasure request is received, the organization deletes or anonymizes the data subject’s personal data across all systems within one month. Technically, this means: cascading deletion through relational database foreign key relationships; removal from search indexes; anonymization in analytics pipelines where deletion of historical data would break aggregate reporting; notification to processors so they delete the data from their systems; and a procedure to prevent deleted data from being restored from backups. The EDPB’s CEF 2025 action, in which 32 EU data protection authorities examined Article 17 compliance, identified multiple information systems and technical difficulty in coordinating deletion across them as the most common compliance challenge.

What is a Data Processing Agreement and when is it required?

A Data Processing Agreement (DPA) is a contract between a data controller (the organization that determines what data to collect and why) and a data processor (a third party that processes data on the controller’s behalf). GDPR Article 28(1) requires that any processing by a processor be governed by a contract (the DPA) that binds the processor and sets out the subject matter, duration, nature, and purpose of the processing. In software development terms, this means DPAs are required with every third-party service that handles user personal data: cloud hosting providers, analytics platforms, email services, support tools, and error monitoring systems. The German Federal SA’s 2025 GDPR fines against Vodafone GmbH included Article 28(1) violations, indicating that DPA compliance failures are treated as seriously as data breach events.

Does GDPR require storing EU data within the EU?

No. GDPR requires that transfers of EU personal data to non-EEA destinations use a valid legal mechanism, it does not require that the data be stored within the EU. The primary mechanisms are Standard Contractual Clauses (SCCs), which the European Commission has published for both controller-to-controller and controller-to-processor transfers, and the EU-US Data Privacy Framework, which provides a certification mechanism for US organizations. A US-based SaaS company can store EU user data on AWS US-East infrastructure using SCCs or DPF certification. However, some regulated industry customers and enterprise procurement requirements may impose data residency requirements beyond what GDPR mandates, requiring EU-region infrastructure regardless of GDPR’s actual legal requirements.

How does WebOsmotic implement GDPR technical controls?

WebOsmotic implements GDPR technical controls as engineering deliverables at the architecture phase. This includes: data inventory design that maps where personal data exists across all system components (primary database, analytics, logs, backups, third-party processors); right to erasure workflow that covers cascading deletion across all data stores and processor notification; data portability export endpoint with structured output format; DPA coverage audit of all third-party services handling user data; data residency architecture that identifies transfer mechanisms needed for non-EEA storage; and automated retention enforcement via database lifecycle jobs or cloud storage policies. For SaaS, fintech, and healthcare clients, these controls are designed before the first EU user account is created, not added retroactively when a DSAR or enforcement inquiry arrives.