Backup Compliance Reports From AWS Backup

The situation

A platform team runs AWS Backup centrally in an audit account, with backup plans applied via Organizations backup policies:

• ~400 protected resources across 8 AWS services.
• 4 backup plans: daily-7-day, daily-35-day, monthly-1yr, hourly-continuous-rds.
• Backups land in backup vaults per account; critical tiers replicate to a central backup vault in a second Region with DeleteBackupVault denied by SCP.
• KMS-encrypted, vault-locked for regulated workloads.

Existing monitoring:

• CloudWatch alarms on BackupJobsFailed fire to Slack; someone acknowledges within the hour.
• CloudTrail captures the API calls.
• Nothing produces a monthly artefact the compliance officer accepts without follow-up questions.

The asks:

• A monthly compliance report with per-resource status: was each expected backup taken, on time, with the correct retention?
• Alignment to a framework: “backups encrypted with CMK,” “retention at least 35 days,” “cross-Region copy enabled for critical tier.” If a resource falls out of the framework, the report highlights it.
• Evidence down to the backup job ID, so audit can trace any individual backup back to its source resource.
• Distributable. Landing in S3 in a bucket the audit team can read, not just visible in the console.

What actually matters

Turning backup activity into an auditor-ready artefact splits into three jobs that each want their own layer.

The first is the schedule itself: what to back up, how often, for how long, to where. This is the “what happens” layer: rules and selections that bind resources to retention and destination. If this layer is missing, the rest is measuring silence.

The second is the declared policy, what the backup story should look like. A control list: “backups encrypted with a customer-managed key,” “minimum retention 35 days,” “frequency at most 24 hours,” “cross-region copy enabled for critical tier.” Controls don’t take backups; they measure whether existing backups and resources conform to the rules. This layer is what tells the report which resources are out of policy and why; not whether the schedule ran but whether what ran was correct.

The third is the artefact generation: a scheduled job that compares actual against declared and produces the CSV or PDF the auditor reads, dropping it into S3 where the audit team can fetch it. Without this layer, the team is still screenshotting at audit time.

The three compose: declarations describe the rules; schedules cause the backups; reports compare the two and write the result to durable storage. Miss any of the three and the report either doesn’t exist, doesn’t measure anything meaningful, or measures empty state.

The second thing worth thinking about is what kind of report answers which question. A jobs report (one row per backup and restore job in the reporting window, with resource ARN, job ID, status, start time, duration, size) answers “did backups run?” A resources compliance report (one row per protected resource per control, showing each resource’s compliance against the declared policy) answers “does the estate match policy?” A control compliance report (the same data rolled up by control rather than by resource) answers “what’s the overall posture, control by control?” Pick the report to the question; in most audits the team produces more than one.

The third is where all of this aggregates across accounts. The reporting layer has to read across the Organization rather than per account, or the audit deliverable is “one PDF per account” instead of “one PDF.” Delegated administration for the relevant service is the usual shape.

What we’ll filter on

Ranking the options against:

1. Produces an artefact, not a dashboard. CSV or PDF in S3, not a console view.
2. Framework-keyed output. Results map to declared controls (CMK use, minimum retention, etc.).
3. Per-resource traceability. Every backup job traces back to source resource and destination vault.
4. Cross-account aggregation. One report spans the Organization.
5. Automated. Report generates on a schedule without human intervention.

The backup-reporting landscape

1. Console screenshots. Status quo. Fails every requirement. Rejected.

2. CloudTrail + Athena queries. Write SQL against CloudTrail for every StartBackupJob, CompleteBackupJob, BackupJobCompletedNotification. Works; builds the report from scratch each time. Adds Athena query maintenance and manual joining across accounts. Doesn’t map to a framework.

3. AWS Backup jobs report plan. Native jobs report generated daily or monthly to S3. Every job in the window, one row per job. Answers “did backups run?” Doesn’t by itself answer “does the estate match policy.”

4. AWS Backup + framework + resources compliance report plan. Framework declares the policy; report plan generates a CSV listing each protected resource with per-control compliance. Answers “does the estate match policy?” Doesn’t list individual jobs (complementary, not substitute).

5. AWS Backup + framework + control compliance report plan. Same framework, rolled-up summary by control rather than by resource. Useful for executive summary; too coarse for per-resource audit trail.

6. AWS Backup Audit Manager framework deployed via delegated admin. The framework and report plans deployed centrally, aggregating data across every member account of the Organization. Produces one consolidated report per run.

Side by side

The pick is the last one: an AWS Backup delegated administrator account with a framework and two report plans, one jobs report for the per-job evidence and one resources compliance report for the framework alignment.

How the pieces wire together

The pick in depth

Delegated administrator setup. The Organization’s management account registers the audit account as a delegated administrator for AWS Backup via organizations register-delegated-administrator --service-principal backup.amazonaws.com. Once registered, that account can create frameworks and report plans that reference data across every member account. The management account itself is not the correct place for operational tooling; delegated admin is the clean separation.

The framework. A backup framework declares controls as a list of rule objects. The AWS-managed control BACKUP_RESOURCES_PROTECTED_BY_BACKUP_PLAN validates that every resource matching a selection criterion is in at least one backup plan; BACKUP_PLAN_MIN_FREQUENCY_AND_MIN_RETENTION_CHECK validates minimum frequency (e.g. every 24 hours) and minimum retention (e.g. 35 days); BACKUP_RECOVERY_POINT_ENCRYPTED validates CMK encryption on recovery points; BACKUP_RECOVERY_POINT_MINIMUM_RETENTION_CHECK validates retention on actual recovery points; CROSS_REGION_EVENT_NOTIFICATIONS_ENABLED validates that critical tier resources have cross-Region copy rules.

