Server and Application Decommissioning Checklist

Switching off a server or application is easy; removing every account, key, certificate, firewall rule, DNS record and data copy that still points at it is what stops yesterday's system becoming tomorrow's way in. Retired systems leave residual access behind: service accounts that still authenticate elsewhere, SSH keys trusted by other hosts, allowlist entries at partners, dangling DNS records, monitoring and scheduler agents that keep stored credentials, and backups that outlive the retention decision. This template is an end-to-end run sheet for one decommissioning, from approval to sign-off, with numbered checks you can paste into a change ticket. It is for infrastructure, application and change teams, and for the identity and security staff who approve retirements. It links rather than repeats the deep guides on NHI Offboarding and Decommissioning, media sanitisation and dangling DNS.

How to use this template

Copy one template per system being retired. Replace every [placeholder]. For an application spread over several servers, run sections 3 to 10 per component and keep one record.
Mark each line Done, Not applicable (with reason) or Exception (with risk owner), and attach evidence: command output, ticket number, screenshot or export.
Work in the order given. Discovery (section 2) comes first because every later section depends on knowing what the system touched. Removal of DNS and public IP addresses (section 7) is deliberately sequenced against resource deletion to avoid takeover.
Our recommendation is a quarantine period of [30] days between "switched off" and "deleted", with the system powered down or isolated rather than destroyed, so a missed dependency can be restored. Shorten it only for systems with no external dependencies.
The checks are NHI Mgmt Group's recommended baseline. Add organisation-specific items in the blank rows of each table.

1. Decommission record

Field	Value
System name, hostnames and FQDNs	[names]
CMDB or asset ID	[ID]
Environment	[production / non-production / disaster recovery]
Business owner and technical owner	[names]
Reason for retirement and replacement system	[reason, replacement]
Data classification of data held	[classification]
Change ticket and approval date	[ticket, date]
Switch-off date, quarantine end date, deletion date	[dates]

2. Discovery and approvals

#	Check	Result and evidence
2.1	Inbound and outbound connections observed for at least [30] days (flow logs, firewall logs, load balancer logs) and every peer identified.	[ ]
2.2	Every account that logs on to the system, and every account the system uses to log on elsewhere, listed from authentication logs, not only from documentation.	[ ]
2.3	Owners of every upstream and downstream dependency notified, with the switch-off date.	[ ]
2.4	Data retention decision recorded: archive, migrate, retain in backup for [period] or destroy, with legal or records management approval.	[ ]
2.5	Licences, support contracts and third-party hosting agreements identified for termination.	[ ]
2.6	Rollback plan agreed for the quarantine period: how to restore service and who decides.	[ ]

3. Human and privileged access

#	Check	Result and evidence
3.1	Application user accounts and roles removed or the user store archived; SSO application assignment and federation trust removed from the identity provider.	[ ]
3.2	Groups created only for this system (access groups, admin groups) emptied and deleted, and removed from access review campaigns.	[ ]
3.3	Privileged access management entries for the system (accounts, connection profiles, session recording targets) removed.	[ ]
3.4	Local administrator and root accounts recorded as retired; LAPS or equivalent entries removed with the computer object.	[ ]
3.5	Remote access paths (VPN profiles, jump host entries, bastion targets, vendor remote support accounts) removed. The Colonial Pipeline attack began through a legacy VPN account that was no longer used but had not been disabled.	[ ]
3.6	Computer object in Active Directory disabled at switch-off and deleted at end of quarantine; Linux host removed from the domain and from SSSD or LDAP access rules.	[ ]

4. Service accounts, keys and secrets

#	Check	Result and evidence
4.1	Every service account used only by this system disabled at switch-off and deleted after quarantine; accounts shared with other systems have their passwords rotated because the retired host held a copy.	[ ]
4.2	Service principal names (SPNs) registered for the system's services removed.	[ ]
4.3	SSH public keys from this host removed from `authorized_keys` on every other host, and this host's host key removed from `known_hosts` files and SSH certificate authorities' trust lists.	[ ]
4.4	Keytabs issued for the system's principals invalidated by rotating or deleting the principal.	[ ]
4.5	API keys, OAuth clients, app registrations and service principals created for the system revoked or deleted at the issuing platform, not just deleted from the host.	[ ]
4.6	Database logins and connection credentials the system used on other databases dropped or rotated.	[ ]
4.7	Secrets in vaults, CI/CD variables and configuration management for the system deleted or archived, and their access policies removed.	[ ]
4.8	Cloud workload identities (instance profiles, managed identities, Kubernetes service accounts) and their role bindings removed.	[ ]

