Understand What Your SaaS Provider Does Not Back Up for You

When a SaaS service is available every day, it is easy to assume the provider can restore every record, setting, identity, and workflow the business might lose. That conclusion does not follow from uptime alone. Availability, retention, deleted-item recovery, version history, export, independent backup, and tested business recovery answer different questions.

This guide helps a 1–50-person team document those questions for one bounded service category. It does not inspect a tenant or tell you what a named provider does. Use only current primary evidence that applies to the exact service and plan; when that evidence is absent or unclear, record the gap instead of guessing.

Start with responsibility, not a product conclusion

The NCSC cloud shared-responsibility guidance says security and availability responsibilities are shared between provider and customer and vary with the service and its implementation. It also says customers remain responsible for ensuring the service can meet their security needs, configuring chosen services securely, and deciding which data to store.

Those documented statements support the responsibility questions in this guide. They do not establish any named provider’s availability, retention, deletion recovery, version recovery, export, backup, restore, identity, configuration, administrator, support, or plan behavior.

The fourteen questions, eight stages, state vocabulary, evidence threshold, 18 fields, completion rule, and review triggers are PlainFort editorial judgment. They are not NCSC requirements, provider claims, contract interpretation, procurement or compliance criteria, certification, a universal SaaS backup rule, or a guarantee.

Keep fourteen evidence questions separate

1. Service or workflow category: the bounded business use, not a tenant, account, domain, or named provider.
2. Business and data boundary: the category-level scope and BR-21 objective this decision consumes.
3. Internal ownership and authority: the accountable owner, responsible operator, genuine backup, evidence owner, and escalation authority.
4. Provider and plan category: the non-sensitive service and plan boundary to which evidence would apply.
5. Dated primary provider evidence: what a current first-party source actually states, its check date, applicable scope, exclusions, and ambiguity.
6. Availability and resilience: whether the service is designed to remain available, separate from customer recovery.
7. Retention: how long a category may remain available under stated conditions, separate from backup and restoration.
8. Deleted-item or recycle recovery: a bounded native undo or recovery feature, separate from retention and complete restore.
9. Version or point-in-time recovery: whether earlier states can be recovered, with object, field, time, and condition limits kept visible.
10. Export: whether data can be extracted, separate from a complete, current, usable, and recoverable copy.
11. Independent backup: a separately controlled recovery copy or method, not inferred from availability, export, or a provider feature.
12. Identity and configuration recovery: the administrators, roles, settings, metadata, integrations, and access prerequisites needed to make recovered content useful.
13. Administrator, access, and continuity dependencies: surviving authority and access paths, without redesigning MFA, administrative accounts, or vendor access.
14. Tested business recovery, evidence, unknowns, exceptions, residual risk, escalation, and review: truthful completion and the BR-22 handoff without performing a test.

Do not collapse these questions into one provider backs it up, protected, recoverable, covered, resilient, exportable, available, compliant, or secure checkbox. A strong state in one question cannot silently compensate for an unknown provider or plan scope, stale evidence, inaccessible administrator, missing identity or configuration recovery, unresolved BR-21 objective, or outstanding BR-22 test.

Use an eight-stage evidence-first process

This sequence is an editorial method for building a responsibility record. It does not authorize provider contact, tenant access, export, backup, restore, deletion, configuration, account, support, procurement, or contract action.

1. Bound the service category and consume BR-21

Choose one critical workflow category. Record only inert references to its business and data boundary and the approved BR-21 recoverability objective. Do not copy a real provider, service name, tenant, account, domain, plan, contract, data record, or objective value.

If the business objective is missing or still disputed, use BR-21 objective required. Do not decide whether independent backup is needed before the business need is bounded.

2. Assign internal ownership, backup, and authority

Record an internally accountable owner, responsible operator, genuine backup, evidence owner, and escalation authority. A repeated role may be unavoidable in a small team, but the resulting lack of independent challenge, capacity, availability, or continuity must remain visible.

A provider, reseller, broker, contractor, managed service, or software feature may execute separately authorized work or supply evidence. It does not silently acquire the team’s internal accountability, business authority, evidence judgment, or proof of recovery. Naming a role does not prove competence, access, authority, plan eligibility, or availability.

3. Fix the provider and plan evidence boundary

