NIST SP 800-53 CP-9(7): Dual Authorization for Deleting or Destroying Federal Backup Information

NIST SP 800-53 CP-9(7) is one of the more operationally specific controls in the catalog. It requires that organizations implement dual authorization before any backup information can be deleted or destroyed. On paper, the requirement reads simply enough. In practice, enforcing it across a federal environment with distributed storage, multiple administrators, contractor-managed systems, and aging backup infrastructure is considerably more complicated.

The control exists because backup data represents the last line of recovery for most federal systems. An adversary who can delete backups before executing a destructive attack eliminates the organization’s ability to recover. An insider who can quietly purge retention copies removes evidence and creates operational gaps that may not surface until a disaster recovery event. Dual authorization addresses both threat vectors by requiring that no single individual can complete a deletion action alone.

What makes CP-9(7) difficult to implement well is that it sits at the intersection of backup operations, access control, and procedural governance. Most organizations already have backup administrators. Most have some form of role-based access. But having those things does not mean dual authorization is actually enforced at the point of deletion. The gap between having a policy and having a technically enforced control is where most programs fall short.

This article examines what CP-9(7) requires, how it applies across different backup architectures, where implementation commonly breaks down, and what a practical federal approach looks like when you account for real staffing constraints, legacy systems, and RMF documentation requirements.

What CP-9(7) Actually Requires

The control statement for CP-9(7) is direct: the organization enforces dual authorization for the deletion or destruction of backup information. NIST defines dual authorization as requiring the approval of two authorized individuals before an action can be completed. This is sometimes called two-person integrity in defense contexts, and the concept is well established in physical security and nuclear command authority. Applying it to backup data is a logical extension of the same principle.

The supplemental guidance in SP 800-53 Rev 5 clarifies that organizations may use automated mechanisms to enforce dual authorization. This is an important distinction. The control does not require two people to be physically present or to manually sign off on a paper form, though procedural documentation may still be required by the organization’s policies. What it does require is that the system or process prevents a single individual from completing the deletion action without a second authorization.

The control is an enhancement to CP-9, which covers the baseline backup requirements including frequency, scope, and storage. CP-9(7) is not included in the Low baseline. It appears in the Moderate and High baselines, which means it applies to the majority of federal systems that handle sensitive but unclassified information, as well as classified and mission-critical systems. If your system is categorized at Moderate or above, this control is not optional.

One area that sometimes creates confusion is the word “destruction.” In the context of CP-9(7), destruction includes physical media destruction, not just logical deletion. If your organization destroys backup tapes, hard drives, or other physical media as part of a retention or sanitization process, that destruction workflow must also satisfy the dual authorization requirement. This is relevant for organizations that manage on-premises tape libraries, removable media, or decommissioned storage hardware.

Technical Enforcement Versus Procedural Controls

The most consequential implementation decision for CP-9(7) is whether dual authorization is enforced technically or procedurally. Both approaches can satisfy the control on paper, but they carry very different risk profiles in practice.

A procedural control means the organization has a documented process requiring two individuals to approve a deletion before it occurs. The backup administrator submits a request, a second authorized individual approves it, and the deletion is then performed. The problem with purely procedural controls is that they depend entirely on people following the process every time. If the backup platform itself does not enforce the requirement, a single administrator with sufficient privileges can bypass the procedure without any technical barrier. For Moderate and High systems, assessors increasingly expect to see technical enforcement, not just a policy document.

A technically enforced control means the backup platform, storage system, or surrounding access control infrastructure prevents the deletion from completing unless a second authorization has been recorded. Some backup platforms support this natively through workflow approvals, role separation, or immutability features. Others require the organization to architect the control through a combination of role-based access restrictions, ticketing system integrations, and audit logging that creates a verifiable chain of authorization.

Role Separation as a Technical Control

One practical approach to technical enforcement is strict role separation at the backup platform level. If the role that can initiate a deletion request is different from the role that can approve and execute it, and no single account holds both roles, then dual authorization is technically enforced through access control. This requires careful account provisioning, regular access reviews, and audit logging to demonstrate that the separation is maintained over time.

The challenge is that many federal backup environments were not designed with this level of role granularity. Legacy backup platforms may have limited role structures, and administrators who have managed the environment for years may hold broad permissions that were never formally reviewed. Retrofitting role separation into an existing environment requires coordination between the backup team, the access management team, and the ISSO, and it often surfaces undocumented dependencies that complicate the effort.

