How do we decide what to back up, how often and for how long?

Start

A data set needs a backup decision

A backup nobody decided on is usually the wrong one: too infrequent for the service, kept too short to get behind an attacker, or missing altogether. Decide three things for each data set: whether it is backed up, how often, and for how long. Do it per data set, such as one database or one file share, because each can need a different answer.

• Then: List every data set a critical service needs, plus the foundations

Step

List every data set a critical service needs, plus the foundations

List each data set with its owner, class, location, how it is backed up, how often, for how long and by whom. Include the data needed to rebuild the foundations: the sign-in directory, network configuration, the backup catalogue and build images. A data set that is not listed is treated as not backed up, so a gap in the list is a gap in the backups.

• Then: Does a critical service need this data set?

Decision

Does a critical service need this data set?

Yes when its loss would stop a critical service that your resilience work has already named. If you are not sure which services are critical, or whether this data set feeds one, answer yes and settle it with the service's business owner. That is the more cautious answer, because it brings the stricter rules.

• Yes, or not known: Class it Critical, owned by the service's business owner
• No: Is it data the foundations need to be rebuilt?

Step

Class it Critical, owned by the service's business owner

For the data a critical service needs, the data owner is that service's business owner. They own the interval too, because the recovery point is the longest gap of data they will accept. The class also sets the default restore check: every 3 months for Critical, 6 for Important and 12 for Other.

• Then: Is the service's recovery point already agreed?

Decision

Is the service's recovery point already agreed?

The recovery point objective is the most data, measured in time, that the service can lose. The business owner agrees it as part of the service's objectives. You do not set it in the backup standard. If it is missing or not known, the interval cannot be chosen yet, so take the cautious branch.

• No, or not known: Get the recovery point agreed with the business owner first
• Yes: Does it run at an interval within the recovery point?

Step

Get the recovery point agreed with the business owner first

Ask the business owner how much data the service can lose. The interval cannot be checked against a recovery point that does not exist. Use the process in your resilience work for objectives, then return to this question with the figure.

• Then: Is the service's recovery point already agreed? (back to an earlier step)

Decision

Does it run at an interval within the recovery point?

Choose an interval no longer than the recovery point of the service that needs the data set, then compare the real schedule with it, in hours. A service that can lose 4 hours of data cannot rely on a nightly backup. A failed job also takes the data set outside its recovery point until a good copy exists again. Where a supplier runs the backup, the interval it reports counts. If the supplier cannot tell you the interval, answer no.

• Yes: Write down the three retention needs, each with its source
• No, or not known: Shorten the interval, or raise a finding with an owner and date

Step

Shorten the interval, or raise a finding with an owner and date

If the schedule cannot be shortened yet, a failed check is a finding with an owner, a severity and a due date. Where it also means the service cannot meet its objective, link it to the objective gap in your resilience work, so the business owner sees the consequence.

• Then: Write down the three retention needs, each with its source

Decision

Is it data the foundations need to be rebuilt?

Foundations are the directory, network configuration, backup catalogue and build images that every rebuild needs. They serve no single service, so the matrix leaves the service and its recovery point blank. Yes, or not known, brings them in as Critical.

• Yes, or not known: Class it Critical, list it as foundations data, agree its interval
• No: Would losing it cause Major harm on the risk register's scale?

Step

Class it Critical, list it as foundations data, agree its interval

Foundations data is Critical because every rebuild depends on it. List it with its own named data owner. The pack sets no interval for it, so agree one with the data owner on your own judgement of how much change could not be redone after a rebuild. Record it in the list so it can be checked and tested like any other.

• Then: Write down the three retention needs, each with its source

Decision

Would losing it cause Major harm on the risk register's scale?

Use the impact scale in your risk register: Important means Major harm without stopping a critical service. If you cannot say, answer yes. Class Important gets a restore check at least every 6 months by default, against 12 for Other.

• Yes, or not known: Class it Important
• No: Class it Other

Step

Class it Important

An Important data set is not a critical service's data, but its loss would hurt. It still needs an owner and a recorded interval and retention. The class sets how often it is restored in a test.

• Then: Agree with the data owner how much data they can lose

Step

Class it Other

Other is any further data set you back up. Keep it in the list and give it an owner. Its restore check is the least frequent, but it is still a test that restores data, not a record that a job ran.

• Then: Agree with the data owner how much data they can lose

Step

Agree with the data owner how much data they can lose

No service recovery point applies here, so the data owner decides how much they could lose and what that means for the interval. The pack sets no figure for these classes. Write the choice down with its reason, so the next reviewer knows it was a decision.

• Then: Write down the three retention needs, each with its source

Step

Write down the three retention needs, each with its source

The three needs are how far back the business may need to go, any duty in law or contract, and the recovery need: long enough to reach a copy taken before an attacker's earliest sign, which can be days or weeks before the damage. The pack gives no figure for the recovery need, so set your own. The data owner records each need and where it comes from.

• Then: Do you know what law or contract asks you to keep it, if anything?

Decision

Do you know what law or contract asks you to keep it, if anything?

Yes also covers a clear finding that nothing applies, recorded with its source. Law sets minimums and they differ by data type, sector and country. The pack states none, so ask counsel or the contract owner rather than guess. If you do not know, take the no branch and find out.

• Yes, or none applies: Set retention to the longest need; record a reason for any more
• No, or not known: Ask counsel or the contract owner, and record the answer

Step

Ask counsel or the contract owner, and record the answer

Put the question to the person who owns the duty, for example counsel for a legal duty or the contract owner for a customer or supplier term. Record the answer and its source against the data set. Then return to the question.

• Then: Do you know what law or contract asks you to keep it, if anything? (back to an earlier step)

Step

Set retention to the longest need; record a reason for any more

Retention is the longest of the three needs, never the cheapest: setting it by storage cost alone is a recorded pitfall. Nothing is kept longer than the longest need without a recorded reason and who agreed it. Copies kept longer are a cost, and for personal data a data protection risk. If you do not know what is kept, read the settings of the backup system or ask the supplier.

• Then: Enter it in the coverage list before the system goes live

Step

Enter it in the coverage list before the system goes live

A new or changed system, and every new data set, goes into the list before it goes live. Keep a copy of the list, the suppliers' contacts and the instructions to recover the keys where people can reach them when the main systems are down.

• Then: Does a cloud or software-as-a-service provider hold the data?

Decision

Does a cloud or software-as-a-service provider hold the data?

Yes when the provider runs the platform that holds the data, such as a mail or document tenant. Its own backup may not cover items your people delete, changes an attacker makes or administrator errors. If you do not know who holds the data, answer yes.

• No: Take the decision to your approver and plan the first restore check
• Yes, or not known: Settle what the provider covers before you rely on it

Step

Settle what the provider covers before you rely on it

Record what the provider backs up, for how long and what it leaves out. Where its commitment falls short of the recovery point or the retention you set here, you keep your own copy outside its account. “How do we protect data in a cloud or software-as-a-service system when the provider does not back it up?” sets that out.

• Then: Take the decision to your approver and plan the first restore check

Outcome

Take the decision to your approver and plan the first restore check

The backup standard and the coverage list are approved by the approver your governance names: the board or its committee, the management board, or executive management, depending on how you are governed. The pack names the Backup owner as responsible. Then plan the first restore check for each data set by its class, and check how many copies each critical data set has and where they are kept.