Backup and Disaster Recovery for GxP Systems

Computerized Systems • Data Integrity • Business Continuity

Backup and Disaster Recovery for GxP Systems: A Practical GMP Guide

A dependable backup is only the starting point. Pharmaceutical companies also need a tested, risk-based way to restore regulated records and critical systems, keep essential operations controlled during an outage, and prove that recovered data remain complete, readable, and trustworthy.

Guide for pharma quality, IT, engineering and system owners Includes RTO/RPO, restore tests and audit checklist

Quick answer

Backup and disaster recovery for GxP systems means protecting regulated data and system components, then proving through documented restore tests that they can be recovered accurately within approved business recovery targets. A complete program links a risk assessment, backup schedule, secure storage, validated restoration, business continuity procedures, and periodic review. GMP regulations do not set one universal backup interval or recovery-time target for every system; companies should justify those controls from system criticality, data risk, record-retention needs, and operational impact.

Key takeaway: A successful backup job is not proof of recoverability. The evidence is a controlled restore that shows the required records, metadata, audit trails, configuration and application functions are accessible and accurate.

In this guide

1. What backup and disaster recovery mean
2. Why GxP systems need recovery controls
3. Regulatory expectations
4. Backup, DR, continuity and archiving
5. Risk assessment and system tiers
6. RTO and RPO
7. What to protect
8. Backup architecture and security
9. How to build the program
10. Restore testing and acceptance
11. Disaster response and recovery
12. Cloud and supplier responsibilities
13. Documentation and records
14. Audit-ready checklist
15. Common gaps
16. FAQs

What are backup and disaster recovery for GxP systems?

A backup is a protected copy of information or system components that can be used to recover from loss, corruption, or an operational failure. Disaster recovery (DR) is the organized process for restoring systems, infrastructure, and services after a significant disruption. In a GxP environment, both must support the integrity, availability, and continued use of records that affect product quality, patient safety, or regulatory decisions.

Examples of GxP systems include laboratory information management systems (LIMS), manufacturing execution systems (MES), electronic batch records, quality management systems, chromatography data systems, environmental monitoring platforms, ERP modules used for regulated activities, and infrastructure that stores or controls their data. The required safeguards depend on each system's intended use and its effect on regulated decisions. These controls should align with the organization’s Computerized System Validation lifecycle and its cGMP quality system.

Recovery is not simply restarting a server. The company must know what to restore, in what order, from which trusted copy, how to verify it, and how to document decisions while normal services are unavailable.

Why is GxP backup and disaster recovery important?

A prolonged outage or unrecoverable data loss can interrupt manufacturing, testing, batch disposition, deviation investigations, stability programs, or product traceability. A recovery process that restores incomplete or altered records can create a second problem: the system may run, but regulated decisions may no longer be supported by trustworthy evidence.

Protect patient and product decisions

Preserve the records needed to assess process performance, laboratory results, release status, complaints, and quality events.

Limit operational downtime

Restore the most critical systems in a planned order, with approved manual or alternate procedures where appropriate.

Support data integrity

Maintain complete records and associated context, including metadata and audit trails when relevant to reconstruct the activity.

Demonstrate control

Show inspectors that recovery arrangements are defined, assigned, tested, reviewed, and improved when gaps are found.

Good recovery planning is part of maintaining a validated state. Significant restoration, infrastructure changes, or changes to backup tools may require documented impact assessment and testing under the site's change-control process.

What do GMP regulations expect?

Regulatory requirements are expressed as outcomes rather than as one mandatory backup technology or a single universal schedule. Organizations should interpret the rules that apply to their products, markets, records, and system use, then document a scientifically and operationally justified control strategy.

• EU GMP Annex 11: The published Annex 11 addresses storage of data, protection against damage, and backup. Section 7.2 says regular backups should be made and that backup data integrity and accuracy should be checked during validation and monitored periodically. Section 16 calls for continuity provisions for computerized systems supporting critical processes, including manual or alternative arrangements and an appropriate recovery time.
• US finished-pharmaceutical CGMP: 21 CFR 211.68(b) requires backup files of data entered into computers or related systems, subject to the regulation's stated exception. The regulation also requires backup data to be exact and complete and protected from alteration, inadvertent erasure, or loss. Related record-retention and access obligations still apply.
• Data integrity: A risk-based control strategy should protect records across their lifecycle. Backups support recoverability, but they do not replace access controls, audit trails, record review, retention, or validation.

