Business continuity policy

How our SaaS products and internal systems stay recoverable after a disruption, without losing more data than agreed and without lowering security. It applies to Infrastructure, the Project leads and everyone who runs a system in scope.

Annex A controls: 5.29, 5.30, 8.13, 8.14.

Continuity objectives (5.30)

• Maximum data loss: one day. Every system in scope has a restore point that is at most one day old.
• Maximum downtime: a critical system runs again within one working day after the decision to restore it.
• A customer contract or SLA can require more for a product. The Project lead records those objectives in the product’s README, and the product’s backups and redundancy meet them.
• Critical systems: the production databases and file storage of each SaaS product, GitLab (source code, CI and ISMS records), Vaultwarden (secrets), Keycloak (single sign-on) and the mail server.

Backups (8.13)

• Every system in scope that holds data has an automated backup that runs at least daily. Code and server configuration live in Git, so the GitLab backup covers them, and a server is rebuilt from its configuration rather than restored as a whole.
• Production databases on Coolify have scheduled backups to object storage, set up as described in deployments.
• Self-hosted company services, such as GitLab, mail and Nextcloud, back up nightly to an encrypted repository on the office NAS, reached over a VPN tunnel.
• Servers that hold state also have the hosting provider’s daily server backups, for a whole-server restore.
• A backup is always stored in another location than the system it protects: another object storage location, or the office NAS.
• Retention is set per system and documented with the system’s backup configuration in the infra repository.
• Every backup reports its last success to monitoring. An alert fires when a daily backup misses a run, and when a backup’s integrity check fails. The integrity check reads part of the backup data every week, so all of it is verified every five weeks.
• Before a change that can lose data, such as an upgrade, a migration or a disk change, Infrastructure takes a snapshot to roll back to.
• Laptops have no central backup. Work belongs in GitLab, Nextcloud and Vaultwarden, as described in backup strategy.

Restore tests (8.13, 5.30)

• Every critical system has a restore test at least once a year: restore a recent backup onto a separate server or database, check that the data is complete and the application works, and compare the time it took with the objectives.
• The test is a yearly recurring task. Its issue records what was restored, from which backup, by whom, the result and the time it took.
• A restore for a migration or a reinstall counts as the test for that system when it is recorded the same way.
• A failed or incomplete restore is a non-conformity, handled as described in improvement.
• The restore procedure of each service is documented in the infra repository, so that someone other than its author can restore it.

Redundancy (8.14)

• The availability a product needs, from its contracts and the availability objective, decides whether backups are enough or the product needs redundancy. A product that needs it runs several application instances behind a load balancer.
• Every server can be replaced: Ansible configures the host from Git and Coolify redeploys its applications, so a failed server is rebuilt on a new machine and its data restored.
• Monitoring runs on other servers than the systems it watches, so it keeps reporting when they fail.
• CI jobs run on several runners, so a failed runner reduces capacity but does not stop development.

Security during a disruption (5.29)

• A restored or rebuilt system gets the same security configuration as the original, because it is built from the same Ansible and Coolify configuration, with the same single sign-on and firewall rules.
• Backups are protected like the data they hold: encrypted or in private storage, readable only by Infrastructure.
• Break-glass access to the systems needed for recovery works when single sign-on is down. Its use is recorded in the incident issue.
• A disruption is handled as an incident under the incident management policy. Emergency changes follow the change management policy.

Responsibilities

• The Information Security Officer owns this policy, plans the yearly restore tests and checks their records.
• Infrastructure runs and monitors the backups, performs the restore tests and keeps the restore procedures current.
• Project leads set the continuity objectives that their customers’ contracts require and check the restored data of their product.
• Management approves the continuity objectives.

Review: yearly by the Information Security Officer.