ServiceNow Business Continuity Management Governance Model

Decision Forums and Authorities

Business Continuity Management decisions fall into categories that require different authorities. Strategic decisions (whether to maintain continuity for a business function, target recovery time and cost) are made by business leaders and approved by executives. Tactical decisions (whether specific mitigations are adequate, whether recovery procedures are documented) are made by process owners and business continuity coordinators. Operational decisions (executing recovery procedures during an incident) are made by incident commanders and team leads.

Establish explicit forums for each level. A strategic Business Continuity Committee meets quarterly to review top risks, approve changes to recovery strategies and make resource decisions. A tactical working group meets monthly to review procedures, update test schedules and coordinate with other teams. An operational crisis management team activates only during actual incidents to coordinate response.

Document who sits on each forum, what decisions each forum makes and what approval authority each requires. A decision to change target recovery time for a critical system requires executive approval. A decision to update documentation does not. Clarity on authorities prevents decisions from languishing or proceeding without necessary approvals.

Standards and Policies

Define standards that all business continuity plans must meet. Standards might include: recovery time objectives must be documented and justified, recovery procedures must be tested at least annually, cross-team dependencies must be identified and documented, and recovery sites must be validated to ensure they can actually host workloads. When a team develops a continuity plan, it must satisfy these standards or be rejected.

Document policies on acceptable risk. Some organizations accept that non-critical systems may remain down for extended periods. Others require recovery for all systems within hours. Make this explicit. If business continuity policy states critical systems must recover within 4 hours but a team’s plan has 24-hour recovery, the plan does not meet policy and must be revised.

Include policies on testing and maintenance. Plan documents must be current; a plan that has not been updated recently is not trusted. Testing must validate recovery procedures work; a test run that finds major problems is successful (it found issues before a real incident). Policies enforce this discipline.

Change Control for Configuration

Business continuity configuration (recovery objectives, hot standby systems, failover procedures) is critical infrastructure. Changes must be controlled. When a team updates recovery time objectives, document why. When infrastructure is changed (a system is moved to a new data center), update recovery procedures. When staff leaves and new people take on recovery roles, train them and document the transition.

Implement a change review process: proposed changes are evaluated for impact on recovery capability. A change that reduces recovery site capacity must be mitigated (more investment elsewhere or accepting lower recovery targets). A change to dependencies must be incorporated into recovery procedures. Establish a change control board that reviews these decisions quarterly.

Track configuration baselines. The “official” version of your recovery procedures, system dependencies and recovery sites is the source of truth. When someone asks “where is this documented,” there is one answer not multiple conflicting sources.

Ownership and Accountability

Every business continuity plan must have a plan owner who is accountable for its accuracy and testing. A plan with no clear owner is not maintained. Plan owners report status to the Business Continuity Committee. If testing is overdue, the plan owner explains why and commits to a test date. If procedures are out of date, the plan owner documents what changed and updates the procedures.

Recovery procedures must have procedure owners. A procedure for recovering the billing system has an owner accountable for testing it regularly and updating it when systems change. When that person leaves the organization, ownership transfers explicitly. Do not assume the new team member knows they own it.

Executives are accountable for resourcing continuity efforts. This means funding testing, maintaining recovery sites or contracts, and allowing teams time to update procedures. Build this into organizational review cycles so it does not get overlooked.

Review Cycle and Cadence

Business continuity plans must be reviewed and refreshed regularly. Establish a yearly review cycle: each plan is reviewed once per year at minimum. During reviews, verify that dependencies are still accurate, recovery sites still exist, procedures are still valid and contact information is current. If significant changes were made to systems during the year, additional review may be needed.

Testing is part of the review cycle. At least one exercise per year should run through recovery procedures to validate they work. Some organizations do quarterly exercises. The frequency depends on risk tolerance and change rate.

Incident reviews are also part of governance. After any incident that required recovery activation, conduct a review: what worked, what failed, what do we need to change? This learning loop ensures procedures improve after each test.

Roles and Responsibilities Summary