Platform-specific mechanics for each identity type are in the NHI Offboarding and Decommissioning Guide and How to find and retire Active Directory service accounts with SPNs.

5. Certificates and trust

#	Check	Result and evidence
5.1	TLS server certificates for the system's names revoked with the issuing CA (public or internal) and removed from certificate inventory and renewal automation.	[ ]
5.2	Client certificates and mutual TLS identities issued to the system revoked.	[ ]
5.3	Private keys on the host destroyed with the media (section 9), and HSM or key vault keys used only by the system scheduled for deletion per your key management policy.	[ ]
5.4	SAML or OIDC trust in partner systems and federation metadata entries for the system removed.	[ ]
5.5	Code-signing or document-signing keys held by the system retired, with a record of what they signed.	[ ]

6. Network rules and allowlists

#	Check	Result and evidence
6.1	Firewall rules, security groups and network ACL entries referencing the system's addresses or objects removed on every firewall, not only the local one.	[ ]
6.2	NAT rules, port forwards and published services removed.	[ ]
6.3	Load balancer pool members, virtual servers and health checks removed.	[ ]
6.4	IP allowlists at partners, SaaS providers and cloud services that trust the system's egress address updated; partner contacts confirmed in writing.	[ ]
6.5	Private connectivity (VPN tunnels, peering, private endpoints) used only by this system removed.	[ ]
6.6	Switch ports disabled and VLAN assignments removed for physical servers.	[ ]

A rule left behind after a server is retired lets the next system that receives the IP address inherit its access. See the Firewall Rule Review Checklist for periodic clean-up.

7. DNS, IP addresses and external references

Microsoft's guidance on preventing subdomain takeover is explicit: if a resource is deleted while its CNAME remains, anyone can create a resource with the same name and receive the traffic. It recommends adding "Remove DNS entry" to the decommissioning checklist and putting delete locks on resources with custom DNS entries so the mapping must be removed first.

#	Check	Result and evidence
7.1	All DNS records pointing at the system (A, AAAA, CNAME, ALIAS, SRV) found in every zone, internal and public, including other teams' zones.	[ ]
7.2	DNS records removed before the cloud resource, public IP or hosting name they point to is released or deleted.	[ ]
7.3	MX, SPF include, DKIM and DMARC references to the system removed if it sent or received email.	[ ]
7.4	Reverse DNS (PTR) records removed or reassigned.	[ ]
7.5	Public IP addresses released only after DNS and allowlists are cleared; a released address can be allocated to someone else.	[ ]
7.6	Domain verification and ownership records (for example TXT verification records) reviewed so the name cannot be claimed by another tenant.	[ ]
7.7	Domains registered only for this system: renewal decision recorded. Letting a domain lapse lets anyone register it and receive its email and traffic.	[ ]
7.8	Hard-coded URLs to the system in other applications, documentation, mobile apps and partner integrations found and updated.	[ ]

8. Agents, tooling and records

#	Check	Result and evidence
8.1	Monitoring targets removed and the credentials the monitoring platform held for the system deleted. See SNMP Security Guide for device polling.	[ ]
8.2	Job scheduler agents unenrolled and run-as entries for the system removed.	[ ]
8.3	Backup jobs stopped; backup agent credentials and any backup-only service accounts removed; existing backups retained or destroyed per decision 2.4.	[ ]
8.4	EDR, vulnerability scanner and configuration management agents removed and the asset retired in each console so licences and alerts stop.	[ ]
8.5	Log forwarding stopped; historical logs retained per your logging policy.	[ ]
8.6	CMDB, asset register and architecture diagrams updated to "retired" with the date.	[ ]
8.7	Business continuity and disaster recovery plans, runbooks and on-call rotas updated.	[ ]

9. Data retention, archive and sanitisation

#	Check	Result and evidence
9.1	Data required by decision 2.4 archived or migrated, and the archive's access controls and owner recorded.	[ ]
9.2	Copies outside the system found: file shares, exports, test environments, analytics extracts, replicas and snapshots.	[ ]
9.3	Storage media sanitised using a method matched to the data classification and media type, per your programme based on NIST SP 800-88 Rev. 2. See the media sanitisation guide.	[ ]
9.4	Cloud volumes, snapshots, object storage buckets and database backups deleted, and encryption keys used only for them scheduled for deletion.	[ ]
9.5	Certificate of sanitisation or destruction obtained for hardware leaving your control.	[ ]
9.6	Personal data records of processing updated where the system appeared in them.	[ ]

