This article was originally published on InBusiness.ae and is reproduced with permission.

Do all users of cloud-based services need to have a service assurance programme in place? Of course not. Can these risks be mitigated in other ways? Yes. Should consideration be given to the importance of a service assurance program? Absolutely.

Across the Gulf, businesses and governments alike are embracing digital transformation, joining what is clearly a very strong global trend. Cloud computing is one of the cornerstones of this trend due to the many benefits it can deliver. Rapid access to new innovations, huge reductions in infrastructure capital expenditure and rapid scalability are just three benefits on offer. Such advantages, as attractive as they are, should not distract cloud service customers from a considered approach to managing the wide range of associated risks. If such risks are managed correctly it will inevitably help to ensure that any cloud-based initiative is a success.

How can risk be managed?

Just like on-premises solutions, cloud computing solutions do carry a wide range of risks. Truth be told, most are very similar in nature. The solutions for managing the risks, however, are often materially different. At the heart of these differences is the degree of direct control an organisation has over the software, IT infrastructure and data used to deliver services to end users.

In the case of a typical on-premises implementation, an organisation buys licences to the relevant software directly from a software vendor, takes possession of the object code (at least) for that software and deploys that software on IT infrastructure in its physical possession and control. By way of contrast, in a pure cloud computing scenario, there is no purchase of a software licence, no need for the delivery of any code and no installation of any software on IT infrastructure by the customer. Rather, the infrastructure, development platforms and software are provided “as a service”. Because of these inherent differences, when it comes to assuring continuity of the service, the cloud computing model places the customer at a major disadvantage when compared with the on-premises model.

Switching off

Put simply, in the cloud environment, and putting contractual terms aside, the supplier can just switch off the customer’s service. The same cannot be said for an on-premises solution because even if the supplier decides to no longer support the software, subject to any existing software-related problems and the terms of the relevant licence, the customer can carry on operating the code on its infrastructure. An immediately effective switch-off is not possible. While the likelihood of a switch-off occurring depends on a variety of factors, the possibility of it taking place is far from fanciful. The cloud service provider could be acquired by a third party which decides to stop the services, it could become insolvent as a result of which the service may be stopped, or it may simply decide to no longer support the service any more, most probably for commercial reasons. These possibilities are very real and do manifest themselves in real life. So how should risk be managed?

Why software escrow should be a necessity

In the IT industry, software escrow arrangements have been around for a long time and are a reliable way to protect both the customer and supplier’s divergent interests in relation to software. On the one hand, the customer wants to ensure that any investment it has made in the procurement, installation and development of the software is not diluted because of the supplier ceasing to support the software. On the other hand, the supplier wants to ensure that the value of its intellectual property in the software is not diluted by the customer or some third party using or exploiting the software in a way which is not consistent with its proprietary rights. Under a traditional standard escrow arrangement, therefore, the parties agree to place the source code for the software in the hands of a trusted third party on the terms of a tri-partite agreement which govern when that source code may be released to the customer and what use may then be made of it. Such an arrangement does not work in the context of cloud services. Even if the customer was given the source code for the solution, where would it deploy the solution, what would it do about the data stored in the cloud and how would it manage that solution with which it has no technical experience other than as a user? The risks and concerns are the same, but the solution to manage those risks and concerns is materially different.

What about regulation?

Reduction or optimisation of costs, agility and decreased risks are fuelling the adoption of cloud computing in the UAE. It has already moved from hype to the mainstream as businesses and governments are moving farther and faster. A recent study revealed that 49 per cent of enterprises have implemented a private cloud model while 35 per cent consider their environment to be a public cloud.

Regulation is a word that features heavily in conversations around cloud software assurance. Regulations that are currently in place, such as the Information Security Regulation (ISR), identify the responsibilities that organisations have to ensure that they are committed to managing risk, while also ensuring that both organisations, and their customers, are not exposed to any potential risk of provider failure.

So what does a cloud escrow arrangement look like?

First of all, because it is not a traditional escrow arrangement, it is probably better to call such an arrangement a service assurance programme. The key difference between the traditional escrow and a service assurance programme is what it covers. A comprehensive programme will involve:

  • Capturing a snapshot of the entire solution used to deliver the cloud service
  • Transferring and documenting the knowledge needed to deploy and maintain that solution if a trigger event occurs
  • Storing and making available the customer’s data which is used by the solution

In contrast, a traditional escrow arrangement would only cover the source code of the relevant software.

Other features of the software assurance programme will be very similar to those of a traditional escrow arrangement, including how and when deposits are to be made, what happens if the deposits are deficient and, very importantly, the trigger events allowing the agent to release the solution to the customer.

When looking at the importance of a service assurance programme, this will probably involve a consideration of the criticality of the services, the speed at which alternative services can be acquired in the event of an interruption, the degree of control the customer has over its own data, the overall cost to the organisation if the service stops versus having an assurance programme in place, and so on. Such considerations are best made at the start of an organisation’s journey to the cloud so that sensible customer and supplier discussions can be had and solutions found.