Application Decommissioning for Information Security, Step 1: Getting Your Stakeholders Onboard

In a recent post, What's Application Decommissioning Got to Do with InfoSec?I wrote about how dormant applications in your technology portfolio don’t just cost plenty to maintain. I also pointed out that they present significant security risks to your organization. And I argued that Chief Information Security Officers (CISOs) need to be concerned with.addressing these expensive and increasingly risky content repositories. 

In this six-part series, I outline not only why—but how—to tackle Application Decommissioning.

It's problematic when organizations keep files forever.

Inability to reach consensus isn’t confined solely to application decommissioning. It is a larger problem that concerns how corporate data is managed throughout the lifecycle of the data. This tendency leads most organizations to keep everything forever. That's a practice that often violates corporate policies on data management (particularly records retention schedules.) It also impairs risk management efforts. By keeping everything forever, firms expose themselves to unnecessary levels of risk.

Organizational buy-in is the hardest part of an application decommissioning effort.

We all know that when it comes to application decommissioning, the technology component tends to be the easiest part of getting it right. That's because the tools to scan, analyze and decommission applications have been mature for five to 10 years.

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

Each data stakeholder holds a different perspective.

However, as with many necessary corporate activities, it’s not easy to get all stakeholders in an organization at the same table to discuss application decommissioning, let alone getting them to reach a workable consensus.

The first step in bringing the parties together is to understand the perspective that each stakeholder at an organization likely will bring to the topic of application decommissioning.

Here's how you can anticipate the viewpoint of each stakeholder. Indeed, viewpoints tend to be based on stakeholder role and function within the organization. Each stakeholder has a unique set of concerns.

These are some common, department-specific stakeholder concerns:

  • Information Technology: Focus on IT support costs, the need to manage to service level agreements (SLAs), and juggle costs and effort involved in platform maintenance (e.g. managing patches, integration, etc.).

  • Legal: Always a focus on litigation management, as well as e-discovery risks and cost. Also concerned with the ability to ensure legal hold and defensible disposition of content for any applications that are decommissioned.

  • Information Security: Sensitive data exposure, application and network vulnerabilities.

  • Records Management: Compliance with corporate record-keeping policies.

  • Compliance: The need to meet regulatory, trade, and industry standards, as well as corporate obligations.

  • Business Stakeholders: Focus on operational efficiency and costs of training users for applications that few people use. Also concerned about availability of information from decommissioned applications.

  • Finance: Cost/benefit analysis of maintaining the status quo versus taking action.

You’ll need to keep these various perspectives in mind as you work to gain consensus and get the alignment needed to move forward with decommissioning.

Follow these 5 steps to achieve stakeholder alignment:

Once you have everyone at the table, there are five things you need to do to ensure alignment. Achieving alignment goes far beyond simply having everyone agree that something needs to be done, although that’s an important first step. At a minimum, you need to accomplish the following:

  1. Articulate (and acknowledge) the variety of viewpoints represented.
  2. Document what a “win” would look like for each stakeholder group.
  3. Quantify high-level benefits and costs for realizing the proposed decommissioning, even if only in outline form. This includes direct savings, indirect savings, as well as risk and cost avoidance. Rank the decommissioning opportunities.
  4. Determine how the defined benefits of application decommissioning align with your organization’s higher-level corporate priorities.
  5. Define organizational goals for application decommissioning, along with the high-level approach to be followed.

The decision is whether to invest in, maintain or sunset each application.

All of this information will be put to further use later in the decommissioning process, as you begin to weigh the benefits of various applications in your existing technology portfolio and decide whether to invest, maintain or sunset each application. You'll also need to articulate the justification for each decision.

When they’ve been informed and given the chance to provide input early on in the process, your stakeholders will understand your subsequent decommissioning and prioritization recommendations.

In my next post, in Part 2 of this series, that’s exactly where we’ll be going: How to identify and prioritize the systems for 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.