PBS Compliance: GDPR, SOC 2, and ISO 27001

Your auditor will ask about backups. Not "do you have backups?" They want encryption key management documentation, retention policies with defined windows, access control lists, and evidence of tested restores. If your answer is "trust me, it works," your controls documentation is incomplete. Proxmox Backup Server, combined with a properly configured offsite target, maps directly to the technical controls that GDPR, SOC 2 Type II, and ISO 27001 require from a backup system. This post covers what each framework expects, how PBS addresses it at the technical layer, and what evidence to collect before your next audit.

What Auditors Actually Ask For

The underlying requirements across GDPR, SOC 2 Type II, and ISO 27001 overlap heavily. Auditors are not testing different things. They're asking the same questions through different lenses. The backup system itself must satisfy these controls, not just your production infrastructure.

When you're managing client environments under multiple compliance frameworks, a well-configured PBS stack addresses most of the technical controls in this table. The sections below go through each one.

Encryption: Client-Side AES-256-GCM

Client-side encryption is the foundation of a compliant PBS setup. When you configure a Proxmox Backup Server storage with an encryption key, the backup client on your Proxmox VE node splits the VM data into chunks and encrypts each one with AES-256-GCM before the data leaves your network. The remote PBS server receives encrypted chunks and nothing else. It has no key, no decryption capability, and no way to read the backup content.

This addresses the encryption technical control referenced in:

• GDPR Art. 32: "appropriate technical and organisational measures" — encryption is the named example; organisational measures (key management docs, access policy) are required alongside it
• SOC 2 CC6.1: encryption of data at rest to prevent unauthorized access
• ISO 27001 A.10.1: cryptographic controls for information protection

Key management is the client's responsibility. Document where your encryption key and its passphrase are stored. Auditors want to see that you have a key backup procedure, not just that encryption is on.

# Generate a new encryption key on the PVE node
proxmox-backup-client key create /etc/proxmox-backup/encryption-key

# Create a paper key backup (QR code, printable offline copy)
proxmox-backup-client key paperkey /etc/proxmox-backup/encryption-key \
    --output-format text > /tmp/encryption-key-paperkey.txt

# Store passphrase in password manager AND print the paper key
# Never store the key on the PBS server itself

For your compliance evidence pack, document when the key was generated, where it is stored, and who has access to it. Treat this like a certificate inventory entry.

Access Controls and API Token Scoping

PBS has a role-based access model that maps directly to least-privilege requirements. The right pattern is one API token per use case, scoped to a single datastore and a single role. This is described in detail in the PBS security hardening guide. The short version for compliance purposes is below.

# Create a user for the backup agent
proxmox-backup-manager user create backup-agent@pbs \
    --comment "Automated backup agent - client ACME"

# Generate a named API token
proxmox-backup-manager user generate-token backup-agent@pbs agent-token-01

# Grant DatastoreBackup on a specific datastore only
proxmox-backup-manager acl update /datastore/client-acme \
    --auth-id backup-agent@pbs!agent-token-01 \
    --role DatastoreBackup

Tokens are expirable. Set an expiry when you create them and rotate on a schedule. Quarterly is a reasonable baseline. For SOC 2 CC6.1 and ISO 27001 A.9.4, your evidence is the ACL list showing scoped permissions. Run proxmox-backup-manager acl list and export it before each audit cycle.

For MSPs managing client environments, the multi-tenant PBS architecture goes deeper on isolating client datastores. The principle is the same: one token per client per purpose, no shared credentials across tenants.

Retention Policies and Data Deletion

GDPR Art. 17 includes a right to erasure. For backups, regulators generally accept that you cannot immediately scrub individual records from encrypted backup chunks — but you need a documented retention window, a process to avoid restoring erased data, and the ability to fully delete a client's dataset when the retention period ends or an offboarding request comes in.

PBS prune jobs define retention windows per backup type. Configure them at the datastore level so they apply automatically without manual intervention.

