For compliance professionals, there's no overstating what a huge challenge a cloud transition can be. A cloud deployment is challenging to start with, from both a technical and operational level. Add to that the added complexity of ensuring post cloud deployment adherence to regulatory requirements, such as PCI DSS, HIPAA, the Sarbanes-Oxley Act and FISMA, and it becomes even more difficult.
The biggest challenge from a regulatory and data risk standpoint comes about when an organization's compliance team encounters a cloud deployment "after the fact." This happens more often than you might think: Most cloud deployments don't happen in a graceful, workmanlike manner where compliance teams are kept in the loop from inception through the final stages of implementation. Instead, what happens more often than not is cloud adoption is far along before compliance teams even realize it's in place. Reasons for this are varied. Most commonly it occurs when business teams bring in a cloud service without realizing they should engage the compliance department. Another common under-the-radar transition occurs when existing cloud technology expands its scope from handling non-sensitive information systems, such as development and QA boxes, to include regulated environments or to process, store and transmit regulated data.
When this backdoor cloud deployment happens, compliance professionals find themselves behind the proverbial eight ball. By that point, mitigation options are sparse because contracts are already signed, environments are already developed, controls are already in place and due diligence assessments have already been completed or, in some cases, not. What can compliance professionals do at that point? Below are a few immediate steps they can take.
Step 1: Don't panic. Assess and document risk
Let's say a hospital's compliance professional discovers that a clinical system (an electronic medical record, for example) has been relocated to an IaaS provider. The questions that arise as a result of this transition are legion: Have business associate agreements been signed? Is PHI being protected appropriately? Is there a contractual arrangement to ensure notification in the event of a data breach?
Instead of immediately pushing back, a prudent first step might be to undertake a systematic analysis of the situation. After all, if the vendor services healthcare providers regularly, this won't be the first time they've heard about HIPAA and may have already spent quite a bit of time thinking through how to address the administrative, technical and physical controls associated with its security rule. Compliance officers should first engage with internal teams to find out what level of due diligence they've done regarding information security during the cloud deployment, as well as what controls the vendor already has in place.
It's vital to understand two things: new compliance gaps this cloud deployment introduces to your organization, and any newly introduced risk. The first item is relatively straightforward: Walk through each of your compliance requirements and evaluate the cloud deployment documentation to ensure the vendor agreement meets these rules. To evaluate risk, you can leverage one of the many readily available risk assessment templates to assist in this regard: Some examples include the Cloud Security Alliance's GRC stack (notably the CAIQ and CCM), the European Union Agency for Network and Information Security 's Cloud Computing Risk Assessment and the NIST SP800-30.
Step 2: Know what you can change, and what you cannot
It's important to remember that the vendor's controls are what they are, and changing them rapidly to meet your company's control gaps is unlikely to be the most efficient path to maintaining security. Compliance officers can probably lean on vendors enough to make changes, but they will not come quickly. Instead of railing against a vendor's deficiencies, companies should look inward to see if there are things they can change on their end to maintain data security during a cloud deployment.
Of course, you should call out areas where vendor's controls are woefully inadequate and note these concerns in risk assessments, in reports to management and in long-term remediation plans. But also remember that it's easier to change your environment versus theirs. During long-term remediation talks, ask what controls you can implement in the short term to offset cloud-related security gaps. For example, can you encrypt data in transit or at rest to add a layer of protection? Or, will implementing additional monitoring controls help notify you of inappropriate access?
Step 3: Build the strategic remediation road-map
If you followed the steps outlined above, by this point you'll have two crucial pieces of data: a gap analysis showing where you don't meet your particular compliance requirements and a risk assessment identifying any potential problem areas after the cloud deployment. You will have also put in place short-term stopgaps to address as many of those areas as you can.
At this point, you'll want to take a comprehensive look at changes that both you and the vendor can make to maintain compliance. Keep in mind that many cloud service providers have resources on staff specifically to understand customer compliance requirements and address them when developing and offering services. It behooves you to engage with those vendor resources -- you might be surprised at the responsiveness and expertise.
Also remember that most responsible vendors have a commercial incentive not to stonewall you. Any changes they make to meet your compliance requirements or alleviate risk ultimately helps them become more competitive in your industry.
Long term, maintaining a compliant cloud environment is an exercise in cooperation between the company and its vendor(s). By objectively analyzing and documenting compliance gaps and risks, changing what the company can do internally to close short-term gaps, and putting together a long-term plan, dealing with unexpected cloud deployment doesn't have to be as painful as it seems.
About the author:
Ed Moyle is director of emerging business and technology at ISACA. He previously worked as a senior security strategist at Savvis and a senior manager at CTG. Before that, he served as a vice president and information security officer at Merrill Lynch Investment Managers.