Owner: CTO, with CISO
Effective Date: May 15, 2026
Reviewed: Annually
Frameworks: SOC 2 CC7.5 (recovery from disruption) and A1.2 / A1.3 (backup and recovery testing); ISO/IEC 27001 A.5.30 (ICT readiness for continuity) and A.8.13 (information backup). Implements the Business Continuity & DR Policy.
This procedure verifies that Neuroscale’s backups are restorable and that the disaster-recovery runbooks meet the RTO/RPO targets in the Business Continuity & DR Policy. It is the canonical operating record for SOC 2 CC7.5 (recovery from disruption) — with the same evidence supporting the Availability criteria A1.2 / A1.3 (backup and recovery-plan testing) — and ISO/IEC 27001 A.5.30 (ICT readiness for business continuity) and A.8.13 (information backup).
Scope timing. CC7.5 is a Common Criteria (Security) control and these tests operate now. Consistent with the Business Continuity & DR Policy, the Availability (A1) operating-effectiveness evidence these tests also support is not attested in the initial Security-only window — it accrues into the first subsequent Type II window (Sep 2026 – Sep 2027) when the Availability criterion comes into scope.

​
Cadence

  • Backup-restore test (per data store) — at least quarterly.
  • Full DR exercise (tabletop or live) — at least annually; at least one live failover per two-year period.
  • Triggered test — after any change that materially alters backup format, target store, encryption keys, or RTO/RPO; after any failed restore in production.

​
Scope

In-scope data stores and recovery paths are enumerated in the RTO/RPO Matrix. At a minimum the following are exercised on the quarterly cadence:
ClassExamplesTest type
Production databasesAurora / Postgres customer-data instancesRestore latest snapshot to an isolated VPC; verify row counts and key checksums
Object storageS3 customer-data buckets, audit-log Object-Lock bucketsRestore a representative prefix; verify checksums and lock state
Configuration & secretsHashiCorp Vault, KMS key material backupsRestore to a staging Vault; verify auth methods and policy enumeration
Source of truthGitHub neuroscale org repository archivesVerify the offline archive can be re-cloned and contains the most recent tag
The full DR exercise additionally walks the AWS root-compromise playbook, Vultr root-compromise playbook, and the rollback procedure end-to-end.

​
Trigger

The CTO opens a Linear issue at the start of each quarter:
  • Title: DR & Backup-Restore Test — <Quarter> <Year>
  • Owner: SRE on-call lead for the quarter
  • Linked artifacts: RTO/RPO Matrix, test plan, evidence pack, sign-off.

​
Process — quarterly backup-restore test

  1. Plan. SRE on-call lead drafts a test plan from the RTO/RPO Matrix. The plan names: data store(s), source snapshot ID, target environment (isolated VPC), success criteria (row counts, checksums, app-level smoke), and the RTO/RPO targets being verified.
  2. Approve. CISO and CTO approve the plan in the Linear issue before execution.
  3. Execute. SRE on-call lead performs the restore in the isolated environment. Production is never the target of a restore test. Wall-clock duration is recorded.
  4. Verify. Success criteria are evaluated. For database restores, row counts and the latest few primary keys are checked against the source snapshot’s manifest; for object storage, a representative prefix is checksummed; for Vault, auth-method and policy enumeration is diffed against the live tenant.
  5. Record. Test results — pass/fail, wall-clock vs RTO target, data-loss window vs RPO target, anomalies — are added to the Linear issue. Any failure or RTO/RPO miss is filed as an incident per the Incident Response Policy with severity assigned by the CISO.
  6. Tear down. The isolated environment is destroyed within 24 hours of test completion to avoid lingering data copies.
  7. Sign off. CTO and CISO sign off on the test outcome in the Linear issue.

​
Process — annual DR exercise

The annual exercise extends the quarterly test with:
  • A tabletop walkthrough of one root-compromise playbook and one customer-impacting outage scenario, with the engineering on-call, CTO, CISO, and (where customer comms is in scope) GC and customer-success lead.
  • A live failover in alternating years — failing over a customer-data-bearing service to its DR target and serving production traffic from the DR target for at least one hour before failing back. The decision to run live (vs. tabletop-only) for any given year is made by the CTO and CISO at the start of the year and recorded in the Compliance Calendar.

​
Evidence

For every test, the following are retained in the SharePoint evidence library used for SOC 2 / ISO 27001 audits:
  • Approved test plan (with CTO + CISO sign-off).
  • Execution log — start time, end time, commands run (or runbook checklist completed), screenshots of verification.
  • Pass/fail determination with comparison to RTO/RPO targets.
  • Linear issue link (which threads the audit trail).
  • For annual exercises: tabletop attendance list and the run-book diff (any updates the exercise motivated).
Records are retained for at least 3 years per the Records Retention Schedule.

​
Escalation

A failed restore — restore did not complete, data did not match source, or RTO/RPO targets were missed — is filed as a Severity 2 incident at minimum. The CISO may upgrade severity. Remediation is tracked through the Incident Response Policy post-incident-review process and reported at the next ISMS Management Review.

​
Version history

VersionDateDescriptionAuthorApproved by
1.0May 15, 2026Initial version — implements Business Continuity & DR Policy, SOC 2 CC7.5 / A1.2 / A1.3, ISO 27001 A.5.30 / A.8.13Cameron WolfeIshan Jadhwani