Most hosting providers will tell you they are "GDPR compliant." They will point to a privacy policy on their website, maybe a Data Processing Agreement template buried in their legal section, and call it done. What they will not tell you is that GDPR compliance is not a document — it is an infrastructure architecture. The regulation imposes specific technical requirements on how personal data is stored, transmitted, accessed, logged, and deleted. If your hosting stack does not enforce these requirements at the infrastructure layer, your compliance is a legal fiction that will not survive a supervisory authority audit.

This matters most for SaaS companies operating in regulated verticals — fintech, healthtech, insurtech, any platform that processes personal data of EU residents at scale. A Data Protection Authority does not care about your marketing copy. They care about whether you can demonstrate, with technical evidence, that your infrastructure enforces the controls your Data Protection Impact Assessment claims exist.

This guide covers what GDPR-compliant hosting actually looks like at the infrastructure level. Not the legal theory — the specific technical controls, configurations, and architectural decisions that separate real compliance from paperwork compliance. We will cover encryption, access controls, network isolation, audit logging, data retention enforcement, backup handling, and why the jurisdiction your servers sit in determines the ceiling of your compliance posture.

Article 32: The Technical Measures Requirement Most Teams Underestimate

Article 32 of the GDPR mandates "appropriate technical and organisational measures" to ensure a level of security "appropriate to the risk." The regulation specifically names four categories: pseudonymisation and encryption, confidentiality and integrity, availability and resilience, and regular testing and evaluation. These are not suggestions — they are legal obligations with enforcement teeth. Fines under Article 83 can reach 4% of annual global turnover or EUR 20 million, whichever is higher.

The problem is that Article 32 is deliberately technology-neutral. It does not tell you which cipher to use or how to configure your firewall. This flexibility is intentional — it allows the regulation to age without becoming obsolete — but it creates a gap between legal requirements and engineering implementation. Most SaaS teams know they need "encryption" and "access controls," but the specific implementation details that satisfy a supervisory authority's technical audit are not obvious.

Here is what actually matters at the infrastructure layer.

Encryption at Rest: It Is Not Optional, and Self-Managed Keys Matter

Every disk that stores personal data must be encrypted at rest. Full-disk encryption using LUKS on Linux or BitLocker on Windows is the baseline — not the ceiling. For regulated workloads, the question is not whether data is encrypted but who controls the encryption keys.

If your hosting provider manages the encryption keys, they have the technical ability to decrypt your data. This creates a legal problem under GDPR's "appropriate measures" standard: you are relying on a contractual promise (the DPA) rather than a technical control. A supervisory authority evaluating your setup will distinguish between "the provider promised not to look at our data" and "the provider is technically unable to access our data without our key."

For LUKS-encrypted volumes on a dedicated server, the architecture looks like this:

# Create an encrypted volume
cryptsetup luksFormat /dev/sdb1 --cipher aes-xts-plain64 --key-size 512 --hash sha512

# Open with your key (not stored on the host permanently)
cryptsetup luksOpen /dev/sdb1 data_encrypted

# Create filesystem on the encrypted device
mkfs.ext4 /dev/mapper/data_encrypted

# Mount
mount /dev/mapper/data_encrypted /var/data

The critical detail: the LUKS passphrase or key file should not live on the server's unencrypted boot partition in a way that allows automatic decryption without operator involvement. For production workloads, this means either a remote key server (such as Tang/Clevis for network-bound disk encryption) or a manual unlock process during boot. Automatic unlock from a local key file defeats the purpose of encryption at rest — if an attacker gains root access to the running system, they already have the mounted filesystem, and if they image the disk offline, the key file is right there.

For database-level encryption, you want a separate layer on top of disk encryption:

# PostgreSQL: enable data-at-rest encryption via pgcrypto
# For column-level encryption of sensitive fields:
CREATE EXTENSION IF NOT EXISTS pgcrypto;

-- Encrypt on insert
INSERT INTO customers (name, email_encrypted)
VALUES ('John Doe', pgp_sym_encrypt('john@example.com', 'app-level-key'));

