Business continuity

Continuity management, listed as Continuity (BCM) in the Cybersecurity group of the sidebar, is the oversight register for your business continuity program. It tracks the plans your institution maintains and approves, the business impact analyses that justify their recovery objectives, and the exercises that prove those plans are tested on cadence. It is a second-line tracking surface. Plan authoring and recovery execution live elsewhere, and Zovos does not run a failover. The same sidebar group also holds the Cybersecurity page and the Security incidents register, described in Cybersecurity.

The screen is headed Continuity management, and it has five tabs: Coverage, Continuity plans, Business impact analyses, Exercise log and Notification linkage.

Continuity plans

Each plan carries a display ID, a type, an owner, the processes it covers, and a lifecycle that runs draft, awaiting approval, in force, and retired. The types are enterprise BCP, IT disaster recovery, pandemic, department, and other. A plan is only in force once it has been approved, so a draft that never reached the committee cannot quietly count as coverage.

Every plan commits to a recovery time objective and a recovery point objective. Those say how quickly the process must be back and how much data loss is tolerable. These are your institution's own commitments recorded against your own processes.

Business impact analyses

A business impact analysis records what a process actually requires: the required recovery time objective, the required recovery point objective, and the maximum tolerable downtime. It is the justification behind the plan's commitment rather than a restatement of it.

Keeping the two separate is what makes the next part possible. Because the requirement and the commitment are recorded independently, Zovos can compare them and surface recovery-objective conflicts, where a plan commits to less than its own business impact analysis says the process needs. That mismatch is one of the most common findings in a continuity examination, and it is usually invisible when both numbers live in the same document.

Exercises

The exercise log records each test. An entry holds the plan under test, its type, the date it was conducted, a written summary, and its result of pass, partial or fail. The type is tabletop, walkthrough, functional, or full interruption.

An exercise does two things beyond recording itself. First, it moves the cadence clock on the plan it tested, so the coverage grade updates from the test rather than from a calendar entry. The anchor only ever moves forward, so filing a back-dated exercise cannot rewind a plan's clock or make it look freshly tested. Second, a fail or a partial can be promoted with Open a finding, which takes an optional note for the finding. A failed exercise opens at high severity and a partial at medium, and whoever promotes it can override that. A failed test that produced no follow-up is exactly the pattern an examiner looks for.

Notification linkage

The fifth tab states a boundary out loud. Zovos sends no emergency alerts and holds no contact roster. Your mass-notification platform does that, and it should stay the only system that does. What Zovos does is emit a signed event when a plan goes into force and when an exercise is recorded, so that platform stays in step with the plan register instead of drifting away from it.

The tab reads whether each of those events is wired or not wired, which endpoints are registered and which of them are actually live, how many live subscribers each event has, and when each event last delivered. A paused endpoint is shown but does not count as wired, and an event that has never fired makes no claim about delivery at all. Endpoints themselves are registered under Settings, on the Webhooks panel of Integrations.

The coverage grade

The coverage tab is where the program is read at a glance. Every process with an active business impact analysis is graded, critical processes first, into one of six states. They are covered, covered but with a test due soon, test overdue, never tested, plan not in force, and no plan at all.

The headline shows how many of your critical processes are covered, and how many processes of any criticality are not.

Those last three states are the point of the screen. A process with a beautifully written plan that has never been exercised is not covered, and a process with a plan still sitting in draft is not covered either. Grading them separately means the gap has a name, and the report to the board or the examiner distinguishes between missing documentation and untested documentation.

Notes and limits

This is oversight rather than orchestration. Zovos does not author continuity plans, run recovery procedures, monitor infrastructure, or execute a failover. It records what your plans commit to, what your analyses require, what your exercises found, and where those three disagree.

The recovery objectives on this screen are your institution's, recorded by your team about your own processes. They are not statements about Zovos as a service. For our own posture, see Security.

Plan approval and exercise-driven findings run through the shared machinery. See Approvals & delegation of authority and Findings & remediation. Continuity plans collected from vendors as part of due diligence are tracked separately in Third-party risk & partner programs.