If you’re responsible for managing backups in an organization, then you might have been asked to author a backup policy (but been unsure about what exactly it entails). A backup policy is a formal document setting out the high-level governance of backups within an organization. It takes its place among other high-level corporate documents and commonly receives input from functions outside of IT including the compliance and legal teams.
Although several departments may maintain their own backup documentation, the backup policy is the overarching document responsible for setting down standards and best practices for backup within an organization. Think of it as the definitive word as to which backup practices will be followed. There might be other backup policies within a company (we’ll get to those later) but the backup policy is the one that sets down the score.
Table of Contents
What Is A Backup Policy?
A backup policy is a formal document that sets down guidelines for how backups should be handled within a company. The document could set down procedures, responsible parties, and specify related documentation (we’ll review the contents of the typical backup policy later in the article).
A formal backup policy differs from other documents in the organization which might describe themselves as backup policies. These could, for instance, be the backup or disaster recovery (DR) plans which certain parts of the business — like the marketing or sales teams — have prepared.
While these policies might pertain to specific technical systems, only the formal backup policy is the overarching document that is responsible for setting company-wide backup direction. Backup policies have strict structures and may require input from HR and legal teams, among other stakeholders.
Further reading Creating Resilient Backup Policies: A Step-by-Step Guide
Formal Backup Policy
As an official corporate document, the backup policy will tend to follow a tried and tested formula. Some of the fields that should be included are:
Statement
The statement component of the backup policy will state the key information about the backup policy such as the document’s formal title, how it should be referred to internally, what date it was prepared on, and who was responsible for authoring it.
Purpose
The purpose section will typically state what the backup policy is meant to achieve. It might say, for instance, that the policy is intended to standardize backup procedures across the organization.
Scope
If your organization is large enough to be authoring a backup policy, then the backup policy should also probably clearly delineate its scope. The backup policy might spell out exactly which employees (or departments) and assets fall under the governance of this backup policy. It’s always better to be clear than ambiguous. So if there’s any room for doubt about whether the backup policy will apply to a certain team, it’s better to state it in the document.
Related Documentation
If your IT team has a formal Backup Manager, then he or she may be charged with periodically reviewing and updating all the existing backup documentation in an organization. For that reason, it’s worth including a list of all the other backup-related documents within the company. If the backup policy is going to be a digital file (or hosted in a knowledge management system like Confluence) then you could either embed the other documents or link off to them here.
The related documentation, specifically, could map out:
- Other documentation relating to procedures and workflows
- Disaster recovery plans within the organization
This index section can be periodically updated as companies’ libraries of internal backup documentation continue to expand and evolve.
Further reading Guide to MSP Internal Documentation: Principles and Practices
Responsibility
To maximize the effectiveness of disaster recovery (DR) efforts, the backup policy should also clearly outline areas of responsibility for an organization’s approach to backup. For instance, the document should lay out which team member is responsible for backing up and restoring which systems. Many organizations choose to specify a job function (title) rather than an individual in case people leave the company.
When You Need A Formal Backup Policy
Certain companies are likely to be able to manage just fine without a formal backup policy. However, there are circumstances in which authoring this kind of document is essential.
Such companies include:
- Companies that need to manage sensitive data that falls under standards or legislation. For instance, healthcare companies need to manage patient data, like electronic medical records (EMRs) in accordance with the standards set down in the HIPAA legislation. Companies in this space may be subject to governmental audits. In many instances, they are also obliged to have a formal policy backup in place documenting how backup data is managed. In other instances achieving compliance with a data governance standard may require that a backup policy be documented and maintained.
- Besides healthcare, this requirement may affect companies operating in the financial services and legal spheres, among others.
- Large organizations might also require backup policies because these companies are more likely to appoint a dedicated person, or team, for managing backup. Backing up multiple systems typically involves more complexity. A formal backup policy is very useful in these cases to set down standards for the workflows of many delegated backup administrators.
Further reading Guide to Backup Management for MSPs
Other Backup Policies
In addition to a formal backup policy, other backup documentation can sometimes be called “backup policy”. If you are tasked with creating a “backup policy”, but you clearly understand that it’s not a formal document, you should better ask about the exact nature of the needed document. Here are some popular examples:
Disaster Recovery Plan
The disaster recovery (DR) plan typically consists of detailed documentation outlining exactly what steps the business will have to take in order to restore from any of a number of disasters. The DR plan will typically set out detailed instructions for restoring key mission-critical business functionalities and also stipulate a personal responsibility for executing each task in the plan.
DR plans are vital and often the first pieces of documentation that those involved in continuity go looking for when something goes wrong. But they don’t set down the same overarching standards as a backup policy typically does.
Further reading Building a Cloud Disaster Recovery Plan: Tips and Approaches
Backup Retention Policy
The backup retention policy specifies the time periods for which backups need to be retained in the organization. This particular policy can be informed by the regulatory policies that the company has to comply with.
Further reading Backup Retention Policy and Scheduling Best Practices
RTO / RPO Considerations
The recovery time objective (RTO) and recovery point objective (RPO) specify the maximum amount of time that can elapse from a declaration of a disaster through to the restoration of services and the maximum amount of data that can be lost in the restore process respectively. Sometimes companies will create a separate backup policy document setting out the RPO and RTO targets for every business system with mission-critical tools (like CRMs and ERPs) typically having more ambitious objectives than less essential IT services
Further reading Recovery Time (RTO) and Recovery Point (RPO) in DR Strategy
Backup and Recovery Frameworks
Finally, any document(s) that have to do with the overall backup and disaster recovery process might tend to be referred to as “policies” — even if they merely contain information or were intended as reference documents. Examples of this kind of document might be:
- An inventory of all current systems
- A contact directory of all staff responsible for backup or an organizational chart of the backup decision-makers
Best Practices For Creating A Backup Policy
All backup policies are not created equal and some IT teams do a better job of creating them than others. If you’re been charged with preparing one for your department or workgroup then you should draft it with the following best practices in mind.
- Understand the purpose: Remember that the backup policy is intended to set down the overall direction for how your organization is to run backups and DR. Take an inventory of existing backup “policies” including the ones we referred to in the previous section. Draft a document that sets down guidelines that these policies meet. After all, the document you’re about to create should be the central source of knowledge that will inform the creation of future derivative documents.
- Fill the gaps: If, on the other hand, your organization doesn’t have any backup documentation, then see this as your chance to begin creating it. You might wish to begin thinking about what credible target RTOs / RPOs might look like for the various systems and data repositories you’ll want to be backing up.
- Clear language: Backup policies don’t tend to make good bedside reading. Bear in mind that people are likely going to be skimming your document in order to access the required information. Therefore adhere to a clear structure. Use headings and subheadings to highlight information logically. Use easy to understand language.
- Reviewed by legal department or lawyer: Because backup policies often touch up on data governance, they may raise compliance issues — particularly for organizations that are bound by certain statutes. If this is the case, then make sure that your policy has received all the appropriate internal sign-offs, including from your law officer or legal department.
Further reading The Importance of Legal Services to MSPs Explained - Tested: All backups should go through test restore processes. The policy should be a living document that reflects actual backup workflows. If a policy isn’t feasible — or it can’t be tested — then it shouldn’t be documented.
Further reading How to Test Your Backups: A Comprehensive Guide - Regularly updated: Don’t forget to include a field for periodic updates so that the document can be kept updated and readers can see when it was last revised. It’s especially important to include this field if your corporate governance dictates that all policy documents need to be revised and updated at fixed intervals.
A Strong Policy Governs Good Backups
Managing backup and DR in the enterprise environment is a complex process and the person entrusted to lead it is responsible for maintaining the integrity of data across multiple business systems.
To ensure continuity and operational efficiency, a central backup policy should be documented and periodically revised. This is the central document that can serve to set down agreed best practices and RTO/RPO for all staff members involved in the backup.
Those drafting the document should remember that the document should be considered the first source of backup knowledge in the company. It should supersede and agree with other existing “backup policies” in the company, which may in fact simply be frameworks. The document should have a nominated custodian and be periodically updated with a clear revision date update (and sometimes a changelog) after every edit.
Simple. Reliable.
