Business Continuity · Business impact analysis, continuity planning and DR software

Business continuity: what you cannot be without, the plan to carry on, and exercises that prove it

Work out what your organization cannot be without, and for how long; write the plan to carry on, with the team and who calls whom; and show, with assessments and evidence, that what is critical would come back in time.

Start free See pricing

Included in Small business, Mid business, Large business, Dedicated Hosting

What Business Continuity does

A method you configure

  • Your own impact criteria — financial, operational, legal and regulatory, reputation, customers, health and safety to start — each saying what every level means for it
  • Your own time frames, scale, and the level at which an impact is intolerable
  • Tiers of maximum tolerable downtime, each mapped to the criticality it gives a process and an application
  • Started from the AI Pazz method and yours to change; a cycle already open keeps the method it opened with

BIA cycles

  • A cycle for the processes you pick, for your own unit, for several units, or for the whole catalogue — the yearly round or one process looked at today
  • One BIA per process, service or capability, given to its owner: impact over time, the RTO and RPO it sets, the applications and providers it needs, and its workaround
  • The maximum tolerable downtime and the tier worked out from the answers, never typed
  • Submitted when complete and approved by someone other than the person who submitted it; each analysis read against the last

Recovery targets for your technology

  • The RTO, RPO and MTD required of every application derived from the processes that need it — and of every cloud and hardware provider from the applications that run on it
  • Every figure names the process that set it
  • Applied to the inventory after a preview of every change — replacing a criticality set by hand with the one the analysis gives
  • What each application and provider can do, stated beside what is required, and the gap between them, worst first

Assurance: assessments, DR plans and evidence

  • A continuity checklist for applications, for cloud providers and for hardware providers — is there a plan, has a restore been tested, what has the vendor committed to — started from AI Pazz's and yours to change
  • Each critical application and provider assessed against it: answered with evidence as a link or a file, scored, and reviewed by someone other than the assessor; a gap raised as an issue in Issue & Remediation
  • DR plans with the strategy, what must be up first, and a runbook whose steps add up against the recovery time required
  • The evidence each plan asks for — a restore test, a failover test, the vendor's SOC report — with an owner and a frequency: submitted, accepted or returned by a second person, and flagged when due or overdue

Plans, teams and call trees

  • Continuity plans for the organization or for particular departments: when it is activated and by whom, what is done in each phase, and the processes it covers shown with their tolerable downtime and recovery times from the BIA
  • Approved by someone other than whoever submitted it, and kept as a numbered version that never changes; a plan changed since, or whose BIA figures have moved, says so
  • A team from your own list of roles — crisis leader, department recovery lead and the rest — allocated to people of your organization, licensed or not, with alternates; what is missing is flagged, and one view shows the allocation across every plan
  • A call tree of who calls whom with primary and alternate numbers, held as personal data on the plan
  • The plan pack: the plan, its team and its call tree as one PDF, for the day the systems are down

Scenarios and exercises

  • Scenarios as what they take away — a cloud region, a supplier, a site, a department's people — each showing what would stop today, how soon that becomes intolerable, and which plan covers it
  • Walkthroughs and tabletops judged objective by objective
  • Crisis simulations from a prepared inject timeline: each inject released in order as it runs, with the response recorded — planned beside actual
  • Call tree tests of a plan's tree as it stood: who was reached, on which number, after how long
  • DR tests that record how long recovery actually took and what was lost against what is required — and become each system's tested capability
  • Reviewed by someone other than the facilitator; whatever fell short raised as an issue in Issue & Remediation

Kept in view

  • A dashboard of the cycles in progress, the catalogue by tier, the most time-critical processes and the recovery gaps
  • BIAs to complete and to review in each person's My Tasks
  • Its own module roles: an owner completes their own BIA, Module Managers run cycles and review, the Module Admin sets the method and applies results
  • Optional maker-checker approval on the acts that matter — opening or closing a BIA cycle, leaving a BIA out, applying BIA results, changing the BIA method or a checklist, retiring or deleting a plan — on the module's own Approvals page

Business Continuity: questions and answers

What is a business impact analysis (BIA)?
A business impact analysis asks, for each process or service, how bad it would be if it stopped — after four hours, a day, a week — across the kinds of impact that matter to the organization. From the answers come the maximum tolerable downtime (MTD), and the recovery time and recovery point objectives (RTO and RPO) the process sets.
How are RTO, RPO and MTD worked out for applications?
Each BIA names the applications and providers the process needs. An application's required RTO, RPO and MTD are the shortest among the processes that need it, and a provider's the shortest among the applications that run on it. Every figure names the process that set it.
Can we use our own impact criteria and time frames?
Yes. The criteria, what each level means for each, the scale, the time frames, the level that counts as intolerable and the tiers are all settings. You start from the AI Pazz method and change it; a cycle already open keeps the method it opened with.
How do we show a DR plan would actually work?
Each DR plan lists the evidence it asks for — a restore test, a failover test, the vendor's assurance report — with who submits it and how often. The owner submits a file or a link dated to when it was done; a second person accepts or returns it; and it shows as due or overdue when its time comes round again.
Can people without a login be on the continuity team?
Yes. Team roles and the call tree are filled from the organization's people, which lists everyone whether or not they hold a licence. They are reached by the printed plan pack; only members of the module see the phone numbers in the product.
How does a DR test change what the product says a system can do?
A DR test records, for each application or provider, how long recovery actually took and how much data was lost. When the test is completed those figures become the system's tested capability, which outranks anything merely stated. Recovery then shows it as meeting its target, or missing it and by how much.
Does it cover continuity plans, DR plans and exercises?
Yes. A continuity plan has its sections, the processes it covers with their recovery times, a team with alternates and a call tree; it is approved by a second person, kept version by version and printed as a PDF pack. A DR plan has its strategy, a runbook measured against the recovery time required, and evidence submitted on a schedule. Exercises — walkthroughs, tabletops, crisis simulations, call tree tests and DR tests — are planned, run and reviewed, and a plan says when it was last exercised.
Which plans include Business Continuity?
Small business and above — the plans that include Process and Technology Governance, whose catalogue and inventory it analyses.

Works with

Small business and up

Process governance, application inventory and IT contract management software

Process and Technology Governance

Govern what the organization does and what it runs on: its processes, services and capabilities — each with an owner, SOPs, KPIs and a review cycle — and its applications and providers — the cloud and hardware they depend on, with their contracts and licences.

  • What the organization does, placed under the unit that does it — capabilities holding the processes that deliver them, and the services it provides
  • SOPs inside each process and service — the procedure written out, with its forms and documents uploaded or linked, and its own review date
  • Applications, cloud providers and hardware providers in one list, told apart by category — each with the company behind it, its criticality and its status
More about Process and Technology Governance
Small business and up

Risk management software

Risk Tracking

Risk registers at every level of the organization: score risks, treat them, evidence their closure, and raise the ones the board should see.

  • As many registers as your organization needs, each run by its own administrator
  • Risks at organization, unit or individual level, each with an owner
  • Optional approval before a risk closes — by the register’s administrator or someone you name
More about Risk Tracking
Small business and up

Organization structure, committee and site management software

Organization

Model the organization: its units, who leads each and who they report to, its people and their reporting lines, its committees and its sites — used by every module to track, assign and report by unit.

  • Units of every kind — CEO office, division, business unit, department, team, function — nested in whatever order your organization really runs
  • Everyone in the organization, licensed or not, with their email and primary unit
  • Offices, plants, warehouses and other places the organization works from, each with its country and the unit it belongs to
More about Organization

Every module