As an IT lawyer I benefit every day from my business science background and my extensive experience in business systems implementations. Particularly cloud implementations in regulated industries are projects in which the project management and IT law combination is valuable to my customers. Business strategy, project management, the contractual framework and compliancy are deeply interwoven in these projects. Being able to provide control over these aspects integrally is of exceptional value to the implementing organization. Not only does it prevent a project to move off-track, it also enables effective communication with the relevant regulators.
The meaning of the word ‘cloud’ in this context requires some clarification first. This blog is about business information systems in the financial services industry. So, also ‘cloud’ is limited to this. It can concern PaaS (Platform as a Service) or even only IaaS (Infrastructure as a Service) in which proprietary or licensed standard software is running. It can also be SaaS (Software as a Service). Within SaaS, there is a wide range of software applications it could concern. This blog can apply to any of these situations but is mostly relevant in case of a high complexity of the envisaged solution. For example, moving an existing marketing material content management system into an IaaS would probably not qualify as ‘high complexity’ while a full new implementation of core administrative business systems into a SaaS would.
A few years ago cloud solutions were only considered to be viable for non-business critical applications in the financial services industry. There is a clear tendency now to move a much wider range of information systems to the cloud, including complete infrastructures. The key reasons for this development are the acceleration of cyber threats that can more easily be fought by large and very specialized technology providers and also by a general business need to truly integrate systems such as terminal services, various office applications, workflow systems, document management systems, and all sorts of formal business systems, such as ERP and customer relationship management systems. Projects like this have a different character than on-premise projects. The differences revolve around issues related to:
- Strategic business objectives
- Strategic IT objectives
- Project objectives
- Integration of technical and functional aspects of information systems implementation
- Specific requirements from regulators
Typically, each of the aspects mentioned above are being handled and defined by a variety of people each operating in their own field of expertise. Also, usually the contracts will be negotiated by contract lawyers while contacts with regulators are usually handled by compliancy officers. Strategic project management is typically a steering committee task in which senior management of both the business and IT are represented. The contract lawyer is then already out of the picture and compliance mangers are usually not in a steering committee. Solutions concerning security setup and access management are developed by specialists in the relevant fields.
During the contracting stage all of the above aspects need to be taken into account. This is necessary to make sure all aspects of the project are well integrated. If that doesn’t happen, risk analysis on the project will show lack of integral approach and it may not be easy to correct that. It will also show when questions of regulators cannot be answered adequately. If a cloud project entails activities in multiple jurisdictions there shall be a different approach of the regulators in each jurisdiction. However, the requirements of regulators have one thing in common: They all relate to the quality of the contracts underlying the project and strategic and integral project execution quality.
Contracting cloud services
The key step when moving to cloud solutions is the selection of your service providers. They must be able to render services in a way that ensures the financial services company is and will remain compliant with all requirements. The service providers must also be willing and able to commit to these specific requirements contractually. This may sound obvious but execution is often not simple. Especially in case of public cloud solutions suppliers cannot simply change contracts and their commitments. After all, the offering is standard and should comply with all requirements as offered in the first place. This means that the supplier contracts must be analyzed in detail to verify if all requirements are being met. And if not, how this can be overcome.
Also contracts arranging the project execution are critical in this respect. Many requirements are too specific to tackle in the contract stage and must be managed during the project. It is important to ensure this is clear and is explicitly managed in the project. The way this is being done must be agreed upon in these contracts. During the project high awareness remains essential in order to ensure project decisions will not cause problems in terms of compliance.
Execution of Projects
During cloud service implementations one must continuously align what happens in the project with what was contractually agreed and guarding the project objectives and project constraints. This relates in particular to:
- User access management to the new systems
- The security setup – including networks to connect to physical workplaces –
- Certain functional choices that may affect the level at which strategic objectives shall be achievable
- Development of an exit strategy.
These choices are not only of vital importance to the implementing organization, they are of vital importance in order to gain and keep approval of regulators. Regulators require notifications and sometimes up-front approval of cloud implementations. The requirements for these notifications and requests for approval are sometimes quite extensive and require a specific approach which may be rather different per regulator, depending on the jurisdiction. It helps if the person writing these notifications and requests has a deep and wide understanding of the project – or has direct access to people who can provide the relevant input and the ability to interpret such input.
Data security and data access
Security and access management in on-premise systems are typically issues addressed by IT departments who have specialists in these fields that ensure security. When moving to cloud solutions these subjects suddenly become high-level requirements rather than in-depth highly specialized activities. The solution is judged on a more generic security level approach of the cloud supplier, the audit possibilities and the tracing facilities offered. Once satisfactory levels of security and access control have been confirmed the key concern is how to verify if the supplier actually does what he promises. Old school auditing rights will often not be possible because if one cloud environment contains systems of multiple companies the provider cannot have them all at the same time coming in auditing. Audits will have to be coordinated. As a result, the customer must rely on third party audits. However, more importantly, full traceability of every data access allows for verification of the security levels. The problem with these traceability facilities is that the access data is voluminous and requires specialized analysis which may require people with completely new types of expertise. This blog just addresses possible concerns. There can be various solutions but in all cases these issues must be addressed.
Continuity & Exit
Continuity of business critical systems is crucial to the existence of the organizations using these systems. It is not attractive if survival depends on one supplier. Nonetheless, this is what happens when entering into a cloud environment for business critical applications. In cases of a dispute with the supplier this situation puts the supplier in an extremely powerful position. Risks of bankruptcy of suppliers must be considered seriously and the scenario’s thereafter must be evaluated. There is of course also the risk that the service availability is bad. This may also jeopardize the continuity of the user-organization.
In all cases where continuity is not sufficient or threatened, the users organization must be able to transfer to another infrastructure. For this reason a well developed exit strategy must be brought in place. It must describe what should be done to move to another infrastructure. The more complex the environment is the larger the challenge development of a proper exist plan is. If the reason was to implement security levels that are not achievable on a stand-alone basis, moving back on-premise may not be a serious option anymore on the longer run. It might cause insufficient control on security related matters. Also, the specific expertise to manage system security will probably not be in-house and may not be easy to acquire. This means that moving to another cloud infrastructure may be required. Now, if integration of terminal services, document management and various administrative systems have been realized it may not be easy to move to another IaaS because the whole infrastructure may have been designed for the specific IaaS it runs in. This may leave no other option than a complete new system implementation. Again, this blog doesn’t provide a specific solution but it addresses potential issues to be considered. It must be clear that a good understanding of all business aspects, technical aspects and project management aspects, as well as regulatory requirements are vital to develop reasonable exit solutions.
Cloud implementation may be highly complex impacting all aspects of the business of the implementing organization. It is vital to ensure an integrated view continues to exist of all business, legal, technical and regulatory aspects from the initial stages and throughout the entire project.