How do we protect data in a cloud or software-as-a-service system when the provider does not back it up?

Start

A provider runs the platform that holds our data

A provider that runs a platform does not necessarily back up what your people delete, what an attacker changes or what an administrator breaks. Never assume it does. Find out what it does cover before you rely on it.

• Then: Is this a critical data set, one that a critical service needs?

Decision

Is this a critical data set, one that a critical service needs?

The pack's rule on provider backups is written for every cloud or software-as-a-service system that holds a critical data set. For other data the data owner decides how much of this flow to apply, and the data set's class still sets how often it is restored in a test. If you are not sure whether a critical service depends on it, answer yes.

• Yes, or not known: Record what the provider backs up, for how long and what it leaves out
• No: Record what the provider covers and let the data owner decide

Step

Record what the provider backs up, for how long and what it leaves out

The data owner records, for each system, what the provider backs up, for how long, how it restores, and what it leaves out. Read its terms, ask its support, and keep the answers with the system's entry in the coverage matrix. If you cannot get an answer, treat it as no commitment until you do.

• Then: Does its commitment cover our recovery point and retention?

Decision

Does its commitment cover our recovery point and retention?

The pack compares the provider's backup period with the recovery point and the retention you set for the data set, and has you record what it leaves out. Reading a commitment that leaves out items you delete, or changes an attacker makes, as not covering your needs is a cautious judgement, not the pack's text. If you do not know, answer no.

• Yes: Does the provider run a backup for us under a contract?
• No, or not known: Can we take our own copy of the data outside the provider's account?

Decision

Can we take our own copy of the data outside the provider's account?

Some providers give an export or a connector for a third-party backup tool, and some do not. The pack's model cloud clause asks for the means to export all your data in a usable format at any time during the term, not only at exit. If you do not know, answer no and ask.

• Yes: Keep our own copy outside the provider's account
• No, or not known: Record the gap as an exception and take it to the risk approver

Outcome

Record the gap as an exception and take it to the risk approver

With no way to hold your own copy and a commitment that falls short, the provider's gap is a risk you carry. The pack's route for a clause given up is to record it as an exception, co-signed by the risk approver where it leaves the supplier outside appetite. Ask the supplier for an export route or a change of terms. Test the tenant restore with the provider where you can. Tell the data owner what the service stands to lose.

Step

Keep our own copy outside the provider's account

Keep the copy outside the provider's account, so deleting a tenant or losing it to an attacker does not delete the backup. A second copy in the same cloud account, reachable with the same credentials, is not offsite and is not immutable.

• Then: Put one copy out of reach of production administrator credentials

Step

Put one copy out of reach of production administrator credentials

Each critical data set needs at least one copy that production administrator credentials cannot change or delete. The same applies to the copy you take of a cloud tenant, because attackers look for the backups first.

• Then: Include what a restore needs, and set the interval and the retention

Step

Include what a restore needs, and set the interval and the retention

A restore needs more than the data: configuration, the sign-in directory, the backup catalogue, build sources and the keys. Take the copy at least as often as the service's recovery point, and keep it for the longest of the business, legal and recovery needs.

• Then: Does the provider run a backup for us under a contract?

Decision

Does the provider run a backup for us under a contract?

Yes when a supplier runs a backup that you rely on, such as a managed backup of your tenant. Then its contract gives a restore time and it shares the results of its own restore checks. If you do not know, read the contract or ask the supplier liaison, and take the yes branch until you know.

• Yes, or not known: Is the contract restore time within the recovery time?
• No: Restore a tenant's data in a test, from our own copy or the provider's

Decision

Is the contract restore time within the recovery time?

The restore time must be no longer than the service's recovery time. A contract that gives no time, or a longer one, is recorded as a failed P22 check (MX-04). The supplier also shares the results of its own restore checks, which you keep with your test records.

• Yes: Restore a tenant's data in a test, from our own copy or the provider's
• No, or not known: Record it as a failed supplier check and agree a fix with the supplier

Outcome

Record it as a failed supplier check and agree a fix with the supplier

Record the contract gap, tell the backup owner and press the supplier to commit to a time within the recovery time. Where it cannot, “If a critical supplier's recovery time is longer than our service can wait, then what do we do?” covers what to do about a supplier recovery time that is longer than the service can wait.

Step

Restore a tenant's data in a test, from our own copy or the provider's

A cloud or software-as-a-service tenant is tested by a data restore (TT-1) and a tenant restore (TT-5), into a test tenant, with the provider where needed. The defaults are a data restore every 3 months and a tenant restore every 12 months for a critical data set. The tenant restore proves data the provider holds can be restored, including what it does not back up itself.

• Then: Did the test pass every criterion?

Decision

Did the test pass every criterion?

A test passes only when every criterion holds: the restore completed, the integrity checks passed, the time was within the recovery time and the data lost within the recovery point where the test is timed, someone other than the tester checked it with the data owner, and the evidence is recorded. A tenant restore is not a timed test by default, so the time and data-loss criteria apply only if you timed it. If any criterion is unknown, the test has not passed.

• Yes: Keep the records and repeat the restore on schedule
• No, or not known: Raise a finding with an owner and a due date, then retest

Outcome

Raise a finding with an owner and a due date, then retest

Every failed criterion is a finding with an owner, a severity and a due date. It closes only when a retest or new evidence shows the fix works. “If a restore test misses the recovery time or loses too much data, then what do we do?” covers what to do about a missed time or lost data.

Outcome

Keep the records and repeat the restore on schedule

Keep the provider's scope record, your copy details and the evidence of the test with your backup records. Repeat the restore on the schedule for the data set's class. Report the result as counts, naming every gap.

Outcome

Record what the provider covers and let the data owner decide

The pack's rule on provider backups is written for critical data sets. For other data, record what the provider covers and leaves out, and let the data owner decide whether an own copy is worth the cost. The data set's class still sets how often it is restored in a test.