Record only a non-sensitive provider and plan category, then require the exact current primary provider source before making a capability statement. The evidence reference must include a check date, applicable service and plan category, precise supported statement, exclusions, ambiguity, and volatility trigger.

Do not infer provider behavior from a product label, interface, sales page, uptime statement, support response, contract fragment, another customer’s experience, search result, third-party article, or AI summary. If primary evidence is missing, inaccessible, contradictory, marketing-only, or unclear about plan applicability, use Unknown — provider/plan applicability unresolved or Blocked — qualified help required.

4. Separate availability, retention, and native recovery

Record availability and resilience, retention, deleted-item or recycle recovery, and version or point-in-time recovery as separate statements. One does not prove another.

Provider availability is not proof that customer-controlled recovery exists. Retention is not automatically a backup. A recycle feature is not complete recovery. Version history may apply only to selected objects, fields, conditions, or time windows. Keep every unsupported scope and limit visible.

5. Separate export, independent backup, identity, and configuration recovery

An export capability does not prove that the output is complete, current, consistent, restorable, or sufficient to recover the business workflow. Record export and independent backup as separate questions.

Then record whether identity, administrator roles, settings, metadata, integrations, permissions, devices, keys, business knowledge, and sequence dependencies are covered. Recovered content may still be unusable when those dependencies are missing. Do not inspect or perform an export, open a tenant, configure a backup, select a tool, or design a recovery architecture.

6. Map administrator, access, continuity, and volatility gaps

Record category-level dependencies on surviving administrators, authentication, access paths, support, provider behavior, evidence ownership, and internal continuity. Do not choose an MFA method, redesign administrative accounts, or reproduce vendor-access fields.

Mark stale evidence, unknown plan coverage, ambiguous retention, inaccessible export, unresolved identity or configuration recovery, and missing backup authority explicitly. A documentation date is evidence about when a statement was checked, not a promise that the provider will notify the customer of every later change.

7. Hand off bounded verification to BR-22

Turn the documented responsibility boundary into one bounded verification question for the BR-22 restore-test record. The handoff may name only the objective category, expected result category, provider/customer assumption, dependencies, and safe evidence reference.

Do not execute, simulate, schedule, or pass a restore test. BR-22 test required means the responsibility worksheet is not proof of tested recovery and does not authorize a test.

8. Close only with dated evidence, visible unknowns, escalation, and review

Close the documentation pass only when every field has a truthful state, dated evidence or an explicit gap, unresolved exceptions and residual risks remain visible, the escalation route is named, and the next review trigger is recorded.

Reopen the worksheet when the provider, plan, retention, deletion recovery, export, backup, identity, configuration, administrator, support, contract context, business objective, or evidence changes. A completed worksheet is not proof that the provider or customer can recover the business workflow.

Use workflow states, not a provider score

• Documented — dated primary evidence referenced
• Reported — primary evidence not inspected
• Unknown — provider/plan applicability unresolved
• BR-21 objective required
• BR-22 test required
• Blocked — qualified help required
• Deferred — owner and review date required
• Exception — scope, reason, owner, expiry, and residual risk required
• Not applicable — bounded rationale and reviewer required

These are workflow positions, not a security score, provider rating, maturity level, resilience grade, compliance status, procurement verdict, or prediction that recovery will succeed. Documented is not tested; Reported is not primary evidence; and Not applicable cannot hide a missing fact.

Build the 18-field vertical responsibility worksheet

Complete one vertical record for each bounded service or workflow category:

1. Service or workflow category: category only; no real provider or service name.
2. Business and data boundary: bounded scope and inert business reference.
3. Internal accountable owner: role, not a personal identity.
4. Responsible operator and genuine backup: role coverage and handover state.
5. Provider and plan category: non-sensitive category; no subscription or contract details.
6. Dated primary provider evidence reference: approved-system location, check date, scope, and exclusions; content not copied.
7. Availability and resilience statement: precise supported statement or truthful unknown.
8. Retention statement: scope, conditions, and evidence state without operational values in this article.
9. Deletion or recycle recovery statement: distinct native-recovery scope and limits.
10. Version or point-in-time recovery statement: distinct earlier-state scope and limits.
11. Export statement: scope, completeness questions, format category, and evidence state without performing an export.
12. Independent-backup statement: responsibility and current decision state without implying a universal purchase need.
13. Identity and configuration recovery statement: identity, settings, metadata, integrations, and permission categories.
14. Administrator, access, and continuity dependency: surviving authority and access categories.
15. BR-21 objective handoff: inert approved-record reference; value not copied.
16. BR-22 restore-test handoff: bounded verification question and state; no test authorized.
17. Unknowns, volatility, exception, and residual risk: visible gaps, owner, expiry, and consequences.
18. Qualified escalation and review trigger: authority, safe route, and event or date that reopens the record.

