CP-9(7): Dual Authorization for Deletion or Destruction

CP-9(7) requires you to enforce dual authorization before anyone can delete or destroy the backups (or other CP-9-defined items) your organization relies on for recovery. Operationally, that means two distinct approvals (or two distinct actors) must be required and recorded for destructive actions across backup platforms, storage tiers, and any third party managed backup service. ¹

Key takeaways:

• Dual authorization must be enforced for deletion/destruction events, not just documented in policy. ¹
• Scope is your CP-9-defined backup information; define it explicitly so enforcement is testable. ¹
• Auditors will ask for system evidence: access controls, workflow settings, and immutable logs proving two-person approval occurred. ¹

The cp-9(7): dual authorization for deletion or destruction requirement is a guardrail against a specific failure mode: a single person, a single compromised credential, or a single mis-click wiping out your ability to recover. CP-9 is the contingency planning “information system backup” control family; this enhancement adds a higher bar for destructive events against the backup assets you depend on. ²

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize CP-9(7) is to treat it as an engineering requirement with measurable configuration outcomes: “Deletion/destruction of in-scope backup artifacts requires two separate authorizations, recorded, and reviewable.” Your job is to ensure (1) scope is unambiguous, (2) enforcement exists in the platforms and with third parties, and (3) evidence can be produced on demand.

This page gives requirement-level implementation guidance you can hand to infrastructure, security operations, and your backup/storage admins, plus an evidence checklist that stands up in assessments mapped to NIST SP 800-53 Rev. 5. ²

Regulatory text

Requirement (verbatim): “Enforce dual authorization for the deletion or destruction of {{ insert: param, cp-09.07_odp }}.” ¹

What the operator must do

1. Define the object of protection (ODP) for CP-9(7): what exactly counts as “the backups” in your environment (backup sets, snapshots, backup vaults, tapes, replication targets, backup encryption keys, or other items you specify under CP-9). Document this in a way an engineer can implement and an auditor can test. ¹
2. Enforce dual authorization for any action that deletes or destroys that in-scope backup information. “Enforce” means it must be technically prevented without the second authorization, not merely discouraged by policy. ¹
3. Record and retain evidence that the two authorizations happened, tied to the specific deletion/destruction event, with identities and timestamps. ¹

Plain-English interpretation

If one person can delete your backups, you do not meet CP-9(7). You need a two-person rule (or two independent approvals) for destructive backup actions so a single insider, a compromised admin account, or an automation error cannot eliminate recovery points without a second, accountable check. ¹

Dual authorization can be implemented as:

• Two-person workflow approval (Requester + Approver) in the backup platform or an external ITSM workflow that gates the action.
• Two-party technical control (separation of duties), where one role can request/prepare deletion but a different role must execute/authorize it.
• Cryptographic or key-based separation, where destruction requires access to two independent approval paths (common with immutable storage governance features, key management approvals, or privileged access workflows).

What does not qualify in practice: a single admin deleting backups, then getting a retroactive manager sign-off.

Who it applies to

Entity scope

• Federal information systems and contractor systems handling federal data that implement NIST SP 800-53 Rev. 5 controls or inherit them through contractual or program requirements. ¹

Operational scope (where this shows up)

• Centralized backup platforms (backup servers, backup SaaS, backup appliances)
• Snapshot-based protection (hypervisor snapshots, storage snapshots) when used as recovery points
• Cloud backup vaults and object storage used for backups
• Offsite media workflows (tape rotation, vaulting, destruction)
• Any third party that administers backups or storage where destructive actions could occur (managed service providers, cloud providers, colocation operators)

What you actually need to do (step-by-step)

Step 1: Define “in-scope deletion/destruction” events

Create a one-page scoping statement your engineering teams can implement:

• In-scope assets: list backup repositories, vaults, buckets, tape libraries, backup accounts/tenants, and backup encryption keys if key deletion equates to backup destruction.
• In-scope actions: delete backup job history only (usually not in scope) vs delete restore points (in scope), delete vault/container (in scope), remove immutability lock or shorten retention (treat as destructive).
• In-scope identities: humans and service accounts with permissions to perform destructive actions.

Output artifact: “CP-9(7) Scope & ODP Definition” mapped to systems and owners. ¹

Step 2: Pick an enforcement pattern per platform

Use a decision matrix and document the choice:

Platform area	Preferred enforcement	Acceptable alternative	Avoid
Backup SaaS / backup appliance	Built-in two-person approval for delete/purge	ITSM approval that gates privileged access through PAM	“Policy only” or post-approval
Cloud storage vault/bucket for backups	Separate roles + change control for lifecycle policy/retention changes	Dual control on key operations in KMS + restricted deletion permissions	Shared admin role with delete permission
Tape/offsite media	Two-person sign-off at chain-of-custody + inventory reconciliation	Two-person approval for destruction request with third-party certificate	Single person initiating and confirming destruction

The goal is consistent: two independent approvals before destruction is possible. ¹

Step 3: Implement role separation and technical gating

Minimum technical expectations to make this auditable:

• Separate roles: “Backup Operator” (runs jobs, restores) vs “Backup Security Admin” (authorizes destructive actions). Do not allow the same person to hold both roles without documented compensating controls and explicit exception handling.
• Gating mechanism: configure the platform so deletion requires an approval step or a privileged elevation that itself requires approval.
• Privileged Access Management (PAM) integration (if you have it): enforce “check-out” of privileged credentials only after approval, and time-bound the access. Configure deletion commands to require that elevated session.

If you can’t enforce in the backup tool, enforce at the access layer (PAM + IAM + change management) so the destructive permission is never active without a second approver.

Step 4: Make it work with third parties (TPRM reality)

If a third party administers backups:

