Canal bylaws require lock-camera footage to remain unaltered and undeleted for seven years. Which storage protection should the security engineer configure?

Canal bylaws that require lock-camera footage to remain unaltered and undeleted for seven years call for a time-based retention immutability policy (container-level or version-level WORM), understanding that a locked policy cannot be shortened. Time-based immutability enforces write-once read-many protection for a known fixed interval—the right match for a seven-year bylaw rather than an open-ended investigation hold. Soft delete and versioning help recovery but do not provide the same WORM guarantee municipal auditors expect for footage retention.

Configuring soft delete with a seven-year retention and allowing operators to clear soft-deleted items anytime fails by concept: soft delete is recoverable deletion, not immutable WORM, and operator clearing defeats long retention. Using blob versioning without immutability so editors can prune old versions freely during the seven years fails because prunable versions are not a locked unalterable retention seal. Using a legal hold only, even though the retention period is a known fixed interval rather than an open investigation, fails because legal hold is event-driven; a fixed bylaw period maps to time-based retention.

Exam caveat: locked time-based immutability cannot be shortened until expiry; choose legal hold for indefinite or event-driven cases and time-based policies for fixed intervals such as seven years. Operational check: enable versioning if using version-level WORM, apply a time-based retention policy for seven years on the footage container, lock the policy per compliance process, verify delete and overwrite attempts fail, and record in the canal records schedule that the locked policy outlasts staff turnover.