RMFInsider

CP-9 requires backups of user-level information, backups of system-level information, and backups of system documentation including security and privacy documentation, each at a frequency your organization defines, plus protection of the confidentiality, integrity, and availability of the backup information itself. CP-10 requires that you can recover and reconstitute the system to a known state within a time period consistent with your recovery time and recovery point objectives. The evidence that passes assessment is narrow: the backup job configuration, success and failure logs across a sample period, a restore test record with timestamps and a named tester, and media inventory and handling records. In my experience the failure is nearly always the same one. The backups ran fine for three years and nobody ever proved a restore.

What CP-9 and CP-10 actually say

Read CP-9 in Rev 5 as four distinct obligations, because assessors test them separately. User-level information on components you define, at a frequency you define. System-level information, at a frequency you define. System documentation, including security and privacy documentation, at a frequency you define. And protection of the confidentiality, integrity, and availability of the backup information. Three of those are schedule questions. The fourth is a controls question, and it is where encryption, access restriction, and media handling come in.

The enhancements carry the real expectations for anything above low. CP-9(1) tests backups for reliability and integrity. CP-9(2) tests restoration using sampling. CP-9(3) requires separate storage for critical information. CP-9(5) covers transfer to the alternate storage site. CP-9(6) is a redundant secondary system, CP-9(7) is dual authorization for deletion or destruction, and CP-9(8) is cryptographic protection. Pull your control allocation rather than guessing which apply, because your categorization and overlay set decide it, not the catalog.

CP-10 is one sentence and teams underestimate it: recover and reconstitute the system to a known state within a time period consistent with the recovery time and recovery point objectives, after a disruption, compromise, or failure. Known state is the phrase worth arguing about internally, because a restored server with no patches, no STIG settings, and a default administrator password is not a known state, it is a new problem. CP-10(2) adds transaction recovery for transaction-based systems, CP-10(4) adds restoration within a defined period from configuration-controlled and integrity-protected information, and CP-10(6) protects the components you use to recover.

RTO and RPO set the schedule, not the other way around

The order of operations that keeps you consistent: the contingency plan states the recovery time objective and the recovery point objective, and the backup schedule is derived from them. Not the reverse. Write the schedule first and back-fill objectives to match, and the numbers in your plan end up describing whatever the backup software happened to be configured to do in 2021.

Recovery point objective is the tolerable data loss measured in time. Nightly backups at 2300 mean an RPO of roughly twenty-four hours, so a plan claiming a four-hour RPO against a nightly full contradicts itself on paper, and an assessor comparing your CP-2 contingency plan against the backup job configuration finds it in a minute. Either move to more frequent incrementals or log shipping, or revise the objective to what the system actually delivers and let the AO accept that risk knowingly.

Recovery time objective is how long recovery may take, and it is what the CP-10 restore test measures. State it per component when the system has tiers, because a single system-wide RTO is usually either wrong for the database or wrong for the reporting server. Write both numbers into the plan, into the CP-9 control implementation statement, and into the restore test record, and keep the three copies identical.

Offsite and alternate storage

A backup sitting on the same array as production, or on a share reachable from the same compromised domain, is not a backup for contingency purposes. CP-9(3) asks for separate storage of critical information, CP-9(5) asks for transfer to the alternate storage site, and CP-6 governs the alternate storage site itself. Distance and separation expectations come from your component’s guidance and your own plan, so document what you have and why it is sufficient rather than describing an ideal you do not operate.

What I document for offsite, whatever the medium: where the copy lives, how far it is from primary in a way that matters (different building, different facility, different region), how it gets there, who has physical or logical access to it, how often the copy is refreshed, and how long retrieval takes. Retrieval time is the number teams skip, and it feeds the RTO directly. If media comes back from a storage vendor in four hours, a two-hour RTO is fiction.

For cloud-hosted workloads the same questions apply with different nouns. Snapshots in the same region and the same account as production satisfy nobody on separation. Write down the account boundary, the region, the retention lock if you have one, and whether the credentials that can delete production can also delete the backups. That last question is worth asking out loud in a room.

Encrypting backups, and where media protection takes over

CP-9(8) is cryptographic protection of backup information, and in DoD that means a validated module, not a checkbox labeled encryption in a vendor console. Record the algorithm, the module validation reference, and how keys are managed and recovered, because an encrypted backup you cannot decrypt during recovery is worse than no backup: it consumed budget and produced a false sense of readiness.

