GDPR: Privacy by Design as the Foundation of Modern Software

TL;DR

• The GDPR has required since May 25, 2018, that personal data be protected according to the “Privacy by Design” principle – technically, this means risk-based security architecture, end-to-end encryption, and well-implemented processes for data subject rights.
• Article 32 demands “state of the art” in security and availability: Pseudonymization, encryption, access control, auditability, and robust backup/recovery processes are now minimum standards in cloud-native environments.
• Article 28 shifts responsibility into the supply chain: Cloud providers must provide clear guarantees as processors – from adherence to instructions, transparency of subprocessors, to technical support for deletion requests (Article 17).
• EU data localization is not a political luxury but a technical and legal anchor of stability: Data residency in EU data centers reduces regulatory risks and simplifies architectural decisions.
• ayedo practically implements Privacy by Design: EU-based data centers, BYOK key management, end-to-end encryption, detailed audit logs based on systems like Loki, and documented Compliance components in the ayedo Kubernetes distribution.

Privacy by Design as an Architectural Principle – Not an Add-on

“Privacy by Design” in the GDPR is not a marketing slogan but an architectural principle. The regulation is deliberately technology-neutral. It does not prescribe which software you must use but defines protection goals and leaves you the freedom to implement them technically in a meaningful way.

This is an opportunity: Those who design platforms and applications with privacy in mind today build more stable, secure, and often operationally efficient systems. Security standards, clean logging structures, precise data models for deletion and retention – all these are not only responses to regulatory requirements but also good engineering practice.

The following discusses three key GDPR articles – 32, 28, and 17 – and how to technically manage their requirements in a modern, cloud-native multi-tenant environment. We then look at EU data localization and its practical implementation at ayedo.

Article 32 GDPR: Security of Processing as a Technical Target Catalog

Article 32 (“Security of Processing”) requires “a level of security appropriate to the risk.” Since May 25, 2018, this has been the binding standard for anyone processing personal data. For cloud-native architectures, four key requirements can be derived from Article 32: Pseudonymization and encryption, ensuring confidentiality/integrity/availability, recovery, and continuous review.

Pseudonymization and Encryption by Default

Technically, it makes sense to assume a principle: Personal data is only stored or transmitted in plain text in exceptional cases.

Specifically, this means:

• Data in Transit
  All connections through which personal data flows are secured with modern protocols (e.g., current TLS versions, strong cipher suites). In service-oriented architectures, mTLS between services is now state of the art.

• Data at Rest
  Persistent storage (volumes, databases, object storage) is encrypted by default. Ideally, with central key management and a clear link between tenant and key material.

• Pseudonymization in the Data Model
  In many cases, it is sufficient to decouple direct identifiers:

  • Use of technical IDs instead of email addresses or names in internal references
  • Separate storage of identity data and business data with clear access paths
  • Use of hashes or tokens where only recognizability, not assignability to the individual, is required

Privacy by Design here means planning this decoupling in the data model and API design from the outset – not trying to “bolt it on” later.

Confidentiality, Integrity, Availability, and Resilience

Article 32 explicitly names these four aspects. For a cloud-native platform, they can be broken down into central technical patterns:

• Confidentiality

  • Strict role-based access control (RBAC) across all platform levels
  • Network segmentation and policies to minimize internal attack surfaces
  • Secret management with separate access paths and rotation
  • Limited admin rights with a four-eyes principle for sensitive actions

• Integrity

  • Immutable infrastructure components, reproducible deployments
  • Signing of container images and pipeline artifacts
  • Admission and policy engines that enforce compliance before deployments
  • Integrity checks for backups and restores

• Availability and Resilience

  • Redundant control plane and worker resources
  • Automated backups, tested through regular recovery exercises
  • Auto-scaling and self-healing mechanisms to cushion load peaks and partial failures
  • Proactive monitoring and alerting across all layers

In sum, this creates a technical security level that withstands an appropriate risk assessment while remaining operationally manageable.

Continuous Review: Security as a Process

Article 32 explicitly requires “regular testing, assessing, and evaluating” of measures. Practical components:

• Automated vulnerability scanning of images and libraries
• Regular penetration tests and red teaming exercises
• Review obligation for security-relevant changes (change management)
• Evaluation of audit logs with systems like Loki and clear processes for incident analysis

Security thus becomes an iterative process – not a one-time project.