• Add a contract/SOW clause requiring dual authorization for destructive actions on your backups.
• Require the third party to provide evidence on request: ticket approvals, privileged session logs, platform audit logs.
• Define escalation paths for emergency deletion (still dual-authorized; speed is not a reason to waive control without an exception).

This is a common control gap: the internal policy exists, but the managed service desk can still purge your vault with one engineer.

Step 5: Logging, monitoring, and review

Dual authorization must be provable:

• Enable audit logging for deletion/destruction actions and retention/immutability policy changes.
• Forward logs to your central logging/SIEM if available.
• Establish a review procedure: periodically review destructive events for completeness (two approvals present) and investigate anomalies.

Step 6: Document the control in an assessor-ready way

Map CP-9(7) to:

• Control owner (Backup/Infrastructure lead + Security Governance)
• Systems in scope
• Procedure: “How to request deletion,” “Who approves,” “Where logged,” “How to evidence”
• Recurring evidence artifacts (see below)

If you use Daydream for control management, set CP-9(7) up as a control with a defined owner, implementation procedure, and an evidence collection cadence so the proof is ready before the audit window opens.

Required evidence and artifacts to retain

Keep evidence that shows design and operation:

Design evidence (what’s configured)

• CP-9(7) scoping/ODP definition document (what is protected) ¹
• Role-based access control (RBAC) matrix for backup platform(s)
• Screenshots or exported configuration showing two-person approval settings, retention locks, deletion restrictions
• IAM policies / cloud role definitions showing separation of delete permissions
• Third-party contractual clauses or control attestations specific to dual authorization for destructive actions

Operating evidence (what actually happened)

• Sample deletion/destruction tickets showing requester + approver identities and timestamps
• Backup platform audit logs for a destructive event showing two-step approval or two separate actors
• PAM session logs or privileged check-out approvals tied to the deletion event
• Exception records (if any) with risk acceptance, time-bound approval, and post-action review notes

Common exam/audit questions and hangups

• “Show me where dual authorization is technically enforced for backup deletion.” Expect to demonstrate config, not just policy. ¹
• “What is the {{ cp-09.07_odp }} in your environment?” If you can’t define scope, you can’t prove coverage. ¹
• “Can a global admin bypass this?” Auditors often test for bypass paths: break-glass accounts, root credentials, or inherited permissions.
• “Does your third party follow the same dual control?” If not, you have an unmitigated control gap in outsourced operations.

Frequent implementation mistakes (and how to avoid them)

1. Policy-only dual control. Fix: implement technical gating in the platform or through PAM/ITSM so deletion cannot occur without the second approval. ¹
2. Ignoring retention/immutability changes. Fix: treat reducing retention, removing holds, or changing lifecycle rules as “destruction-equivalent” and require dual authorization.
3. Same person approves their own request. Fix: enforce approver/requester separation in workflow tooling; block self-approval.
4. Third-party blind spot. Fix: contract language + evidence rights + periodic sampling of their tickets/logs.
5. No testable scope. Fix: name systems, repos, vaults, and actions; avoid vague “all backups everywhere” statements that don’t map to enforcement points.

Risk implications (why auditors care)

Backup destruction is a high-impact event with low reversibility. CP-9(7) reduces the likelihood that a single compromised admin account, malicious insider, or operational error removes your recovery capability. It also reduces “silent failure,” where backups exist but can be deleted without friction. ¹

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and ownership)

• Assign a control owner and a technical owner for each backup platform.
• Write the CP-9(7) ODP/scope statement and get it approved.
• Inventory all destructive permissions and identify who has them (human and service accounts).
• Confirm whether any third party can delete/destroy backups and document the pathways.

Days 31–60 (implement enforcement)

• Implement dual authorization in the backup tools where supported.
• Where not supported, implement a gating control: PAM approval workflow, IAM separation, and change-management approval that is required before permissions are granted.
• Update third-party agreements or operating procedures to require dual authorization and evidence production.
• Turn on audit logging for destructive events and retention/immutability changes.

Days 61–90 (prove operations and harden)

• Run a tabletop or controlled test: attempt a deletion without the second approval and confirm it is blocked.
• Collect an evidence packet: configs, RBAC, sample approved tickets, logs, and review records.
• Add continuous monitoring: alert on delete attempts, retention reductions, vault deletions, or policy changes.
• Formalize exceptions: break-glass process with dual authorization and post-event review.

Frequently Asked Questions

What counts as “dual authorization” for CP-9(7)?

Two independent approvals or two distinct authorized actors must be required before deletion/destruction can occur, and the system must enforce it. A manager signing after the fact does not meet the “enforce” expectation. ¹

Does CP-9(7) apply to deleting a single restore point, or only deleting entire backup repositories?

Apply it to any deletion/destruction event that reduces your recovery capability for in-scope backup information as defined in your ODP scope. Define this explicitly so engineers and auditors treat the same events as in scope. ¹

Can we meet CP-9(7) with ITSM approvals instead of a native backup feature?

Yes if the workflow technically gates the action, such as by controlling PAM elevation or permission grants so deletion cannot execute without the second approval. Document the linkage between the ticket approval and the privileged action logs.

How do we handle emergencies where we need to delete backups fast (legal hold release, corrupted vault, cost incident)?

Create an exception path that still requires dual authorization, uses a break-glass procedure, and triggers a post-action review with preserved logs. Keep the exception time-bound and auditable.

What if our backup platform cannot do two-person approval?

Enforce dual authorization at the access layer: separate IAM roles, remove standing delete permissions, require PAM check-out with an approver, and log every elevated session tied to the deletion event.

What evidence will an assessor ask for first?

Expect requests for (1) configuration proof of dual authorization or access gating, (2) RBAC/permissions showing separation of duties, and (3) a sampled destructive event with two approvals and matching audit logs. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5