Compliance evidence

The evidence problem

Most teams can describe their DR plan. Far fewer can produce a dated record showing it was exercised, what recovered, how long it took, and that the result was verified rather than assumed, which is what the assessor actually asks for.

Asternodis generates that as a by-product of the testing you should be doing anyway. Every non-disruptive DR test is recorded: when it ran, which guests booted, which recovery point each booted from, the measured recovery time, and a pass or fail verdict. Nothing needs to be reconstructed from memory at audit time, because it was written down when it happened.

What you can hand over

• •DR test history: every test with its date, scope, per-guest outcome, the recovery point booted, measured RTO, and verdict. Exportable as CSV.
• •Control coverage: which of the controls below your recent tests produce evidence for, and where the gaps are. Exportable as CSV.
• •Audit log: every operator action, with actor, target, outcome and timestamp. Exportable as CSV.
• •Recovery point integrity: points are re-verified across their whole retention life, and any that silently rot are quarantined rather than counted.

The evidence is mirrored between the two sites, so the record survives losing the site it describes, which is the one moment it is most likely to be asked for.

The audit log is tamper-evident

Each entry commits to the one before it with a chained hash. Removing or editing an entry after the fact breaks the chain, and Asternodis raises an alert when it does. That is a meaningful difference from a log file: an assessor can be told not just what the record says, but that nobody quietly rewrote it.

Destructive recovery actions can also require two-person approval, so the separation of duties an auditor expects is enforced by the tool rather than by convention.

Controls your DR tests produce evidence for

These are the controls whose text genuinely describes recovery testing. Asternodis maps a passing, in-cadence test to each of them and shows you the coverage in-product.

What is deliberately absent

Three things you might expect to see here are missing on purpose, because claiming them would be false:

• •VS-NfD. An approval the BSI grants to a product against an Anforderungsprofil, with approved cryptography. It cannot be self-declared, and claiming it would be the most serious false statement this product could make.
• •DISA STIG. Hardening guidance for a host OS and application platform, not something a recovery test evidences. What applies is the operating-system STIG on the controller VM, which is yours.
• •FIPS 140-3. A property of the cryptographic module a binary is built against, not of recovery evidence. Our tree builds under Go's validated module, but that build option is off. Until it is on and every cryptographic path has been audited against the approved algorithm list, nothing here may imply otherwise.

Everything on this page is written to survive an assessment: we don't claim what we can't defend.

Need a framework we don't list yet?

Adding one means adding controls whose text genuinely describes recovery testing, not stretching an existing mapping to fit. If the standard you report against has such a control, tell us which and we will look at it properly.