Three weeks after go-live, the security department mandates encryption at rest on the production appliance - which is now full of live backup data. Why is this a bring-forward decision rather than a checkbox that can be flipped at any time?

The key hierarchy that encryption at rest relies on is established at enablement, and the platform's enablement path requires initializing the encrypted state - on a populated system that means cryptographically erasing stored data. The rule follows directly: the feature must be on before data exists, so go-live procedures fold the encryption decision into deployment rather than a later compliance project. For this system, the honest options are deliberate re-initialization with validated backups, or documented compensating controls while a migration is planned. New-writes-only conversion borrows array-based volume-encryption mental models and does not match this platform's mechanism; lazy per-block conversion is not the enablement path. An in-place re-encryption weekend is the same invented capability in different clothing - the operation on a populated system is initialization, destructive of existing data by definition. Physical destruction to activate licensing is wrong twice: activation is not tied to destroying hardware, and crypto erase exists so leaving-custody media needs no destruction. Exam caveat: treat encryption-before-data as a deployment-order rule, and put erase operations under the same sensitive-task approvals as key management. Operational check: audit every production system lacking encryption at rest and record the decision for each - rebuild window or compensating control.