Cloud Storage Object Lifecycle Policies

Conditional and version-aware lifecycle rules in Google Cloud Storage (GCS) (opens in a new tab) are automated bucket rules that enforce retention, archival, and deletion without manual work. A conditional rule pairs one or more conditions with an action that GCS applies only when an object matches. A version-aware rule extends that logic to both live objects and older archived generations. Together they keep compliance retention and cost control working continuously as new objects arrive.

1.1Conditional Rules Based on Age, Storage Class, and Metadata

Conditional lifecycle rules in GCS apply actions selectively based on object properties instead of acting on every object in the bucket. The condition defines which objects are in scope, such as objects that have reached a required age, objects in a specific storage class that should move to cheaper archival storage, or objects with custom metadata that marks sensitivity or workload type. The action then moves matching objects through their lifecycle, such as transitioning storage class or deleting objects whose business or legal retention period has ended. Because GCS evaluates conditions and actions automatically, the bucket enforces security, compliance, and cost goals even as new data lands.

1.2Version-Aware Lifecycle Management for Versioned Objects

Version-aware lifecycle management in GCS controls live and archived generations separately when Object Versioning is enabled. Object Versioning preserves an overwritten or deleted live object as an archived generation, so one object name can have one live generation plus zero or more archived generations. A version-aware rule can keep the live object available while expiring old archived generations after a defined period, which prevents data loss from overwrites without keeping history forever. Deletion of a specific archived generation is generation-aware and requires the bucket name, object name, and generation number together. The lifecycle evaluation therefore affects only the targeted generation, so the live generation is unchanged when the rule targets an archived generation.

1.3Retention Policy and Soft Delete as Guardrails

Retention Policy and Soft Delete in GCS are bucket-level guardrails that sit beside lifecycle rules to block premature or irreversible deletion. A Retention Policy, configured through Bucket Lock, prevents deletion or replacement of an object until its retention duration expires and enforces minimum retention required by law or regulation. Soft Delete keeps an object for a recovery window after deletion, so it can be restored if a lifecycle rule or user deletes it too early. Together with Object Versioning, the three controls cover different failures: versioning protects against overwrite, Retention Policy enforces must-keep compliance, and Soft Delete protects against must-recover mistakes.

1.4Validating Configuration Against Business and Compliance Requirements

Validation of lifecycle configuration checks whether retention and deletion rules match business requirements and applicable laws and regulations. The control GCP Foundation GCS Has Retention Deletion Rules (opens in a new tab) reports finding category GCS_RETENTION_POLICY_NOT_SET at HIGH severity in Detective and Audit enforcement modes. The control evaluates lifecycle ownership at the organization, folder, and project levels. When the finding fires, remediation is to configure retention and deletion rules for the bucket, verify version handling, immutable retention, and recovery settings, then re-evaluate to confirm the bucket no longer allows unintended loss or excessive retention.

Designing lifecycle rules based on data classification and policy means translating sensitivity, regulatory, and business needs into automated retention, archival, and deletion behavior. In this design, Knowledge Catalog stores two governance tags on each asset, retention_period in days and expiration_action of archive or purge, and automation enforces those values. Once data reaches archive storage, Cloud Storage (opens in a new tab) object lifecycle management continues the lifecycle by moving older files to lower-cost storage classes automatically.

2.1Classification-Based Retention Schedule

The retention schedule is the policy table that maps each data category to how long data lives and what happens at expiration. Tag Engine (opens in a new tab) applies the retention_period and expiration_action tags to tables in the secured data warehouse based on corporate rules in a governance data warehouse, so classification directly drives lifecycle. The default schedule keeps the most sensitive category for the shortest time and removes it without recovery, while less sensitive personal data is kept longer for archival. This gives security, compliance, and cost teams one enforceable definition.

The table values are defaults that can change for organization needs, such as adding Material Non-Public Information or adjusting periods by asset location.

2.2Purge and Archive Execution Paths

The purge and archive paths are the two ordered workflows that carry out the expiration_action after the retention period ends. Cloud Scheduler triggers a serverless workflow using Workflows or Cloud Run functions, and the workflow first reads tag metadata and then evaluates the expiration action. If the action is purge, the workflow creates a table snapshot with an expiration time for soft deletion and recovery, then applies BigQuery table or partition expiration to the source table. If the action is archive, the workflow preserves data and metadata in Cloud Storage before removing the source.

An archive workflow moves data from BigQuery to Cloud Storage in order:

1. Export: Export the table data to Cloud Storage in Parquet format.
2. Register: Register a BigLake table to support external metadata tagging and access control on the archived file.
3. Carry over policy: Copy metadata and policy tags from the source table to the BigLake table, or re-apply tags using Tag Engine.
4. Remove source: Drop or expire the source table to complete archival.

An alternative implementation uses Record Manager, an open-source asset that purges and archives from the same tag values plus a configuration file. Record Manager purging sets a table expiration and creates a snapshot with a configured expiration time, 30 days by default, during which the table can be retrieved.

2.3Extending the Lifecycle to Cloud Storage

Cloud Storage object lifecycle management is the continuation of the retention schedule after archival, focused on lowering storage cost without manual action. Once Parquet files and BigLake external tables land in Cloud Storage archive storage, lifecycle rules automatically transition older files to lower-cost storage classes as access frequency drops. This creates a two-stage lifecycle where BigQuery controls retention period and archive-or-purge, and Cloud Storage controls long-term storage cost. The dependency is explicit: the Cloud Storage transition depends on successful archival from BigQuery, and BigLake preserves access control and catalog tagging so archived objects stay governed.

2.4Governance, Orchestration, and Compliance Detection

