Decommissioning a System: How to Streamline a Complex Process

Larry G. Wlosinski, CISSP, CISM, CISA, CAP, CRISC, CCSP, CBCP, CDP, ITIL v3
April 2016

INTRODUCTION

Decommissioning a computer system (i.e., stop using or remove from service) is not as easy as it
may sound. You could encounter a variety of issues before and after it is decided that a system
is to be decommissioned or replaced. In this document, we discuss the decommissioning plan
and considerations that should be reviewed as you write it. When a replacement system is
involved, it will be necessary to write a migration plan. This document is intended to help federal
government personnel write the plan and manage the decommissioning process.

PROCESS FLOW

The process of decommissioning a system consists of the following steps: assess, plan,
decommission, archive, and report. When it has been decided1 that a system will be
decommissioned, coordination needs to be performed with the network architects, system
owners, the information technology operations group, information security, and external entities.
The considerations by process are outlined in detail below.

ASSESS

The first step is to assess the environment, which includes governing requirements and the data
sharing agreements. If there is an office that will be downsized due to system discontinuance,
you need to work with the affected office manager to address this concern, especially if it is a
large office because of the many people that could be affected.

Legislated Data Retention Requirements.

The Federal Records Act (FRA) defines recordkeeping requirements for federal
agencies. Records include books, papers, maps, photographs, machine-readable
materials, and other documentary materials regardless of physical form or characteristics
made or received by a United States government agency. All federal systems (including
e-mail) must manage and archive their data per the direction of the National Archives and
Records Administration (NARA).

The Freedom of Information Act (FOIA) provides for individuals to request information
from agencies, but data availability is restricted to a records retention schedule that could
be up to six years. To complicate matters, there are exemptions to FOIA requests to
include national security information, trade secrets, privileged communications, individual
personal privacy information, privileged communications (e.g., attorney work), and more.

1Note that the decision to decommission a system could be a funding decision, a component of the
strategic plan, by the stakeholders, or for some other reason.

1
 If this information is incorporated into the system to be decommissioned, precautions
need to be put in place to protect it from disclosure for extended periods of time.

Data sharing or exchange agreements. Are there any outside agreements in place for your
system and others that depend on the information you provide? Example agreements in the
federal government include (i) the Interconnection Security Agreement (ISA), which usually has a
three year duration, (ii) the Information Exchange Agreement (IEA), which can be for five-years,
(iii) Computer Matching Agreement (CMA), which can be for one year or more, and (iv) a
Memorandum of Understanding (MOU), which can be for many years. Be sure to investigate all
connections and agreements and incorporate your findings into your plan. There may be more
agreements than what is listed above.

PLAN

Owner status. It is possible that when it has been decided to discontinue a system that the
system owner will pursue new job placement, employment, or retirement opportunities. If the
system owner is reassigned to other systems, and there is nothing of major concern, then the
transition will be easy. If there is a lengthy or complicated system retirement plan, then the
system owner will need to write and manage a migration plan.

Network architecture. If a system on the organizations network is to be partly or entirely

removed, then the network architect must be informed. The architect is responsible for every
device connected to the network and must be informed about any changes (major and minor).
This coordination or change activity is commonly performed by the Change (or Configuration)
Management Board (CMB). The CMB is responsible for approving any changes of this nature
and making sure that the transition occurs smoothly and does not upset production operations.
Any presentation to the CMB must be complete and performed with sufficient warning so as to
ensure that every aspect of change has been considered. Remember that the CMB consists of
the experts of the organization who are responsible for the entire organizations production
environment, and its mission.

Operational procedures. Any procedures and responsibility assignments in operations need to

be reviewed to see what can be discontinued. The operational review should include procedure
manuals (including data backup and archiving), any supporting guidance, contingency (or
business continuity) plans, continuity of operations (COOP), and possibly disaster recovery plans.
Be aware that operations may need to review procedures for other systems that are currently
connected to it.

Interconnections and subsystems. You may or may not know it, but your system may feed
data to systems inside your organization and sometimes outside your organization. Just turning
off your system may cause serious problems for those who depend on it. There may be
agreements in place with other organizations, and they may also have agreements in place with
other organizations to share the data. If you are decommissioning a mission critical or high
impact system, be sure you do your due diligence and make a plan before turning the system off.
To make matters worse, if your system is old technology, which has been the center of
information for a long time, you may need to include the development of a replacement system
(that uses new technology) in your decommission and migration plans. Other federal or state

2
 agencies and outside organizations may be involved. An example system is a financial or central