Encryption does not release you from media protection. MP-4 covers media storage, MP-5 covers transport, and disposal runs through MP-6 media sanitization, which is where backup media goes to die and where inventories get audited. Marking and handling requirements follow the classification of the information on the media, and encryption does not automatically lower them. Check your component’s guidance and your security classification guide before assuming an encrypted drive can be handled as unclassified, because in the environments I have worked the answer was no.

One overlap worth closing now: your media inventory has to account for every piece of backup media, including the drive somebody pulled out of rotation two years ago and left in a desk. If your MP-6 evidence and your CP-9 evidence disagree about how much media exists, both controls take the finding.

Restoration testing, the evidence nobody has

This is the gap. Backup software produces success logs automatically, so teams arrive at assessment with three hundred green entries and nothing proving data came back. A backup you have never restored is a hypothesis with a retention policy.

A restore test does not require a full failover. Sampling is acceptable under CP-9(2), and a bounded quarterly test is stronger evidence than an annual heroic effort nobody documented. What I run: pick a file set or a database, restore it to an isolated location, verify integrity against a known value or a functional check, record start and finish times, and compare elapsed time against the RTO. Thirty to ninety minutes of work, and it produces the one artifact assessors cannot get anywhere else.

Record failures too. A restore test that missed the RTO by two hours, with a corrective action and a POA&M reference, reads as a functioning program. A file containing only successes reads as a file that only gets written when things go well. Assessors have seen both, and when they compare your restore records against what they test during the assess step, the honest record survives the conversation and the curated one does not.

The artifact set

This is what I put in the package for CP-9 and CP-10, and it is close to what every assessor I have worked with asked for:

• Backup job configuration. An export or screen capture showing scope (which systems, which data), type (full, incremental, differential), schedule with times, retention period, and destination. Dated, and matching the plan.
• Success logs for a sample period. Thirty to ninety days of job history, not one clean night.
• Failure logs for the same period, with evidence of what was done about each failure: a ticket number, an acknowledgment, a re-run. Suppressing failures is worse than having them.
• Restore test record. Date, start and end timestamps, what was restored, the source backup set and its date, who performed it, how integrity was verified, pass or fail against the RTO, and a signature.
• System documentation backup evidence. Proof that the SSP, diagrams, configuration baselines, and recovery procedures exist somewhere other than the system they describe. That is part c of CP-9, and the part teams forget entirely.
• Media inventory. Identifiers, media type, classification marking, current location, custodian, and rotation history.
• Handling and transport records. Chain of custody for anything that physically moves offsite, with dates and signatures.
• Encryption details. Algorithm, validated module reference, and the key management and recovery procedure.
• The contingency plan sections stating RTO, RPO, and the backup and recovery procedures, so the configuration and the plan can be read side by side without contradiction.

Map these to CP-9, to CP-9(1) and CP-9(2) where selected, and to CP-10, and name the files so an assessor can tell what they are without opening them. The naming discipline that makes an RMF artifacts checklist useful applies here too: a file called backup_evidence_final_v3.xlsx costs you goodwill you will want later.

The four ways this control fails in an assessment

• No restore test record. Backups are configured, logs are green, and nothing shows recovery was ever exercised. This is the finding I have seen written more often than any other in the CP family, and one bounded test per quarter prevents it.
• The schedule contradicts the plan. The plan states a four-hour RPO and the job runs nightly, or the plan names a weekly full and the console shows the job disabled since March. One document against one screen, and the gap is obvious.
• Failures nobody acknowledged. The log shows nineteen failed jobs across sixty days with no tickets, no comments, and no pattern of response. That turns a schedule finding into a monitoring finding, because it means nobody was reading the alerts.
• Documentation was never backed up. Part c gets ignored, and when the assessor asks where the SSP, the diagrams, and the recovery procedures live, the answer is a file share on the system being recovered. Circular, and a legitimate finding.

None of the four need money to fix. They need a quarterly restore test that produces a signed record, a monthly look at the failure log, and a ten-minute read of your own plan to confirm the numbers still match the configuration. Do that and CP-9 stops being a scramble in the week before assessment. If you want the full evidence set laid out control family by control family alongside these, the RMF Checklist is what I work from.