Care-sector cloud backups: Security depends on tested restoration
Synchronisation, version history and backups serve different purposes. Plan independent copies and verify that the care application can actually restart.
Editorial review:
Background & source findings
BSI backup guidance covers both creating copies and restoring them, with defined scope, procedures and responsibilities. A successful backup notification is not proof that a complete clinical application can restart in time. [1]
The BSI ransomware catalogue recommends offline-separated backups and checking for possible infection before restoration. Compromising production credentials should not destroy every recovery path. [2]
Synchronisation may propagate deletion or encrypted files. Version history can still help, depending on the actual service and configuration. Article 32 GDPR addresses timely restoration and regular testing of security measures. [3]
Scope & limitations
The 3-2-1-1-0 mnemonic is not a legal requirement or ransomware guarantee. Immutability depends on configuration and retention. Choose test intervals from operational risks.
In plain language
Fictional example: A service has several backups but cannot access the recovery account. A test exposes this before an actual outage.
Practical recommendations
Our recommendation: Inventory applications, data, keys and dependencies. Define tolerable data loss and restoration deadlines. Separate copies and privileges so one compromise cannot reach everything. Maintain an appropriately protected offline or immutable copy.
Test full restoration in an isolated environment, including login, patient attribution, databases and the care application. Record duration and remedial actions. Ensure another authorised person can carry out recovery when the usual administrator is absent.