-- Decrypt on read (application provides key)
SELECT name, pgp_sym_decrypt(email_encrypted, 'app-level-key') AS email
FROM customers;

This gives you defense in depth: the disk is encrypted (protects against physical theft or improper decommissioning), the database connection is encrypted in transit (protects against network sniffing), and the sensitive columns are encrypted at the application layer (protects against SQL injection or unauthorized database access). A supervisory authority will view this layered approach favourably because each layer mitigates a different threat vector.

Encryption in Transit: TLS Everywhere, Including Internal Traffic

TLS on public-facing endpoints is table stakes. Every SaaS product already does this. What most teams miss is internal traffic — the connections between your application servers, databases, cache layers, message queues, and monitoring systems. Under GDPR, if personal data traverses a network path, that path must be secured. "It is on a private network" is not a sufficient control if the hosting provider or other tenants share the same physical network infrastructure.

On a dedicated server or private VLAN, the risk is lower than on shared infrastructure, but the regulatory expectation is the same. TLS between your application and PostgreSQL:

# postgresql.conf
ssl = on
ssl_cert_file = '/etc/ssl/certs/postgres-server.crt'
ssl_key_file = '/etc/ssl/private/postgres-server.key'
ssl_ca_file = '/etc/ssl/certs/ca.crt'
ssl_min_protocol_version = 'TLSv1.3'

# pg_hba.conf — require TLS for all remote connections
hostssl all all 0.0.0.0/0 scram-sha-256 clientcert=verify-ca

The clientcert=verify-ca parameter enforces mutual TLS: the client must present a certificate signed by the same CA, and the server verifies it before allowing the connection. This prevents unauthorized services from connecting to your database even if they have valid credentials — they also need a valid client certificate.

For Redis, which many teams leave unencrypted on the assumption it is "internal only":

# redis.conf
tls-port 6380
port 0  # Disable unencrypted port entirely
tls-cert-file /etc/ssl/certs/redis.crt
tls-key-file /etc/ssl/private/redis.key
tls-ca-cert-file /etc/ssl/certs/ca.crt
tls-auth-clients yes  # Require client certificates

Every service that handles personal data — even transiently, even as a cache — must encrypt its connections. A compliance auditor will check this, and "we did not think Redis counted" is not a defensible answer.

Network Isolation: Microsegmentation Beyond the Perimeter

A flat network where every service can talk to every other service is an implicit violation of the "confidentiality" requirement in Article 32. If your web-facing application server is compromised, the attacker should not be able to reach your database server, your backup storage, or your monitoring infrastructure without crossing additional network boundaries.

On dedicated infrastructure, network isolation starts with VLANs and firewall rules that enforce the principle of least privilege at the network layer:

# Example: iptables rules on the database server
# Only allow connections from the application server on the PostgreSQL port
iptables -A INPUT -p tcp --dport 5432 -s 10.0.1.10 -j ACCEPT
iptables -A INPUT -p tcp --dport 5432 -j DROP

# Only allow SSH from the management VLAN
iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

# Drop everything else by default
iptables -P INPUT DROP
iptables -P FORWARD DROP

For containerised workloads on Kubernetes, network policies provide the same isolation at the pod level:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-access-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgresql
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api-server
      ports:
        - protocol: TCP
          port: 5432

The principle is the same regardless of the technology: every service should only accept connections from the specific services that need to talk to it, on the specific ports they use, and nothing else. This limits the blast radius of any single compromise and creates the kind of architectural boundary that compliance auditors want to see.

For SaaS teams running on managed Swiss infrastructure, this network segmentation can be handled at the provider level — dedicated VLANs, private interconnects between servers, and firewall rules managed as infrastructure-as-code. The advantage is that the isolation is enforced at a layer below your application, where misconfiguration in your code cannot weaken it.

Access Controls: The Principle of Least Privilege, Enforced Technically

