Establish Software End of Life Procedures
Create and share guidelines for safely removing and managing old software and user data.
Plain language
This control is about knowing when and how to safely get rid of old software and make sure that any data or user accounts linked to it are either stored securely or destroyed if no longer needed. It matters because outdated software can be a security risk, and holding onto unnecessary user data can expose your organisation to data breaches.
Framework
ASD Information Security Manual (ISM)
Control effect
Proactive
Classifications
NC, OS, P, S, TS
ISM last updated
May 2025
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
End of life procedures for software, covering how to remove the software and how to archive or destroy any user accounts and data, are produced and made available to consumers.
Why it matters
Without end-of-life procedures, obsolete software may remain installed and user accounts/data may persist, increasing exposure to unpatched vulnerabilities and data leakage.
Operational notes
Document and publish EOL runbooks: uninstall/disable software, revoke access, archive or destroy accounts and data, and confirm completion before decommissioning.
Implementation tips
- The IT team should create a clear checklist for when software is no longer supported or used. This list should include steps for removing the software from all systems and ensuring any related data is archived correctly or securely deleted.
- Managers should identify software that is nearing its end of life by regularly reviewing software usage and support timelines with the IT team. They can do this by setting up quarterly meetings to discuss which software is still actively used and which ones need to be phased out.
- System owners should communicate with employees about upcoming software removals to ensure everyone is aware of what changes will occur and when. This can be done through internal newsletters or dedicated meetings to explain the reasons and steps being taken.
- Data protection officers should work with the IT team to define clear guidelines on how to handle user data linked to outdated software. This includes deciding whether data should be archived for legal obligations or destroyed if it is no longer needed.
- Procurement teams should ensure that any new software contracts include clear terms regarding end-of-life procedures, so the organisation is prepared from the start. They can do this by consulting with the legal and IT departments to cover all necessary points before signing contracts.
Audit / evidence tips
- AskThe software end-of-life policy document GoodWould be a detailed policy that includes step-by-step procedures and responsible persons
- GoodWould be a list showing all software in use with corresponding end-of-life dates
- AskRecent meeting notes discussing software end-of-life procedures GoodWould show regular meetings with actionable decisions recorded
- GoodIs demonstrated by emails or meeting records showing users were informed ahead of time
- AskRecords of data handling after software removal GoodShows documented proof of actions taken, aligned with defined procedures
Cross-framework mappings
How ISM-2053 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| sync_alt Partially overlaps (2) expand_less | ||
| Annex A 5.16 | ISM-2053 requires organisations to define end-of-life procedures for software, including how to archive or destroy user accounts and asso... | |
| Annex A 8.10 | ISM-2053 requires documented software EOL procedures that explain how to remove retired software and how to archive or destroy related us... | |
| handshake Supports (1) expand_less | ||
| Annex A 7.14 | ISM-2053 covers end-of-life procedures for software, indirectly supporting Annex A 7.14 by addressing licensed software management during... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.