Heraclitus of Ephesus once famously said that no man ever steps in the same river twice.
What he meant by this is that the nature of the river is to change -- the water you step into at any given moment is not the same a millisecond later. Heraclitus went on to argue that this same principle could be applied to everything in the universe, from the largest mountain to the smallest grain of sand.
It took a while for modern science to reveal it, but it turns out Heraclitus was right.
We don't often stop to think about it through this lens, but just like Heraclitus' principle of constant change applies to the physical world, it is an apt description of what transpires in the technology ecosystems that run our businesses, as well. At any given second, the "state" of any ecosystem is in flux -- it's in a configuration that has never been seen before and that won't ever be seen again. Like Heraclitus' river, changes are always happening; these include not only larger macro changes (like when new hardware or software is installed), but also micro changes, such as the configuration of memory and storage on an individual device.
As a consequence of this, most IT shops have set up procedures and processes to manage change in the technology environment -- i.e., to make sure business-supporting infrastructure and applications remain available despite the often chaotic changes that might be happening in the background. I'm sure most technologists in the profession can think of a time when change management policies have "saved their bacon" and prevented major catastrophe. However, many enterprises have failed to complete the task of creating a cloud change management policy, a misstep that should be reconsidered.
Why cloud change management?
As you might imagine, changes are no less frequent in a cloud context than they are in a traditional IT environment. The difference, though, is that compared to a traditional IT ecosystem, we may not manage and track changes in the cloud in quite the same way.
This is true for a few reasons. First, because everything below the tier that we purchase is a black box from a customer point of view, meaning we may not see directly the changes that impact the service we purchase. Second, because we're relying on service providers to maintain availability and accessibility of the service they offer, a lot of the considerations that have historically been important from a change management point of view (for example, minimizing downtime) are seen more as the responsibility of the service provider rather than of in-house technology teams.
The point is, only rarely do organizations have change management policies and procedures in place that directly address changes in the cloud. This can put organizations in a tricky position. Not only are there situations where changes can, and do, impact a particular cloud service -- either changes on our side (like changes in how business teams employ particular services), or changes on the service provider side that are still relevant to us (such as how particular services are implemented, how features are added and so forth) -- but it's also relevant from a security point of view. Why security? Because individual changes could have a bearing on the security of business processes that are best reviewed and understood before they propagate out to business teams. For example, imagine a sales-enablement SaaS that allows sales teams to share leads and coordinate activities. Maybe the security team has reviewed that service -- and the proposed usage -- from a risk standpoint and made a decision that, with appropriate monitoring, this usage is in line with the risk appetite of the business. But what happens if that service adds a new feature, for example, the ability to store customer information or quotes? Is that risk analysis still valid? Maybe, maybe not. The risk could very well change in light of the change in usage.
Creating a cloud change management policy
Due to this change in risk, there is definitely a role for cloud change management. However, extending change management processes into the cloud can be a bit more complicated than it might seem on the surface. There are a few things you'll want to account for; note that these are true regardless of the type of cloud service or model you're employing, whether PaaS, SaaS or IaaS.
First, keep abreast of changes to the cloud services themselves. Should a service provider add functionality, make significant changes or modify the service, you'll want to know about it so you can evaluate the impact. Note that there is some information you'll need to accomplish this. It implies that you have the ability to determine what services your business is currently using; if you don't, you'll need to build and maintain an accurate and reliable inventory of cloud services. For each cloud service your organization has in place, you'll need to understand how -- and who -- the provider notifies when changes happen. Many times this is someone in IT, but depending on how the service was set up and who negotiated the contract, it might not be. It's also important to understand what's driving the change: Is it a routine upgrade or new feature? Or is it in response to a security issue that you need to be aware of?
Second, you'll want to evaluate changes for impact the same way you would any other technology. Evaluate what the impact will be of changes that come down the pike and keep key stakeholders, such as security personnel, in the loop to those changes to evaluate if action -- whether it be reevaluation, additive controls or other steps -- needs to be taken. Evaluate it from a feature standpoint (i.e., how will the change impact how you're using the service), as well as from the standpoint on interactions that the change might have with on-premises technology or controls/safeguards that you've set up to secure the service. If the provider supports it, you may wish to consider a test-bed such as a sandbox, one-off instance, or other environment that can be established to allow you to do some hands-on testing of new features or changes.
Lastly, you'll want to keep a record of the decisions you make and the actions you take in response. Keep in mind that the decisions you make today may be impacted by changes that come down the road. Therefore, keeping a record of past decisions, steps that you take and important informational points about the services in scope is relevant and important to a cloud change management plan. It's ideal to tie this together with inventory information so you will be able to call up this information on a service-by-service basis.
All told, a cloud change management policy is both necessary and achievable. Approaching it systematically, tying in processes that you already have and retaining adequate documentation about decisions you make is time well spent.