KSI-RPL-ABOAligning Backups with Objectives

The mark says whether an authored AWS recipe fetches evidence for the control; the tier strip shows which Rev5 baselines also require it — where automated KSI evidence doubles as Rev5 control evidence. ▪▪▫ = in the class B, C and D baselines, left to right

• ●recipe— an authored recipe collects evidence for this control
• ◐KSI only— a Key Security Indicator reaches it, but no recipe is authored yet
• ○orphan— no Key Security Indicator reaches it — a person writes it up instead

• ◐KSI onlyCM-02 (03)CM▫▪▪In baseline C, D
• ◐KSI onlyCP-06CP▫▪▪In baseline C, D
• ●recipe · 1 recipeCP-09CP▪▪▪In baseline B, C, D
• ●recipe · 1 recipeCP-10CP▪▪▪In baseline B, C, D
• ●recipe · 1 recipeCP-10 (02)CP▫▪▪In baseline C, D
• ◐KSI onlySI-12SI▪▪▪In baseline B, C, D

Collect evidence (2)

Authored AWS recipes whose output is evidence for KSI-RPL-ABO. This mapping is this project’s opinion (overlay v3.0.0), versioned separately from the dataset — the upstream FedRAMP rules name none of these tools.

• ◐partialAWS Config compliance results proving system data is backed up on a defined schedule — RDS automated backups enabled with a minimum retention, and AWS Backup plans meeting a minimum frequency and retentioncontinuousconfig-rule
  config-data-backup-enabledAWS Config · Amazon RDS · AWS Backup

  Set db-instance-backup-enabled's backupRetentionMinimum and backup-plan's requiredFrequencyValue/requiredFrequencyUnit/requiredRetentionDays to your CP-09 policy (defaults are 1/days and 35 days). These two cover RDS and AWS Backup-managed resources; for the other stores you run, add dynamodb-pitr-enabled, elasticache-redis-cluster-automatic-backup-check, and s3 versioning/replication as applicable. Backup existence is telemetry; the restore test that proves recoverability is CP-10's separate exercise — do not present a backup config as a successful restore. The frequency and retention that carry CP-09's organization-defined values live in the rule parameters, not in the output, so a human confirms they match the SSP; system documentation under CP-09(c) is never AWS telemetry.

• ◐partialRestore jobs that actually ran — the schedule they ran on, whether each one completed, how long it took, and what it produced — plus the point-in-time recovery window that makes transaction-level recovery possiblemonthlycli
  backup-restore-testingAWS Backup · AWS Config · Amazon RDS · Amazon DynamoDB

  A completed restore job is the strongest recovery evidence AWS emits, and it is still not the whole of CP-10. It proves a recovery point could be materialised into a resource and how long that took; it does not prove the restored system is functionally correct, that the data inside it is intact, or that the reconstitution ran to a known operational state. ValidationStatus does not close that gap either — restore testing validation is an EventBridge-triggered workflow you write, and PutRestoreValidationResult records whatever your own Lambda asserted, so treat it as your test result, not AWS's verdict (and note it cannot be set from the console, and once set it cannot be changed). RTO and RPO conformance is arithmetic you perform, not a field: compare CompletionDate minus CreationDate against your RTO, and the gap between LastBackupTime (or LatestRestorableTime) and the incident against your RPO. Restore testing also deletes the restored resource when the retention window closes, tagging it awsbackup-restore-test, so there is no lasting artifact beyond the job record — capture the output at collection time. Scope caveats: restore testing supports a fixed resource-type list (Aurora, DocumentDB, DynamoDB, EBS, EC2, EFS, FSx, Neptune, RDS, S3), rds-in-backup-plan evaluates AWS::RDS::DBInstance and AWS's own documentation notes it applies only to Aurora DB instances with clusters unsupported (aurora-resources-protected-by-backup-plan is the DB-cluster rule), and aurora-resources-protected-by-backup-plan is unavailable in a handful of Regions, none of them GovCloud. Backup existence is the CP-09 recipe's job; this recipe deliberately starts where that one stops.

Default evidence owed by every indicator (5)

From info.default_artifacts.KSI — no indicator carries its own artifacts; requirement-specific evidence lives on /evidence.

• Explanation of measures (and their objectives) that demonstrate the Key Security Indicator, or an explanation of the reason and resulting risk to customers for not having measures available for that Key Security Indicator.
• Explanation of the cycle for any measures that are implemented persistently (if applicable).
• Verification that the measures demonstrate the Key Security Indicator, or that the reason for not having them is accepted.
• Verification that the automation in place is accurate and sufficient to demonstrate appropriate measures for the Key Security Indicator, or that automation is not necessary for each measure.
• Validation that the measures are accurately produced and are in place and working as intended, or that the reason for not having them is valid.

Defined terms used (3)

Information Resource

Has the meaning from 44 USC § 3502 (6): "information and related resources, such as personnel, equipment, funds, and information technology." This includes any aspect of the cloud service offering, both technical and managerial, including everything that makes up the business of the offering from non-machine-based information resources like organizational policies, procedures, employees, etc. to machine-based information resources like hardware, software, cloud services, code, etc.

Machine-Based (Information Resources)

Any information technology information resource—including systems, processes, software, hardware, services, cloud-native capabilities, and any other such capability, component, or resource—that relies primarily on mechanical or electronic devices (i.e. computers) for operation.

Persistently

Occurring in a firm, steady way that is repeated over a long period of time in spite of obstacles or difficulties. Persistent activities may vary between actors, may occur irregularly, and may include interruptions or waiting periods between cycles. These attributes of persistent activities should be intentional, understood, and documented; the status of persistent activities will always be known.

• ●2 authored recipesKSI-RPL-ABOAligning Backups with Objectivesyou are here
• ●1 authored recipeKSI-RPL-ARPAligning Recovery Plan
• ●1 authored recipeKSI-RPL-RROReviewing Recovery Objectives
• ●1 authored recipeKSI-RPL-TRCTesting Recovery Capabilities