Annex 11 does not specify a single backup frequency, restore-test interval, RTO, or RPO that fits every computerized system. The site should define and justify these parameters based on risk, the system’s criticality, transaction volume, business impact, record requirements, and recovery capability. Avoid turning a company practice or industry convention into a claim that it is a universal legal number.

For inspection readiness, connect the recovery controls to the broader 21 CFR requirements and documented procedures. Ensure electronic evidence is governed by appropriate ALCOA+ data integrity principles.

Backup vs. disaster recovery vs. business continuity vs. archiving

These terms are related but not interchangeable. A resilient GxP program defines how each one works and which procedure or plan owns it.

Control	Main purpose	Typical scope	What it does not prove by itself
Backup	Recover copies of data or system components after loss or corruption	Database backups, file backups, configuration exports, transaction logs	That a complete application can be restored or that business can continue
Disaster recovery	Restore a system or service after a major outage	Infrastructure, applications, databases, interfaces, identity services and runbooks	That the restored records meet all long-term retention needs
Business continuity	Keep critical operations controlled during disruption	People, decisions, alternate processes, facilities and communications	That the original system or data have been recovered
Archive	Retain records for the required period and retrieve them in readable form	Final records, metadata, audit trails and retrieval context	That current operations can be restored quickly from the archive

Backups usually support operational recovery and may be rotated or superseded. Archives are designed for retention and retrieval over the applicable record lifecycle. A backup copy does not automatically satisfy an archiving obligation, and a long-term archive is not necessarily suitable for rapid system recovery.

How to assess GxP system recovery risk

Begin with a documented inventory of computerized systems and their dependencies. Then evaluate what could happen if a system, record set, interface, or service became unavailable, corrupted, or compromised. Involve Quality, IT, system owners, business process owners, engineering or manufacturing, laboratory representatives, and cybersecurity as applicable.

Factors to include in the assessment

• Impact on patient safety, product quality, release decisions, or validated process control.
• Critical records created, modified, reviewed, approved, or retained by the system.
• Maximum acceptable period without the system and maximum acceptable data loss.
• System architecture, single points of failure, interfaces, identity services, network dependencies, and vendor-hosted components.
• Data volume, update frequency, transaction throughput, and likelihood of unsynchronized data.
• Ransomware, malicious deletion, administrator error, hardware failure, utility loss, site disruption, and cloud-region outage scenarios.
• Availability of an approved manual or alternate process and the time needed to reconcile records when service returns.
• Applicable record-retention periods, retrieval expectations, and ability to read records without the original production environment.

Use the assessment to assign recovery tiers and control depth. A system that supports batch release or real-time manufacturing controls may need a different recovery sequence from a reference-only application. Risk ranking should be revisited when intended use, system configuration, architecture, data flows, supplier arrangements, or business impact changes.

RTO and RPO: setting useful recovery targets

Recovery Time Objective (RTO) is the target time within which a system or process should be restored after an interruption. Recovery Point Objective (RPO) is the maximum tolerable period of data loss measured backward from the disruption. Both should be derived from a business-impact and GxP risk assessment, approved by the process owner and Quality where regulated records or decisions are affected, and supported by technical capability.

Illustrative system profile	Example recovery discussion	Controls to evaluate
Manufacturing execution or electronic batch record platform	Could an outage stop a batch step or compromise contemporaneous recording?	Recovery sequence, transaction-log protection, controlled alternate recording, reconciliation and QA review
Laboratory data system	Would a recovery gap affect raw data, processing methods, review status, or reportability?	Database and raw-file recovery, audit trail completeness, instrument interfaces and recalculation/review evidence
Quality event management system	Can deviations, investigations, change controls, and approvals be managed safely during downtime?	Read-only or paper contingency, status reconciliation, signature controls and audit trail continuity
Lower-criticality reference platform	Can users safely defer access without affecting a regulated operation?	Retention, availability expectations, restore priority and documented rationale

The values above are prompts, not prescribed targets. Assign actual RTO and RPO values only after evaluating real process constraints, regulatory record needs, technical design, and approved business risk. A target that cannot be achieved should be escalated and addressed through system design, additional controls, or a formal risk decision.

What should a GxP backup protect?

