Application Decommissioning for Information Security, Step 2: Identify and Prioritize Systems to Retire

Every organization has applications that are no longer needed, but which have been left in place to provide access to historical content. In Step 2 of our 6-part blog series, Application Decommissioning for Information Security, I outline how you can identify and prioritize which systems to retire.

The maintenance of dormant applications presents a security risk.

Increasingly, application decommissioning has come within the purview of the Chief Information Security Officer (CISO). That's because these dormant applications are likely to contain potentially petabytes of inactive content. The maintenance of dormant applications not only wastes budget dollars, it presents a security risk to the organization.

But how do you go about decommissioning these dormant applications—and their expensive and increasingly risky content repositories?

In Part 1 of this series, Getting Your Stakeholders on Board, I discussed how to get stakeholder consensus around the decommissioning process. Here, I look at how to identify the specific applications which can be retired—and how to prioritize which applications to decommission—and when.

How to identify and prioritize application systems to retire:

  1. Determine what systems you have in place.
  2. Document key information about each application that helps drive decommissioning decisions.
  3. Analyze the data, then rank and prioritize the opportunities decommissioning presents for each application—and thus for the overall portfolio that your organization manages.

1. Determine the systems you have in place.

Once you’ve aligned the key stakeholders, you need to determine what systems you have in place. That's not an easy task, since most organizations have as many as two to five applications per employee!

2. Document key information about each application with an application inventory.

There’s no single best practice for conducting an application inventory. At the very least, however, an inventory should capture the following information about each enterprise application:

  • Name
  • Description
  • Platform (software, database, and hardware), including version information
  • Integration points (for instance, upstream or downstream hand-offs
  • IT owner
  • Business owner
  • Business process(es) supported
  • Information type(s) at a high level (e.g. claims, billing records, customer data)
  • Data security (e.g. public, internal, confidential)
  • Archiving and backup protocols
  • Annual costs (e.g. software maintenance, storage, the number of FTEs to support the application)
  • Functional capabilities (e.g. document management, collaboration, accounts payable, accounts receivable, billing)

This data can be captured and memorialized in a variety of ways, ranging from a spreadsheet to a full-fledged configuration management database.

3. Analyze the data and prioritize the opportunities.

Typically, an organization will conduct its application inventory and consider that inventory in light of the perspectives of each type of stakeholder. (That perspective is gained once the stakeholders are aligned; see my previous post.)

And while each organization will have distinctive perspectives on how to prioritize applications for decommissioning, the following are some of the key drivers to consider:

  • Cost
  • Functional overlap
  • Compliance risk
  • Operational risk
  • Business benefits
  • IT portfolio sustainability

Packaging Your Recommendations

Using these findings, you would analyze each application and decide for each whether to invest in improving the application, maintain that application or sunset it. Any decision will need to be justified.

Decommissioning and prioritization recommendations typically identify the benefits for each decision, expressed as some combination of cost reduction, cost avoidance, risk reduction and risk avoidance for each application. That analysis also should take in to account the overall effect of what you decide to do with that application on the organization’s technology portfolio as a whole.

Budgeting for the Decommissioning Process

These findings give your stakeholders the information they need to make an initial proposal about how to proceed. But ultimately, the team needs to determine the benefit/cost ratio and time for payback before making the decision to proceed.

Based on your initial recommendations, you can estimate the cost to execute the decommissioning process, which at a minimum will include the following:

  • The purchase of any software and hardware needed to scan, analyze and decommission applications
  • Software maintenance
  • System integration costs
  • Professional services costs (for items such as policy and procedure work, program management, design and solution architecture)
  • Internal resource costs

Next up in this series: How to Define the Archiving Plan for System Decommissioning.

The Doculabs Application Decommissioning Blog Series

Step 1: Getting Your Stakeholders on Board

Step 2: Identify and Prioritize Systems to Retire

Step 3: Defining the Archiving Plan

Step 4: Cataloging Data Within the Target Application

Step 5: Archive and Manage the Content

Step 6: Retire Applications

The CISO's Six-Step Guide to Managing Application Risk

Rich Medina
Joe Shepley
I’m VP and Practice Lead, focusing on developing Doculabs’ InfoSec practice and its applications in a wide range of industries.