Management of Change for OT systems
A White Paper By Daryl Shaw
Introduction
For any business, change is inevitable. It is also a requirement to grow market share and maintain competitive edge. Change can be external or internal, with external change often driving internal changes to mitigate challenges to the organization. The challenges could be product or service related (value proposition), sales, services, financial, organizational, or technical, among others. This paper will address managing change at the technical layer of organizations operating critical infrastructure in the Energy sector.
Organizations operating critical infrastructure deal with technology change in two environments, Information Technology (IT) and Operational Technology (OT). Operational Technology infrastructure typically contains an Industrial Control System (ICS), which is a collective term used to describe different types of control systems and associated instrumentation. This includes the devices, systems, networks, and controls used to operate and/or automate industrial processes. Depending on the age of the systems, they may be supported or unsupported by the original manufacturers. In some cases, the physical equipment may be so old that there is a significant concern that it may never come back up if it is shut down.
Management of Change for OT (MOC) is a systematic approach to deal with technical change to the ICS environment. It includes a process that ensures that technical risks are properly documented and managed. MOC also includes a detailed, documented set of procedures and a mitigation strategy to ensure that risks are addressed prior to changes being implemented. The intent is to ensure that all possible contingencies are considered when implementing changes. Change can be operational, technical or security related and may involve system downtime whether intentionally or unintentionally. Having an MOC process in place can help avert unintended consequences of changes, provide documented procedures, and assist with regulatory compliance requirements.
What types of change should trigger an MOC in an operational technology environment? Changes to the infrastructure that could affect its stability, size, design should trigger an MOC while changes which are normally part of day-to-day operations are typically not considered as MOC triggers.
Some questions that must be asked as part of the MOC process include:
- How are changes in the environments tracked?
- What are the communication requirements for the change?
o Who needs to be aware of the change?
o Who needs to approve the change?
- What is the issue that the change is intended to resolve?
- What are the details of the change?
- What could go wrong by making this change?
- What testing is performed to validate that the change is successful?
- What contingency planning is needed to minimize the impact to the organization?
So, what does Management of Change mean for an operational technology (OT) environment? It means we are analyzing, documenting, and implementing changes to the OT environment that potentially improves performance, enhances security posture, address regulatory compliance, and ensure the technology is keeping up with operational requirements.
OT MOCs should be structured and work in conjunction with Process Safety Management (PSM) and Control Room Management (CRM) (if CRM is required to operate regulated assets).Although there may be a certain amount of overlap amongst these processes the MOC should address step by step instructions to ensure all procedures are followed before the change is implemented.
Recommendations
The following steps are recommended to facilitate an MOC process.
- Identify the proposed change and equipment affected
- Evaluate risks associated with this change (include the risks if this change is NOTmade).
- Develop mitigation steps for each risk
- Develop a rollback procedure in case of failure
- Identify and implement documentation and/or procedural changes required because of thechange
- Communicate the change to all affected parties
- Obtain approval(s) to make the change
- Where possible, use a test and development system to validate the change and itseffects
- Schedule and implement the change
o Implement first on a backup environment, if available
o Consider Operations schedule to minimize impact
Best Practices
- Keep the MOC process simple - the less onerous the process, the more likely that itwill be adopted and followed by the end users
- The MOC process should be mandatory for all significant changes
o Changes covered by standard operating procedures may be exempted
- Always minimize impact to the OT environment
- Keep both written and electronic records of all changes for audit purposes
- Be mindful of other changes taking place
Check in with stakeholders for feedback