Immutability and Its Relationship to CP-9(7)

Immutable backup storage is frequently discussed alongside CP-9(7), but the two are not the same thing. Immutability prevents modification or deletion of backup data during a defined retention period, regardless of who attempts the action. This is a strong technical control, but it addresses a different threat model than dual authorization. Immutability prevents deletion entirely during the retention window. CP-9(7) governs what happens when deletion is authorized and appropriate, such as at the end of a retention period or during a decommissioning event.

Organizations that implement immutable backup storage still need to address CP-9(7) for the processes that govern what happens when immutability expires or is administratively overridden. If the platform allows an administrator to shorten the immutability period or delete data after the lock expires, those actions must be subject to dual authorization. Immutability and dual authorization work together, but neither replaces the other.

Scope, Applicability, and Retention Boundaries

CP-9(7) applies to backup information, which the control defines broadly. This includes system-level backups, database backups, application-level backups, and configuration backups. It also applies to backups stored on-premises, in cloud environments, and on removable or portable media. The storage location does not change the requirement.

One area that organizations frequently overlook is automated retention expiration. Many backup platforms allow administrators to configure retention policies that automatically delete backup data after a defined period. If a single administrator can modify those retention policies, they can effectively cause backup data to be deleted without a second authorization by shortening the retention window. CP-9(7) applies to this scenario. The ability to modify retention policies that govern when deletion occurs should be treated as equivalent to the ability to initiate deletion directly.

Cloud backup environments introduce additional complexity. When backup data is stored in a cloud service, the deletion controls available to the organization depend on what the cloud platform exposes. Some cloud backup services support object lock features that enforce immutability and require elevated authorization for deletion. Others provide standard storage with no built-in dual authorization capability, placing the burden on the organization to architect compensating controls through identity and access management, approval workflows, and audit logging.

For organizations managing data protection, backup, and cyber recovery across hybrid environments, the scope of CP-9(7) must be evaluated for each backup tier separately. An on-premises backup server, a cloud-based secondary copy, and an offsite tape archive may each require different technical implementations of the same control, and each must be documented in the system security plan.

Backup Deletion Scenario	CP-9(7) Applies	Typical Enforcement Approach	Common Gap
Manual deletion by administrator	Required	Role separation, approval workflow	Single admin holds both initiator and approver roles
Automated retention expiration	Required	Restrict who can modify retention policy settings	Retention policy changes not treated as deletion events
Physical media destruction	Required	Two-person witness and sign-off process	Destruction handled by single contractor without oversight
Cloud backup deletion via console	Required	IAM role separation, MFA delete, approval workflow	Cloud admin accounts not scoped to least privilege
Immutability period expiration	Required for post-expiration deletion	Workflow approval before deletion after lock expires	Assuming immutability alone satisfies the control

Control Dependencies and SSP Documentation

CP-9(7) does not operate in isolation. Its implementation depends on several other controls being in place and functioning correctly. Understanding those dependencies is important both for implementation planning and for SSP documentation.

AC-2 governs account management, including the provisioning and review of accounts with backup administration privileges. If AC-2 is not implemented with sufficient rigor, the accounts that should be separated for dual authorization purposes may not be properly scoped. AC-3 governs access enforcement, which is the mechanism through which role separation is technically applied. If access enforcement is weak or inconsistently applied, role separation breaks down. AU-9 governs the protection of audit information, which is relevant because the audit logs that record backup deletion events must themselves be protected from tampering by the same administrators who perform backup operations.

In the SSP, CP-9(7) should be documented with enough specificity that an assessor can understand exactly how dual authorization is enforced, who holds each role, what technical mechanism prevents a single individual from completing a deletion, and how the organization detects and responds to unauthorized deletion attempts. Vague language such as “backup administrators follow a two-person approval process” is not sufficient for a Moderate or High system. The documentation should describe the specific platform capabilities, role assignments, and audit mechanisms that make the control real.

Continuous monitoring obligations also apply. If the role assignments that enforce dual authorization change, that change should trigger a review of the control’s effectiveness. Access reviews for backup administration accounts should explicitly verify that no single account holds both the initiator and approver roles. This is the kind of operational detail that often gets lost between the initial implementation and the next assessment cycle.

Common Mistakes

The most common mistake is treating CP-9(7) as a documentation exercise rather than a technical control requirement. Organizations write a policy, describe a two-person approval process in the SSP, and consider the control satisfied. When an assessor asks to see the technical mechanism that enforces the separation, there is none. The backup platform allows any administrator with sufficient privileges to delete data without any second authorization. This is a finding, and it is one of the more serious ones because it directly undermines the organization’s recovery capability.

