Resilience Assurance
Redundancy that is assumed is not redundancy. REAP inventories the redundancy relationships it can see and flags standby pairs that are out of sync, drift from recorded configuration, and CVEs that matter because of the features you run, each finding with evidence an auditor can read. Backup-path capacity and continuous failover-readiness proof are In development.
The buyer’s question
You paid for redundancy: a second circuit, a standby firewall, a second core. Can you show your auditor, your insurer or your board that it works today? Failover was tested at commissioning. Since then: a standby that stopped synchronizing, a backup circuit that cannot carry peak load, drift on forty access switches, and a CVE (opens in a new tab) that matters because of the feature you enabled. Start before the audit, the circuit renewal or the failover you did not plan.
Active/standby pairs REAP can read, checked for sync; running-versus-startup drift and configuration history across vendors; CVEs ranked by the features you have configured, with upgrade and configuration options and their side effects; posture findings across security, availability and configuration standards, each with the vendor-specific fix; backup-path capacity as a finding where interface telemetry is available: all reviewed with your architect in week 3.
Discovery of every redundancy relationship, cross-vendor equivalence and continuous failover-readiness evidence. Built with design partners; see product status.
For teams whose redundancy is audited or insured and whose HA pairs span vendors: early access and a say in what counts as proof, in exchange for structured feedback.
Ask for a seatWhat you get
Pilots target at least three previously unknown material risks, confirmed by your architect, for example, a firewall pair whose standby cannot be seen or is out of sync, with the reason and the configuration change that fixes it.
Which CVEs matter here, because of what the device runs and what sits behind it.
In pilots with audit scope: configuration and segmentation evidence produced from live configuration and topology, not screenshots gathered over weeks.
Evidence shown
Week 3 of a pilot is a findings review with your architect: each finding carries severity, evidence and a recommended fix.
Finding
Backup circuit DRS-WAN-B is 100 Mb/s (interface bandwidth and carrier order). Business-hours 95th-percentile load on the primary is 240 Mb/s. Failover would succeed and then congest.
Why it matters
MES and plant telemetry share the backup with all other traffic and no QoS class protects them, so a daytime failure drops production telemetry with everything else. Nightly backups (peak 310 Mb/s) matter only for a night-time failover.
Severity and exposure
High Since the June bandwidth change on the primary; no alarm exists for this condition today.
Recommended fix
QoS class for MES and telemetry on DRS-WAN-B; an alert when business-hours p95 on the primary exceeds 80% of backup capacity; the backup upgrade in the next budget cycle. Verify with a failover test in the next maintenance window.
Evidence
How a pilot measures it
| Measure | Default target (agreed per pilot) | Source |
|---|---|---|
| Prevention | ≥3 previously unknown material risks confirmed by the customer | Resilience & Posture Findings Report |
| Context completeness | ≥95% devices discovered · ≥90% topology accuracy | Network Context Report |
| Economics | Audit-evidence hours and incidents prevented in the value model | Value model |
Related
Explain incidents with evidence.
Learn moreScore your redundancy proof and learning loop.
Learn moreDeployment, data and controls.
Learn more