Legal Hold Tag

The tag functions as a hard override on automated retention policies. When applied, it intercepts any cron-based or event-driven deletion job targeting the tagged dataset, returning a preservation lock exception. This prevents spoliation even if an administrator manually triggers a data purge. The mechanism operates at the storage abstraction layer, ensuring that immutability flags are set at the object, block, or record level, depending on the infrastructure. Unlike a simple retention policy extension, a legal hold tag typically requires a corresponding release action with a verifiable legal authorization before normal lifecycle management can resume.

Upon activation, the tag initiates an automated chain of custody log for the affected data. This log immutably records every access attempt, administrative action, and integrity check performed on the held dataset. The metadata is extended to include a custodial identifier linking the data to a specific legal matter or case ID. This creates a defensible audit trail demonstrating that the data has not been altered or destroyed since the duty to preserve attached. The log itself is often stored in a write-once, read-many (WORM) compliant storage tier to prevent tampering with the evidence of preservation.

Legal hold tags support two primary operational modes. In-place preservation locks the data in its current production location, minimizing disruption but requiring the production system to respect the hold. Archive preservation triggers an automated copy of the data to a dedicated, secure legal hold repository with strict access controls, allowing production data to continue its normal lifecycle. The tag's metadata schema includes a preservation strategy field that dictates which mode is executed. Hybrid models are common, where metadata and indexes are held in-place while large binary objects are replicated to a lower-cost legal archive tier.

The tag binds data to specific data custodians—individuals or roles identified in a legal notice. The tag's metadata schema includes fields for custodian identifiers, such as email addresses or employee IDs, and the scope of the hold (e.g., all email, specific SharePoint sites, Slack channels). This allows for granular preservation, avoiding the costly and risky over-preservation of irrelevant data. Automated systems use these custodian fields to query and tag all data sources associated with the identified individuals, ensuring a comprehensive and defensible collection process that maps directly to the legal notice's instructions.

A legal hold tag is not permanent by default. It contains a release condition field that can be tied to an external event, such as the closure of a legal matter or the expiration of a regulatory retention period. Upon receiving a verified release signal, the system automatically removes the tag and resumes normal data lifecycle policies. This prevents the accumulation of 'zombie holds' that indefinitely consume storage and complicate eDiscovery. The release process generates a final custody log entry and a certificate of release, providing a clean audit endpoint for the preservation obligation.

A critical distinction exists between these two metadata types. A retention tag defines a fixed, policy-driven lifecycle (e.g., 'delete after 7 years') for regulatory compliance. A legal hold tag is an event-driven exception that temporarily suspends that lifecycle. When a legal hold is active on an object, its retention clock is paused. If a retention period expires while a legal hold is in effect, the deletion is blocked. Only after the legal hold is released does the retention policy re-evaluate the object's age and take the appropriate action, which may be immediate deletion if the retention period had already lapsed.