Home » Business Continuity » Disaster Recovery (BCDR)

Business Continuity — Disaster Recovery

Disaster recovery planning for New York businesses.

Recovery targets chosen with the costs visible, runbooks that name people and steps, and rehearsals run before the incident instead of during it.

RTO and RPO, without the mystique

Every disaster recovery decision reduces to two numbers, and both are business decisions wearing technical clothes.

TermThe question it answersWhat tightening it costs
RTO — recovery time objectiveHow long can this system be down before the damage compounds?Faster recovery requires standby infrastructure, replication, and rehearsal time
RPO — recovery point objectiveHow much recent work can we afford to re-create or lose?Smaller windows require more frequent replication and more storage

Here is the honest part vendors skip: minutes-level recovery for everything is purchasable, and almost nobody needs it. Most firms need it for two or three systems and can tolerate a day elsewhere — and the budget difference between those two designs is large. The real work is deciding deliberately, system by system, and writing the decision down where the business signed it.

The targets then flow downhill: they set the backup architecture and restore-test cadence, the replication design, and the order of the runbook. A DR plan that was never derived from targets is a wish list.

What the plan contains

A usable DR plan is short enough to follow under stress and specific enough to need no interpretation.

  • System inventory and dependency map

    What runs where and what depends on what — discovered on a calm day, not during the outage.

  • Tiered recovery targets

    RTO and RPO per system, agreed with the business and priced honestly, not defaulted.

  • Runbooks

    Steps, owners, and credential custody for each scenario — ransomware, hardware loss, cloud tenant compromise, site loss.

  • Communication plan

    Who informs staff, clients, regulators, and the insurer, in what order, with drafts written in advance.

  • Workspace contingencies

    A New York-specific concern: building access, transit disruption, and remote failover for anything that assumes people are in the office.

  • Review triggers

    Plans decay. System changes, staff changes, and the calendar each reopen the document.

How an engagement runs

  1. Continuity assessment

    Current backups, single points of failure, and recovery reality versus assumption. You keep the findings document whatever you decide next — see how assessments work.

  2. Targets and design

    Systems tiered, RTO and RPO set with the cost trade-offs on the table, and the recovery architecture designed to meet them.

  3. Runbooks written

    Scenario by scenario, with owners named and steps a stressed person can follow literally.

  4. Rehearsal

    Tabletop first to test the decisions, then technical — actually failing over and restoring in isolation to test the machinery.

  5. Maintain

    Findings fixed, plans updated after every material system change, and rehearsals repeated on the agreed cadence.

Rehearsals are the product

A plan that has never been run is a document. The first rehearsal always finds something: a dependency nobody mapped, an MFA prompt that goes to a phone locked in the office you cannot enter, a step that assumes a person who left in March.

Regulators have reached the same conclusion. NYDFS Part 500 requires BCDR plans to be tested, and HIPAA’s contingency-plan standard includes testing and revision. Rehearsal records are the evidence both regimes — and your insurer — want to see.

  • A rehearsal checks

  • Restores complete within the target you promised yourself

  • Runbook steps work when followed literally

  • People know their roles without being briefed mid-incident

  • Dependencies outside your walls — DNS, identity, SaaS — are accounted for

  • Findings are written down and actually fixed

Common questions

What is the difference between backup and disaster recovery?

Backup is a copy of the data; disaster recovery is the plan for operating the business while systems come back — order of restoration, where people work, who communicates what. You cannot have DR without tested backup underneath it, but backup alone leaves the operational questions unanswered.

We are fully in Microsoft 365 and the cloud. Do we still need DR?

Yes — the shape changes, the need does not. Cloud removes the burned-down server room and replaces it with tenant compromise, mass deletion, account lockout, and provider outages. A cloud-era plan covers identity recovery, independent Microsoft 365 data copies, and how you communicate when email itself is the casualty.

How often should we rehearse?

Annually is the common floor, plus after any material system change; regulated firms and insurers sometimes expect more. We set the cadence in the plan itself so it is a commitment with a date, not an intention.

Can you review a DR plan we already have?

Yes. The continuity assessment works as a standalone engagement: we test the plan’s assumptions against your actual environment and report what would hold and what would not. The findings are yours either way.

Rehearse the bad week before it happens.

Start with a continuity assessment — you keep the findings regardless of what you decide.