Backup is a decision about what you accept, not about technology.

How much data loss is acceptable is decided by the business; technology implements that decision. This page covers the decision itself and the obligations around it.

The architecture — layered retention, immutable copies, restore testing — lives on the Data Protection page under Services. Here we discuss how objectives get set and what must be retained.

Set objectives with the business Back to Business Continuity

Setting objectives with the business

Acceptable data loss and downtime are not numbers a technical team should guess. For each critical service the business supplies a figure, and the cost of that figure is shown back to them.

Whoever sets the target also sees the cost
The figure is signed off and reviewed annually
Systems that cannot meet their target are declared openly
A new system gets its objective as it goes live

Retention obligations

How long to retain is a legal question as much as a technical one. Commercial, tax and data protection rules impose different periods, and deleting once a period expires is as much a duty as keeping.

Retention periods are listed per data type
Destruction triggers itself once the period ends
Destruction records are retained and producible on request
A legal hold suspends destruction temporarily

Separating backup from archive

Backup exists for return, archive for obligation. Managed in one system, data past its retention period keeps living in backups, growing both cost and compliance risk.

Two needs, two policies, two durations
Archive access may be slow but never incomplete
The rule for moving backup to archive is written
Archive formats are chosen to stay readable long term

Evidence and reporting

Meeting an obligation is demonstrated only through evidence. Coverage reports, failed job lists and restore test results are produced and retained on a regular cycle.

Systems outside coverage appear in the report
A failed backup job is followed up the next day
Test results are recorded with date and duration
Reports are kept ready for an audit request

How we work

List critical services and their owners
Turn objectives into numbers with the business
Write retention duties into policy
Separate backup from archive
Produce evidence reports on a cycle

How success is measured

Every critical service has a signed objective
Retention periods match the written policy
Destruction follows without delay once a period ends
Nothing critical sits outside the reported coverage

Frequently asked questions

Where does this sit next to the Data Protection page?

Architecture belongs there: layered retention, immutable copies and restore testing. This one covers how objectives are set and what retention duties apply.

Isn't keeping everything safer?

No. Retaining personal data past its period is a compliance breach, and it enlarges the surface you would lose in an attack. A retention period is a ceiling, not a goal.

If we run in cloud, does the provider back us up?

Most services provide infrastructure durability while responsibility for the data stays with you. Recovering data deleted or encrypted by mistake depends on your own backup decision.

Let's turn acceptable data loss for your critical services into a number, with the business in the room.

Set objectives with the business