Backup makes copies of data, records, configuration and software so that none of them is lost or left unusable and restore returns them when required, supporting disaster recovery; it is distinct from archiving and is not used as an archive. Procedures set out how backup and restoration work, covering management of failures, technologies and services are chosen on business need with scheduling consistent with the recovery point objective, procedures and technologies are verified, storage is separated from the primary location with geographical separation by risk considering natural hazards, and contracts or service level agreements exist with providers who are assessed on a documented risk basis. The process or data owner decides on external providers and their assessment, monitors agreements, defines recovery point and recovery time objectives, backup scope and retention; the system or service owner ensures technologies meet those needs, verifies operation and performance and manages failures; and a documented risk assessment, usually with disaster recovery planning, informs the strategy. Strategies include replication to the cloud, backup to the cloud, cloud backup services and cloud-to-cloud backup, backup appliances, and portable media used per manufacturer recommendations with service life, storage conditions and periodic integrity verification considered, held in a separate secure location safe from fire, flood and other hazards with storage standards and access defined. Procedures address backup and restoration instructions, approval responsibilities for restoration, identification and labelling, approach whether full, differential or incremental, technologies, scope, frequency against the recovery point objective, separation, monitoring and failure management and periodic integrity verification, and for automated backups may reduce to how new requirements are added to the schedule. Backup and restoration are tested at validation and after technology changes, scheduled backups are monitored with logs retained as evidence and persistent failures handled through incident and problem management, integrity is periodically verified at a frequency by risk, retention and approach without restoring to production, and backup testing may be combined with disaster recovery testing. Software and configuration are backed up before changes for back-out, after changes for recovery and periodically to capture routine patches and updates, development environments and source code are backed up with version identification, data backups include metadata and GxP audit trails, and the backup solution's own metadata is itself backed up.
This control maps to 1 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 1 it maps to, and the evidence behind each claim, over MCP and REST.