Skip to content

Decommissioning and Data Purge

When a component is released from active service (an edge device node is retired or sent for repair, a storage volume is replaced, a site is decommissioned, or a whole cluster is torn down), the information it held must be purged so it cannot be recovered from the released hardware or storage. This is the IEC 62443-3-3 SR 4.2 / 62443-4-2 CR 4.2 information persistence requirement (base selection at SL 2): the capability to purge all information for which explicit read authorization is supported from components released from active service. In this system that covers process data, recipes and procedures, audit records, and credentials: every tier in the Encryption at Rest table.

Two procedures elsewhere already cover their own slices and are referenced, not duplicated, here: node re-provisioning during disaster recovery wipes the ephemeral partition (DR Runbook), and credential rotation fully decommissions the old credential (Rotation Runbook § Verification After Rotation). This runbook covers release from service: the hardware or storage is leaving the system's control.

Before You Purge: Retention Obligations

Purging a released component must not destroy records still under a retention clock. 21 CFR Part 11 deployments retain the audit trail and batch records for the validated retention period (3 years in the reference configuration), and the optional S3 Object-Lock archive mirror enforces a Compliance-mode retention floor that cannot be shortened by anyone, including the bucket owner. That immutability is the feature.

The order is always:

  1. Archive — export or confirm archival of every record class the component holds that is still under retention (dcs backup crds, dcs backup audit, historian base backup).
  2. Verify the archive — dcs backup verify for exports, and a restore drill for anything load-bearing (see Backup and Recovery).
  3. Purge the released component (scenarios below).
  4. Verify the purge and record the evidence (checklist at the end).

Scenario A — Edge Device Node Released from Service

Tier: unit-runtime hostPath (persisted FB networks, ISA-88 state replay buffer). These nodes are SBCs or industrial PCs with locally attached storage, the tier most likely to physically leave the building.

  1. Reassign or stop the unit's control responsibility (failover to another device node, or place the unit out of service), then remove the node:
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
kubectl delete node <node>

  1. Sanitize the storage, by node baseline:

    • Talos edge nodes: a full reset wipes both the ephemeral and state partitions (deliberately broader than the DR re-provisioning wipe, which preserves STATE):
    talosctl -n <node-ip> reset --graceful=false \
  --system-labels-to-wipe=EPHEMERAL --system-labels-to-wipe=STATE
    • LUKS-encrypted Linux (the hardened edge baseline from Encryption at Rest): cryptographic erase: destroy every keyslot, which renders the ciphertext permanently undecipherable without wiping the full disk:
    cryptsetup erase /dev/<luks-partition>   # destroys all keyslots
    • Unencrypted storage: media sanitization per NIST SP 800-88 — blkdiscard on SSDs that support deterministic TRIM, ATA Secure Erase (hdparm --security-erase) where implemented, or physical destruction when the device is faulty and cannot execute a sanitize command (the repair/RMA case: if it can't be sanitized, it doesn't ship, so swap the storage out first).

  2. Decommission the node's machine identities (kubelet client certificate, per-node MQTT credentials) per the Rotation Runbook decommission checklist. The released hardware's credentials are then dead even if step 2 was somehow incomplete.

Scenario B — Historian or MQTT Storage Volume Decommission

Tiers: historian PostgreSQL/TimescaleDB PVC (batch records, time-series tags, archived AuditRecords), MQTT broker PVC (retained messages, persistent sessions).

  1. If any contents are still under retention, take and verify a final backup first (§ Before You Purge).
  2. Scale down the consumers so nothing re-creates state mid-purge (historian Deployment / CNPG Cluster, Mosquitto StatefulSet).
  3. Check the PersistentVolume reclaim policy before deleting the claim. A Retain PV survives PVC deletion with its data intact:
kubectl get pv -o custom-columns=NAME:.metadata.name,RECLAIM:.spec.persistentVolumeReclaimPolicy,CLAIM:.spec.claimRef.name
kubectl -n cloud-native-dcs delete pvc <pvc>
kubectl delete pv <pv>   # only needed when reclaimPolicy is Retain
  1. Erase the backing volume. On the encrypted StorageClasses the Encryption at Rest guidance requires for SL 2, deleting the provider volume destroys its data encryption key, a cryptographic erase (CCSC 2 delegation, register entry D14). Where the key is operator-managed (KMS-backed StorageClass), schedule key destruction in the KMS as well. For LUKS-backed local volumes, run cryptsetup erase on the backing device as in Scenario A.
  2. Verify at the provider (console or API) that the volume no longer exists, and in the KMS that the key is destroyed or pending destruction.

