- 01Most security programs have well-defined deployment processes. Decommissioning is consistently weaker. A system that has been 'turned off' but still has DNS records, certificates, IAM grants, and an active service account remains a risk surface.
- 02Decommissioning checklist: DNS (every record removed or repointed), certificates (revoked or allowed to expire and tracked), IAM (service accounts disabled, keys rotated and removed from secret stores), network (security groups, firewall rules, load-balancer entries removed), logging (pipeline configurations updated; long-term logs retained per policy), backups (final backup taken, retention scheduled), documentation (runbooks/dashboards/alerts archived), asset register (system marked decommissioned with date and owner).
- 03Why this is hard: decommissioning lacks the urgency of deployment. There is no business event driving completion. The work falls to whoever is paying attention; in many organizations, no one is. Make decommissioning an explicit project gate with owner and verification — otherwise it becomes 'mostly done' indefinitely.
- 04Verification: quarterly reconciliation between asset register and DNS, IAM, and network records. The drift surfaces systems that should be decommissioned but are not — and systems that are running but are not in the register, the equally common problem.
Most security programs have well-defined deployment processes. Decommissioning is consistently weaker. A system that has been 'turned off' but still has DNS records, certificates, IAM grants, and an active service account remains a risk surface.
The decommissioning checklist
- 01DNS — every record pointing to the system removed or repointed
- 02Certificates — issued certificates revoked or allowed to expire and tracked
- 03IAM — service accounts disabled, keys rotated and removed from secret stores
- 04Network — security groups, firewall rules, load-balancer entries removed
- 05Logging — pipeline configurations updated; long-term logs retained per policy
- 06Backups — final backup taken, retention scheduled per policy
- 07Documentation — runbooks, dashboards, alerts archived or removed
- 08Asset register — system marked decommissioned with date and owner
Why this is hard
Decommissioning lacks the urgency of deployment. There is no business event driving completion. The work falls to whomever is paying attention; in many organizations, no one is. Make decommissioning an explicit project gate with owner and verification — otherwise it becomes 'mostly done' indefinitely.
Verification
Quarterly reconciliation between asset register and DNS, IAM, and network records. The drift surfaces the systems that 'should be' decommissioned but are not — and the systems that are running but are not in the register, which is the equally common problem.