Interactive BCM tool

BCM Readiness Scorecard

Create a fast, evidence-focused baseline across eight continuity capability domains and turn the weakest areas into a practical improvement backlog.

Rate each domain from 0 to 5

Use 0 when no reliable evidence exists and 5 only when the capability is defined, implemented, exercised, measured and improved. Avoid scoring on intention alone.

Use the scorecard as an evidence conversation, not a vanity score

A maturity percentage is useful only when it changes a decision. Business continuity programs can appear mature because policies exist, templates are complete and responsibilities are written down. During disruption, however, the organization needs demonstrated capability: owners who understand their decisions, recovery strategies that can actually be activated, dependencies that are known, technology that has been restored under realistic conditions, and corrective actions that are closed rather than repeatedly carried forward.

The BCM Readiness Scorecard is designed as a rapid self-assessment before a deeper review. It deliberately uses only eight domains so leadership can see the shape of the program without reading hundreds of controls. Each rating should be defensible with evidence. If a team cannot show the evidence, use the lower score and capture the missing proof as an action. This produces a more useful baseline than awarding high scores because a document exists.

A practical 0–5 evidence scale

Apply the same reasoning across every domain. A score of zero means there is no reliable evidence of the capability. One is ad hoc: individuals may perform useful work, but the organization depends on personal knowledge. Two means some process is defined but implementation is incomplete or inconsistent. Three means the capability is operating across the intended scope. Four means it has been tested or independently checked and is measured. Five should be reserved for a capability that is sustained, uses evidence from exercises or incidents, closes corrective actions and adapts when the organization changes.

This scale prevents a common assessment error: comparing unlike evidence. A polished policy should not receive the same weight as an exercised recovery capability. Likewise, a successful technical failover does not prove that business teams can operate, communicate and manage suppliers. The goal is not to make every domain equal; the goal is to expose where the chain of continuity is weakest.

Domain 1: governance and accountability

Look for an approved continuity policy, defined scope, executive sponsorship, accountable service or process owners, escalation routes, a program calendar and evidence that leadership reviews material gaps. Strong governance connects continuity decisions to real priorities and funding. A weak score is appropriate when the BCM team owns every task while business owners treat continuity as an annual documentation exercise. Evidence can include governance terms of reference, meeting decisions, approved risk acceptance, action ownership and documented exceptions.

Domain 2: business impact analysis

Assess whether the BIA produces decisions that the organization actually uses. Useful evidence includes impact criteria, time-based impact analysis, MTPD/MAO, RTO and RPO where appropriate, minimum resource needs, critical dependencies and management approval. Check whether the data is current after organizational change. A BIA should not be scored highly merely because every department completed a questionnaire. The stronger question is whether recovery priorities and strategies can be traced back to credible impact information.

Domains 3 and 4: strategy, plans and procedures

Recovery strategy turns the BIA requirement into a capability. Review alternate working arrangements, manual workarounds, staffing strategies, technology recovery, supplier alternatives, records access and facilities options. Then test whether plans convert those capabilities into executable actions. A plan should make it easier to decide what to do during disruption, not force the user to read policy language while the incident is active. Look for activation criteria, priorities, roles, contact methods, dependencies, decision points, recovery tasks and return-to-normal steps.

Domain 5: ICT and disaster recovery

Technology readiness should be assessed against business service requirements, not only infrastructure health. Verify that technical recovery objectives align with the consuming business service, that critical applications have mapped dependencies, and that backups or replication support the required RPO. Evidence should include test results, restore times, unresolved failures, capacity assumptions, identity and network dependencies, data validation and operating procedures. Use the Recovery Objective Consistency Checker to identify obvious contradictions before scoring this domain.

Domain 6: suppliers and external dependencies

A supplier list is not a continuity capability. Strong evidence shows which suppliers are critical to which services, how quickly substitution is possible, what continuity commitments are contractually meaningful, which sub-tier or geographic concentrations exist, and what recovery evidence has been reviewed. The organization should know when a supplier disruption becomes its own continuity incident and who has authority to invoke alternatives. The Supplier Continuity Risk Tool can help prioritize where evidence and substitution planning deserve the most attention.

Domains 7 and 8: people, exercises, assurance and improvement

Continuity depends on people understanding their role under pressure. Training should therefore be role-based: executives need decision practice, coordinators need activation and information-management practice, technical teams need recovery procedures, and general staff need awareness of notification and alternate-working expectations. Exercises then test the integrated capability. Use scenarios that force decisions and expose dependencies rather than only confirming that participants can read the plan.

The final part of maturity is whether findings change the system. Track exercise actions, incident lessons, audit findings, overdue plan reviews and changes in services or suppliers. A program that repeatedly identifies the same weakness should not be scored as “tested and measured” simply because many exercises were conducted. Closure evidence matters.

How to turn the result into an improvement backlog

  1. Take the three lowest domains. Do not start by polishing already-strong areas because they are easier to improve.
  2. Write the evidence gap. State what proof is missing: approved objective, mapped dependency, tested procedure, supplier evidence or closed action.
  3. Connect the gap to a business service. Prioritize weaknesses that can prevent recovery of the most important services.
  4. Name one accountable owner and a decision date. Avoid generic actions assigned to “BCM” when another function controls the capability.
  5. Re-score only after evidence changes. Completing a meeting or drafting a document is not automatically a maturity increase.
Suggested review rhythm: use the scorecard for quarterly or major-change health checks, then perform a deeper control-based assessment for domains that remain weak or materially affect critical services.

Example: a program with good documentation but weak assurance

Consider an organization that scores governance 4, BIA 4, strategy 3, plans 4, technology 3, suppliers 2, people 3 and exercises 1. The overall percentage may look respectable, but the shape of the result shows a specific risk: the organization has designed continuity arrangements without enough evidence that integrated recovery works. The improvement plan should not begin with another policy rewrite. It should focus on supplier dependencies and an exercise program that tests business, technology and supplier recovery together.

After the exercise, the team should update plans only where the evidence requires change, assign corrective actions and repeat the relevant test. That feedback loop is more valuable than pursuing a higher score for its own sake.

Related BCM.Center guidance

Use the BCM maturity model for a deeper review method, the exercise and drill guide to design validation activities, and the BCM metrics guide to monitor whether improvement actions are producing measurable change.

Frequently asked questions

Is an 80% score equivalent to certification?

No. The bands are planning labels used by this tool. Certification or formal conformity assessment requires the applicable criteria, scope, evidence and independent process. Do not present this self-assessment as a certification result.

Should every domain reach five?

Not necessarily. The appropriate target depends on business criticality, risk, obligations and the cost of capability. A smaller organization may deliberately use simpler controls while still maintaining effective recovery. The rating should reflect evidence and conscious decisions.

Who should complete the scorecard?

A cross-functional review is stronger than a BCM-only score. Include business service owners and, where relevant, technology, facilities, security, procurement, HR, communications and risk representatives so the evidence is challenged from multiple perspectives.

Other interactive tools