Change Enablement & Federation: Maintaining Change Velocity in Regulated Environments

[ScottG_SN]

With modern digital organizations transitioning to DevOps concepts for faster and higher volumes of change, creating a concept of modern change enablement is a new challenge for many teams. This issue can be more apparent in regulated environments where certain risks have to be migrated with control measures.

This guide aims to give an overview of the challenges, and some strategies to help organizations break down these barriers to accelerate change. 

 

The Landscape: Automation is no longer a luxury; it is an imperative

With the exponential increase change enablement-focused organizations are seeing as a result of smaller, more frequent changes, automating the change process from registration through to approval and delivery has become a business imperative. As a result, using tools such as multimodal change, visibility through DevOps toolchain integration and automated risk assessment and scoring will be critical to management. The tactics and guidance outlined in this document will support your journey to greater change velocity through automation and the core capabilities of the ServiceNow platform.

Figure 1 - Google's State of DevOps 2022 report showing correlation between key change acceleration metrics and average change failure rate

The 2022 Google State of DevOps report surveyed a wide range of organizations and has shown no correlation between deployment frequency and lead time and change failure rates, which demonstrates that organizations can automate and accelerate change without compromising on delivery quality and risk protection.

One of the most common challenges we face when helping organizations increase the velocity of their change enablement is working in regulated environments.

IT Change Management policies and processes are often mandatory items in leading and common regulatory frameworks such as SOX and ISO27001. Some frameworks fail to keep pace with the changes we see within digital technology, and this can be seen in examples like the integration of development and operations as part of DevOps’ focus on deployment speed and availability.

An example of this is the core requirement for segregation of duty between development and operations teams within SOX IT Change Management controls. Often, organizations have built an air gap between these teams as part of their operating model but are finding it hard to become DevOps focused with this limitation.

Thankfully, there are methods that can be used to maintain control over your audit requirements whilst enabling change through automation and DevOps practices:

Develop clear policies for streamlined change approval

It is often thought that in order to maintain compliance with change management standards in auditing frameworks, all changes must be approved by a central review board, for example, a CAB. This causes delays in releasing new features and fixes, and often frustrates product teams who want to get their new value-adds out to users as quickly as possible.

Developing robust policies around change approval allows you to federate change approval responsibility without requiring a CAB, whilst still meeting the requirements of audit controls. Policies should be written for three key areas:

Incorrect code or configuration is deployed into a production environment that causes outages or degradation in services

Internal security and integrity threats caused by privileged users with malicious intent

External security and integrity threats caused by external actors with malicious intent

Control strategies for these key areas will satisfy many audit controls in common technology standards. The control strategies may vary depending on the change model and operating model, for example, if you are able to bring evidence of testing directly into the change record, for example via a DevOps toolchain integration with ServiceNow via DevOps Change Velocity, this may reduce the burden on proving testing has been completed, automating more of the process, and reducing change lead time. Teams who can’t do this may require another step to fulfil the controls. This provides an incentive for other teams to provide greater visibility of changes to accelerate the process for them.

The DevOps Audit Defense Toolkit provides detailed information on how to develop controls and evidence that enable accelerated change whilst meeting audit requirements. Also ensure you work directly with your auditing partners to ensure there are no surprises when it comes to audit time!

Here’s an example of a control environment that would mitigate risks for area 1 above and form a control strategy without needing all changes to go through the CAB:

Policy 1: All changes that have a change success score of >850 and are considered low risk are not subject to CAB approval but are subject to the accelerated change policy, which is as follows:

1. All code is validated by the orchestration tool to ensure it meets all the standards and rules (syntax etc.); any failure in validation results in the change being rejected
2. Code is peer-reviewed by another developer prior to publishing. Peer-reviewers are trained in reviewing code and review against an agreed standard, for example Google’s coding standards. Additional controls such as randomizing the peer reviewer can also be added to increase peer review impartiality and quality
3. DevOps/IT Operations management teams review change statistics to monitor the ratio of rejections/approvals to determine the quality of peer reviews.
4. No new developers or engineers can submit changes until they have been trained on the policy and risks

Policy 2: All changes that have a change success score between 500-850 or are considered medium risk are subject to the enhanced review policy. They follow all the accelerated change policy rules but in addition:

1. The change must be reviewed and approved by the development/engineering team manager and product manager prior to deployment

Policy 3: All changes that do not meet the criteria of the previous two policies are subject to full CAB review and approval.

Ensure that there is defined ownership and management of all change policies

Working in a federated change enablement organization requires management of multiple change approval policies, like outlined above. Large enterprises may have tens or hundreds of policies depending on the product, technology stack or business unit. As complexity of change models and relevant policies increases, ensure you have owners and approvers responsible for updating and refreshing the policies. Depending on the type of policy, this may be owned by a development or engineering team manager or product manager. You may decide that the CAB will transition from a change approval board to a board focused on reviewing and approving changes to these policies.

Example CAB Transition Journey

Change Manager to Change Enabler: Get ready for the change

One of the biggest changes that will be seen in organizations that are looking to accelerate change will be in the role of the change manager. Where typical change manager roles in the past have focused on:

• Running the CAB
• Reviewing and approving changes
• Maintaining a static list of standard changes

Change managers of the future will take on a more strategic role, ensuring that change is enabled across an organization. Success in change enablement will require the following key competencies:

• Working with teams to make change a seamless part of their roles (integrated with DevOps pipelines)
• Automation of approval based on toolset integrations and data-driven risk assessment
• Enabling faster change through streamlined processes and custom change models that react to business need

Change velocity and automation is a number one priority for digital product-driven organisations, of which regulated industries such as financial services are prime example. Take the tips above as a starting point to kick-start your change enablement strategy.

Collaborate with your audit teams

Making pro-active contact with your auditors (whether they are external, internal or via an internal IT audit team) will help you to enable the transition by discussing the strategies to meet controls whilst accelerating change. Work with them on your new controls and get buy-in and agreement from them well in advance of any surveillance audits. Most auditors are receptive to change and have seen this transition in other organizations.

Key ServiceNow capabilities to support your journey

• Change approval policies: manage your change policies and approvals within the ServiceNow platform. Associate change models to policies to automate the process of approval and management.

• Change success scores and Next generation change risk: Use the data within the ServiceNow platform to automate change risk assessment.

• Change Models: Change managers can use the Change models feature to conveniently tailor change activities and flows for specific use cases.

• DevOps Config: The ServiceNow® DevOps Config application validates and manages the configuration data of your enterprise applications across every stage of the DevOps pipeline.

• DevOps Change Velocity: Use the ServiceNow® DevOps application with your DevOps toolchain to provide data insights, accelerate change, and increase visibility in your DevOps environment using a single system.

Wider ServiceNow capabilities to supercharge your change management and risk control

• Risk Management: Continuously monitor to identify high-impact risks. Engage the first line through familiar user experiences and make better risk-based decisions.

• Policy and Compliance: Manage policies, standards, and internal control procedures that are cross mapped to external regulations and best practices as well as continuously monitor control activities.

• Internal Audit: Utilize compliance and risk data to plan, scope, and execute audit engagements. The ongoing review of policies, risks and controls provides an opportunity for fixing issues before they become audit failures.