6 Steps to Managing Application Risk - Application Decommissioning

6 Steps to Managing Application Risk

How many applications do you currently have in place that are no longer used? Or no longer useful? It’s very likely you have a lot of them and for different reasons. Maybe you acquired some applications from a merger or acquisition, maybe the apps were getting old and although you know it’s time they go, you haven’t budgeted for system retirement.

What if you could put a plan in place to reduce your application risk and clean house?

Joe Shepley, ‎Vice President and Practice Leader at Doculabs, and an expert in the art of enterprise content management (and yes, there are days we feel it’s as much art as science) created a six step guide to managing application risk that we would like to share with you.

The first three steps are all about getting the right plan in place:

Step One: Gain Stakeholder Alignment

“The hardest part, and the part that keeps most firms from moving forward to successfully retire their obsolete applications, is gaining the organizational alignment on whether and how to proceed.”

IT, lines of business, Information Security, Legal, Compliance, Records Management, Finance, Analytics – all these teams bring different perspectives to the table and it’s critical you listen and understand each group and their requirements. It’s more than simply getting them to agree, it’s about getting true alignment and buy in.

Step Two: Identify and Prioritize Systems to Retire

Figuring out what you have is no small task. As Shepley points out most organizations have 1-4 or more applications per employee. Document this inventory and prioritize those that can go based on things such as cost, level of effort to decommission, functional overlap, compliance risk, operational risk, business benefits and IT portfolio sustainability.

In your inventory, including things such as:

  • Name 
  • Description 
  • Platform (software, database, and hardware), including version information 
  • Integration points (i.e. upstream/downstream handoffs) 
  • 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, FTEs to support) 
  • Functional capabilities (e.g. document management, collaboration, accounts payable, accounts receivable, billing)

Step Three: Define Your Application Archiving Plan

Your application archiving plan could take up to five years or more, depending on the number of applications you decide to decommission.

“There’s no sexy, silver bullet for putting such a plan in place; it’s really all about Program Management 101—i.e. blocking and tackling, focusing on execution, and maintaining a sustained cadence. “

Shepley recommends setting up a program management plan to manage the entire application decommission effort. Don’t think about this as little one-off projects, it won’t work.

The next three steps are all about execution:

Step Four: Catalog the data within the Target Application

You have the big picture. Now it’s time to dive into the details. Starting with the first application, dig into the content it contains. Attempting to do this manually is crazy considering the amount of content the application likely contains.

You’ll need software like File Analytics to analyze the content and tell you exactly what’s stored inside the application. File Analytics can categorize the content for you, helping you understand where you might have PII and PCI content, what content is ROT (redundant, obsolete or trivial), and what needs to be archived.

Step Five: Archive and Manage Content

You know the content that you need to archive. Now you need to archive it. But you want to do this in a way that lets you still have access to it when you need it.

“Successfully managing that archived content requires limiting access to authorized users, supporting the ability to search and retrieve information, and addressing compliance and regulatory requirements (including purging content that’s no longer operationally needed or is past its legal life).”

An application archiving tool will offer you several key capabilities:

  • Content analytics
  • Search
  • Retention Management
  • Litigation Hold

Purging Content in Applications

Step Six: Retire the Application

You’ve dealt with the content in the application you want to decommission, now you are ready to shut down the app. Not so fast. It’s probably not that simple. If it’s a simple app that you were keeping only because you didn’t want to loose the content it contains, then decommissioning is straightforward. If it’s an application that has integrations with other systems, it’s a lot more challenging. Keep these general ideas in mind when planning application decommissioning activities.

  • Applications that are already out of service will be the easiest to decommission 
  • Applications that are needed only for the data they contain will be easier to decommission 
  • Applications that are currently in service and supporting business transactions will be more difficult to decommission 
  • Applications that integrate into other systems will be more difficult to decommission

Learn More

You can read Joe’s full whitepaper here: “CISO’s Six Step Guide to Managing Application Risk.”

This is a topic near to our hearts and one that we will continue to share insights on. Our own Ken Lownie has provided his views on application decommissioning that you’ll also find valuable. If this topic is important to the work you do, sign up for our newsletter and get more insights on a monthly basis in our newsletter.