Building for Resilience: Security, Backups and Recovery

Start with what the business needs to recover #

Identify the tasks, information and integrations the business depends on. Agree the impact of an interruption and the amount of lost work the business could tolerate. Use those decisions to guide backup frequency, recovery priorities and support arrangements.

Avoid promising an instant recovery unless the system and service have been designed and tested to deliver it. Write down who can make decisions during an incident and how people will work while the service is unavailable.

Keep provider assurance separate from application security #

An infrastructure provider may have independent assurance over its own controls. That does not make your application or organisation SOC 2 compliant. Ask what the report covers and what remains your responsibility.

Supabase describes this distinction in its shared responsibility model. Application permissions, configuration, data handling and operating procedures still need attention.

Test access, not just sign-in #

Successful authentication tells a system who a user is. Authorisation determines what that user may see or change. Test customer separation, staff roles, file access and administrative operations directly.

Use appropriately limited service access, protect credentials and remove access when roles change. Keep dependencies maintained and give someone responsibility for reviewing errors and suspicious activity.

Prove that recovery works #

A successful backup job is not evidence of a successful restore. Run a controlled recovery exercise, check the restored data and record how long it takes. Include files, configuration and third-party dependencies as well as the database.

Confirm retention, access to backups, restore assistance and what is excluded in the service agreement. Avoid assuming that a hosting subscription includes every recovery task.

Make care an ongoing responsibility #

Use a practical record of updates, incidents, recovery tests and outstanding improvements. Review it when the system changes or business requirements grow. Security and resilience are ongoing work, not a permanent property of a framework.