Business Continuity Committee: approves strategy, reviews top risks, allocates resources. Business Continuity Coordinator: maintains plans, schedules testing, coordinates updates. Plan Owners: keep plans current, ensure testing happens. Procedure Owners: maintain specific recovery procedures. Process Owners: inform continuity planning of process changes. Operations Teams: execute recovery procedures during incidents.

Escalation and Governance Integration

Business continuity decisions integrate with other governance: information security, risk management and change management. A new security control may affect recovery procedures. A risk that exceeds continuity targets requires executive decision. A system change needs coordination with continuity planning. Establish links between these governance structures so decisions are not siloed.

Route every policy exception through a written decision record

Continuity programs often fail less from a missing policy than from unrecorded exceptions. A team cannot meet part of the policy, and the exception is handled by a conversation in a corridor. Six months later no one can say who agreed the exception, what it covered or whether it still applies. A decision record fixes that. Each exception gets an entry that states the policy clause, the affected process, the reason it cannot be met, the compensating control, the approver and the date the exception must be reviewed. The record lives with the plan it modifies, so an auditor or a new coordinator can see the exception without asking anyone.

The record should be short. Two or three sentences per field are enough. The discipline is in filling every field every time, including the compensating control, because an exception with no compensating control is simply a gap that has been given a name. Exercise evidence for each compensating control is worth cross-referencing with the best practices guide.

Waivers need an expiry date and a named approver

A waiver that never expires often becomes the standard. Give each exception a review date that is tied to a real event, such as the scheduled replacement of the system or the next exercise, and not a loose calendar year. When the review date arrives, the approver must choose one of three outcomes: close the exception because the plan now complies, renew it with a fresh reason, or escalate it to the executive who owns the risk. Renewal without a new reason should not be allowed, because it turns a temporary compromise into an unexamined habit. For who should own that renewal decision, the risk management accountability article is the relevant read.

Decide who decides, and what each decision needs as evidence

Different continuity decisions carry different weight, and the governance model should say so explicitly. The table sets out the decision type, the person who decides, the evidence that should accompany the decision and the event that should trigger a fresh look.

What to do when a plan owner leaves during a review cycle

1. Identify every plan, procedure and exception where the departing person is named as owner or approver.
2. Assign an interim owner in writing before the departure date, and record the handover in the decision log.
3. Ask the interim owner to confirm each procedure step-by-step against the current system, not against the old document.
4. Re-approve any exception that relied on the departing person’s judgment, since the reason may no longer be understood.
5. Schedule the new owner’s first exercise within the cycle so the handover is tested, not only signed.

Ownership transfers that happen only through an email often do not survive the next reorganization. The transfer is complete when the new owner has performed one piece of the work. Once the transfer is made, confirm it against the roles and RACI guide.

Keep the decision log useful after an incident

After any activation, the decision log becomes the most valuable record in the program. It shows which exceptions were in force, who approved them and whether they affected the outcome. Review the log in the post-incident session, and close or renew each exception that the incident touched. Teams often skip this step because the incident feels resolved, but an exception that contributed to a slow recovery is exactly the one that will recur if nobody revisits it. The platform governance charter article covers how decision rights are set out, which is closely related to a log like this.

Frequently asked questions about continuity governance

How is an exception different from a risk acceptance?

An exception means the plan does not meet a policy requirement and a compensating control is in place. A risk acceptance means the organization is knowingly carrying an exposure that is not fully controlled. Many exceptions should be recorded as risk acceptances too, because the policy gap is itself a risk the sponsor must see.

Who should sit on the decision forum for exceptions?

The forum needs the program sponsor, the continuity lead and at least one business owner whose processes are affected. Including the infrastructure owner helps when the exception depends on technical capacity that the business owner cannot judge.

Can a single decision cover several processes?

It can, but the record should list each process separately. A shared decision with a combined impact statement hides the cases where one process carries most of the consequence.

How do we stop exceptions piling up?

Count them each cycle and treat the count as a governance measure. A rising count often means the policy is unrealistic for the current systems or the program lacks the capacity to meet it. Either conclusion is worth raising with the sponsor.

Next step

A decision record is only as useful as the habit of filling it in.