Model | Operations | Operational Management | System Decommissioning / Legacy Management
Identification of unused of software assets or components
Identify unused applications on an ad hoc basis, either by chance observation, or by occasionally performing a review. When you identify unused applications, process those findings for further action. If you have established a formal process for decommissioning unused applications, ensure teams are aware of and use it.
Manage customer/user migration from older versions of your products for each product and customer/user group. When a product version is no longer in use by any customer/user group, discontinue support for that version. However, at this level of maturity you may have a large number of product versions in active use across the customer/user base, requiring significant developer effort to back-port product fixes.
Do you identify and remove systems, applications, application dependencies, or services that are no longer used, have reached end of life, or are no longer actively developed or supported?
|You do not use unsupported applications or dependencies|
|You manage customer/user migration from older versions for each product and customer/user group|
|Yes, for some applications|
|Yes, for at least half of the applications|
|Yes, for most or all of the applications|
Standardized decommisioning process decreasing the risk of forgetting components
As part of decommissioning a system, application, or service, follow an established process for removing all relevant accounts, firewall rules, data, etc. from the operational environment. By removing these unused elements from configuration files, you improve the maintainability of infrastructure-as-code resources.
Follow a consistent process for timely replacement or upgrade of third-party applications, or application dependencies (e.g., operating system, utility applications, libraries), that have reached end of life.
Engage with customers and user groups for your products at or approaching end of life, to migrate them to supported versions in a timely manner.
Do you follow an established process for removing all associated resources, as part of decommissioning of unused systems, applications, application dependencies, or services?
|You document the status of support for all released versions of your products, in an accessible location|
|The process includes replacement or upgrade of third-party applications, or application dependencies, that have reached end of life|
|Operating environments do not contain orphaned accounts, firewall rules, or other configuration artifacts|
|Yes, some of the time|
|Yes, at least half of the time|
|Yes, most or all of the time|
Full visibility into lifecycle of all software assets
Regularly evaluate the lifecycle state and support status of every software asset and underlying infrastructure component, and estimate their end-of-life. Follow a well-defined process for actively mitigating security risks arising as assets/components approach their end-of-life. Regularly review and update your process, to reflect lessons learned.
Establish a product support plan, providing clear timelines for ending support on older product versions. Limit product versions in active use to only a small number (e.g., N.x.x and N-1.x.x only). Establish and publicize timelines for discontinuing support on prior versions, and proactively engage with customers and user groups to prevent disruption of service or support.
Do you regularly evaluate the lifecycle state and support status of every software asset and underlying infrastructure component, and estimate their end of life?
|Your end of life management process is agreed upon|
|You inform customers and user groups of product timelines to prevent disruption of service or support|
|You review the process at least annually|
|Yes, for some of the assets|
|Yes, for at least half of the assets|
|Yes, for most or all of the assets|