The framework takes a ControlScope per control, typically a tag-based selection that says “this control applies to resources tagged BackupTier=critical” or similar. Multiple controls can use different scopes, so “minimum retention 35 days for critical, 7 days for standard” becomes two controls with different scopes.

The report plans. Two plans in the delegated admin account, both running monthly:

• monthly-jobs-report: type BACKUP_JOB_REPORT. Lists every backup job in the previous month. Schema: job ID, resource ARN, resource type, backup plan ARN, vault name, start time, completion time, status, size in bytes, source account ID. One row per job. Destination: s3://audit-backup-reports/jobs/year=2028/month=03/.
• monthly-resources-compliance: type BACKUP_RESOURCES_COMPLIANCE. One row per protected resource × framework control, showing COMPLIANT, NON_COMPLIANT, or INSUFFICIENT_DATA. Destination: s3://audit-backup-reports/resources-compliance/year=2028/month=03/.

The report plans accept ReportDeliveryChannel parameters: S3 bucket name, KMS key, optional SNS topic for completion notification. The bucket policy has to allow the AWS Backup service principal to write to the bucket; the framework’s PutReportPlan call fails at runtime if the policy is missing.

Athena over the output bucket. Partition projection on year and month turns the S3 output into queryable tables without manual partition management. The monthly PDF generation is a small script that runs SELECT queries, joins against resource metadata for friendly names, and renders into an HTML template that the browser prints to PDF (or a Lambda that uses chromium-aws for headless rendering).

A useful query for the compliance officer:

SELECT control_name,
       SUM(CASE WHEN compliance_status='NON_COMPLIANT' THEN 1 ELSE 0 END) AS non_compliant,
       COUNT(*) AS total
FROM backup_resources_compliance
WHERE year=2028 AND month='03'
GROUP BY control_name
ORDER BY non_compliant DESC;

One row per control with the non-compliance count. Paired with a second query that drills into “which specific resources are non-compliant,” the PDF has both the summary and the detail.

A worked exception

Mid-March, an engineer spins up a new Neptune cluster in staging. They don’t tag it with BackupTier. The backup plan selection (BackupTier=standard) doesn’t pick it up. The Neptune cluster runs un-backed-up for two weeks until the compliance officer opens the March report.

The BACKUP_RESOURCES_PROTECTED_BY_BACKUP_PLAN control in the framework has a ControlScope of “all Neptune clusters regardless of tag.” The resources compliance report flags the untagged cluster as NON_COMPLIANT. The engineer tags it, the plan picks it up on the next evaluation, and next month’s report clears it.

Without the framework-driven report, the compliance officer would never notice until the cluster was in prod and had lost data. The framework’s job is not to prevent the mistake; it is to surface the mistake in the next month’s report so the team can correct it.

Vault locking and report plan protection

Critical-tier backup vaults have Vault Lock in compliance mode: once locked, recovery points in the vault cannot be deleted before their retention expires, even by root. The lock is an AWS Backup feature, not SCP-dependent, and survives account compromise scenarios where an attacker might try to destroy backups before ransomware deployment.

Report plans don’t need the same immutability; the generated reports do. The S3 bucket holding the reports has Object Lock in compliance mode with a retention period aligned to the audit retention requirement (often 7 years). Every monthly CSV becomes immutable. The bucket policy denies s3:DeleteObject even for the root principal of the audit account. The reports themselves become evidence.

What’s worth remembering

1. Three objects compose. Backup plans take backups; frameworks declare the policy; report plans measure actual against declared and write to S3. Miss any one and the audit story falls over.
2. Frameworks use control scopes. Each control can target a tag-based subset of resources, so different tiers (critical vs standard) can have different minimum retentions and encryption requirements.
3. Jobs report and resources compliance report answer different questions. Jobs report is “did backups run?” per job. Resources compliance report is “does the estate match policy?” per resource × control. Typically produce both.
4. Delegated administrator is the aggregation point. Register an audit account as delegated admin for AWS Backup; frameworks and report plans there cover every member account. The management account stays out of operational tooling.
5. S3 Object Lock makes reports immutable. Compliance mode retention aligned to the audit-retention requirement; DeleteObject denied even for root; the monthly CSV is evidence, not a working document.
6. Vault Lock protects recovery points. Compliance mode on critical vaults; locked recovery points survive until retention expires regardless of subsequent policy or root-level actions. Complementary to the report layer, not a substitute.
7. Athena + partition projection makes ad-hoc queries free. Report CSVs partition by year/month; Athena reads them without needing a Glue crawler run per month. “Which resources missed a backup in March?” is a single SQL query.
8. Tagging discipline is the feedback loop. The framework surfaces resources missing required tags or missing backup plan coverage; next month’s report re-checks. Tagging failures become visible rather than silent.

AWS Backup already takes the backups. Turning that activity into an auditor-ready report is the framework and the report plans combined, dropped onto a delegated admin account, with Object Lock keeping the output honest. The compliance officer’s monthly ask stops requiring a week of screenshotting; the S3 bucket has the artefact by 02:30 on the first of every month.