GDPR Article 29 requires that anyone processing personal data does so only on documented instructions from the controller. At the infrastructure level, this translates to: every human and service account must have the minimum access necessary to perform its function, and that access must be auditable.

Start with SSH access to servers. Password authentication should be disabled entirely — key-based authentication only, with individual keys per operator:

# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers deploy_user audit_user
MaxAuthTries 3
LoginGraceTime 30

Each operator gets their own user account with their own SSH key. No shared accounts, no shared keys. When someone leaves the team, you revoke their key — not change a shared password that six people know.

For database access, the same principle applies. Your application should connect with a service account that has permissions only on the tables it needs:

-- Create a read-only reporting user
CREATE USER reporting_svc WITH PASSWORD 'strong-random-password';
GRANT CONNECT ON DATABASE production TO reporting_svc;
GRANT USAGE ON SCHEMA public TO reporting_svc;
GRANT SELECT ON customers, orders, invoices TO reporting_svc;
-- No INSERT, UPDATE, DELETE, DROP, or schema modification

-- Create the application user with limited write access
CREATE USER app_svc WITH PASSWORD 'different-strong-password';
GRANT CONNECT ON DATABASE production TO app_svc;
GRANT USAGE ON SCHEMA public TO app_svc;
GRANT SELECT, INSERT, UPDATE ON customers, orders, invoices TO app_svc;
-- No DELETE (soft-delete pattern), no DROP, no schema modification

Notice the absence of DELETE permission for the application user. Under GDPR, data deletion (for erasure requests under Article 17) should be a controlled operation — typically handled by a dedicated service with specific deletion logic, audit logging, and verification. Your main application should not have the ability to silently drop rows.

For teams managing multiple servers, centralised identity management via LDAP or an identity provider with SAML/OIDC integration eliminates the sprawl of local accounts. Combined with multi-factor authentication for all human access, this creates an access control architecture that a Data Protection Authority will recognise as aligned with the "state of the art" standard in Article 32.

Audit Logging: If You Cannot Prove It Happened, It Did Not Happen

This is where most hosting setups fail compliance audits. You can have perfect encryption, flawless access controls, and bulletproof network isolation — but if you cannot produce logs showing who accessed what data, when, and why, a supervisory authority will treat your controls as unverifiable. Under GDPR's accountability principle (Article 5(2)), the burden of proof is on you.

Comprehensive audit logging for a GDPR-compliant infrastructure covers three layers:

1. Infrastructure-level logging: Every SSH session, every sudo command, every firewall rule change.

# /etc/sudoers.d/audit — log every sudo invocation
Defaults log_output
Defaults!/usr/bin/sudoreplay !log_output
Defaults logfile="/var/log/sudo.log"
Defaults log_input

# auditd rules for file access monitoring
# /etc/audit/rules.d/gdpr.rules
-w /var/data/ -p rwxa -k personal_data_access
-w /etc/ssh/ -p wa -k ssh_config_change
-w /etc/passwd -p wa -k identity_change
-w /etc/shadow -p wa -k identity_change
-a always,exit -F arch=b64 -S execve -k command_execution

2. Database-level logging: Every query that touches personal data tables, every schema change, every privilege modification.

# postgresql.conf — audit logging
log_statement = 'all'              # Log every SQL statement
log_connections = on                # Log every connection
log_disconnections = on             # Log every disconnection
log_line_prefix = '%t [%p]: user=%u,db=%d,app=%a,client=%h '
log_min_duration_statement = 0      # Log all statements with duration

# For granular audit, use pgAudit extension
shared_preload_libraries = 'pgaudit'
pgaudit.log = 'read, write, ddl, role'
pgaudit.log_catalog = off

3. Application-level logging: Every data access, modification, export, or deletion event at the business logic layer.

The audit logs themselves are personal data under GDPR (they contain information about who did what), so they need the same protection as the data they are monitoring: encrypted storage, access-controlled, with a defined retention period that balances accountability needs against data minimisation requirements.

