GDPR Compliance as an Engineering Discipline

The General Data Protection Regulation (GDPR) remains the most consequential privacy legislation affecting software businesses that serve European users. Since enforcement began in May 2018, regulators have issued over 4 billion euros in fines, reaching companies of all sizes. For engineering teams, GDPR is not simply a legal matter to be managed by counsel. It is an architectural discipline.

Consent must be captured with specificity, stored durably, and made auditable. A compliant consent record includes the user identifier, the specific purpose consented to, the version of the consent notice presented, the timestamp of capture, the channel, and the IP address or device fingerprint where appropriate.

Every field in a database schema is a potential liability. Teams should conduct regular schema reviews to justify the continued collection of each data point against a documented business or legal purpose. Pseudonymisation reduces risk for a large class of data processing and enables secondary analytics use cases that would otherwise require explicit consent.

Manual deletion processes are fragile and non-compliant in practice. Retention policies must be implemented as automated system behavior. This requires a retention schedule defined at the data category level, a deletion pipeline triggered by age or account closure, verification that deletions cascade to all replicas and backups, and audit logging of deletion events.

The 30-day window for responding to Subject Access Requests demands automation. Systems must be capable of identifying all data held about a given subject across all datastores, exporting it in a structured format, and deleting it on demand.

Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a breach. This window presupposes automated detection, an established incident response workflow, and pre-drafted notification templates.

Transferring personal data outside the EEA requires a valid transfer mechanism. Teams must rely on Standard Contractual Clauses, Binding Corporate Rules, or adequacy decisions. Cloud infrastructure choices have direct GDPR implications.

We worked with a game studio on GDPR compliance for their player accounts system. Our audit revealed a number of issues.

We replaced the binary consent flag with a versioned consent table. Each record stores the player ID, the consent version identifier linked to a table containing the full text displayed, the timestamp of acceptance, the channel, and the specific purposes consented to as individual boolean columns. When the studio updates its privacy policy or expands its processing purposes, the system flags affected players and gates continued play on re-acceptance at next login. Players who do not re-consent within 30 days are moved to a restricted mode that disables data collection beyond what is required for contract performance.

We also designed a separation between the operational data store, which holds identified player records, and a dedicated analytics environment that receives only pseudonymised or aggregated data. Player events are tagged with a rotating pseudonymous identifier rather than the account ID. The mapping between pseudonym and account lives exclusively in the operational store and is never replicated into analytics, meaning that even if the analytics warehouse were compromised, the data could not be linked back to individual players without access to the mapping key.

For cohort-level analysis, we apply differential privacy techniques that add calibrated statistical noise to aggregate query results, ensuring the presence or absence of any individual player cannot be inferred from the output. Aggregate trends remain clearly visible while individual re-identification becomes computationally infeasible.

A European health app contracted Jinka to modernize their backend infrastructure. Our audit revealed that data was housed on a single SQL Server database with no regional separation, no audit logs, no privacy controls, and no encryption at rest.

We designed a set of REST endpoints centralising all data subject rights operations across three areas. Consent management endpoints allow clients to record consent events, query current consent status by purpose, and check validity before any processing proceeds. Any service handling health data calls the consent check endpoint before acting, treating it as a gate rather than an assumption. Data subject request endpoints handle deletion and structured data exports asynchronously, with completion events logged to an audit trail. Internal reporting endpoints behind role-based access controls allow the compliance team to pull consent coverage rates, deletion request status, and response time metrics without ever touching raw health data directly.

For data residency, all production resources are deployed to Azure's West Europe region with policy constraints applied at the subscription level blocking resource creation outside approved European regions. Health data at rest is encrypted with customer-managed keys scoped to that region via Azure Key Vault, with every decryption event logged through Azure Monitor. All internal service communication runs over TLS.

The result is an infrastructure the customer can demonstrate to regulators and enterprise clients is controlled, logged, and auditable at every layer.