ServiceNow Business Continuity Management Best Practices

Business continuity management is the discipline of deciding how fast each critical function must recover after a disruption, and proving that the plan can meet that target. The page covers recovery targets, runbooks, exercises, backups and activation rights, and the review habits that keep them current.

Prioritize Business Functions and Define Recovery Targets Explicitly

Every business function matters, but not every function needs to recover in the same timeframe. A payment processing system must recover in hours; a training portal can wait days. Define Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for each critical business function. RTO is how long you can afford to be down before financial or operational impact becomes severe. RPO is how much data loss you can tolerate. A customer-facing service might have a four-hour RTO and zero-data-loss RPO, meaning you need an active backup that is synchronized in real time. An internal reporting system might have a 24-hour RTO and accept loss of a few hours of data, allowing you to use simpler backup methods. These definitions drive your disaster recovery infrastructure investments. If your definitions are vague or never formally documented, you will invest poorly: either over-building expensive redundancy for non-critical functions or under-protecting critical ones.

Document Recovery Procedures and Assign Clear Responsibilities

When a disaster occurs, you need runbooks that specify exact recovery steps: which servers to restore first, in what order, how to validate that services are working, and who to notify. Assign a recovery lead for each critical business function so there is no ambiguity about who makes decisions during recovery. Document dependencies: a payment system cannot function without the customer database, so the database must be recovered first. Build decision trees for common scenarios: if the primary data center becomes unavailable, do we immediately fail over to the backup data center, or do we first investigate whether the outage is temporary? Having these decisions documented and approved ahead of time prevents confusion and delays during an actual incident. Update recovery procedures annually or whenever your infrastructure or business processes change significantly.

Test Recovery Plans Regularly and Document Results

An untested recovery plan is often a plan that will not work when you need it. Schedule regular disaster recovery drills: quarterly full recovery tests for critical systems, semi-annual tests for less critical systems. Full tests involve actually initiating failover to your backup environment and confirming that business functions operate normally. Do not just test technical recovery; test the human aspects: can your team follow the runbook, can they make decisions, can they communicate with stakeholders during an incident? Document test results including how long recovery took, what went wrong, and what you improved. Use test results to refine procedures and to build organizational knowledge about what recovery actually requires. A team that has practiced recovery is far more effective than a team that has never tested.

Coordinate Incident Response Across Technical and Business Functions

Business continuity requires more than technical failover. When a disaster occurs, you need to communicate with customers, adjust service offerings if recovery is partial, coordinate with key vendors, and document impact for auditors or insurance purposes. Define roles for your incident response team: technical lead, communications lead, customer support lead, executive sponsor. Include decision authorities so that someone can quickly decide whether to initiate failover or whether to attempt repair first. Establish a communication escalation path so that executives are notified at the appropriate time and level of detail. Different stakeholders need different information: technical teams need troubleshooting details while executives need impact and timeline. Build message templates so your communications team can respond quickly without waiting for details.

Plan Backups and Replication to Match Your Recovery Targets

Your backup strategy must align with your RTO and RPO. If you can tolerate 24 hours of data loss and 48 hours of downtime, nightly tape backups to an offsite location might be sufficient. If you need zero data loss and four-hour recovery, you need real-time replication to a backup data center. Document what you are backing up, where backups are stored, how often they are refreshed, and how long recovery takes. Test restoration from backup regularly; backups that cannot be restored quickly are worthless. For critical databases, implement continuous replication to a standby server in another location so that failover is automatic if the primary fails. For less critical systems, periodic backups may be sufficient. The key is ensuring your backup strategy actually delivers your target RTO and RPO, not just hoping it will.

Maintain and Exercise Your Supply Chain During a Disruption

Some disruptions affect your vendors and partners as well as your own infrastructure: a data center outage might affect cloud services hosted at that facility, a shipping disruption might affect hardware delivery, or a supplier bankruptcy might require finding replacement vendors. For critical vendors and suppliers, understand their disaster recovery capabilities and how you will get service if they are disrupted. Maintain alternative suppliers for critical goods so you are not dependent on a single source. During a disaster recovery test, include a communications check with key vendors to verify you can reach them and that they can support your recovery. Build this coordination into your recovery procedures so that when an actual disaster occurs, you have already established relationships and know how to work with backup suppliers.