Scenario C — Site Decommission (etcd-Resident Data)

Tier: etcd, holding the site's CRs (batches, procedures, recipes, AuditRecords not yet archived) and namespaced Secrets.

  1. Run a final audit archive so every AuditRecord for the site is in the PostgreSQL archive (and Object-Lock mirror where configured) before the etcd copies go away: trigger the audit-archiver CronJob, then dcs backup audit for a verified export.
  2. Delete the Site CR. The site namespace (site-<name>) and everything namespaced under it (CRs, Secrets, the runtime pods) is cascade- deleted with it.
  3. Verify:
kubectl get site <name>          # NotFound
kubectl get namespace site-<name>  # NotFound (allow for finalizer drain)
  1. Deletion removes the objects from the current etcd revision. Copies can linger in etcd's historical revisions and freed pages until compaction and defragmentation run (routine on managed control planes). The at-rest boundary for those residues is the encrypted etcd volume (SR 4.1 RE(1) delegation, register D7). Their hardware-level purge happens when the control-plane nodes themselves are released (Scenario D). Within a live cluster, site deletion plus routine compaction is the complete SR 4.2 procedure.

Scenario D — Cluster Teardown

All etcd-resident data plus every PVC at once.

  1. Final verified backups of anything under retention (§ Before You Purge) to storage that survives the cluster.
  2. Purge every PVC-backed volume per Scenario B steps 3–5.
  3. Wipe every node. Talos: talosctl reset with both EPHEMERAL and STATE wiped, as in Scenario A. On control-plane nodes this destroys the etcd payload including every Secret. k3s: run k3s-uninstall.sh, then sanitize the datadir's backing storage (/var/lib/rancher) with the Scenario A media-sanitization methods. File-level deletion alone is not purge.
  4. Release cloud resources (load balancers, volumes, snapshots) and verify in the provider console that no orphaned volume or snapshot holding DCS data remains.

Scenario E — Archive Buckets and Backup Artifacts

Tier: the S3 Object-Lock audit-archive mirror, CNPG/barman base-backup object store, and dcs backup export files.

  • Object-Lock mirror (Compliance mode, ≥ 365-day floor): objects are undeletable until each object's retention expires. Early purge is structurally impossible, by design and by regulation. The procedure is retention-respecting: list objects with their RetainUntilDate, wait out (or confirm past) expiry, then delete objects and bucket. A decommissioning timeline that needs the mirror gone sooner was decided when the retention period was configured, and purge time cannot revisit it.
  • barman object store: after the final historian backup's retention window lapses, delete the barman bucket/prefix and verify via the provider that no base backups or WAL segments remain.
  • Export files (dcs backup crds/audit outputs and their <file>.manifest.json integrity sidecars on operator workstations or transfer media): delete with the Scenario A sanitization standard applied to the media class, and note the locations in the decommissioning record.

Verification and Record

Decommissioning is complete when every applicable box is ticked and the record is filed with the site's change-management system:

  • [ ] Retained records archived and verified before purge (dcs backup verify output kept).
  • [ ] Per tier: purge method executed and verified (node wipe/crypto-erase confirmed, provider volume gone, KMS key destroyed, namespace deleted, bucket emptied after retention).
  • [ ] Machine identities of released components decommissioned (Rotation Runbook checklist).
  • [ ] Record filed: date, operator, component/hardware identifiers (serials for physical media), sanitization method per NIST SP 800-88 category (Clear / Purge / Destroy), and verification evidence.

Requirement Mapping

Requirement Coverage
62443-3-3 SR 4.2 / 62443-4-2 CR 4.2 (base @ SL 2) This runbook: purge capability documented for every data-bearing tier
SR 4.2 RE(1) / CR 4.2 RE(1)–(2) (shared-memory / verification enhancements, select at SL 3) Not claimed at the SL 2 target
Platform-executed erasure (volume-key destruction, node wipe) CCSC 2 delegation — register entry D14