Append-Only Archive - Retention Policy

Every document processed by the REFRACT Platform with the immutableAudit flag enabled is packaged into a tamper-evident .raudit archive bundle and written to an Azure Blob Storage container configured with a time-based immutability (WORM) policy.

---

Retention Period

7 years from the date of creation (default; configurable at deployment time via the AuditRetentionDays infrastructure parameter).

During the retention period, the archived bundle is write-locked at the storage layer: it cannot be modified or overwritten by any user, application, or administrator. The strength of the deletion guarantee depends on whether the immutability policy has been locked:

Locking is a deliberate action performed at go-live. WORM protection requires the policy to be locked; an unlocked policy protects against accidental modification and overwrite but can be removed by a storage administrator. Once locked, the policy can be extended (lengthened) but never shortened, unlocked, or deleted until the retention window expires.

After the retention period expires, the write-lock is lifted. A blob lifecycle policy is deployed by default: it tiers data to Cool storage after 90 days, to Archive storage after 365 days, and deletes it after AuditRetentionDays (2555 days by default). This lifecycle policy is configurable at deployment time.

Deleting an Archive Container After Retention Expires

Once retention has expired, individual archive blobs can be deleted through the normal Azure Portal or CLI delete operation - no special step is required at the blob level.

The container that held a locked policy is a different matter. It carries a permanent record of having been locked, and that record does not clear once retention expires or once the container is empty. This has two practical consequences for whoever eventually decommissions the storage account:

To decommission a storage account that contains an expired, empty, formerly-locked container:

1. Confirm every blob in the container has been deleted (retention must have expired for each one).

2. Delete the container itself via the Azure CLI using the --bypass-immutability-policy flag - this flag only exists in the CLI/SDK, not the Portal:

   az storage container delete \
     --account-name <storage-account> \
     --name <container-name> \
     --auth-mode login \
     --bypass-immutability-policy

   This flag does not force-delete blobs that are still under an active WORM lock - the delete is refused unless the container is genuinely empty. It only clears the container's leftover "was locked" metadata so the shell can be removed.

3. Once the formerly-locked container is gone, the storage account and resource group can be deleted normally through either the Portal or the CLI.

---

Configuring Retention

Two choices are made at deployment / onboarding:

The retention window is measured per bundle, from its creation date - not from the deployment date. The .raudit archive bundle itself is a single block blob written once at seal time; the eSign and Workflow hash-chain JSONL logs it draws from are separate append blobs with protected append writes, so those logs can keep growing while every already-written line remains in place.

---

What the Archive Contains

A render archive (audit/{docType}/{yyyy}/{mm}/{correlationId}.raudit) includes:

This set of components is sufficient to verify and reproduce the original document at any future point in time.

A signed archive ({correlationId}.signed.raudit, next to the render archive) holds the same components plus the signature manifest, each signature image, and the eSign evidence certificate.

A workflow seal archive (workflow/{tenantId}/{workflowId}.workflow.raudit) is different: it holds the sealed PDF, the workflow schema, a snapshot of the workflow's state and answers, the inputs the seal used, the redaction policy, and a manifest. It contains no document template or source payload.

The bundle is protected by two independent layers: component hashes recorded in the generation manifest (tamper-evidence at the application layer) and the storage-layer WORM policy (write-once, where the immutability policy has been applied and locked for the storage account).

---

Retention and Your Own Requirements

Retention defaults to 2555 days (7 years) and is configurable via AuditRetentionDays. Refract Logic does not hold independent certifications and this page is not legal advice - confirm what retention period your own regulatory or contractual obligations require with your compliance and legal counsel, and set AuditRetentionDays accordingly at deployment.

---

GDPR Considerations