Article 28 GDPR: What Cloud Providers Must Deliver as Processors

Article 28 regulates the role of processors – typically your cloud or platform providers. Since the GDPR came into effect on May 25, 2018, it is clear: Technical measures and contractual arrangements must interlock.

Adherence to Instructions and Transparency

Processors act solely according to documented instructions from the controller. From a technical perspective, it is important:

• Logging and auditability of all administrative accesses by the provider
• Clear tenant separation so that provider operations can specifically address individual customers
• Documented standard processes for changes, patches, and access requests

Transparency also includes complete information about subprocessors (e.g., hosting providers), their roles, and locations.

Technical and Organizational Measures (TOMs)

Cloud providers must document and keep their TOMs up to date. For you as the controller, the following are particularly relevant:

• Concrete description of the security architecture (network, storage, identity, logging)
• Proof of certifications (e.g., ISO 27001) and audits
• Clearly defined RTO/RPO values for availability and recovery
• Processes for reporting and handling security incidents (Articles 33/34)

Good provider documentation allows your data protection officer to efficiently conduct DPIAs and risk analyses – without having to clarify every technical detail individually.

Support for Data Subject Rights

Article 28 explicitly obliges processors to assist controllers in fulfilling data subject rights. Technically, this means, among other things:

• Identifiable and traceable deletion processes (Article 17)
• Access to audit information for access requests (Article 15)
• Processes for rapid analysis and containment in case of suspected data breaches

Those who take Privacy by Design seriously incorporate these requirements into APIs, data models, and logging structures from the start.

Article 17 GDPR: Right to Erasure in Multi-Tenant Environments

The right to erasure (“right to be forgotten”) is one of the most visible aspects of the GDPR. In distributed, multi-tenant architectures, the technical implementation is challenging but manageable if considered early.

Clean Separation of Data Domains and Identifiers

The technical basis is a clear structure of data domains:

• Business data (e.g., orders, contracts, tickets)
• Identity data (e.g., name, address, email)
• Metadata and telemetry data (e.g., logs, metrics, traces)
• Backups and snapshots

For deletion, the relationship between these domains and the affected person is relevant. Practically, this means:

• Unique, stable person IDs that are consistent across all systems
• Declarative mapping of which tables, collections, or objects reference which person ID
• As few direct personal attributes as possible in logs and metrics

The clearer these relationships are, the better a deletion request can be technically implemented.

Logical vs. Physical Deletion

In multi-tenant systems, two levels must be distinguished:

• Logical Deletion in the Business Domain
  Data is removed or anonymized so that no personal reference remains, while maintaining technical consistency and business history (as required).
  Examples:

  • Replacing clear names with neutral placeholders in historical datasets
  • Removing communication content but retaining aggregated metrics
  • Separation between legally required data (with strict purpose limitation) and additional information

• Physical Deletion in Infrastructure and Storage

  • Removal of data from production databases and storage
  • Cleanup of caches, indexes, and search systems
  • Lifecycle policies for backups and snapshots ensuring data disappears from these sources after defined periods

In practice, organizations often implement deletions in two stages: Immediate logical deletion in production systems, physical deletion in backups after defined retention periods.

Making Deletion Processes Auditable

From the GDPR perspective, you must be able to prove that a deletion has occurred. Here, logging comes into play:

• Deletion operations are logged with timestamp, responsible party, and affected data domains
• Logs contain no substantive data content, only metadata about the operation
• The logs themselves are stored in a secure, tamper-resistant system like Loki, with clear retention periods

This allows you to provide concrete evidence to data subjects, auditors, and supervisory authorities without creating new data protection risks.

EU Data Localization as an Anchor of Stability

At the latest since the invalidation of “Safe Harbor” (2015) and “Privacy Shield” (2020), it is clear: Third-country transfers are legally volatile. EU data localization reduces this uncertainty.

Why Data Residency in the EU is Technically Sensible

• Legal Certainty
  Processing in EU/EEA data centers is subject to a consistent legal framework. Additional transfer mechanisms, standard contractual clauses, or complex Transfer Impact Assessments are often avoidable.

• Simpler Architectural Decisions
  If data does not leave the EU, complex geo-redundancy scenarios across legal jurisdictions with different governmental access rights are unnecessary.

• Clarity for Your Customers
  EU data localization is a decisive trust factor for many customers. It can be clearly and understandably communicated.