accounting system, or a shared repository that is shared by multiple organizations.

Automated security and operational tools. In many cases, the system to be discontinued may
have had a lot of tools implemented that need to be discontinued or repurposed. Changes can
include configuration settings to: the firewall(s), intrusion detection system, patch management
system, event log management system, operational reporting (e.g., dashboards), archiving, etc.
Technical staff will need detail requirement information, so that they are able to identify and
remove any special settings without affecting other systems that are on the network.

Documentation. There are a variety of types of documentation that need to be considered. The
first is system documentation because copies can exist with the writer, system owner, security
staff, organization architect, supporting outside organizations, etc. Operations manuals for the
system may need to be removed and destroyed. Contingency plans may exist not only with local
operations, data storage/backup sites, and the contingency coordinator, but with other recovery
planning staff. Security oriented documentation from system security assessments should be
archived, and after a time, destroyed. Vulnerability scan reports (soft and hardcopy) should be
destroyed according to organization policy. In some cases, it may be required that certain
documents be stored for extended periods of time because of NARA requirements, FOIA
requests, court orders, or oversight directives.

Systems in the cloud. If the production system is in the cloud, you need to review your
agreement with the cloud provider. There may be termination clauses with penalties as well as
data storage and leasing issues. If there is an organizational policy, or some federal directive or
requirement, you may need to move the system with all its data onto devices at your location (or
a computer environment that you control). In your support termination discussions, make sure
that you address the issue of data that they store at their data center and elsewhere. There may
be a need to adjust some of their usage and access permissions when a cloud system is
discontinued. Also, are there actions (e.g., adjust responsibility assignments, revise
documentation, change procedures, etc.) that you need to make within your organization to
complete the decommissioning?

DECOMMISSION

Access Accounts. Accessibility to the system and its data is also a concern when a system is
decommissioned. Affected areas include user accounts, network and system administrator
accounts, single sign-on, notification alerting capabilities, and government issued access cards.
If you use a Software as a Service (SaaS) emergency alerting system, you will need to discuss
what will be done with the data they hold and have backed up. Both you and the service provider
will also need to discontinue the data connection and all supporting procedures. Another
question to consider is what to do with the final data. Are you required to retain account and
personal contact information for a period of time, or move it to a replacement system?

Inventories. When a system is discontinued the decision of what to do with the hardware must
be made. If it is old or no longer of use to the organization, it may be disposed of and the asset
inventory system can easily be updated. If the hardware is to be reused, then the ownership
would need to be changed. If some or all of the components of the system equipment or
hardware have some future use, then multiple parties are involved and a variety of scenarios can

3
 be put in play. In this event, ownership of the components would need to be clearly defined and
the asset inventory updated as appropriate. This can get complicated if other states and regions
are involved because multiple hardware and software inventories would be affected.

Vulnerability scans. Network devices, servers, user workstations, and web applications may all
be scanned for vulnerabilities on a scheduled basis. If these system scans are automated and
they gather information into a central repository, then they will continue to run unless the job
scripts are removed. Just cancelling the jobs will not ensure that they will not run again. Scans
take up system and network resources and thereby affect others on the enterprise network. Be
sure to remove all scheduled jobs, adjust the parameters of the receiving storage system, and
notify all involved to avoid confusion and problems. Areas involved include operations, other
departments, and outside agencies and organizations (if they are at the receiving end).

ARCHIVE

Sensitive Information. Hardcopy and softcopy documents classified as For Official Use Only
(FOUO), Sensitive But Unclassified (SBU), Law Enforcement Sensitive (LES), Sensitive
Homeland Security Information, Sensitive Security Information (SSI), Critical Infrastructure
Information (CII), etc., require special handling to include special storage arrangements,
transportation, archival, and destruction.

FISMA. The Federal Information Security Modernization Act (FISMA) has many reporting
requirements related to the cybersecurity framework. Changes in hardware assets, endpoints,
and mobile assets must be reported and explained. The metrics affect government activity,
trending, and forecasting. Contracts related to contractors who run your system or facility, as well
as those who use cloud systems approved by the Federal Risk and Authorization Management
Program (FedRAMP) will need to be reviewed when a system is decommissioned.

HIPAA. Under the Health Insurance Portability and Accountability Act (HIPAA) you are required
to protect the data (e.g., health, claims, transactions, costs, etc.) of public and private entities
stored and transmitted, as well as trade secrets. Additionally, you cannot sell, transfer, or use PII
to commercial advantage, personal gain, or malicious harm. If these requirements are not
enforced, then penalties such as a fine, imprisonment, or both, may ensue.