Governance for lifecycle rules separates tagging, checking, and acting among different components. Tag Engine owns tagging data in the secured warehouse, Report Engine owns checking whether tags are applied and whether tables meet retention policy, and Cloud Scheduler plus Workflows or Cloud Run functions own enacting expiration or archival. Findings flow from Report Engine to Pub/Sub for distribution to ticketing, dashboards, and a BigQuery governance store. This loop lets every sensitive asset be inspected to prove a lifecycle policy exists and is followed.

Lifecycle violations are reported as distinct misalignments:

• The expiration action for a sensitive asset is not aligned with the policy for the asset location.
• The retention period for a sensitive asset is not aligned with the policy for the asset location.
• Sensitive data exists without retention period or expiration action tags.

Lifecycle actions in Cloud Storage are automated rules that transition objects to archival storage or delete objects when age or other conditions are met. Lifecycle actions enforce retention, archival, and deletion for security, compliance, and cost optimization objectives. A missing or misaligned policy creates compliance risk, which is why absent retention and deletion rules are treated as a HIGH severity finding.

3.1Retention and Deletion Rules as Compliance Controls

Lifecycle retention and deletion rules are compliance controls that keep Cloud Storage aligned with business requirements and applicable laws and regulations. The GCP Foundation check GCS_RETENTION_POLICY_NOT_SET operates in Detective and Audit modes at the organization, folder, and project levels to verify that object lifecycle management is configured. When the check fails, remediation requires configuring retention and deletion rules for the bucket, which may include enabling Object Versioning, setting a Retention Policy with Bucket Lock, and enabling Soft Delete. Without these rules, data may be kept too long and increase exposure, or deleted too early and violate retention duties.

Data risk management gives those rules their governance context, with three intended outcomes: data is properly discovered and classified, risk of data exposure is properly understood, and data is protected by appropriate controls or de-risked through obfuscation. Lifecycle policies depend on discovery and classification because Sensitive Data Protection (opens in a new tab) discovery continuously profiles sensitivity and data risk levels. A deletion or archival rule applied without knowing which buckets hold sensitive personally identifiable information (PII) cannot satisfy a data governance framework.

3.2Archival Transitions and Data Availability

Archival transitions are lifecycle actions that move Cloud Storage objects from standard storage to lower-cost tiers such as Nearline, Coldline, and Archive for long-term retention. The Cloud Storage object remains stored and protected after transition, but its availability profile changes because archival tiers are optimized for infrequent access and cost savings rather than frequent, low-latency reads. A policy that transitions regulated records too aggressively can delay incident response, analytics, or subject-access requests, while a policy that never transitions increases cost and widens exposure. Deletion is more severe because the action removes the live object, so requests from applications and authorized principals to that object will no longer succeed unless a protective copy exists through versioning or soft delete.

Governance requires mapping each transition and deletion to a defined retention schedule. The advanced control Govern the Maximum Retention Period for Sensitive Data detects violations when sensitive data is kept beyond its allowed maximum, which supports privacy principles such as data minimization. The complementary preview control Govern the minimum retention period for Cloud Storage objects enforces a minimum retention period in seconds. Together the two controls prevent both unlawful early deletion and unlawful over-retention.

3.3Encryption Continuity Through Lifecycle Changes

Encryption state in Google Cloud does not change when a lifecycle action transitions or deletes an object. Google Cloud services encrypt customer content at rest and in transit automatically with no customer action required, so an object moved to Nearline, Coldline, or Archive remains encrypted at rest. For sensitive or regulated data, customer-managed encryption keys (CMEK) (opens in a new tab) add a layer where Cloud Storage depends on Cloud Key Management Service (Cloud KMS) keys to access data on every API call. The key location is set when the key is created, and keys can be held in Cloud KMS, in a physical hardware security module with Cloud HSM, or outside Google infrastructure with Cloud External Key Manager (Cloud EKM).

Lifecycle automation therefore depends on continued key availability. If CMEK protection is missing, advanced Enforce CMEK encryption controls detect sensitive data created without CMEK encryption, and Security Command Center correlates Compliance Manager and Sensitive Data Protection ACTIVE findings on the same resource to surface combined risk. If a CMEK key is disabled, destroyed, or denied through Key Access Justifications, Access Approval, and Access Transparency controls, the archived object becomes unreadable even though the lifecycle transition succeeded. Deletion plus key destruction provides strong de-risking, but deletion without key governance leaves audit uncertainty about what remains recoverable.

3.4Legal Holds and Immutable Retention

Legal holds and retention locks override normal lifecycle deletion when litigation, investigation, or regulation requires preservation. A Cloud Storage Retention Policy configured with Bucket Lock creates an immutable retention period during which the protected object cannot be deleted or replaced, and Soft Delete and Object Versioning preserve recoverable copies after overwrite or delete operations. The minimum-retention control enforces that floor in seconds, so a lifecycle delete rule with a shorter age creates a compliance violation rather than a successful early deletion. Lifecycle design must therefore evaluate holds first, then set deletion age only after the longest legal, contractual, and regulatory retention requirement expires.

Key Facts

• Conditional lifecycle rules pair conditions such as object age, storage class, or custom metadata with actions that Google Cloud Storage applies only to matching objects.
• Deleting a specific archived generation requires the bucket name, object name, and generation number together, leaving the live generation unchanged when an archived generation is targeted.
• A Retention Policy with Bucket Lock blocks deletion until retention expires, Object Versioning protects against overwrite, and Soft Delete provides a recovery window after deletion.
• Purge creates a table snapshot and then expires the source table, while archive exports BigQuery data to Cloud Storage in Parquet with a BigLake table and then drops the source.
• Lifecycle transitions to Nearline, Coldline, and Archive do not change encryption at rest, but objects protected by customer-managed encryption keys depend on Cloud Key Management Service key availability for every access.