Your auditor will ask to see your BCP. More importantly, they will ask when you last tested it, what the tabletop exercise found, and how ransomware is specifically covered. The plan most SaaS teams have on file answers the first question and none of the others. Here is what cyber-resilient business continuity looks like and how to build a version your auditor cannot pick apart.
Why traditional BCPs fail cyber-specific audits
Traditional BCPs were designed for physical disasters — data centre floods, hardware failures, power outages. Cyber incidents behave differently. They can be silent for weeks before discovery, spread laterally into backup infrastructure, and require forensic preservation before any restoration can begin.
Auditors reviewing your BCP against ISO 27001, SOC 2, or NIST CSF increasingly look for explicit cyber recovery procedures. A generic failover runbook — or a plan that describes what to do when the building floods — will raise flags in a security audit because it does not address the threat category most likely to trigger an invocation.
NIST SP 800-34 — the federal contingency planning guide — defines a structured hierarchy: Business Impact Analysis, Information System Contingency Plan, Business Continuity Plan, and Disaster Recovery Plan. Most SaaS teams produce one combined document and call it all three. Conflating them creates visible gaps that auditors familiar with the framework will find immediately [source: https://codific.com/nist-800-34-contingency-planning-a-practical-guide-to-resilience/].
The four documents your contingency program needs
NIST SP 800-34 is explicit about the distinct role of each document [source: https://medium.com/@tahirbalarabe2/business-continuity-planning-bcp-implementing-nist-sp-800-34-contingency-planning-cb29fedb0b8a]:
- Business Impact Analysis (BIA): Maps each system to a business function, assigns Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs), and quantifies the cost of downtime. Without a BIA, your RTOs are guesses.
- Information System Contingency Plan (ISCP): The technical runbook for recovering each critical information system. Engineering owns this.
- Business Continuity Plan (BCP): The business process layer — how operations continue while the technical layer is being restored. Operations owns this.
- Disaster Recovery Plan (DRP): The plan for restoring primary operations once the incident is resolved. The DRP merges both layers.
What the BIA must include for cyber scenarios
Most BIAs cover physical disruptions but leave cyber scenarios vague or absent. Add these explicitly:
- Ransomware encrypting the production database: What is the maximum tolerable downtime, and does your RTO account for the time needed to verify backup integrity before restoring?
- Credential compromise of an admin account: Which downstream systems are at risk, and what is the isolation sequence?
- Supply chain compromise via a SaaS dependency: What is the blast radius, and what is your fallback if the vendor is unavailable for 48 hours?
Three gaps most BCPs miss
Backup integrity validation
Ransomware frequently targets backup repositories alongside production systems. Your BCP should name the person responsible for verifying backup integrity before invoking recovery procedures, the verification method, and the expected verification time. An auditor will ask for evidence of your last backup restoration test — not a checkbox confirming backups ran, but a test log showing the date, systems restored, time taken, and outcome. If you cannot produce that log, the backup is theoretical.
Forensic preservation before restoration
Restoring a compromised system before capturing forensic artefacts destroys evidence needed for root cause analysis and potential legal proceedings. Your BCP needs an explicit, sequenced step: isolate the affected system, capture a forensic image, then restore. This ordering is not optional and is routinely absent from generic templates downloaded from compliance portals. It is a common finding in post-incident reviews and in audits that follow an incident.
Third-party dependency recovery
SaaS teams depend on dozens of external services: identity providers, cloud infrastructure, monitoring tools, communication platforms. Your BCP should list critical SaaS dependencies with their published RTOs from SLAs and your fallback procedures if a dependency is unavailable. Auditors reviewing vendor risk programmes will cross-reference this list against your vendor inventory and access reviews. If those do not align, it surfaces a control gap.
Testing that satisfies auditors
A plan that has never been tested is a document, not a plan.
NIST SP 800-34 defines three test levels that progress in fidelity [source: https://compassmsp.com/resources/nist-framework-guide]:
- Tabletop exercise: A structured walkthrough with key stakeholders. Tests comprehension and communication, not technical execution. Fast to run, low disruption.
- Functional exercise: Partial activation — for example, spinning up the disaster recovery environment and verifying system connectivity — without declaring an actual incident.
- Full test: Complete failover to backup operations, confirmed against BIA success criteria for each critical system.
Your test report should contain: the date and scenario tested, participants present, steps completed and any that failed, gaps identified, and a remediation owner with a target close date for each gap. Gaps found during testing are not a liability. Auditors are not looking for a perfect BCP. They are looking for a process that surfaces and closes gaps systematically over time.
Getting from current state to audit-ready
The fastest path is not writing a 40-page document from scratch. It is triaging what you already have and closing the most visible gaps.
Start with the BIA. Without it, you cannot write credible RTOs, scope the ISCP accurately, or prioritise which systems need cyber-specific procedures added. The BIA is the foundation every other document rests on.
Separate the documents. The ISCP belongs with the engineering team. The BCP belongs with operations. The DRP combines both layers. Keeping them separate makes ownership and maintenance unambiguous — single documents with no named owner are rarely maintained.
Add cyber scenarios explicitly. For each critical system in the ISCP, add ransomware and insider threat scenarios with specific recovery steps and named responders. Generic procedure language is not enough.
Run a tabletop before the audit window opens. A 90-minute session with engineering, legal, and leadership will surface more actionable gaps than months of document review. Close what you find, document what you closed.
Close the backup loop. Pick one critical system and run a full restoration test. Record the steps, the time taken, and any failures. That test log is audit-ready evidence. Three pages of backup policy are not.
NIST CSF's Recover function, ISO 27001 Annex A.17, and SOC 2's Availability trust service criterion converge on the same requirement: you know your RTOs, you have tested your recovery procedures, and you track gap remediation. Get those three things demonstrable and the audit conversation becomes a process review rather than a gap-finding exercise.
BCP gaps surface at the worst moment — mid-incident or mid-audit. CloudAnzen maps your operational procedures to ISO 27001, SOC 2, and NIST CSF controls, flagging business continuity gaps before the auditor does. Talk to us.