Media sanitization. When you discontinue a system you need to realize that it created data
during its life. The data gathered was stored in the system databases (i.e., server hard drive) and
was backed up to another media for system recovery. If the system was more critical to the
organization, the data may have additionally resided on a mirror system at another location. So,
you may have two locations and multiple sets of backup to control. All of these backups need to
be sanitized (or destroyed) when the system is decommissioned, unless there is an overriding
directive in play.

Recovery. For the federal government, this could be an FOIA request, or a requirement to save
the system in case the information needs to be obtained per a court order request. If this is the
case, the system owner needs to ensure that the data is retrievable, which means that device
readers and associated software are needed, data file retrieval instructions are required, and
there must be a means to print or extract (in part or in its entirety) the requested information. Be

4
 aware, that you may also need to retain any customer or old hardware to accomplish a recovery,
so plan for it.

REPORT

Security assessments. In the federal government, every system has a security assessment on
some type performed according to some schedule. When it is decided that the system will no
longer be around and the designated authorizing official has acknowledged that there will no
longer be a need for further assessments, then steps can be taken to discontinue them. If
however, the system is granted an extension (or two) and it is still connected to the organizations
network, then there is still the risk of compromise. The risk to the network may even be greater if
the system owner did not take security seriously by not applying security patches or making sure
that vigilance was maintained while it was connected to the network. As a result, those who
manage the independent assessments need to be in the loop, and it may be necessary to
continue assessments until the actual plug is pulled.

Security control inheritance relationships. If you are using an assessment repository (e.g.,
CSAM2) and other systems within your organization are using your system as the source from
which security controls are inherited, you need to announce the decommissioning. Before you
remove the system, you should notify management who can then notify all of the other system
owners, assessment planners, and assessment support staff (including outside contractors) who
might be affected. Making adjustments within that systems repository is only part of the work.
The removal of inherited security controls can also mean that new controls need to be put in
place by the dependent systems, and that could take some time and effort. So, incorporate some
time for adjustments in your decommissioning plan for those who inherit the controls, before
removing the system from the repository.

Management oversight. Another security aspect is management-related reporting. Within the

federal government, all systems are registered and monitored not only by the owning
organization, but by upper management who are required to report to controlling and monitoring
organizations like the Office of Management and Budget (OMB). Any change in national system
inventory must be explained and adjustments to reporting made. This is a FISMA requirement.
Notifying other oversight organizations like the General Accounting Office (GAO) and the
Department of Homeland Security (DHS) might also be needed.

DECOMMISSION PLAN

In order to prepare for a successful system decommission, you need to prepare a formal plan.
The plan should include:

System name (with acronym)

An executive summary (that includes concerns and risks)
Statement of plan purpose
Any applicable assumptions that the tasks and schedule depend upon
Planned decommission date
Description of scope (i.e., multiple locations, interconnections, outside agencies, etc.)

2 Cyber Security and Assessment Management system

5
 Points of contact (i.e., plan manager, system owner, security, operations, technical staff,
management, outside organizations, etc.)
Any additional resources (i.e., staffing and funding) required to accomplish the
decommission
System description
Network level diagram(s)
System hardware inventory by location. Be sure to describe what should be done with
the hardware. Hardware disposition options may include device re-purpose, recycle,
donation, degaussing, or destruction.
Software license status of all applicable vendor software and utilities. Can licenses be
terminated early and/or not renewed to save money?
Detail task description with tasking [See Considerations above]
Appendices:
o Tentative schedule of decommission activities
o Management checklist
o List of acronyms
o Glossary of terms

To support the plan the following supporting activities will be required:

Testing of affected systems as components are removed

Management presentations at multiple levels
Coordination and status meetings (e.g., management, security office, outside
organizations, etc.)
E-mail and/or memorandum announcing the decommission along with summaries of the
plan
Lessons learned report with follow-up discussion.

CONCLUSION

As you can see, the act of decommissioning a system should not be taken lightly. There are
many considerations and it could take a long time. Only careful planning leads to success and
the avoidance of many problems and headaches.

Larry G. Wlosinski, CISSP, CISM, CISA, CAP, CRISC,

CCSP, CBCP, CDP, ITIL v3, is a Senior Associate of
Veris Group, LLC, an industry-leading, award-winning
cybersecurity company headquartered in Vienna, VA.

verisgroup.com
E: info@verisgroup.com
T: 703.760.9160
6