Critical requirement: audit logs must be tamper-evident. If they are stored on the same server they are monitoring, a compromised root account can edit or delete them. Ship logs to a separate, append-only log aggregation system that the application servers cannot modify:

# rsyslog — forward audit logs to a remote log server
# /etc/rsyslog.d/50-audit-remote.conf
$ActionQueueType LinkedList
$ActionQueueFileName audit_fwd
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on

if $programname == 'audit' then @@log-collector.internal:6514;RSYSLOG_SyslogProtocol23Format

The remote log server should be on a separate network segment with its own access controls. The application servers can write to it but cannot read from it or modify existing entries. This architectural separation is what turns your logs from "we think we have a record" into "we can prove, with evidence an attacker could not have tampered with, exactly what happened."

Data Retention and Automated Deletion: Article 5(1)(e) at the Infrastructure Level

GDPR requires that personal data be "kept in a form which permits identification of data subjects for no longer than is necessary." This is not a policy statement you put in a document — it is a technical control you enforce in your infrastructure.

Most SaaS applications accumulate data indefinitely. Customer records, transaction logs, support tickets, analytics events — they pile up because nobody built a deletion pipeline. When an auditor asks "how do you enforce your stated retention period of 24 months for transaction data?" the answer cannot be "we have a policy document." It must be "we have an automated process that runs nightly and removes records older than the retention window, with audit logging of what was deleted."

# Example: PostgreSQL function for automated retention enforcement
CREATE OR REPLACE FUNCTION enforce_retention()
RETURNS void AS $$
DECLARE
  deleted_count integer;
BEGIN
  -- Delete transaction records older than 24 months
  DELETE FROM transactions
  WHERE created_at < NOW() - INTERVAL '24 months'
  AND status IN ('completed', 'cancelled');
  GET DIAGNOSTICS deleted_count = ROW_COUNT;

  -- Log the deletion to the audit table
  INSERT INTO data_retention_log (table_name, records_deleted, retention_period, executed_at)
  VALUES ('transactions', deleted_count, '24 months', NOW());

  -- Delete anonymised analytics older than 36 months
  DELETE FROM analytics_events
  WHERE event_date < NOW() - INTERVAL '36 months';
  GET DIAGNOSTICS deleted_count = ROW_COUNT;

  INSERT INTO data_retention_log (table_name, records_deleted, retention_period, executed_at)
  VALUES ('analytics_events', deleted_count, '36 months', NOW());
END;
$$ LANGUAGE plpgsql;

Schedule this with a cron job or a database scheduler, and monitor it. If the retention job fails silently for three months, you have three months of data you should have deleted — and that is a compliance violation, not a bug.

Backups complicate retention enforcement. If you delete a record from your live database to comply with a retention policy or an erasure request, but the record still exists in a backup from two weeks ago, you have not actually deleted it. Your backup strategy must account for this:

• Rolling backups with a defined expiry that aligns with your shortest retention period
• Encrypted backups where the encryption key can be rotated or destroyed (crypto-shredding) to make old backups unrecoverable
• Documentation that explains to an auditor how backup retention intersects with data retention and erasure obligations

The Data Processing Agreement: What Your Infrastructure Must Actually Support

Every hosting relationship where the provider processes personal data on your behalf requires a Data Processing Agreement under Article 28. Most teams treat the DPA as a legal formality — the provider sends a template, legal reviews it, both sides sign, and it goes in a drawer. This misses the point.

A DPA makes specific claims about technical controls. It says the processor implements encryption. It says access is restricted. It says data is deleted upon termination. It says audit rights exist. Every claim in the DPA must be backed by a technical control in your infrastructure. If the DPA says "data is encrypted at rest with AES-256" and your disks are not encrypted, the DPA is a lie with legal consequences.

When evaluating a hosting provider's DPA against your actual infrastructure needs, check these specific technical claims:

