{Company name as you’d like it to appear in your policy:6} Data Security Policy

Last Updated: {date_today:9}

Created By: {user_displayname:10}

Backup and Retention Policy

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.