Compliance & reporting
The Compliance page turns your DR activity into the evidence auditors ask for: proof that recovery actually works, and how fast.
What it captures
Every DR test and recovery-plan run is recorded with its results: which guests recovered, how long it took (RTO), and how current the recovery point was (RPO). These become exportable reports you can hand to an auditor or keep for your own records.
Scheduled tests
You can schedule recurring DR tests so recovery is verified on a cadence rather than only when someone remembers. Set a plan’s test cadence and RTO target at Recovery Plans → Schedule on the plan’s recovery site, which runs its scheduled tests and owns the schedule; on the primary the button is shown disabled and names the recovery site to open instead. Scheduled runs produce the same evidence automatically, so your compliance record stays current without manual effort.
Fleet coverage
Before you export evidence, it’s worth knowing how much of the underlying recovery-point catalogue has actually been checked. That lives on the Overview page rather than on Compliance: on the recovery half of a pair, its Copies held here panel (see The web UI at a glance) reports coverage over that catalogue, one lane at a time, because each kind of recovery storage is checked in the way it can be proven:
- Filesystem-checked: how much of it has a current verdict from the background filesystem check, a read-only pass of the same offline checker that can repair a recovered guest’s disks before boot during a failover or DR test.
- ZFS, Ceph/RBD and container points (chain-verified): Read back at capture is how much was read back against the storage’s checksums within minutes of capture; Content-verified this cycle is how much had its full data re-read and matched in the current cycle; Scrub cycle is the age of the oldest such pass against its 24-hour target.
- Directory, NFS, CIFS and LVM-thin points (measured by digest): Digest-verified this cycle and Digest scrub cycle, plus Digest checks held back when a comparison can’t finish between two captures at the current read rate. Content-hashed, shown when any point is on this lane, is how much of it has a recorded digest baseline. A digest detects change since it was measured, not damage that landed before. That is a weaker claim than a storage checksum, and it is worded as one.
- Oldest unchecked and Quarantined cover every lane.
Every figure is over the points its own lane covers and turns amber below 80% (a cycle at twice its target), so a plan can’t hide a real gap behind a single green number. If a cycle keeps ageing or checks are held back, an admin can raise the read rate under Settings → Replication limits → Recovery-point integrity reads.
Control coverage
Underneath the readiness table, Control coverage names the framework controls each plan’s evidence speaks to: NIST SP 800-53 CP-4, CP-7 and CP-10, ISO/IEC 27001:2022 A.5.30 and A.8.14, BSI IT-Grundschutz DER.4 and CON.3.A5, NIS2 Art. 21(2)(c), and 3.8.9 from SP 800-171 for CMMC Level 2. Hover a control to see, in one sentence, what your evidence actually shows for it.
Each plan carries a badge for how far its evidence goes:
| Badge | Meaning |
|---|---|
| evidenced | The most recent exercise passed, within this plan’s own test interval. A plan with no test interval set is never overdue, so its latest passing exercise stays evidenced however old it is. |
| lapsed | An exercise passed, but not within the interval: the evidence is stale, not absent. |
| last test failed | The most recent exercise did not pass. Kept as evidence: a failed recovery test is a finding. |
| never tested | This plan has never been exercised, so it evidences nothing yet. |
Export control matrix (CSV) writes one row per plan per control, so an assessor can filter to a single control and read across. Every row carries the scope note below, because a caveat in a header is separated from its data the moment anyone filters the sheet or pastes part of it into a questionnaire.
The export covers exactly what the page shows, including evidence whose plan has since
been deleted: a test that ran still ran, and a failed one especially still counts.
Those rows are marked plan_retired so you can tell a live obligation from a historical
record: a retired row has no next-due date and is never overdue, because there is nothing
left to test.
Compliance and License are readable by any signed-in role, not just administrators: the people who need DR evidence for an audit are often not the people who administer the controller.
Evidence for a control is not compliance with it
Asternodis produces evidence for these controls. It does not make an organisation compliant with them, and it does not say it does. A passing, in-cadence recovery test with a measured recovery time answers “show me you test your recovery plan and meet your stated objective”, and nothing wider. The plan itself, your scope and classification decisions, the cadence you choose, and incident-reporting duties such as NIS2’s 24-hour and 72-hour deadlines all remain yours.
Some frameworks people ask about cannot be evidenced by a recovery test at all (VS-NfD, DISA STIG and FIPS 140-3), and the page says so rather than leaving their absence to be noticed. Control frameworks explains each mapping, what stays your responsibility, and why those three are excluded.
Why it matters
A backup you’ve never restored isn’t a recovery plan. Asternodis’s non-disruptive testing means you can prove recovery regularly without risking production, and Compliance is where that proof lives.
Next: License.