• Sub-processor disclosure: Does the provider use third parties that might access your data? Upstream network providers, monitoring SaaS, support ticket systems? Each one is a sub-processor under GDPR.
• Data location commitment: Does the DPA guarantee data stays in a specific jurisdiction? Can you verify this technically (server IP geolocation, network traceroute, physical data center address)?
• Deletion upon termination: When you leave the provider, is data actually wiped? Disk overwrite? Crypto-shredding? Or does the provider just decommission the VM and reallocate the storage?
• Audit rights: Can you actually audit the provider's infrastructure, or is "audit" limited to receiving a SOC 2 report? For regulated verticals like fintech, a SOC 2 from the provider's auditor may not satisfy your own auditor's requirements.
• Incident notification timeline: GDPR requires notification within 72 hours. What is the provider's internal detection-to-notification pipeline? If they discover a breach on Friday evening and notify you Monday morning, that might already be too late for your 72-hour obligation to the supervisory authority.

Jurisdiction: Why Switzerland Solves the Cross-Border Problem

For SaaS companies serving EU customers, the hosting jurisdiction creates a specific legal architecture problem. Under GDPR Chapter V, transferring personal data outside the EEA requires a legal mechanism: an adequacy decision, Standard Contractual Clauses, Binding Corporate Rules, or a derogation. Each mechanism has limitations and compliance overhead.

Switzerland holds an EU adequacy decision — the European Commission has determined that Swiss data protection law provides an adequate level of protection. This means transferring personal data from the EU to Switzerland does not require SCCs, BCRs, or other transfer mechanisms. The transfer is treated the same as a transfer between EU member states. For a SaaS company with EU customers, hosting in Switzerland eliminates the entire cross-border transfer compliance burden.

But adequacy is only the starting point. Switzerland's Federal Act on Data Protection (FADP), revised in September 2023, aligns closely with GDPR while adding Swiss-specific protections. Swiss banking secrecy traditions influence the broader data protection culture — there is a baseline expectation of confidentiality that extends beyond what the law strictly requires. Swiss data centers operate under a legal framework where government access to data requires judicial oversight, and mass surveillance programs of the kind operated by Five Eyes nations are constitutionally restricted.

For fintech companies specifically, Swiss managed infrastructure offers a jurisdiction that both EU regulators and Swiss financial regulators recognise. FINMA-regulated entities already trust Swiss data centers. EU supervisory authorities accept Swiss adequacy. The result is an infrastructure jurisdiction that satisfies both sides of the regulatory equation without requiring complex legal gymnastics.

This matters at the infrastructure level because swiss data residency is not just about where bytes are stored — it is about which legal system governs access to those bytes. A server in Frankfurt is subject to German law and EU law. A server in Virginia is subject to US law, including FISA Section 702 and potential National Security Letters. A server in Switzerland is subject to Swiss law, with its strong privacy protections, judicial oversight requirements, and EU-recognised adequacy status.

Availability and Resilience: Article 32(1)(b) and (c)

GDPR does not just protect data from unauthorised access — it also requires that data be available when needed. Article 32(1)(b) requires "the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems," and Article 32(1)(c) requires "the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident."

At the infrastructure level, this translates to:

• Redundant storage: RAID configurations that survive disk failures without data loss. For critical personal data, RAID 10 or RAID 6 provides the redundancy level that "appropriate to the risk" demands for regulated workloads.
• Automated backups: Regular, tested, encrypted backups stored in a physically separate location. "We back up nightly" is not enough — "we test restoration monthly and can demonstrate a successful restore from the last test" is what an auditor wants to hear.
• Failover capability: For high-availability requirements, database replication to a standby server that can assume the primary role within your Recovery Time Objective. The RTO itself should be documented and aligned with the risk assessment in your DPIA.
• DDoS protection: A volumetric attack that takes your SaaS platform offline is an availability incident under GDPR. Your hosting infrastructure should include or support upstream DDoS mitigation.

# Automated backup with encryption and remote storage
#!/bin/bash
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="/tmp/db_backup_${TIMESTAMP}.sql.gz.enc"

