Creating a ServiceNow Disaster Recovery Plan

For users of ServiceNow, the importance of creating a ServiceNow disaster recovery plan should not be overlooked.

The platform is critical to the way many organizations operate, and significant downtime and disruption will likely have serious consequences, felt around the enterprise. 

Various limitations to ServiceNow’s in-built backup capabilities mean the solution does not meet every organization’s disaster recovery requirements. Such organizations requrie a purpose-built backup and restore solution for ServiceNow, like Snapshot.

Learn more about Snapshot and how it lets users take control of their ServiceNow backups.

Table of contents:

1. What is a Disaster Recovery Plan?
2. Why Is it Important to Have a ServiceNow Disaster Recovery Plan?
3. How to Create a ServiceNow Disaster Recovery Plan – A Step-by-step Guide
4. Key Considerations for a ServiceNow Disaster Recovery Plan
5. How Perspectium Supports and Improves ServiceNow Disaster Recovery

What is a Disaster Recovery Plan?

A disaster recovery plan (DRP) is a documented list of actions to be taken after an unplanned incident, in order to resume normal operations as quickly as possible.

Creating a DRP plays a vital role in supporting and improving business continuity. Having a DRP better prepares organizations to promptly resolve data loss and return systems to a functioning state.

Why Is it Important to Have a ServiceNow Disaster Recovery Plan?

No system is immune to disruption, and the risk to business continuity following a data breach, corruption or data loss event in ServiceNow is too significant to leave to chance.

ITSM solutions such as ServiceNow support too many business critical functions for organizations to comfortably manage extended downtime.

A ServiceNow disaster recovery plan is essential in supporting and improving:

• Data protection. ServiceNow disaster recovery planning mitigates the risk of loss, exposure and/or corruption of sensitive and critical data generated by and/or stored in the platform.
• Business continuity. A ServiceNow disaster recovery plan is essential for ensuring the business critical solution can recover from incidents quickly, so that ServiceNow-reliant operations can continue with minimal disruption.
• Customer trust. A robust ServiceNow disaster recovery plan helps organizations avoid scandal and mitigate the reputational damage that comes with serious data loss, corruption or exposure incidents.
• Regulatory compliance. ServiceNow disaster recovery planning supports organizations in meeting their legal and regulatory obligations related to data created by and stored in the platform.
• Emergency response. Disaster recovery planning informs an organization’s immediate response to unplanned incidents, helping to mitigate the negative effects experienced by the organization, its employees and its customers.

Related post: Disaster Recovery for ServiceNow Users

How to Create a ServiceNow Disaster Recovery Plan – A Step-by-step Guide

Step 1: Evaluate the ServiceNow environment

The foundation of an effective ServiceNow disaster recovery plan starts with an evaluation of the ServiceNow environment. 

Organizations should document the ways in which they use ServiceNow, who would be affected should the platform become unavailable, and the types of data the platform generates and stores. 

Internal and external data retention policies (e.g., ServiceNow’s backup retention policy) that affect data should be consulted and any data requiring additional protection (i.e. sensitive and/or regulated data) should be identified.

External tools and/or systems integrated with ServiceNow should also be evaluated as they are often essential in supporting ServiceNow-reliant operations. 

Step 2: Set recovery goals

With the information gathered in Step 1., organizations should have an understanding of how ServiceNow could be affected by a disaster event. This information should inform the:

• Recovery Point Objective (RPO), which defines the maximum tolerable period of time that can pass between the last backup and a data loss event.
• Recovery Time Objective (RTO), defining the length of time disruption can continue before normal operations resume, without significant repercussions.

These metrics should shape the strategies and resources needed for an effective DRP.

Step 3: Document and formalize the disaster recovery plan

Once the initial evaluation is complete and the RPO/RTO established, the next step is to document and formalize the DRP.

This process should involve key stakeholders for the ServiceNow platform and its data.

The document should define the risk controls that are in place to mitigate the impact of potential disasters. Such controls can be split into three measures:

