SaaS and service providers
Your customers depend on your uptime and ask for RTO and RPO commitments in contracts. You need objectives you can actually meet and evidence of recovery tests behind them.
Risk & security programs
Business continuity & disaster recovery planning
A customer’s vendor review asks for your recovery time objective, your SOC 2 auditor wants evidence that you test recovery, and your leadership wants to know what happens if ransomware encrypts everything, backups included. Business continuity and disaster recovery readiness gives you an honest picture of what your business can’t live without, plans that restore it in the right order, and the exercise records that show those plans work.
Formal outcome from
No certificate for the plan itself — ISO 22301 certification, if you want it, comes only from an accredited certification body you choose
Who asks for it
Enterprise customers and their vendor-risk teams · SOC 2 auditors reviewing the Availability criteria
Our role
Readiness — we help you build it and prove it
Your organization — readiness viewEvery requirement, an owner and its evidence
Readiness- SCOPEScope and system boundaryReady
- RISKRisk assessment and registerReady
- ACCESSAccess reviews, with evidenceGap · owner set
- CHANGEChange managementClosing
- VENDORVendor managementGap · owner set
- TESTPenetration test evidenceReport in hand
Handed to the assessor you choose — the opinion is theirs
Gaps found before the audit
Who it’s for
Why Business continuity & DR lands on your desk.
Business continuity is the ability to keep delivering what matters while something is badly wrong — a cloud region outage, a ransomware attack, a lost facility, a failed key supplier. Disaster recovery is the technical subset: restoring systems and data. Both start from a business impact analysis, which identifies your critical processes, the systems, people and suppliers they depend on, and how much downtime and data loss each can tolerate, expressed as a recovery time objective (RTO) and a recovery point objective (RPO).
ISO 22301 sets the requirements for a business continuity management system and is the certifiable standard in this field. NIST SP 800-34 Rev 1 gives US organizations a contingency planning model, and the FFIEC Business Continuity Management booklet sets examiner expectations for banks and credit unions. The HIPAA Security Rule requires a contingency plan with data backup, disaster recovery and emergency-mode operation. The SOC 2 Availability criteria ask for recovery plans that are tested, DORA requires EU financial entities to maintain and test ICT business continuity and response and recovery plans, NYDFS Part 500 requires a business continuity and disaster recovery plan, and FINRA Rule 4370 requires broker-dealers to keep one.
Ransomware changed what a good plan looks like. Attackers now go after backups first, and an outage that once meant failing over to a second data center can now mean rebuilding identity, restoring from copies the attacker could not reach, and deciding what is trustworthy before reconnecting it. Continuity planning today has to assume that the primary environment and the backup console may both be compromised at once.
Who asks for it
Enterprise customers and their vendor-risk teamsSOC 2 auditors reviewing the Availability criteriaBank and credit union examinersEU financial-sector clients under DORABoards and cyber insurers
Financial services firms
Examiners, FINRA, NYDFS and EU clients subject to DORA expect a documented, tested continuity program with board oversight and third-party dependencies accounted for.
Healthcare organizations
The HIPAA contingency plan standard requires backup, disaster recovery and emergency-mode operation plans, and clinical operations can’t simply pause while systems come back.
Teams unsure their backups would survive
Your backups exist, but no one is certain they would survive an attacker with administrator rights, or how a full rebuild would actually go. You want that answered before an attacker asks the question for you.
Who certifies
No certificate exists. The proof is yours to build.
Formal outcome from
No certificate for the plan itself — ISO 22301 certification, if you want it, comes only from an accredited certification body you choose
What they produce
Your own business impact analysis, continuity and DR plans and exercise records; optionally an ISO 22301 certificate from an accredited body
Where readiness fits
Most organizations need tested plans rather than a certificate, and tested plans are what SOC 2 auditors, examiners and customers review. If a customer or regulator does ask for ISO 22301, the same work becomes your readiness for that audit, carried out by a certification body independent of the people who helped you prepare.
ISO 22301:2019 — Business continuity management systems: Requirements ISO 22313 — Guidance on the use of ISO 22301 ISO/IEC 27031 — ICT readiness for business continuity NIST SP 800-34 Rev 1 — Contingency Planning Guide for Federal Information Systems FFIEC IT Examination Handbook — Business Continuity Management booklet AICPA Trust Services Criteria — Availability (A1.2 and A1.3) DORA, Regulation (EU) 2022/2554 — Articles 11 and 12 HIPAA Security Rule — 45 CFR 164.308(a)(7), contingency plan NYDFS 23 NYCRR Part 500 — Section 500.16 FINRA Rule 4370 — Business Continuity Plans and Emergency Contact Information
What it covers
What Business continuity & DR readiness covers.
- Business impact analysis of critical processes, systems, people and suppliers
- Recovery time and recovery point objectives agreed with business owners
- Disruption scenarios: cyberattack, cloud or region outage, facility loss, supplier failure and loss of key staff
- Continuity strategies for people, premises, technology, information and suppliers
- Disaster recovery plans for cloud workloads, SaaS platforms and on-premises systems
- Backup architecture: immutability, isolation, encryption and separate administrative credentials
- Restore testing and evidence that restores meet your recovery objectives
- Ransomware recovery: isolated rebuild, identity recovery and deciding what is safe to reconnect
- Crisis management team structure, activation criteria and command roles
- Crisis communications for staff, customers, regulators and media
- Third-party and concentration risk, including cloud provider and critical SaaS dependencies
- Plan exercises: tabletop discussions, walkthroughs, and technical failover and restore tests
- Plan ownership, review cadence and the changes that trigger an update
- Mapping to ISO 22301, SOC 2 Availability, DORA, FFIEC and HIPAA contingency requirements
What you receive
What you have in hand when readiness is done.
Business impact analysis
Your critical processes ranked by the impact of their disruption, with dependencies on systems, people, locations and suppliers, and recovery objectives the business has agreed to.
Business continuity plan
How each critical function keeps running or resumes during a disruption: alternate ways of working, staffing, manual workarounds and who has the authority to activate the plan.
Disaster recovery plans
Technical recovery runbooks for your cloud, SaaS and on-premises systems, in the restoration order the business impact analysis sets, with hidden dependencies such as identity and DNS called out.
Ransomware recovery plan
How you would rebuild when production and possibly backup administration are compromised: isolated recovery, credential resets, clean restoration and the decision points for reconnecting systems.
Backup and restore assessment
A review of whether your backups are immutable, isolated from production credentials and actually restorable to your objectives, with the gaps ranked by risk.
Crisis management plan
The crisis team, activation criteria, command structure, communication channels and message templates for staff, customers and regulators.
Exercise program and after-action reports
Facilitated exercises of the plans, from tabletop discussions to restore tests, with reports on what worked and what to fix — the evidence auditors and examiners ask for.
Framework mapping
How your program lines up with ISO 22301, SOC 2 Availability, DORA, FFIEC and HIPAA expectations, so a single program answers several reviewers.
Common gaps
What a Business continuity & DR readiness review tends to surface.
Better found now, by people on your side, than by your assessor.
Recovery objectives set by IT alone and never agreed with the business owners who live with them
Backups reachable with the same administrator credentials an attacker would steal
Backups that run on schedule but have never been fully restored and measured against the RTO
Recovery plans that assume the identity provider, DNS or the backup console will be available
No plan for losing a critical SaaS provider or an entire cloud region
Continuity plans written for a single office in a company that now works largely remotely
Exercises that are scheduled but never happen, or happen without a written record
Supplier and outsourced-IT dependencies missing from the business impact analysis
Where testing fits
The tests Business continuity & DR calls for, from the same team.
Cloud configuration review
A cloud configuration review checks backup vaults, immutability and object-lock settings, cross-account isolation and the permissions that could let an attacker delete your recovery copies.
What the test coversInternal network pentest
An internal penetration test shows whether an attacker who lands on a workstation can reach backup servers, hypervisors and domain controllers — the systems your recovery depends on.
What the test coversRed team engagement
A red team engagement can make your backup and recovery infrastructure an objective, testing whether your detection notices an attacker going after your ability to recover.
What the test covers Questions
What buyers ask about Business continuity & DR.
What is the difference between business continuity and disaster recovery?
Business continuity covers the whole organization: how critical work continues or resumes when people, premises, suppliers or systems are unavailable. Disaster recovery is the technology part: restoring systems and data. A DR plan without a continuity plan restores servers in an order nobody agreed to; a continuity plan without DR has no route back to normal operations.
Who sets our RTO and RPO?
Your business owners, informed by the business impact analysis. IT can tell you what recovery currently achieves and what faster recovery would cost; the business decides what it can tolerate. Readiness work brings those two views together and records the objectives, so they can be tested and so the commitments in your customer contracts match reality.
Do we need ISO 22301 certification?
Usually not. Most US customers and auditors want to see a tested plan, and SOC 2 Availability or a customer’s vendor review is satisfied by that evidence. ISO 22301 certification makes sense when a customer or regulator asks for it, or when you want an independent, recognized benchmark. If you pursue it, an accredited certification body you choose audits you, and the readiness work is your preparation for that audit.
Isn’t disaster recovery our cloud provider’s job?
Only their part of it. Under the shared responsibility model, your provider keeps its infrastructure running, but your configurations, data, backups, identities and architecture choices — single region or several, whether backups sit in a separate account — are yours. A provider outage or an attacker deleting your resources is still your recovery problem.
How does ransomware change our plan?
A traditional DR plan assumes you fail over to a clean copy. Ransomware assumes the attacker may have been in your environment for some time, may control administrator accounts and may have targeted your backups. Your plan needs immutable or isolated backups, a way to rebuild identity first, criteria for deciding what is clean, and tight coordination with your incident response plan.
What counts as testing the plan?
Testing ranges from a tabletop walkthrough of decisions, to restoring a system and checking its data, to a full failover of a critical service. Auditors and examiners look for tests that match your stated objectives, a written record of results, and evidence that what you learned was fixed. Restoring a single file proves very little; restoring a critical application end to end and measuring it against your RTO proves a great deal.
Is Business continuity & DR on your desk?
One conversation with someone who does this work. You leave knowing where you likely stand and what readiness would involve for you.