10. Cloud and SaaS specifics

#	Check	Result and evidence
10.1	All resources tagged with the system's identifier listed and deleted, including ones in other regions and accounts.	[ ]
10.2	Cross-account roles, trust policies and resource policies that name the system's accounts or identities removed.	[ ]
10.3	Storage buckets deleted only after checking whether the bucket name is referenced elsewhere; a deleted bucket name can be re-registered by another party.	[ ]
10.4	SaaS tenant or workspace closed with the provider's documented process; integrations, OAuth grants and API tokens it held revoked in connected systems.	[ ]
10.5	Subscription, account or project closed, or moved to a quarantine organisational unit with deny-all policies.	[ ]

11. Verification and sign-off

#	Check	Result and evidence
11.1	No authentication attempts by the system's accounts, keys or certificates in the [7] days after switch-off (directory, SSH and cloud logs reviewed).	[ ]
11.2	No traffic to the retired addresses or names in firewall and DNS query logs, or every remaining caller identified and fixed.	[ ]
11.3	External scan confirms no DNS names resolve to released addresses or deprovisioned services.	[ ]
11.4	Exceptions listed with risk owner and target date.	[ ]
11.5	Sign-off by technical owner, business owner and security: [names, dates].	[ ]

Implementation guidance

Sequencing and rollback

Discover (weeks before): complete sections 1 and 2; nothing is removed yet.
Switch off: stop services, disable (do not delete) accounts and computer objects, remove load balancer membership, but leave DNS pointing at an internal holding page or sinkhole that you control, and keep public IPs allocated.
Observe: during quarantine, watch for failed authentications and connections (section 11.1 and 11.2). Each one is a missed dependency to fix or document.
Remove: delete accounts, keys, certificates, rules and records (sections 3 to 8). Remove DNS before releasing IPs or deleting cloud resources.
Destroy: sanitise media and delete data copies (section 9), then sign off.

Rollback during quarantine is re-enabling what was disabled. After the remove step, rollback means rebuilding, which is why the quarantine exists.

Small and large organisations

Small teams: run the whole template for every production retirement; for non-production systems, sections 4, 6 and 7 are the minimum because they create external exposure.
Large estates: automate the evidence: query the directory, vault, certificate inventory, firewall manager and DNS for every reference to the system's names, addresses and identities, and attach the outputs. Make the decommission ticket unable to close while those queries return results.

Measuring the process

Percentage of retirements closed with all sections complete or excepted.
Dependencies discovered during quarantine that were missed in discovery (trend to zero).
Accounts, keys and certificates still active 30 days after a system's deletion date (target zero).
Dangling DNS records found by periodic scans (target zero).
Firewall rules referencing retired addresses found in rule reviews.

Common failure patterns

Deleting the host but not its identities: the server is gone, its service account still works from anywhere.
Releasing the IP before removing DNS: the name now points at an address someone else can obtain. See the Subdomain Takeover and Dangling DNS Guide.
Forgetting the far side: rules, allowlists and trust entries at partners and on other hosts survive because nobody owns them.
Agents with stored credentials: monitoring, scheduler and backup platforms keep the system's credentials and keep trying to use them.
Backups outlive the decision: data the business decided to destroy remains in snapshots and tapes for years.

Framework mapping

Framework	Reference	Checklist sections
NIST CSF 2.0	ID.AM-08 systems, hardware, software, services and data are managed throughout their life cycles	1, 2, 8
NIST CSF 2.0	PR.AA-01 identities and credentials managed	3, 4, 5
NIST SP 800-53 Rev. 5	AC-2 Account Management; IA-5 Authenticator Management; SC-12 Cryptographic Key Establishment and Management	3, 4, 5
NIST SP 800-53 Rev. 5	CM-8 System Component Inventory; MP-6 Media Sanitization; SR-12 Component Disposal	8, 9
MITRE ATT&CK v20	T1584.001 Compromise Infrastructure: Domains	7

Server and Application Decommissioning Checklist: Accounts, Keys, DNS, Rules and Data