• Preventive measures. These include policies – such as the frequency of backups – designed to minimize the risk and extent of data loss.
• Detective measures. Systems and processes to monitor, detect and address incidents early to mitigate the fallout.
• Corrective measures: The immediate incident response and data restoration protocols that should be followed to ensure swift recovery.

While the plan should reflect the organization’s existing capabilities, it should also highlight areas for improvement.

For example, while an organization might rely on ServiceNow’s built-in backup solutions, the evaluation phase may reveal the need for a more robust backup strategy to enhance data protection. 

The DRP should bridge this gap, outlining the current state and the desired future state of the organization’s disaster recovery infrastructure.

Step 4: Assign disaster recovery roles and educate 

Effective disaster recovery requires a coordinated response to crises. 

Organizations should identify appropriate stakeholders, and make them responsible for executing the disaster recovery plan. Often, these stakeholders will include those that helped inform the plan outlined in Step 3. 

Once identified, the disaster recovery team should be trained on the contents of the DRP and their particular responsibilities. 

Step 5: Test and revise the DR plan

A disaster recovery plan is not a static document—it must be tested and revised regularly to remain effective. 

Conducting periodic drills for different scenarios – such as human error, natural disaster, and cyberattacks, etc – help the disaster recovery team be prepared when real disasters arise.

After each test/drill, conduct a thorough after-action review to assess what worked, what didn’t, and what needs to improve.

The organization should continue developing disaster recovery capabilities and work toward the desired future state identified in the disaster recovery plan.

Key Considerations for a ServiceNow Disaster Recovery Plan

Types of backups

Data backups are essential to protecting business-critical information and ensuring it remains recoverable in the event of a disaster.

ServiceNow built-in backup and restore capabilities cover two types of backups.

• Full Backups: ServiceNow performs a full backup of the entire platform every seven days, retaining four weekly backups.
• Differential Backups: These backups occur daily and include only recently changed data. ServiceNow keeps a rolling set of six daily differential backups.

Replication frequency

Another aspect to consider is the replication frequency, which determines how often backups occur. For example, if backups are performed every 24 hours, a disaster could result in losing up to a day’s worth of data. 

ServiceNow’s in-built capabilities only support a replication frequency of seven days for full backups with differential backups created every 24 hours.

Many organizations require more flexibility and/or a higher replication frequency than what ServiceNow provides. 

ServiceNow’s backup capabilities (and limitations)

The limitations of ServiceNow’s OOTB backup and restore capabilities will impact many organizations’ disaster recovery plan. 

• Retention limits: ServiceNow retains full backups for 14 days only.
• Differential backup window: Differential backups only include recently changed data. Restoring data outside of this period requires a full instance restore.
• No control over backup scheduling: Users have no control over data backups. ServiceNow only performs full backups every seven days and differential backups every 24 hours.
• Risk of data loss: Since backups are scheduled by ServiceNow, there is a risk of losing “delta” data—data created or modified between backups.
• Full instance restore as a last resort: ServiceNow advises restoring a full instance only as a last resort due to the potential negative impact of the restore process.
• No restores beyond the retention period: ServiceNow does not support restoring instances to points beyond the retention period.
• Access to instance limited during restoration: During the restoration process, the ServiceNow instance is taken offline and access limited.

Related post: ServiceNow Backup and Restore Limitations

How Perspectium Supports and Improves ServiceNow Disaster Recovery

ServiceNow partner Perspectium, provides the backup and recovery application, Snapshot, for supporting disaster recovery. 

The ServiceNow-native application upgrades the in-built backup and recovery capabilities of the platform, enabling:

• Unlimited backup retention and creation
• User scheduled and on-demand backups
• No instance downtime during restoration
• Condition-based filtering for selecting what is backed up and restored
• The ability to manual select what data is backed up and restored

By providing users with more control over their ServiceNow backups and the restoration process, organizations are better equipped to meet their Recovery Point and Recovery Time Objectives.

Request a demo of Snapshot to see it in action.