Backup and Restore Readiness Scorecard

Contents

• How the score works
• The ten controls
• What counts as evidence
• How to read the rating
• Why successful jobs can still fail
• Review and restore workflow
• Using JSON and embed outputs

How the score works

Job success alone earns no full credit. Backup readiness means recoverable media, monitored jobs, and a timed restore that demonstrates the system can meet its recovery needs.

Answer each of the ten controls as Yes, Partial, or No:

• Yes = 10 points
• Partial = 5 points
• No = 0 points

The maximum score is 100. Evidence quality is not scored automatically. The score reflects your stated control status; the note for each control records why you chose it and what supports the decision.

The scorecard runs entirely in your browser. It does not upload your backup inventory, inspect your storage platform, validate your credentials, or perform a restore. Treat it as a structured review aid, not as an audit or technical test.

The controls reflect practical recovery concerns described in CISA’s Data Backup Options guidance and NIST SP 800-34 Rev. 1, including multiple copies, separation from the primary environment, defined recovery needs, testing, and plan maintenance.

The ten controls

These ten controls cover the path from creating a backup to using it under pressure.

1. Multiple recoverable copies. Keep more than one backup copy, and confirm each copy can actually be retrieved and read. A second copy that has never been accessed is an assumption, not strong evidence.

2. Isolated failure domain. At least one copy must be separated from the same failure that could take out production. Consider the host, account, network, region, administrator path, and facility—not only the folder name.

3. Retention aligned to deletion and corruption. Retention should give you a realistic chance to discover accidental deletion, silent corruption, or unwanted changes before every usable version expires. The right window depends on your data and operating needs.

4. Protected immutable or offline copy. Maintain a copy that cannot be quietly altered or deleted through the same path used to compromise the primary system. Immutability, offline storage, and separate administrative control can all help, when implemented correctly.

5. Failure and stale-job alerts. A backup system should report failed jobs, missed schedules, expired credentials, capacity problems, and stale data. Alerts must reach a person or team that knows what action to take.

6. Recoverable encryption keys and credentials. Encrypted media is not recoverable if the key, account, passphrase, certificate, or access process is unavailable during an outage. Document how authorized recovery staff obtain what they need.

7. Representative restore completed. Restore a meaningful sample, not only a test file or directory listing. Verify that the restored data opens, has the expected structure, and retains the permissions or application behavior that matters.

8. Observed behavior supports RPO. Your actual recoverable points should support the amount of data loss you can tolerate. NIST defines RPO as the point in time to which data must be recovered after an outage. Use observed backup intervals and restore points, not schedule settings alone.

9. Timed recovery supports RTO. Measure the recovery process from the start of the exercise through usable service or data. NIST defines RTO as the overall time components can remain in recovery before negatively affecting the mission or business process.

10. Maintained runbook with owner and escalation. Keep current recovery instructions, prerequisites, contacts, dependencies, and escalation steps. Assign an owner who can update the runbook when systems, vendors, credentials, or responsibilities change.

What counts as evidence

Evidence should let another capable person understand why the answer is Yes, Partial, or No. Useful evidence may include a dated job report, retention configuration, storage inventory, alert test, access procedure, restore transcript, checksum result, or completed recovery record.

A concise note is enough when it identifies:

• What was checked
• When it was checked
• Which system or copy was involved
• What result was observed
• What remains uncertain

Do not confuse documentation with proof. A policy can show intent, but a restore record shows execution. A dashboard can show recent successful jobs, but it may not prove that an older point can be decrypted or that the application will start correctly.

The widget keeps one note per control so you can capture that context without putting sensitive credentials, secret keys, private addresses, or customer data into the assessment. Reference the location of internal evidence rather than copying confidential material into a shared score.

How to read the rating

The score bands are OpenAlt’s disclosed rubric, not an industry standard and not a guarantee of recovery.

Score	Rating	Practical meaning
85–100	Ready with evidence	Core controls appear in place and are supported by current evidence.
65–84	Close, gaps remain	The design may be workable, but one or more meaningful weaknesses need attention.
40–64	High-risk gaps	Recovery depends on assumptions, weak separation, limited testing, or missing operational controls.
0–39	Not ready	The current arrangement should not be treated as a dependable recovery capability.

A high score does not promise that every incident will be recoverable. One untested dependency, unavailable credential, damaged copy, or changed application can still alter the outcome. Re-score after material changes and keep the date with the result.

Why successful jobs can still fail

Snapshots and successful backup jobs can fail the recovery test because they measure different things. A job may complete while writing to storage in the same failure domain, retaining too few historical versions, or copying data that is technically present but not usable by the application.

Common failure points include:

• The snapshot is deleted through the same administrator account as production.
• The backup contains files but not application metadata, catalogs, permissions, or system state.
• Encryption keys or recovery credentials were not preserved with the recovery process.
• Retention expires before corruption or deletion is discovered.
• The restore target lacks required software, network access, licenses, or dependencies.
• The recovered data is incomplete, inconsistent, or too slow to use.
• Alerts were generated but no owner saw them or acted on them.
• The documented process assumes a person, vendor, or system that is no longer available.

That is why the scorecard gives meaningful weight to a representative restore and a timed recovery. NIST describes testing as a way to validate recovery capabilities and identify planning gaps; a green backup dashboard cannot substitute for that validation.

Review and restore workflow

Use the scorecard as a repeatable review, not a one-time declaration.

1. Define what must be recovered. Identify the data, service, or workflow that matters, along with acceptable data loss and downtime. Link the decision to business impact rather than choosing targets because they are convenient.

2. Walk through every control. Answer from the current environment. Use Partial when a control exists inconsistently, depends on an unverified assumption, or covers only some important data.

3. Record the gap and next action. A useful note says what is missing, who owns the correction, and what evidence will close it. Avoid vague entries such as “improve backups.”

4. Prioritize by consequence. A missing isolated copy, unavailable key, or untested restore may deserve attention before a lower-impact documentation improvement.

For a restore drill, choose a representative dataset and a recovery target that will not damage production. Record the backup point selected, the start time, the end time, the people involved, and any dependencies discovered. Validate more than file presence: open the restored data, check expected permissions or application behavior, and confirm that the result is usable.

Compare the observed data point with the RPO and the elapsed recovery time with the RTO. Record failures, workarounds, missing instructions, and follow-up owners. Preserve the drill record with the scorecard export so the rating has a clear date and context.

For storage planning, use the Backup Storage Calculator. To explore how recovery targets affect operational consequences, use the RTO/RPO Impact Calculator. The Immich Backup Guide provides a more focused example for that application.

Using JSON and embed outputs

The widget exports dated JSON so you can preserve the score, rating, control answers, and notes as a point-in-time record. Keep the original export alongside your review or change log. Do not treat a JSON file as proof by itself; it is a record of what was assessed.

The generated HTML link is a normal dofollow link containing the score and rating. Use it responsibly:

• Keep the linked result accurate and current.
• Do not present the rubric as certification, compliance approval, or a guarantee.
• Include the assessment date and scope when sharing it.
• Remove sensitive infrastructure details from notes before publishing.
• Update or replace the link after major changes to storage, retention, credentials, or recovery procedures.

For more backup and storage guidance, browse the File Storage category.