Control frameworks
Asternodis produces evidence for controls. It does not make an organisation compliant with them. That distinction runs through this page, and it is the one an assessor will hold you to: 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 it answers nothing wider.
Everything below comes from evidence the product already records: the per-plan DR-test history on the Compliance page, the recovery objectives you set, and the audit trail. Export the matrix as CSV from that page; the caveat above is repeated on every row, because a note in a header is separated from its data the moment anyone filters it or pastes a subset into a questionnaire.
What a DR test evidences
| Framework | Control | What the evidence shows |
|---|---|---|
| NIST SP 800-53 Rev 5 | CP-4 Contingency Plan Testing | A recovery plan was exercised on a schedule and its outcome recorded, with the achieved recovery time measured against the stated objective. |
| NIST SP 800-53 Rev 5 | CP-10 System Recovery and Reconstitution | Guests were reconstituted at the recovery site from a replicated point and observed to boot, without disturbing production. |
| NIST SP 800-53 Rev 5 | CP-7 Alternate Processing Site | An alternate site held the workload’s data and was shown able to run it. |
| ISO/IEC 27001:2022 | A.5.30 ICT readiness for business continuity | ICT recovery capability was planned, exercised and evaluated against a defined RTO. |
| ISO/IEC 27001:2022 | A.8.14 Redundancy of information processing facilities | A second site carried a current copy of the workload and was exercised. |
| BSI IT-Grundschutz | DER.4 Notfallmanagement | Wiederanlauf wurde geprobt und das Ergebnis samt erreichter Wiederanlaufzeit dokumentiert. |
| BSI IT-Grundschutz | CON.3.A5 Regelmäßige Wiederherstellungstests | Die Wiederherstellbarkeit der Datensicherung wurde durch einen echten Wiederanlauf nachgewiesen. |
| NIS2 / KRITIS | Art. 21(2)(c) Business continuity, backup management, disaster recovery | Backup and disaster-recovery arrangements were maintained and their effectiveness demonstrated by exercise. |
| CMMC L2 / NIST SP 800-171 | 3.8.9 Protect backup CUI at storage locations | Replicated copies were held at a defined recovery site under the same access controls, and their recoverability was exercised. |
Supporting evidence for the same assessments comes from the audit trail (800-53 AU-2/AU-3/AU-12, ISO A.8.15, IT-Grundschutz OPS.1.1.5) and from role-based access with optional two-person approval for failover (800-53 AC-3/AC-6).
CMMC Level 1 is a different matter. Its seventeen practices are drawn from FAR 52.204-21 and are mostly access control and media handling; recovery evidence contributes very little to it. Level 2, which maps to SP 800-171, is where this evidence is useful.
What stays yours
None of these controls is satisfied by a tool alone.
- The plan itself. CP-2 and A.5.29 are about having a contingency plan with roles, dependencies and communications. Asternodis executes and tests a recovery sequence; it does not write your plan.
- Scope and classification. Which systems are in scope, and what data they hold, is your determination: the product replicates what you tell it to.
- Cadence. You set each plan’s test interval and RTO target. The product measures against them and tells you when a plan is overdue; it does not decide what the objective should be.
- Incident reporting. NIS2’s 24-hour early warning and 72-hour notification are organisational processes with deadlines. Webhooks can feed them, but the obligation is yours.
- The rest of the standard. Every framework here is far wider than continuity.
What Asternodis does not claim
These appear on requirement lists next to the ones above, and recovery evidence does not speak to them. Saying otherwise would be false, so the product does not say it.
VS-NfD. An approval the BSI grants to a product, against an Anforderungsprofil and with approved cryptography. It is not something a vendor can self-declare and not something a recovery test demonstrates. Asternodis has not been through that approval.
DISA STIG. Hardening guidance for an operating system or application platform. There is no Asternodis STIG. What applies to a deployment is the OS STIG for the controller’s own operating system, which you apply and assess as you would for any other host.
FIPS 140-3. A property of the cryptographic module a binary is linked against, not of any recovery evidence. Released builds are not linked against a validated module, so no build should be described as FIPS-validated. If you have a requirement here, ask. The codebase builds under Go’s validated cryptographic module, and the work is auditing every cryptographic path against the approved algorithm list and publishing a distinct build, not flipping a flag.