Define the backup scope from the system’s validated intended use and data-flow map. Protecting only the database may leave the organization unable to reconstruct the regulated record or return the system to a usable, controlled state.

Regulated data and context

Raw data, processed results, electronic records, metadata, audit trails, electronic signatures, attachments, approval states and links between records, when applicable.

Application and configuration

Application versions, configuration files, workflows, recipes, methods, templates, report formats, user roles and controlled master data.

Infrastructure dependencies

Operating system and database details, virtual-machine or container definitions, interface services, certificates, network settings, identity components and required keys.

Recovery prerequisites

Licenses, installation media, vendor contacts, build documentation, recovery scripts, encryption-key escrow arrangements and the order of restoration.

Determine whether the backup method preserves record relationships, timestamps, time zones, original values, audit-trail associations, and signature meaning. If a system has special binary formats or vendor-controlled databases, confirm how records can be restored, exported, viewed, and retained independently of the live service.

Do not rely on screenshots or printed summaries as a substitute for required electronic source records where the underlying record, metadata, or audit trail is needed for review or reconstruction. Evaluate exact and complete data requirements with Quality and system owners.

Designing a secure GxP backup architecture

Architecture should address both accidental failure and deliberate attack. A well-designed strategy uses multiple control layers and limits the ability of a compromised production account to delete every recovery copy.

• Separate backup credentials: Restrict backup administration, use named accounts where feasible, and avoid shared credentials or routine production-admin access to backup repositories.
• Segregated storage: Keep at least one recovery copy logically or physically isolated from the production environment. Consider offline or immutable storage where it fits the risk and system design.
• Multiple copies and locations: The familiar 3-2-1 approach (multiple copies, different media, and one off-site copy) can be a useful resilience design pattern. It is a security practice, not a universal GMP mandate; adapt it to validated architecture and risk.
• Encryption and key recovery: Protect data at rest and in transit as appropriate. Ensure encryption keys and certificates can be recovered by authorized personnel under controlled procedures.
• Monitoring and alerting: Record job status, exceptions, capacity, retention execution, repository access, and failed or unusual deletion attempts. Route unresolved failures to accountable owners.
• Malware-aware recovery: Preserve known-good restore points and verify the recovery environment before reconnecting it to production. A clean backup is essential after ransomware or destructive compromise.
• Independent time and identity services: Consider how authentication, directory services, time synchronization, DNS, certificates, and network segmentation affect recovery.
• Controlled retention: Define retention and deletion for backup sets. Ensure expiration does not remove data needed for regulated record retention or open investigations.

A replicated copy is not automatically a safe backup. Replication can copy logical corruption, ransomware encryption, or an erroneous deletion to the secondary site. Retain versioned recovery points and test them.

How to build a backup and disaster recovery program

1. Establish governance. Assign system owner, process owner, IT operations, Quality, cybersecurity, supplier, and recovery decision roles. Define who can approve a restore and who assesses GxP impact.
2. Inventory systems and dependencies. Record system purpose, regulated records, hosting model, interfaces, infrastructure, vendor contacts, support arrangements, and recovery prerequisites.
3. Perform and approve the risk assessment. Rank impact of downtime, data loss, corruption, and recovery failure. Record assumptions, rationale, controls, and residual risks.
4. Set RTO/RPO and recovery order. Define approved, achievable targets for the system and its critical dependencies. Include process continuity arrangements while restoration is underway.
5. Specify backup content and schedule. Document data sets, frequency, method, retention, media or repository, encryption, access, job monitoring, and failure escalation. Align frequency with transaction rate and permitted data-loss window.
6. Document recovery procedures. Include authorized triggers, source selection, restore sequence, technical steps, security checks, data verification, business verification, QA assessment, communication, and exit criteria.
7. Validate the system and recovery process. Confirm intended use and critical functions, verify backup and restoration controls, and ensure test evidence is traceable. Use risk-based testing, including interfaces and record checks.
8. Train assigned personnel. Train operators and responders on the recovery plan, escalation path, downtime records, and manual or alternate procedures.
9. Test, review, and improve. Exercise recovery scenarios, document outcomes and issues, investigate failures, and revise the plan after changes or incidents.

Maintain procedures as controlled SOPs or linked controlled documents. The recovery plan should be practical enough for trained responders to use during pressure, not only during a tabletop review.