# Dump, compress, and encrypt in a single pipeline
pg_dump -h localhost -U backup_svc production \
  | gzip \
  | openssl enc -aes-256-cbc -salt -pbkdf2 -pass file:/etc/backup/key \
  > "${BACKUP_FILE}"

# Transfer to geographically separate backup storage
rsync -avz --progress "${BACKUP_FILE}" backup@offsite-storage.internal:/backups/

# Verify the transfer
ssh backup@offsite-storage.internal "ls -la /backups/${BACKUP_FILE##*/}"

# Clean up local copy
rm -f "${BACKUP_FILE}"

# Log the backup event
echo "${TIMESTAMP} backup completed successfully" >> /var/log/backup-audit.log

The encryption key in /etc/backup/key should be managed separately from the backup files — ideally in a hardware security module or a key management service. If the backup storage is compromised, the encrypted files are useless without the key. If the key is compromised but the backups are on isolated storage, the window of exposure is limited.

Data Subject Rights: Technical Infrastructure for Articles 15-22

GDPR grants data subjects a set of rights that your infrastructure must be technically capable of fulfilling: access (Article 15), rectification (Article 16), erasure (Article 17), restriction of processing (Article 18), data portability (Article 20), and objection (Article 21). These are not features you build "later" — they are legal obligations from day one.

At the infrastructure level, this means:

• Data export capability: You must be able to extract all personal data associated with a specific data subject in a structured, commonly used, machine-readable format. This requires your database schema to support efficient queries by data subject identifier across all tables that contain personal data.
• Selective deletion: You must be able to delete a specific individual's data without affecting other records. This means foreign key relationships must be designed to support cascading deletes or soft-delete patterns that can be fully purged.
• Processing restriction: You must be able to mark a data subject's records as "restricted" so they are retained but not processed. This typically requires a status field and application-layer enforcement.
• Audit trail for rights requests: Every data subject request and your response to it must be logged, with timestamps, for accountability purposes.

-- Schema support for data subject rights
ALTER TABLE customers ADD COLUMN processing_restricted BOOLEAN DEFAULT FALSE;
ALTER TABLE customers ADD COLUMN restriction_reason TEXT;
ALTER TABLE customers ADD COLUMN restriction_date TIMESTAMP;

-- View for data export (Article 15 / Article 20)
CREATE VIEW customer_data_export AS
SELECT
  c.id, c.name, c.email, c.created_at,
  o.order_id, o.order_date, o.total,
  s.ticket_id, s.subject, s.created_at AS ticket_date
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
LEFT JOIN support_tickets s ON c.id = s.customer_id;

-- Data subject rights request log
CREATE TABLE dsr_log (
  id SERIAL PRIMARY KEY,
  customer_id INTEGER REFERENCES customers(id),
  request_type VARCHAR(50) NOT NULL,  -- access, erasure, rectification, restriction, portability, objection
  requested_at TIMESTAMP DEFAULT NOW(),
  completed_at TIMESTAMP,
  handled_by VARCHAR(100),
  notes TEXT
);

The point is not that these specific SQL statements are the answer for every application. The point is that data subject rights require specific database capabilities that must be designed into your schema from the beginning. Retrofitting erasure support into a database with tangled foreign keys and no soft-delete pattern is an expensive, error-prone project that most teams underestimate.

Incident Response: The 72-Hour Clock Starts at Detection

Under Article 33, you must notify your supervisory authority of a personal data breach within 72 hours of becoming aware of it. "Becoming aware" means when your monitoring detects the breach — not when someone reads the alert, not when the incident response team convenes, not when the forensic analysis is complete.

This creates a hard technical requirement: your infrastructure must be capable of detecting breaches in near-real-time. If your log aggregation system processes events with a 6-hour delay, and it takes another 4 hours for someone to notice the alert, you have already consumed nearly half of your 72-hour window before the investigation even begins.

Minimum detection infrastructure for GDPR compliance:

