Skip to main content

Disaster recovery

NEXT maintains a structured disaster recovery (DR) plan to restore service after disruptive events (natural, political, human-made, or malicious). Systems are tiered (critical / non-critical), RTO is within 24 hours, RPO is 24 hours (full backups every 24h plus transaction logs), and the plan is tested annually (incl. tabletop reenactments).

Disaster recovery objectives​

Objective

What it means for NEXT

Target

RTO

Time to restore NEXT during an outage

Within 24 hours

RPO

Max tolerable data loss in a recovery

24 hours (with logs enabling near-point restore when possible)

Note that definitions and process are consistent with NIST SP 800-34 guidance for IT contingency planning.

System tiers (prioritization)​

  • Critical systems: application and database services (or services required for them). If unavailable, restoration begins immediately.
  • Non-critical systems: do not block critical operations; restored after critical services.

Phases & sequencing​

  • Notification / Activation – detect & assess; activate the DR plan when criteria are met; coordinate comms and roles.
  • Recovery – rebuild production capability (e.g., re-deploy partitions with tested scripts; validate with pre-written tests).
  • Reconstitution – return to steady state; goal: full operations within 24 hours of a disaster or outage.

Testing & rehearsal​

NEXT tests DR at least annually, including tabletop (people/process) and technical exercises (e.g., restore-from-backup and alternate site capability checks), followed by a retrospective to improve playbooks.

Standards alignment​

The program follows NIST SP 800-34 Rev.1 principles for contingency planning (objectives, roles, testing, and recovery strategies).

FAQ​

Q: What RTO and RPO does NEXT AI target?​

RTO: within 24 hours. RPO: 24 hours, with transaction logs enabling restores closer to the interruption when possible.

Q: How often is the Disaster Recovery plan tested? What kinds of tests?​

At least annually, using tabletop exercises and technical tests (restore-from-backup, alternate-site capability), plus a retrospective to improve procedures.

Q: What triggers Disaster Recovery plan activation?​

Examples include prolonged unavailability (e.g., systems down >48h) or hosting-facility damage (>24h), with activation by the Security Officer/CTO after assessment.

Q: How are systems prioritized during recovery?​

Critical systems (app/db and dependencies) are restored first; non-critical systems follow.

Q: Which standard does your approach align to?​

The plan aligns with NIST SP 800-34 Rev.1; broader business-continuity practices align with ISO 22301.