A formal information security policy is not an optional item for your business; that's pretty much accepted as a given. Yet when your company migrates to the cloud, in any capacity from data storage through to application delivery, it's often mistakenly accepted that the existing policy will cover this new ground.
After all, the argument goes, data is data wherever it is stored and the same security policies should apply. While there is some logic to this, it's rather flawed and has the potential to leave your enterprise exposed to unnecessary risk. An information security policy needs to be a dynamic thing that changes to meet the security demands of the enterprise, and the data it deals with, as new technologies become part of the business landscape.
When it comes to the cloud, the single biggest benefit of having a relevant policy is that the process of creating it requires in-depth thought about what security in the cloud really means to your business and to your data. This necessity to think out loud, to determine a structured response to your needs from top to bottom, is often an eye-opener for the entire team working upon it.
Making the commitment to your data
Writing such a document for the cloud is actually little different from any other security policy in that, at heart, it's just a formal commitment to protect all the data your business uses which in turn then necessitates a strategy to determine the levels of required protection and the process needed to both achieve and maintain those levels.
Delegating this policy building process to a third party such as, for example, your cloud service provider is security suicide. Your cloud security policy, like your broader data security policy, must be your responsibility; to be sustainable and effective it has to be written from the ground up, and contain input from the top down.
Whether that means the director of a small business working with an external consultant or the board working with the IT, legal and HR departments will depend entirely upon the size and structure (and to some degree the market sector) of your organisation. However, there are some constants which remain no matter how big or small the business, or what sector you are working in.
1. To paraphrase John Donne, no policy document is an island
Your cloud security policy should form a coherent part of your organisation’s Written Information Security Programme (WISP).
So, while it has to be able to stand tall in addressing the specific needs of data security within the cloud environment, it cannot be totally separate from - and at odds with the data security policies - that are in place elsewhere. A WISP should be seen as a collection of policy documents that provide the steps needed to enforce the security measures they demand. Be aware of this need to co-exist from the get-go.
2. Don't reinvent the wheel Although your existing data security policy isn't going to be a shoo-in to a cloud-based document, parts of it will fit without too much adaptation. Don't be afraid to re-use them if they are fit for purpose. Existing policy exists for a reason, and if it can apply to cloudy data then apply it. Equally, look to what others have done and draw from that; ask affiliates or peers within your market sector who have migrated to the cloud for their thoughts, and draw upon their experience when it comes to considering your own policy.
3. Understand your needs before you start writing policy to address them
Which sounds obvious but putting the cart before the horse is not as uncommon as you might imagine.
So, determine how you will be using the cloud; will it be for data or applications, or maybe a combination of the two? This determination will then allow you to focus on which criteria are required in terms of security policy. It's that 'thinking out loud' process mentioned earlier in action.
For example, if looking at data handling in the cloud from a policy perspective, you will first need to think about how you classify data and how that determines which data is considered 'cloudable' by your policy. If you don't already have a data classification policy then you will need to create one, and the processes required to put that into place.
4. Your cloud security policy should be readily accessible A term that must not be ignored and which means in reality that your policy is both available to and understood by all your employees. Bear this in mind when writing the policy in the first place, and if you want to keep training costs down then avoid over-complication and technical complexity.
The best security policy will be one that is clear and concise. State the obvious, as that way nobody can claim to have missed the point. So every cloud security policy should start with a definition of intent, in other words what the policy intention is. For most organisations this is going to be 'to mitigate the risk to data when using cloud-based services'.
5. Include worse case scenarios as well as rose-tinted best practice specs In other words, your policy should not just be about protection but also about reaction. Consider how any cloud data breach would be dealt with, including logging and reporting processes, forensic functions and cloud provider cooperation. Then there are the disaster recovery issues to be considered, ensuring continuity of operations, and not forgetting 'end of life' procedures relating to data transfer and secure wiping if you wish to change cloud providers at any point.
6. Finally, always involve your legal department. (And if you are so small an enterprise you don't have one, then instruct a suitably qualified lawyer) by way of the final review process. A policy which has no legal standing is as good as useless.
This point is particularly pertinent when it comes to the cloud, not least as subjects such as physical location of data storage and transit can have legal implications upon privacy and security compliance issues.