• Real-time log monitoring with alerting for anomalous access patterns (unusual query volumes, access from unexpected IPs, privilege escalation attempts)
• File integrity monitoring (AIDE, OSSEC, or Tripwire) on directories containing personal data, configuration files, and audit logs
• Network intrusion detection (Suricata or Snort) monitoring for data exfiltration patterns
• Automated alerting that reaches the incident response team within minutes, not hours — PagerDuty, Opsgenie, or equivalent with escalation policies

The 72-hour clock also affects your hosting provider relationship. Your DPA should specify the provider's breach notification timeline to you. If the provider detects a breach affecting your infrastructure and takes 48 hours to notify you, you have 24 hours left — barely enough time to assess the scope, determine whether personal data was affected, and draft a notification to the supervisory authority.

Putting It Together: Architecture Checklist for GDPR-Compliant Hosting

Here is the full stack, organised by GDPR article, that a compliant hosting architecture must implement:

Encryption (Article 32(1)(a)):
✅ Full-disk encryption with controlled key management (LUKS/dm-crypt)
✅ TLS 1.3 on all public-facing endpoints
✅ TLS on all internal service-to-service connections (database, cache, queue)
✅ Application-layer encryption for sensitive personal data columns
✅ Encrypted backups with separately managed keys

Access Control (Articles 29, 32):
✅ Key-based SSH only, no password authentication, no shared accounts
✅ Principle of least privilege for all service accounts
✅ Multi-factor authentication for all human administrative access
✅ Centralised identity management with audit trail
✅ Separate database users per service with minimal permissions

Network Isolation (Article 32(1)(b)):
✅ VLAN segmentation between application tiers
✅ Firewall rules enforcing least-privilege network access
✅ No unnecessary open ports — default deny
✅ Private networking for inter-service communication

Audit Logging (Article 5(2) — Accountability):
✅ Infrastructure-level logging (SSH, sudo, file access)
✅ Database-level logging (queries, connections, schema changes)
✅ Application-level logging (data access, modifications, exports)
✅ Tamper-evident remote log storage
✅ Defined log retention periods

Data Retention (Article 5(1)(e)):
✅ Automated retention enforcement with audit logging
✅ Backup retention aligned with data retention policies
✅ Crypto-shredding capability for expired backups
✅ Documented retention periods per data category

Availability and Resilience (Article 32(1)(b), (c)):
✅ Redundant storage (RAID)
✅ Automated, encrypted, tested backups
✅ Documented and tested disaster recovery procedure
✅ DDoS mitigation

Data Subject Rights (Articles 15-22):
✅ Data export capability per data subject
✅ Selective deletion capability
✅ Processing restriction mechanism
✅ Rights request audit logging

Incident Response (Article 33):
✅ Real-time monitoring and alerting
✅ File integrity monitoring
✅ Documented incident response procedure
✅ Provider breach notification timeline in DPA

The Honest Assessment

Building all of this from scratch on raw infrastructure is a significant engineering investment. For a SaaS team with ten engineers, spending three months hardening infrastructure to this level means three months not building product features. That is a real trade-off, and pretending otherwise is not helpful.

The alternative is working with a hosting provider that implements these controls at the infrastructure layer, documented in a DPA that makes specific technical commitments you can verify. Swiss VPS or dedicated server solutions with managed compliance controls shift the burden from your engineering team to a provider whose core competency is infrastructure security.

This is not about outsourcing responsibility — under GDPR, you remain the data controller and you are accountable for the processing. But a provider that delivers managed Swiss infrastructure with encryption, network isolation, audit logging, and backup management built in gives you a verified foundation to build on, rather than a blank slate where every control must be implemented and maintained by your team.

The jurisdiction matters too. Swiss hosting under the FADP, with EU adequacy status, in data centers subject to Swiss judicial oversight — that is a compliance posture you cannot replicate by spinning up instances in us-east-1 and bolting on a DPA template. The legal architecture is as much a part of GDPR compliance as the technical architecture, and getting both right from the infrastructure layer up is what separates "we checked the box" from "we will pass the audit."