Immutable Archive - Retention Policy

Retention period, write-lock behaviour, compliance standards satisfied, and GDPR considerations for the VaultAudit immutable archive.

Every document processed by the REFRACT Platform with the Immutable Audit feature enabled is packaged into a tamper-evident .vpdf 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:

Policy state	Modify / overwrite	Delete	Reversible by an administrator?
Applied (default at deployment)	Blocked	Blocked while the policy is in place	Yes - an admin can remove an unlocked policy
Locked (compliance-grade)	Blocked	Blocked until retention expires	No - cannot be shortened, removed, or bypassed by anyone, including the storage account owner

Locking is a deliberate action performed at go-live. Regulator-grade WORM 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. The archive remains in storage and is accessible for continued reference. It is not automatically deleted. Any deletion of expired archives must be performed explicitly by an authorised administrator in accordance with your organisation's data retention and disposal procedures.

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:

Account and resource-group deletion will fail in the Portal, indefinitely

Attempting to delete the storage account or its resource group through the Azure Portal fails with AccountProtectedFromDeletion as long as any container in the account was ever locked - regardless of how long ago retention expired, and regardless of whether the container is empty. This is not a transient error and will not resolve by waiting longer. There is no Portal option to override it.

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

Confirm every blob in the container has been deleted (retention must have expired for each one).
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.
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:

Decision	Parameter / action	Default
Retention length	`AuditRetentionDays` (days; minimum 1, e.g. 2555 = 7 years)	2555 (7 years)
Lock the policy	Locked at go-live once retention is confirmed correct	Unlocked until explicitly locked

The retention window is measured per bundle, from its creation date - not from the deployment date. The archive container uses append blobs with protected append writes, so the audit stream can continue to grow while every already-written block remains immutable.

What the Archive Contains

The .vpdf bundle includes:

Component	Description
Rendered PDF output	The final document as delivered to recipients
Source payload	The structured data used to generate the document
Document template	The template version resolved at generation time
Redaction policy	Any applied redaction manifest (if VaultRedact was used)
Generation manifest	Component hashes sufficient to independently verify and reproduce the original document at any future point in time

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

The bundle is protected by two independent layers: a cryptographic hash chain over its contents (tamper-evidence at the application layer) and the storage-layer WORM policy (immutability at the infrastructure layer). Detecting tampering does not depend on trusting the storage administrator.

Applicable Compliance Standards

A 7-year retention period satisfies the minimum record-keeping requirements of:

Standard	Scope
SOX § 802	Financial records and audit workpapers
IRS Rev. Proc. 98-25	Electronic records required for tax purposes
EU Directive 2013/34/EU	Financial statements and related records
State e-invoice mandates	Most US state-level electronic invoice retention requirements

Sector-specific regulations

Customers operating under sector-specific regulations - HIPAA, FINRA, FedRAMP, or similar - should verify that a 7-year retention period meets their specific obligations. If a longer period is required, contact your VaultPDF administrator to redeploy with an extended AuditRetentionDays value.

Immutability is a data protection guarantee, not a disposal mechanism

The immutability policy prevents modification and deletion during the retention window - it is not a tool for disposing of data on schedule.

Customers with GDPR Article 17 (right to erasure) obligations should review whether their financial audit records are exempt under Article 17(3)(b) (retention necessary for compliance with a legal obligation or the performance of a task carried out in the public interest) before applying deletion requests to archived documents.

Where an erasure obligation applies to records that are within an active WORM retention window, customers should seek legal advice on the intersection of data protection law and financial record-keeping requirements applicable in their jurisdiction.