Restore testing: procedure and acceptance criteria

A restore test demonstrates that the backup can be used, the recovery steps work, and the recovered data are fit for their intended GxP use. Annex 11 expects backup data integrity and accuracy to be checked during validation and monitored periodically. The testing approach and frequency should be risk based, documented, and reconsidered after material changes to backup or restoration processes.

Recommended restore-test sequence

1. Approve a test protocol, scope, test environment, data set, roles, and pass/fail criteria.
2. Select representative recovery points, including relevant full and incremental/log backups where the architecture uses them.
3. Restore into an isolated or otherwise controlled environment; do not overwrite production to conduct a routine test.
4. Record source backup identifiers, timestamps, software versions, tools, settings, and personnel.
5. Verify checksums or other integrity controls where available, and confirm record counts, file counts, database consistency, and expected relationships.
6. Confirm that key records, metadata, audit trails, attachments, signatures, timestamps, and reports remain readable and associated correctly.
7. Test selected critical workflows and interfaces, including user access, review, approval, retrieval, and relevant reporting.
8. Measure actual restoration time and recovered data point against approved RTO and RPO.
9. Document discrepancies, deviations, impact, root cause, corrective actions, and whether the recovery strategy remains acceptable.
10. Obtain technical, process-owner, and Quality review appropriate to the system’s risk before closing the test.

Practical acceptance statement: “The approved recovery point was restored within the approved recovery objectives; required records and contextual data were complete, accurate, readable, and accessible; critical functions and interfaces met defined criteria; and any discrepancies were assessed and resolved under the quality system.” Tailor this statement to the system rather than copying it without defined evidence.

Successful completion of a backup job checks that data were copied according to the tool’s status. It does not demonstrate that the data can be restored, that a complete application can run, or that regulated records remain interpretable. The restore test should cover the latter outcomes.

What should happen during a GxP system disaster?

Use a controlled incident process that coordinates technical containment with Quality and operational decisions. The urgency of restoring service should never lead responders to overwrite evidence, use an unverified copy, or resume a regulated activity without assessing the system’s state.

1. Declare and classify the incident. Record the time, affected systems, users, sites, and suspected cause. Escalate to the incident lead, system owner, Quality, and security as defined.
2. Protect people, product, and evidence. Apply safe operating controls; isolate compromised components where needed; preserve logs and forensic evidence; prevent further data loss.
3. Activate continuity procedures. Use only approved manual or alternate processes. Control forms and identifiers, capture contemporaneous entries and signatures, and define reconciliation responsibility.
4. Select a known-good recovery point. Confirm its date, integrity status, scope, and relationship to the incident. Do not assume the newest copy is the cleanest.
5. Restore and verify. Follow the approved runbook in a controlled environment. Verify records, configuration, access, interfaces, audit trail availability, and critical workflows.
6. Assess data gaps and product impact. Reconcile transactions from the RPO window and any manual records. Quality determines the impact on testing, manufacturing, investigations, and release decisions.
7. Authorize return to service. Document technical readiness, process-owner confirmation, Quality approval where appropriate, and user communication.
8. Investigate and improve. Record deviations, evaluate root cause, assess recurrence risk, and implement CAPA when warranted.

For operational technology or control systems, coordinate restoration with engineering, process safety, and equipment specialists. Recovery actions must respect safe startup sequences and validated operating conditions; a server being online does not mean a manufacturing control function is ready for use.

Cloud, SaaS and supplier-hosted GxP systems

Outsourcing infrastructure does not transfer the regulated company’s responsibility to understand and control GxP records. For a cloud or SaaS system, define the shared-responsibility boundary in contracts, quality agreements, technical documentation, and the validation strategy.

Assess and document:

• Which party backs up application data, metadata, configuration, audit trails, and attachments.
• Backup frequency, retention, region or location, encryption, access controls, and deletion rules.
• Whether the customer can request or perform a complete restore, and the expected response times.
• How the provider tests recovery and what evidence, summaries, or audit reports are available to the customer.
• How the provider handles incidents, ransomware, service-region failures, data corruption, and recovery-point selection.
• How data can be exported in a readable, usable form during service termination, migration, or vendor failure.
• How changes to hosting, backup tools, subprocessors, or architecture are communicated and assessed.

