{Company name as you’d like it to appear in your policy:6} Backup and Retention Policy
Last Updated: {date_today:9}
Created By: {user_displayname:10}
One very important aspect of security is the proper backup and retention of data, so it is available when we need it. This policy sets forth requirements for identifying, backing up, and retaining data for as long as needed.
Key Takeaways
- The manager/owner responsible for a system is required to identify what type of data their system is handling.
- The manager/owner must implement a data backup schedule appropriate to the type(s) of data identified.
- Data retention and destruction procedures must be followed to ensure data is retained as long as required, and destroyed promptly once that period is over.
Overview, Purpose, and Scope
Effective security is a team effort, which means everybody at {Company name as you’d like it to appear in your policy:6} has a crucial role to play. One very important aspect of security is the proper backup and retention of data, so it is available when we need it. This policy sets forth requirements for identifying, backing up, and retaining data for as long as needed.
This Backup & Retention Policy applies to all data generated, collected, and processed by {Company name as you’d like it to appear in your policy:6}.
Roles & Responsibilities
All systems in use at {Company name as you’d like it to appear in your policy:6} must have adequate backup & recovery and record retention procedures. Data owners and system owners are responsible for identifying the type(s) of data their systems generate, process, collect, or store. Once identified, appropriate backup and recovery measures should be designed, and an appropriate record retention/destruction schedule chosen.
{Company name as you’d like it to appear in your policy:6} management reviews and approves this policy, but if you identify an issue you should bring it to the attention of your manager.
Requirements – Backup
Identification of Data
The owner or responsible manager of a system must identify and document the type(s) of data and their uses in the system, as well as relevant attributes of such data. This documentation must include:
- What’s being done with the data (e.g. is it processed, stored, collected, and/or generated)?
- Is the system the System of Record for this data (i.e. does it reside elsewhere and is merely copied to the system, or does it live only in this system)?
- Is this data critical to {Company name as you’d like it to appear in your policy:6}’s mission?
- Does this data impact {Company name as you’d like it to appear in your policy:6}’s ability to deliver critical services?
- How often does the data change? Examples include:
- Continuously, such as transaction-based, real time data collected from users, etc.
- Daily, such as account balance information, daily reconciliation
- Less often, such as reference information pulled from external sources
Critical Dependencies and Resiliency
When backup and recovery functions, the data owner or responsible manager must identify any critical dependencies both upstream and downstream from their system. These are defined as:
- Upstream: This system can not be recovered until another system has first been recovered (e.g. most applications won’t work until the identity and access management system, such as Google Authentication or Active Directory, has been restored).
- Downstream: Another application, system, or business process relies on this system in order to function, and is therefore blocked from recovery until this system is back online (e.g. online storefronts can not be recovered until payment processing systems are up and running).
Such dependencies must be documented and understood when planning backup and recovery. Some systems may be so critical to {Company name as you’d like it to appear in your policy:6} that they require a resiliency approach rather than recovery. In such cases, the system must be designed to withstand partial or total failure with no interruptions. This may drive design decisions such as High Availability, Active/Active, or other architectures which can shift processing capabilities with no interruption should one component fail.
Backup Frequency and Recovery Adequacy
An appropriate frequency for data backups should be selected based on the attributes identified during data identification. {Company name as you’d like it to appear in your policy:6}’s acceptable backup schedules are described in the table below; one of these options must be selected for all systems in use at {Company name as you’d like it to appear in your policy:6}.
| Frequency | Description
System Example |
Appropriate For | Recovery Supported |
| Mirrored System / Near Real Time (NRT) | Data is copied in real time or in frequent batches, and the system supports processing from multiple locations with no intervention
Example: Systems are duplicated across multiple cloud regions and any one region can handle all traffic if needed. |
Systems which are critical to {Company name as you’d like it to appear in your policy:6} and which block the company if they are down
Highly important systems which could be a blocker if they are down for any length of time |
Mirrored: Instantaneous; little to no lag in processing and no data loss.
NRT: Minor downtime with some data loss |
| Scheduled | Data is copied on a regular schedule (every day/week/ month)
Processing may exist in multiple locations, but requires restoration actions (e.g. restoring data) Example: System exists in one cloud region, with backups stored separately. Recovery involves standing up the application in an alternate region and copying the data to the backup app. |
Systems which are not critical and can be down for a set period of time without impacting {Company name as you’d like it to appear in your policy:6}’s mission | Significant downtime and significant data loss |
| No Backup | Data is not backed up; if the primary system fails there is no way to recover the data.
Example: a copy of all US Postal Codes, which can easily be copied from an official US Government data store, does not need a backup. |
Nonessential systems which are not critical and can be restored at leisure. | Indefinite downtime and total data loss |
Restoration Procedures and Testing
To ensure {Company name as you’d like it to appear in your policy:6} can recover data in the event of an incident, restoration procedures and testing are required. The system/data owner is responsible for ensuring the following requirements are met:
| Backup Method | Documentation Required | Testing Required | |
| Mirrored System / Near Real Time (NRT) | System architecture detailing how data copy/mirroring is implemented, e.g. distributed DB
Procedures or architecture for switching from primary to secondary processing, e.g. distributed load balancing or a manual DNS update |
If the system supports real time, automatic distributed processing, this capability must be tested as part of system testing/QA.
If manual intervention is required, such procedures must be tested at least annually. |
|
| Scheduled | The schedule and type of backup, e.g. weekly full backup, daily incremental with weekly full, etc.
Procedures for restoring data in the event of a primary site failure, e.g. shipping backup tapes/drives, connecting cloud storage to an alternate region, etc. |
Automated integrity checks as part of the backup process, and a test of restoration capability at least annually. | |
| No Backup | Business case for why data is not being backed up, e.g. data is easily recreated or of extremely low value (such as internal social network/chat logs) | None.
Any system deemed not worth backing up should be reviewed during routine risk assessment activities to verify assumptions made. If assumptions are no longer valid, the business case for no backups should be revisited and revised if necessary. |
|
Requirements – Data Retention
Regardless of the classification of data and backup schedule chosen, {Company name as you’d like it to appear in your policy:6} is required to retain certain types of data for a specified period of time. This facilitates accurate operations, regulatory compliance, and legal/investigatory requirements we may face.
The table below defines retention periods for various types of data which may be in use at {Company name as you’d like it to appear in your policy:6}. Each data type has a defined period for retention, after which it must be destroyed using an approved method.
| Data Type | Description | Retention period required |
| Legal Hold Data | Any data which is relevant to ongoing legal action, such as a lawsuit, subpoena, regulatory investigation, etc. | Indefinite. Once the legal action is resolved, the data may be deleted in accordance with its type from this table. |
| Company Data | 1) Any data which does not fall into a category below
2) Personnel records |
1) {How often would you like to ethically remove data is not specifically specified in the document?:15}
2) Indefinitely while an employee is active; after that seven (7) years |
| PCI | 1) Unencrypted cardholder data (e.g. PAN, transaction code, etc.)
2) Encrypted cardholder data |
1) Delete as soon as possible once transaction is completed
2) Follow standard retention schedule |
| PHI | Data related to a person’s healthcare, including diagnoses, payment for medical services, and medical history | Six (6) years |
| PII | Any information which can be used to uniquely identify an individual, such as Social Security Number, full name, birthdate, etc. | Seven (7) years |
Requirements – Data Destruction
Routine Review
If automated destruction is not possible, procedures must exist for the routine review of datasets to determine if any data has exceeded its retention period. The frequency of these reviews shall be determined by the sensitivity of the data; however they shall occur at least annually.
Destruction Procedures
Once data has reached the defined end of its retention period, it should be destroyed using a senior-management approved method. For guidance, refer to NIST Special Publication 800-88, Guidelines for Media Sanitization.
Enforcement
Any exceptions to this policy must be approved by senior management in writing.
Any user found to have violated this policy will be subject to disciplinary actions, up to and including termination of employment.