Backup plans should have minimum frequency and minimum retention configured

Recovery points that expire too quickly leave you exposed during investigations, legal holds, or prolonged incident response. A 35-day floor gives teams enough runway to detect delayed-onset issues (ransomware with a long dwell time, for example) and restore to a known-good state before the oldest usable snapshot disappears.

Short retention also creates compliance gaps that auditors flag fast. Frameworks covering backup and recovery typically require evidence that backups survive at least 30 to 35 days, and missing the threshold by even a single day can result in a finding.

Retrofit consideration

Increasing retention on existing backup plans will generate additional storage costs for EBS snapshots, RDS snapshots, and other protected resources. Estimate the cost delta before rolling this change across all plans.

Implementation

Choose the approach that matches how you manage Terraform.

Terraform resources

Use AWS provider resources directly. See docs for the resources involved: aws_backup_plan.

resource "aws_backup_plan" "this" {
  name = "pofix-abc123"

  rule {
    lifecycle {
      delete_after = 35
    }
    rule_name         = "pofix-rule-abc123"
    schedule          = "cron(0 12 * * ? *)"
    target_vault_name = "example-backup-vault"
  }
}

What this control checks

The policy checks each aws_backup_plan resource. Every rule block must include a lifecycle block with delete_after set to 35 or greater. If delete_after is omitted entirely (recovery points never expire), the retention check passes. If it is below 35, the plan fails.

The schedule argument must also be a cron or rate expression that fires at least as often as the required minimum frequency. A rule failing either condition fails the control. When multiple rules exist in a single plan, at least one must satisfy both requirements.

Common pitfalls

delete_after omitted versus set to zero
Omitting lifecycle entirely from a rule block in aws_backup_plan retains recovery points indefinitely and passes the retention check. Explicitly setting delete_after = 0 is invalid and causes an API error. These are not equivalent states, and conflating them is a common source of confusion.
Multiple rules with mixed retention
If one rule has delete_after = 7 for operational restores and another has delete_after = 90 for compliance, the Config rule may still flag the plan depending on whether it evaluates individual rules or the plan as a whole. Don't assume the compliant rule covers for the short one. Set every rule to at least 35 days.
Cold storage transition miscounted as retention
cold_storage_after moves recovery points to cold storage but does not extend or replace delete_after. A rule with cold_storage_after = 30 and delete_after = 30 still deletes the point after 30 days total. The transition and the deletion are independent clocks.
Schedule frequency not validated by retention alone
Setting delete_after = 90 satisfies the retention half of this control, but if schedule uses a cron expression that only fires monthly, the frequency check still fails. Both conditions must pass in the same rule.

Audit evidence

Config rule evaluation results for BACKUP_PLAN_MIN_FREQUENCY_AND_MIN_RETENTION_CHECK with requiredRetentionDays set to 35 should show all backup plans as COMPLIANT. Back this up with the Backup console showing each plan's schedule expression and lifecycle retention settings, plus CloudTrail CreateBackupPlan and UpdateBackupPlan events confirming retention hasn't been reduced below the threshold.

For CLI-based evidence, export the plan JSON via aws backup get-backup-plan and check the DeleteAfterDays value in each rule's lifecycle section. Pair this with a recovery point report from aws backup list-recovery-points-by-backup-vault to show that points span at least 35 days back.

Framework-specific interpretation

SOC 2: Availability criteria expect organizations to demonstrate recoverability consistent with their documented commitments and service level objectives. Thirty-five days is typically what auditors ask to see when reviewing backup controls, though the exact requirement depends on what your service commitments actually state.

PCI DSS v4.0: PCI DSS v4.0 ties retention duration to business, legal, and regulatory context rather than prescribing a specific number of days. A 35-day floor is one way to satisfy those objectives for in-scope systems, but the right value depends on your documented data retention policy and any applicable legal holds.

HIPAA Omnibus Rule 2013: 45 CFR 164.308(a)(7)(ii)(A) requires covered entities to create and maintain retrievable exact copies of ePHI. Thirty-five days covers the typical window for breach investigation, audit, and disaster recovery, which is what Security Rule reviewers check when evaluating backup adequacy.

NIST Cybersecurity Framework v2.0: Retention at or above 35 days feeds into PR and RC function outcomes for data protection and recovery planning. Keeping recovery points for at least that long supports timely restoration after a disruption, satisfies part of the RC.RP category, and gives measurable evidence for Protect-side data management outcomes.

FedRAMP Moderate Baseline Rev 4: CP-9 and CP-10 expect backup copies retained long enough to support the recovery time and recovery point objectives defined in the system contingency plan. At the Moderate baseline, a 35-day floor is the evidence auditors ask for during contingency plan reviews.

Neptune DB clusters should have automated backups enabled

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

Compliance.tf Control: backup_plan_min_retention_35_days
AWS Config Managed Rules: BACKUP_PLAN_MIN_FREQUENCY_AND_MIN_RETENTION_CHECK, BACKUP_RECOVERY_POINT_MINIMUM_RETENTION_CHECK
Powerpipe Control: aws_compliance.control.backup_plan_min_retention_35_days

Last reviewed: 2026-03-09