Provider certifications and audit reports can inform supplier qualification, but they do not by themselves prove that the customer’s specific GxP data and intended use are recoverable. Link supplier controls to the site’s risk assessment, validation evidence, and ongoing monitoring.

Documentation and records to retain

Keep recovery evidence complete, traceable, and available for review. Documentation should make it possible to understand what was protected, what was restored, whether recovery objectives were met, and how the organization assessed the effect on regulated operations.

• System inventory, data-flow diagrams, criticality classification, dependencies, and approved risk assessments.
• Backup and recovery strategy, schedule, retention rules, architecture, roles, and approved RTO/RPO.
• Backup job monitoring reports, exceptions, investigation records, and evidence of resolution.
• Restore-test protocols, raw results, screenshots or machine-generated evidence where appropriate, reconciliations, deviations, approvals, and final reports.
• Business continuity forms, use logs, reconciliation records, and approval of return to normal processing.
• Supplier assessments, service-level commitments, quality agreements, provider recovery evidence, and incident notifications.
• Change controls, configuration records, training evidence, periodic reviews, and CAPA records.

Maintain attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, and available evidence in line with the site's data-integrity procedures. For electronic records, review access, retention, audit-trail, and retrieval controls as part of the broader computerized system validation program.

GxP backup and disaster recovery audit checklist

Use this checklist as a starting point for self-inspection. It should be tailored to system scope, applicable regulations, validated intended use, and site procedures.

• Is the system listed in the computerized-system inventory with an accountable owner and documented GxP intended use?
• Does the risk assessment cover service outage, data loss, data corruption, cyberattack, and supplier failure?
• Are regulated data, metadata, audit trails, signatures, attachments, and configuration included where required?
• Are application, database, infrastructure, interface, identity, certificate, license, and encryption-key dependencies identified?
• Are RTO and RPO approved, achievable, and linked to business impact and GxP risk?
• Is backup frequency justified by transaction rate, data criticality, and allowable data-loss window?
• Are backup copies protected against unauthorized access, alteration, inadvertent deletion, and loss?
• Is at least one recovery copy appropriately segregated from production and protected from common cyber threats?
• Are backup jobs monitored and failures escalated, investigated, and resolved?
• Do procedures define retention, rotation, deletion, and the relationship between backup and archive?
• Is the recovery runbook current, controlled, assigned to trained personnel, and usable during an incident?
• Are approved manual or alternate procedures available for critical processes during downtime?
• Have restore tests demonstrated actual restoration rather than only successful backup completion?
• Do tests verify completeness, accuracy, readability, access, audit trails, metadata, and critical system functions?
• Are test results compared with approved recovery objectives and reviewed by the right functions?
• Are test failures and deviations assessed for product, patient, record, and compliance impact?
• Are significant changes to systems, suppliers, or recovery tools assessed through change control?
• For cloud services, are responsibilities, recovery evidence, exportability, and exit arrangements documented?
• Are recovery incidents and lessons learned used to update risk assessments, plans, training, and controls?

Common backup and disaster-recovery gaps

Common gap	Why it matters	Better practice
Assuming a green backup-job status proves recovery	The copy could be incomplete, corrupt, inaccessible, or missing dependencies.	Conduct and document representative end-to-end restore tests.
Backing up only the database	Configuration, raw files, audit trails, attachments, licenses, or interfaces may be absent.	Map data and technical dependencies; test a usable system restoration.
Keeping all copies reachable with production credentials	A compromised account or ransomware event may affect production and every backup.	Segregate privileges and protect independent or immutable recovery copies.
Using fixed targets without justification	Targets may not reflect system risk or be technically achievable.	Derive RTO/RPO and frequency from impact analysis, data creation rate, and validated needs.
Treating backup as long-term archiving	Rotation and deletion could remove records still subject to retention or retrieval requirements.	Define separate backup and archive strategies with appropriate access and retention controls.
Ignoring manual-operation reconciliation	Records created during downtime can be omitted, duplicated, or entered without clear provenance.	Use controlled forms, unique identifiers, review, and documented reconciliation.
Relying only on provider assurances	The customer may lack evidence that its tenant data and workflows are recoverable.	Assess provider controls and obtain system-relevant evidence; test customer-side retrieval or restore where possible.
Restoring without Quality impact assessment	Service recovery does not resolve possible data gaps or affected product decisions.	Require defined Quality and process-owner review before return to regulated use.

