Business Continuity application
Early access

Business continuity you can show, not just describe

Record your critical business services, set recovery objectives through a versioned business impact analysis, find the dependencies that cannot recover in time, and keep plans and exercises tied to each service.

Request early access

Inside Business Continuity

Objectives set in the BIA, checked against dependencies

RTO
Recovery time objective
RPO
Recovery point objective
MTPD
Maximum tolerable period of disruption
MBCO
Minimum business continuity objective

Example of a flagged conflict

The service needs to be back within 4 hours, but a supporting application can only be restored in 8. The BIA cannot be approved until the conflict is resolved with an owner and a written decision.

Approved BIAs and plans are locked; changes start a new version.

Available in the application today

What Business Continuity does today

Business Continuity is in early access. Everything on this list works in the application now.

Business services

The services your organization has to keep running, and who owns them.
  • Name, reference, owner, status and criticality tier, with an optional rationale
  • Link a service to the AI systems it relies on from AI Governance
  • One page per service with its objectives, BIA versions, dependencies, plans and exercises

Business impact analysis

A versioned BIA that sets recovery objectives with reasons.
  • Impact ratings from 1 to 5 for financial, operational, legal and regulatory, reputational and customer impact
  • Rated over 0–4 hours, 4–24 hours, 1–3 days and 3–7 days, with a note per cell
  • Derived RTO and MTPD and a suggested RPO; you confirm RTO, RPO, MTPD and MBCO with a rationale
  • Submit for review and approval by an admin who did not submit it (a workspace's only admin can approve their own, recorded as self-approved); approved versions are locked

Dependencies and conflict detection

See where what the service needs and what its dependencies can deliver do not match.
  • Dependencies on applications and IT, third parties, sites, people and roles, and other services
  • Each dependency's recovery time and recovery point compared with the service's objectives
  • Conflicts flagged on the service, the BIA and the dashboard; resolving one needs an owner and a decision
  • Unresolved conflicts or unknown capabilities block BIA approval

Continuity plans

Plans written against each service, versioned like the BIA.
  • Strategy, activation criteria and ordered recovery steps with owners and target times
  • Primary and alternate contacts, and a review date (one year after approval if not set)
  • Draft and approved versions; a revision stays a draft while the approved version stays in force

Exercises and actions

Test the plans and follow up on what you learn.
  • Tabletop, simulation or live exercises against a specific plan version
  • Scenario, objectives, participants and an outcome: achieved, partially achieved or not achieved
  • Issues and follow-up actions with owners and due dates

Continuity dashboard

Where the programme stands, in one view.
  • Services by criticality and BIA coverage
  • Open dependency conflicts and plans due for review
  • Upcoming exercises and overdue actions
  • A start-here guide for a new workspace; every change written to the audit log
Part of the suite

Works on its own, better with the other applications

Business Continuity runs in the same Starkguard workspace as AI Governance and IT Audit. You can use it alone; when you use more than one application, they share the core below.

How the shared core works

Today

  • Same workspace, members and roles as AI Governance and IT Audit
  • Business services can link to AI systems registered in AI Governance
  • Changes are written to the same organization audit log

Next
On the roadmap

  • Dependencies picked from one shared inventory, so an application or third party is recorded once
  • Exercise actions in one issues & actions list with audit findings and AI remediation
  • BIA reviews, plan approvals and actions in each person's My Work queue
Standards context

Built with the standards your reviewers use

Services, impact analysis, recovery objectives, plans and exercises follow the structure business continuity teams already use. The standards below are the ones continuity teams in the GCC and EU most often work against.

  • ISO 22301
  • NCEMA 7000 (UAE)
  • SAMA Business Continuity Management Framework

These standards are reference points for how the application is structured. Using Starkguard does not by itself make an organization compliant or certified; that depends on your own programme and, where relevant, an independent assessment.

On the roadmap

What comes next for Business Continuity

Not available yet. Listed so you can see where the application is going; order and scope may change.

  • BCM programme and policy

    Programme scope, policy and a configurable impact methodology.

  • BIA campaigns and import

    Running BIAs across many services at once, and importing existing BIA data.

  • Continuity risk and strategy

    Continuity risk assessment, concentration risk across dependencies, and recovery strategy selection.

  • Exercise programme

    A planned exercise calendar across services, with coverage tracking.

  • Incident activation

    Activating a plan during a real disruption and recording what happened.

  • Reports and exports

    Role-based dashboards, management review packs and exports.

Know your critical services and show you can recover them.

Talk to us about Business Continuity for your organization in KSA, the UAE or the EU.

Request early access