Do not convert the worksheet into a table, provider scorecard, product matrix, architecture, contract checklist, compliance assessment, dashboard, maturity model, sales comparison, configuration worksheet, or live tenant record.

Fictional example — do not copy as a completed backup or recovery record

This deliberately generic example contains no real or plausibly operational provider, plan, account, feature, value, or evidence.

1. Service or workflow category: Example Co. collaboration-workflow category.
2. Business and data boundary: bounded work-record category; details not copied.
3. Internal accountable owner: operations-owner role.
4. Responsible operator and genuine backup: service-operator and continuity-backup roles; independent capacity not evidenced.
5. Provider and plan category: generic hosted-service category; no provider or plan named.
6. Dated primary provider evidence reference: Provider evidence held in approved system — source details not copied.
7. Availability and resilience statement: Documented — dated primary evidence referenced; availability does not establish recovery.
8. Retention statement: Reported — primary evidence not inspected.
9. Deletion or recycle recovery statement: Unknown — provider/plan applicability unresolved.
10. Version or point-in-time recovery statement: unknown scope; qualified follow-up required.
11. Export statement: documentation category exists; completeness and usability are not established.
12. Independent-backup statement: no decision; BR-21 objective and evidence review remain inputs.
13. Identity and configuration recovery statement: administrator, configuration, integration, and permission categories unresolved.
14. Administrator, access, and continuity dependency: surviving administrator and support-authority categories not evidenced.
15. BR-21 objective handoff: BR-21 objective held in approved record — value not copied.
16. BR-22 restore-test handoff: BR-22 test required; no test authorized by this worksheet.
17. Unknowns, volatility, exception, and residual risk: Exception — scope, reason, owner, expiry, and residual risk required because plan applicability and continuity remain unresolved.
18. Qualified escalation and review trigger: Blocked — qualified help required; reopen after current evidence and internal authority are established through an approved route.

The example does not prove that Example Co. has a backup, can export complete data, can recover identity or configuration, meets a business objective, or is secure. A fabricated provider claim, plan, retention window, deletion behavior, export result, backup state, restore result, support response, or failure plausible enough to be mistaken for live evidence is prohibited even when labelled fictional.

Preserve the dedicated-guide boundaries

• BR-21 owns the business recoverability map, tolerated loss and downtime objectives, dependencies, and restore order; this guide consumes those references without rewriting or validating them.
• BR-22 owns one separately authorized bounded restore test and its result; this guide supplies a provider-responsibility question without executing, simulating, or passing the test.
• BR-23 owns later ransomware-readiness synthesis; this guide provides evidence without reproducing incident or ransomware preparation.
• SF-05 owns operational vendor access, privileges, contacts, expiry, review, removal, and closure evidence; this guide records recoverability responsibility, not access or credentials.
• AA-07 owns MFA-method choice, fallback, and recovery tradeoffs; this guide records an identity-recovery dependency without choosing or configuring MFA.
• AA-08 owns everyday and administrator separation, elevation, privilege, and exceptions; this guide records an administrator dependency without designing or modifying accounts.

Stop before provider, tenant, or specialist action

This guide creates a documentation worksheet; it does not contact a provider, access a tenant, inspect evidence, interpret a contract, validate a plan, export data, configure a backup, restore content, change deletion or retention, modify identity or privilege, test a product, select a vendor, recommend a purchase, or determine procurement, legal, compliance, privacy, records, or insurance fitness.

Stop and obtain qualified help when primary provider evidence is missing or contradictory; provider or plan applicability is unclear; critical, regulated, private, or high-impact data is involved; no independent administrator survives; identity, configuration, export, retention, deletion, or recovery scope is ambiguous; the only recovery path may be affected; a destructive or production-impacting test would be required; or a provider-security, procurement, contract, legal, privacy, records, insurance, or compliance conclusion appears. Keep the unknown visible instead of turning it into a claim.