proxmox-backup-manager datastore update client-acme \
    --prune-schedule "daily" \
    --keep-daily 7 \
    --keep-weekly 4 \
    --keep-monthly 3

For complete client offboarding under GDPR, a datastore-per-client architecture is cleanest: delete the datastore, all data is gone. There's no partial-deletion complexity. This also fits naturally with the 3-2-1-1-0 strategy. Your retention tiers are explicit, documented, and auditable.

Audit Logging and Evidence Collection

SOC 2 and ISO 27001 require audit trails for backup operations. PBS logs every backup job, restore operation, verify run, and admin action. The logs are accessible in two places: the task log in the PBS web UI, and /var/log/proxmox-backup/ on the host.

The task log captures:

• Backup start/end time, status, datastore, and auth-id (which user or token triggered it)
• Restore operations with the same metadata
• Verify job results
• ACL changes, user creation, token creation

# Forward PBS proxy logs to external SIEM (UDP syslog)
if $programname == 'proxmox-backup-proxy' then @siem.example.com:514
& stop

# For TCP with guaranteed delivery:
# if $programname == 'proxmox-backup-proxy' then @@siem.example.com:514

Define which events trigger alerts. The table below is a starting point for your monitoring runbook.

Restore Testing: The Control Most Teams Skip

This is where most backup setups fail audits. PBS verify jobs check chunk integrity using SHA-256 hashes. They confirm that the stored chunks have not been corrupted or tampered with. They do not confirm that a VM will boot, that a database can be queried, or that your restore procedure works under time pressure.

SOC 2 CC7.5 and ISO 27001 A.12.3.1 both require that backups are periodically tested by performing actual restores. Verify jobs do not satisfy this control. You need to restore a VM or service and verify it works.

The PBS disaster recovery guide covers full-cluster scenarios. For routine compliance testing, a quarterly cadence per critical system is a reasonable baseline. Document every test.

Keep this log in your runbook. When an auditor asks for restore test evidence, one spreadsheet export is the answer. The PBS verify jobs guide covers the technical difference between integrity verification and restore testing in more detail.

GDPR Data Residency: Why EU-Hosted PBS Matters

GDPR Art. 44 restricts transferring personal data outside the EU/EEA without adequate safeguards. If your backups land on US-based storage (AWS S3, Azure Blob, Backblaze B2), you need Standard Contractual Clauses or another legal transfer mechanism for the backup tier specifically. This is frequently missed in compliance audits.

EU-hosted PBS removes the cross-border transfer obligation for the backup tier. No personal data leaves the EU/EEA, so Standard Contractual Clauses, adequacy decisions, and transfer impact assessments are not required for this layer specifically. You still need a Data Processing Agreement with your storage provider — that applies regardless of where the servers sit.

remote-backups.com operates across multiple EU datacenters with geo-replication within EU borders. For businesses subject to GDPR, this means the backup tier has no Art. 44 cross-border transfer obligations to resolve.

Building Your Compliance Evidence Pack

The most practical question after reading a post like this: what exactly do I collect, and how often? The table below is a starting checklist.

Store this evidence pack somewhere your auditor can access without your help. Use a shared folder with clear naming and dates. Evidence that requires your intervention to retrieve is not evidence, it is a performance.

Wrapping Up

PBS is not marketed as compliance software, but its architecture aligns closely with what GDPR, SOC 2, and ISO 27001 actually require from a backup system. Client-side encryption, scoped API tokens, per-client datastores with prune schedules, task logging, and a clear chain of custody from backup to restore cover most of the controls. The gap between "PBS is running" and "PBS is auditable" is documentation, log forwarding, and a quarterly restore test schedule.

If you need an offsite PBS endpoint with no cross-border data transfer obligations under GDPR, remote-backups.com provides dedicated PBS targets in EU datacenters, client-side encryption support, EU geo-replication, and immutable datastores for ransomware-resistant retention. See the Proxmox Backup Server hosting page for details.