/retention-rpo-compliance

name: "Retention & RPO Compliance"
description: >
  Comparing configured backup retention and cadence against contracted
  retention windows and RPO (recovery point objective) targets: the two
  distinct retention gap types (configured-shorter-than-contracted vs.
  storage-forced truncation), why achievable RPO must be derived from actual
  job success history rather than the nominal schedule, where the contracted
  side of the comparison actually lives, and why "no documented requirement"
  is its own finding rather than an automatic pass.
when_to_use: >-
  When checking whether actual backup retention configuration and cadence
  meet a contracted or required policy, rather than assuming the appliance
  defaults are adequate. Use when: retention compliance, RPO compliance,
  retention policy, recovery point objective, are we meeting retention
  requirements, backup contract compliance, retention gap, how far back can
  we restore.

Retention & RPO Compliance

Overview

Retention and RPO commitments are made in two places that routinely drift apart: the contract or SOW (what was promised — "1-year retention," "4-hour RPO") and the actual backup system configuration (what's actually happening — a 90-day local retention policy, a nightly-only backup schedule). Nobody discovers the gap until a restore request for month 8 of a promised 12-month retention window comes back empty, or a ransomware event reveals that the "4-hour RPO" client's most recent recovery point is actually 22 hours old. This skill exists to find that gap proactively by comparing what's promised against what's configured — not to audit whether backups are running (`backup-job-health`) or recoverable (`restore-test-verification`), both of which are prerequisites to this check actually meaning anything.

Anti-triggers

• **Framework or control compliance** — "compliance" here means a contracted

retention window and RPO target, not CIS/SOC 2/HIPAA control evidence; for that use `evidence-mapping` in compliance-pack.

• **Reading the agreement itself** — pulling a client's contract terms,

services, or renewal dates is the PSA's surface; use `autotask-contracts` or `halopsa-contracts`.

Key Concepts

Retention: contracted vs. configured

Retention is the length of time recovery points remain available for restore. The check here is mechanical but frequently skipped: pull the contracted/required retention value (from a documentation platform, contract record, or explicit org policy) and the actual configured retention window from the backup/BCDR tool itself, and compare them directly.

Two distinct gap types matter differently:

• **Configured-shorter-than-contracted** — e.g. contract specifies 1-year retention,

appliance is configured for 90 days. This is a direct compliance failure: the MSP is not delivering what was promised, and a restore request past the configured window will simply fail. Always the higher-severity finding.

• **Storage-forced truncation** — retention is *configured* correctly, but the

appliance is running out of local storage and silently purging older recovery points before the configured window elapses (see `backup-job-health`'s storage- trending section for the leading indicator). This is a compliance failure with a different root cause and a different fix (capacity, not configuration) — report it distinctly rather than merging it with a simple misconfiguration.

Where a client has no documented retention requirement at all, don't fabricate a default — report the appliance's actual configured retention as informational and flag the absence of a documented requirement as its own gap ("no contracted retention policy on file to check against").

RPO: target vs. achievable

RPO (recovery point objective) is the maximum acceptable amount of data loss, expressed as time — "we can tolerate losing at most 4 hours of data." RPO is not something a backup tool configures directly; it's a target that backup *frequency* either can or cannot meet. The check is: given the current backup schedule (how often jobs actually run and succeed), what is the realistic worst-case age of the most recent usable recovery point, and does that fit inside the contracted RPO?

• A nightly-only backup schedule cannot meet an RPO tighter than roughly 24 hours

(worse, in practice, if the nightly job sometimes fails — the achievable RPO in a failure scenario is however old the last *successful* recovery point is, not the scheduled cadence).

• Don't evaluate RPO against the schedule alone — cross-reference the job success

history from `backup-job-health`. A job scheduled hourly but failing three runs in a row has an actual achievable RPO much worse than its schedule implies.

• Where no RPO target is documented, report the achievable RPO as informational

(derived from schedule + recent success rate) and flag the absence of a documented target explicitly, the same way as an undocumented retention requirement.

Sourcing the "contracted/required" side of the comparison

The contracted or required side of this comparison usually isn't in the backup tool at all — it lives in a PSA contract/service record, a documentation platform entry, or an explicit statement from the person running the check. Don't infer a retention or RPO requirement from the backup tool's own defaults; that would just compare the system to itself and always pass. If no documented requirement can be found anywhere connected, say so plainly rather than treating "whatever is configured" as automatically compliant.

If no backup/BCDR tool is connected

State plainly that retention/RPO compliance cannot be checked: "No backup or BCDR connector is connected through the gateway, so there's no configured retention or backup cadence to compare against requirements." Do not fabricate configured values.

Common Workflows

Portfolio-wide retention/RPO sweep

1. Discover connected backup/BCDR tools via `cond