Section navigation
ARCS-LIF: Record Lifecycle
Foundation Profile
The ARCS-LIF family addresses the handling of records over time. The controls in this family govern when a record is created, how it is classified, how long it is retained, when deletion is required, and how lifecycle changes are documented. These controls are grouped together because lifecycle treatment is not a single event. It is a sequence of governed decisions that determines whether records remain manageable, reviewable, and subject to declared policy.
The formal definition and scope of this family are maintained in the Standard.
| Control | Description |
|---|---|
| LIF-01 | The operator SHALL define default retention posture for each record category. |
| LIF-02 | The operator SHALL define preservation posture triggers: litigation, regulatory inquiry, contractual audit, internal investigation. |
| LIF-03 | The operator SHALL define preservation scope: categories, systems, vendors, time period, derived artifacts. |
| LIF-04 | The operator SHALL suspend deletion controls upon preservation trigger: primary storage, backups, safety records, vendor-held copies. |
| LIF-05 | The operator SHALL distinguish user-visible deletion from backend retention; document which copies remain and why. |
| LIF-06 | The operator SHALL define multi-vendor preservation procedure: vendor notice, compliance verification. |
| LIF-07 | The operator SHALL define exit from preservation posture: authority required, eligible categories, auditable release. |
| LIF-08 | The operator SHALL produce lifecycle disclosure sufficient for procurement, audit, and legal evaluation. |
| LIF-09 | The operator SHALL implement non-creation and non-retention controls where applicable; auditable claims are required. |
| LIF-10 | Where agentic workflows generate artifacts requiring different retention classes within a single session, the operator SHALL support per-artifact retention classification distinguishing retained deliverables from ephemeral process artifacts. |
| LIF-11 | Governed persistence: where records must persist across sessions for operational reasons but contain deliberative content, the operator SHALL define maximum retention duration, encryption requirements, backup exclusion policy, and preservation override procedure. |
| LIF-12 | Vendor deletion verifiability: for each vendor surface, the operator SHALL document whether the operator can verify that deletion requests have been carried out, the verification mechanism available, or state that no verification mechanism exists. |
| LIF-13 | Architecturally precluded deletion: where vendor storage architecture does not support deletion (append-only ledgers, immutable logs, blockchain-based systems), the operator SHALL document that deletion is architecturally precluded, identify affected surfaces and record classes, and treat such records as permanently available for production. |