A related mistake is failing to account for all deletion pathways. Organizations focus on the obvious case, a backup administrator manually deleting a recovery point, and miss the less visible pathways. Automated retention expiration policies, API access used by scripts or orchestration tools, cloud storage lifecycle rules, and physical media destruction workflows all represent deletion pathways that must be evaluated. If any of these pathways allows a single individual to cause backup data to be deleted without a second authorization, the control is not fully implemented.

Ownership ambiguity is another persistent problem. In many federal environments, backup infrastructure is managed by a contractor team under a managed services arrangement. The federal program office assumes the contractor is implementing controls correctly. The contractor assumes the program office has defined the requirements. Neither party has explicitly assigned ownership of CP-9(7) implementation, and the result is that the control exists in the SSP but is not enforced in the environment. This gap is particularly common in environments where the backup platform was deployed years ago and has been sustained without a formal security review.

Organizations also frequently fail to account for privileged access management. Even when role separation is implemented at the backup platform level, a system administrator with access to the underlying operating system or hypervisor may be able to delete backup data at the storage layer, bypassing the backup platform’s controls entirely. CP-9(7) must be evaluated in the context of the full privilege model, not just the backup application’s role structure.

Finally, organizations sometimes assume that immutable backup storage satisfies CP-9(7) entirely. As discussed earlier, immutability and dual authorization address different aspects of backup protection. Immutability prevents deletion during the retention window. Dual authorization governs what happens when deletion is appropriate. Both controls are needed, and one does not substitute for the other.

Recommended Federal Approach

Start with a complete inventory of backup deletion pathways before making any architecture or policy changes. This means identifying every mechanism through which backup data can be deleted or destroyed, including manual platform actions, automated retention policies, API and scripted access, cloud storage lifecycle rules, and physical media destruction. For each pathway, identify who currently has the ability to initiate or complete a deletion action and whether any technical barrier prevents a single individual from doing so without a second authorization.

Once the inventory is complete, assess the backup platform’s native capabilities for role separation and workflow enforcement. Some platforms support granular role definitions that allow you to separate the initiator and approver functions natively. If the platform supports this, configure it and document the role assignments in the SSP. If the platform does not support native dual authorization, identify compensating controls. Common compensating approaches include integrating backup deletion requests with a ticketing or change management system that requires a second approval before the deletion is executed, combined with audit logging that captures both the request and the approval.

Address retention policy modification as a separate but related control point. Restrict the ability to modify retention policies to a separate role from the role that manages day-to-day backup operations. Document this restriction in the SSP and verify it through access reviews. If automated retention expiration is in use, ensure that the configuration of those policies is subject to change management controls that require a second authorization.

For cloud backup environments, evaluate the identity and access management capabilities of the cloud platform. Many cloud providers support features such as object lock, MFA delete requirements, and approval workflows that can be used to enforce dual authorization. Configure these features where available and document them. For cloud environments where native dual authorization features are limited, architect the control through IAM role separation and integrate with an approval workflow that creates an auditable record of both the initiation and authorization of each deletion event.

Physical media destruction requires a documented procedural control with a verifiable record. Define a process that requires two authorized individuals to be present for any media destruction event, with both individuals signing a destruction record that is retained as evidence. Assign clear ownership for this process, whether to federal staff or a contractor, and ensure the assignment is documented in the SSP and the relevant contract or task order.

Audit logging must be configured to capture all backup deletion and retention modification events with sufficient detail to support after-the-fact review. Logs should record who initiated the action, who authorized it, what data was affected, and when the action occurred. Critically, those logs must be protected from modification or deletion by the same administrators who manage backup operations. This is the AU-9 dependency, and it must be explicitly addressed in the SSP.

Once the technical controls are in place, conduct an operational validation before the next assessment cycle. Have someone outside the backup administration team attempt to delete backup data through each identified pathway and verify that the dual authorization requirement is enforced in each case. Document the results. This kind of operational testing is more valuable than a policy review and gives the ISSO and assessor concrete evidence that the control is functioning as designed.

Establish a periodic access review cadence that explicitly verifies role separation for backup administration accounts. Access reviews that do not specifically check whether any single account holds both initiator and approver privileges will not catch the most common implementation failure for this control. The review should be documented and the results retained as evidence of ongoing compliance.