Skip to main content

More Info:

Boot volumes should have a backup policy assigned. Without automated backups, data loss from instance failure, corruption, or ransomware cannot be recovered.

Risk Level

Medium

Address

Compliance, Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • Cloudanix Best Practice
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • Reserve Bank of India (RBI) Master Direction – Information Technology Framework
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • Securities and Exchange Board of India (SEBI) - Cloud Security Adoption Framework
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Using Console

To remediate “OCI Compute Boot Volumes Should Have Backup Policy Assigned” using the OCI Console:

1. Assign a Backup Policy to Existing Boot Volumes

  1. Sign in to the OCI Console.
  2. In the left navigation menu, go to:
    Menu → Storage → Block Storage → Boot Volumes.
  3. At the top, select the correct Compartment where your instances/boot volumes reside.
  4. For each boot volume that shows No backup policy:
    1. Click the boot volume name.
    2. On the boot volume detail page, click Assign Backup Policy (or Edit if available).
    3. In the Backup Policy dropdown, choose an appropriate predefined policy, for example:
      • bronze (daily, shorter retention)
      • silver (daily + weekly, medium retention)
      • gold (daily + weekly + monthly, longest retention)
        or your custom policy if you have one.
    4. Click Assign (or Save changes).
Repeat for all non-compliant boot volumes.
To avoid future non-compliance:
  1. Go to: Menu → Storage → Block Storage → Block Volume Backups → Policies.
  2. Either:
    • Use an existing Predefined Policy, or
    • Click Create Policy to define a custom schedule/retention.
  3. Once you’ve chosen the policy, set it as default for a compartment:
    1. Go to: Menu → Identity & Security → Identity → Compartments.
    2. Select your Compartment.
    3. Look for Default backup policy for block/boot volumes (wording may vary by console version).
    4. Choose the desired backup policy and Save.
New boot volumes in that compartment will automatically get this backup policy.

3. Verify Compliance (for Monitoring / Security Reports)

  1. Return to: Menu → Storage → Block Storage → Boot Volumes.
  2. Confirm that the Backup Policy column shows a policy (not “None”) for every boot volume.
  3. If you are using Cloud Guard / Security Zones / Security Center-like monitoring, run or refresh the compliance check so the “boot volumes should have backup policy” finding is cleared.
Below are step‑by‑step CLI instructions to assign an OCI Block Volume Backup Policy to Compute boot volumes so they comply with “Boot Volumes Should Have Backup Policy Assigned.”

1. Prerequisites

  1. OCI CLI installed and configured (~/.oci/config with a working profile).
  2. OCIDs ready:
    • Your tenancy OCID and/or compartment OCID.
    • User running CLI must have permissions to manage boot volumes and volume backup policies.
Assume:
  • Profile: DEFAULT
  • Compartment OCID: ocid1.compartment.oc1..xxxx
If you use a different profile, add --profile <PROFILE> to every oci command.

2. List Available Backup Policies

First, see which backup policies exist in your region (Oracle‑managed or custom):
Common Oracle‑managed policies are usually named like gold, silver, bronze.
Pick the policy-id you want; call it:

3. List Boot Volumes in a Compartment

Each entry has a id field; that is the boot volume OCID.
For scripting, grab them as:

4. (Optional) Identify Boot Volumes Without a Policy

To see current policy assignments for all volumes in the compartment:
For a specific boot volume:
If this returns an empty list, the boot volume has no backup policy and is non‑compliant.

5. Assign Backup Policy to a Single Boot Volume

Use the chosen policy OCID from step 2 and the boot volume OCID from step 3:
Verify:
You should see the selected policy associated.

6. Bulk‑Assign Policy to All Boot Volumes in a Compartment

This loop assigns the same backup policy to every boot volume in the compartment:

7. Confirm Compliance for Monitoring

Re-run:
Ensure every boot volume reported by:
has at least one corresponding volume-backup-policy-assignment. Your OCI monitoring / security/compliance tool should now show “Boot Volumes Should Have Backup Policy Assigned” as remediated.
Here’s how you can remediate “OCI Compute Boot Volumes Should Have Backup Policy Assigned” using Python and the OCI SDK, by:
  1. Finding boot volumes without a backup policy
  2. Assigning a chosen backup policy to them

1. Prerequisites

  • Install the OCI Python SDK:
  • Set up your ~/.oci/config file with:
    • tenancy, user, fingerprint, key_file, region
    • A profile name, e.g. [DEFAULT]
  • Ensure the principal (user/group/instance/principal) has IAM permissions similar to:

2. Decide which Backup Policy to Apply

You can use a predefined policy (e.g. “gold”, “silver”, “bronze”) or a custom one.Example: find available backup policies and pick one:
Copy the id of the policy you want, e.g.:

3. Script: Assign Backup Policy to All Boot Volumes Without One

This example:
  • Iterates over all compartments (recursive)
  • Lists boot volumes
  • Checks if each has at least one backup policy assignment
  • Assigns TARGET_BACKUP_POLICY_ID where missing

4. Integrate with Monitoring / Compliance

Typical options:
  • Run this script on a schedule (e.g., cron on a bastion host, OCI Compute instance, or OCI Container Instances).
  • Or, wrap it as an OCI Function invoked by:
    • An Event from Cloud Guard/Cloud Events when a new boot volume/instance is created.
    • A periodic trigger (e.g., via external scheduler or Functions + Alarm/Event).
The logic stays the same; only the execution environment changes.
This change does not replace the existing boot volume; it only attaches a backup policy to it.For verification, terraform plan should show creation of an oci_core_volume_backup_policy_assignment resource (and optionally an oci_core_volume_backup_policy if you added one), with no planned replacement of the existing oci_core_boot_volume.