Practical implementation roadmap

1. Prioritize: identify systems with the greatest patient, product, and record impact.
2. Close critical gaps first: verify backup scope, secure copies, owner assignments, and usable runbooks.
3. Test a representative restore: select one high-impact system and prove the end-to-end approach in a controlled environment.
4. Expand by risk tier: apply lessons to remaining systems and their dependencies.
5. Integrate with quality processes: link incidents, changes, test exceptions, supplier updates, and CAPA to the validated-state process.
6. Review effectiveness: trend failures, test outcomes, restoration times, data gaps, and overdue actions at a defined governance forum.

The recovery program should be part of the broader computerized-system lifecycle, not a separate IT document that Quality sees only during an inspection. For connected assets, coordinate system assurance with infrastructure and URS requirements, and maintain clear traceability to qualification and operational evidence such as IQ, OQ, and PQ, where applicable.

Frequently asked questions

1. What is the difference between backup and disaster recovery in GxP?

Backup creates protected copies of data or system components. Disaster recovery is the tested process for restoring systems and services after disruption. Business continuity covers how critical work continues safely while recovery is in progress.

2. How often should GxP system data be backed up?

There is no single interval suitable for every system. Set and justify the schedule based on data criticality, transaction volume, approved RPO, system design, record requirements, and risk. Document the rationale and monitor execution.

3. Does GMP specify a universal RTO or RPO?

No universal GMP RTO or RPO is prescribed for all computerized systems. Organizations should define and approve recovery targets based on process impact, data integrity risk, patient and product considerations, and technical capability.

4. Is a successful backup job enough evidence?

No. It indicates that the configured job reported success, but it does not prove that the backup can restore usable systems and complete, readable records. Periodic restore testing is needed.

5. What should be included in a GxP system backup?

The scope may include regulated data, metadata, audit trails, signatures, attachments, configuration, application and database components, interfaces, required keys, licenses, and other dependencies. The system’s intended use and recovery design determine the exact scope.

6. Are snapshots or replication enough for GxP recovery?

Not automatically. Snapshots and replication can be useful, but they may also replicate corruption or deletion. Use versioned recovery points and demonstrate through testing that the chosen method restores the required records and functions.

7. Is backup the same as electronic-record archiving?

No. Backups generally support operational recovery; archives support retention and future retrieval. A backup rotation may delete older copies, so it should not be treated as the archive unless it has been designed and controlled for the applicable retention and retrieval needs.

8. How should restore testing be documented?

Use an approved protocol with defined scope and acceptance criteria. Record the backup source, restore steps, versions, results, integrity and readability checks, RTO/RPO comparison, discrepancies, impact assessment, approvals, and any follow-up actions.

9. Who is responsible for backups in a cloud or SaaS GxP system?

Responsibilities depend on the service model and contract. The provider may operate infrastructure backups, while the regulated company remains responsible for understanding whether those controls protect its records and support its intended use. Define responsibilities, evidence, restoration access, and data export in supplier controls.

10. What should a pharmaceutical company do if a restore test fails?

Open and document an investigation under the quality system, assess record and process impact, identify root cause, implement corrective actions, and repeat testing to demonstrate effective recovery. Reassess RTO/RPO and continuity controls if the failure changes the risk picture.

Conclusion

Effective backup and disaster recovery for GxP systems combines risk-based planning, secure and complete backup scope, measurable recovery targets, tested restoration, controlled downtime procedures, and Quality oversight. The program is credible when the organization can demonstrate that it can recover both the technology and the regulated evidence needed to make sound decisions. Revisit it whenever system use, architecture, data flows, suppliers, or business risks change.

This article is an educational overview, not a substitute for applicable regulations, current agency guidance, a site-specific risk assessment, or approved quality procedures. Confirm current requirements for each market and product category.

Authoritative references

• European Commission, EudraLex Volume 4 — published EU GMP Annex 11 listing.
• European Commission, EU GMP Annex 11: Computerised Systems (published text).
• Electronic Code of Federal Regulations, 21 CFR 211.68 — Automatic, mechanical, and electronic equipment.
• FDA, Questions and Answers on Current Good Manufacturing Practice Requirements — Records and Reports.
• NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — general contingency-planning guidance, not a pharmaceutical GMP regulation.