Write recovery targets that someone is prepared to fund and test

A target written as “critical systems recover quickly” cannot be tested, and nobody can be held to it. A usable target names the process, the maximum tolerable interruption and the maximum tolerable loss of data, and it names the person who accepted those numbers. The reason to insist on the named approver is practical. When a test misses the target, the conversation about funding, redundancy or a relaxed objective needs someone with the authority to make the trade-off. Without that person, the miss is logged and nothing changes.

Review the targets against the cost of meeting them. A target that requires a standby site for a process that only runs one shift a week is often a target nobody will fund, and an unfunded target gets quietly reset the first time it is tested. Agree the realistic version at the start and keep the rationale beside the figure. A changed target should follow the approval route in the governance model.

Write procedures for the person who is not in the room

Recovery procedures tend to be written by the person who knows the system best, and that person is often the one least likely to be available during an incident. The test of a procedure is whether a competent engineer who has never touched the system can follow it at night with a partial view of what has failed. Steps should name the account to use, the location of the credentials, the expected output of each command and the decision point where the operator should stop and escalate. Missing any of those is often where recoveries stall.

Where a step depends on one individual’s memory, record it as a dependency and schedule a second person to perform it in the next exercise. Cross-training is slower than documentation, but documentation that nobody else can execute does not reduce the risk.

Design exercises that are able to fail

An exercise that always passes is measuring the script, not the recovery capability. Build in conditions that a real event would impose: the primary contact is unreachable, one backup is a day older than expected, or the designated recovery engineer is on leave. The goal is to find the gap while there is still time to fix it. A result with several findings and a clear list of owners is a successful exercise, even though it looks worse on paper than a clean run.

Keep activation rights with named people

In many programs the question of who may invoke recovery is answered with a job title, and job titles are not reliably present at two in the morning. Name the person and the deputy, state the conditions under which each may act, and state what they must do before acting, such as informing the business owner. Record the decision and its timestamp in the activation log so that the post-incident review can reconstruct what was known at each moment. For the deputy and the escalation chain, check the roles and RACI guide first.

Make backups prove that they restore

A backup job reporting success tells you that data was copied. It says nothing about whether the copy can be turned back into a working system within the target. Schedule restores into a separate environment, time them from start to a verified working state, and compare the elapsed time with the recovery target. Restores often take longer than the backup window suggests, because of account lockouts, license activation or the order in which dependent services must come up. Restore timings are worth carrying into the continuity KPI guide so they can be compared across reviews.

Practices worth retiring

Some common habits feel diligent but add little. An annual signature on a plan that nobody has read, a tabletop session without any system actions, and a dashboard that shows green because the test schedule is current rather than because recovery worked are all examples. Replace them with the evidence each practice is supposed to produce. The platform health check article takes a related evidence-first view of readiness.

A quarterly review sequence

1. Confirm that each critical process still has a named owner and deputy, and that both are still employed in those roles.
2. Check each recovery target against the current cost of meeting it, and record any decision to change it.
3. Pick one procedure at random and have a second operator carry it out from the written text.
4. Restore one backup into a separate environment and record the elapsed time against the target.
5. Review open exercise findings, confirm each has an owner and a date, and escalate any that are overdue.

Frequently asked questions about continuity best practice

How many processes should we cover before the first exercise?

Cover the processes whose failure would hurt most, and keep the first exercise to what the team can run and learn from. A wide plan that has never been exercised is less useful than a narrow plan that has been tested twice.

What if a business owner refuses to accept a target?

Record the refusal and the business owner’s reasons, then escalate to the sponsor. The decision to leave a target unagreed is itself a risk decision and should be visible in the governance record, rather than hidden in a plan that appears complete.

Should exercises be announced in advance?

Announce the window, not the scenario. Participants should know when an exercise will happen so that the right people are available, but they should not know the injected faults in advance, because that is the only way to see how the team handles surprise.

How do we keep a tested procedure from going stale?

Tie each procedure to the change record of the systems it depends on. When a dependency changes, the procedure goes back into review before the change is closed, rather than waiting for the annual cycle to notice.

Next step

Pull the signed plans for your two most important processes and compare each recovery step with the last time someone performed it for real.