 |
| Image courtesy of paul (dex) |
Much has been written about the legal implications and risks associated with cloud computing. Some of the potential risks are large and cloud-specific, while others are simply regular issues associated with obtaining services from a third party. All of them need to be properly managed. However, the level of due diligence, customised terms, and type of cloud solution you need depends on the complexity and business criticality of your systems. That need increases exponentially if complex and business critical systems are sent into the cloud by a regulated entity such as a bank or insurance company.
There are six deadly sins to be avoided, and one which should be committed, in relation to the cloud. Most of them are committed by those who focus too much on protecting their client's or company's position at the expense of delivering business outcomes, or who don't understand the solution their client or company needs for their business model. As a result they may ask for too much, or not enough.
Sloth: Don't be so lazy you don't move your data out of Australia simply because of data privacy restrictions. Current privacy legislation and even prudential regulation don't mean you can't move your data offshore, but you do need to put in place proper provisions with your cloud providers, particularly in respect of sensitive information. However, be aware that in the future it may be that some types of data simply cannot be moved. For example, currently draft legislation provides that certain health records won't be able to be held or taken out of Australia.
Pride: Not often related to the sin of Sloth, but the sin of pride here might be nationalistic pride. It's fine to keep your data onshore and only use Australian providers because of concern about the US Patriot Act, just remember not only does the Act apply to Australian subsidiaries of US companies, but the US has law enforcement treaties with Australia. You will face similar issues of government access to data in every country (those without legislative power to do so will be of greater risk), so think about whether any cloud is the right solution.
Gluttony: Having a great availability service level doesn't necessarily mean you get all you can eat from the cloud. Cloud service levels shouldn't be solely about availability and you should also consider disaster, security, and backup related service levels, among others. You also need to pay particular attention to how availability is measured. For example, if the measure is only by reference to infrastructure the service level may be met even if your service, platform or application isn't available (remember Amazon's EC2 outage?).
Wrath: You don't need to fight for everything in relation to liability provisions. Does it really matter if an application testing platform isn't working if you have access to another one? If it's not a critical application and you don't miss development milestones then aren't you really only looking for a refund for an unsuitable service? Save your fight for consequential loss for when you are using the cloud to store confidential, sensitive, or important information.
Greed: A sin you should commit in relation to the cloud. Be greedy about your data both in terms of its ownership and use but also about your ability to get it back, not only on termination, but also at any time during the contract term. You also need to get it back in a form that is usable and transferable to another provider or back into your own systems. That means getting it in a form you specify or as part of a package which gives you the ability to extract it.
Envy: Don't be envious of others' move to cloud computing. If your solution needs to be heavily customised or an agreement heavily negotiated to meet your business model then it may soon erode the value of moving to a cloud solution. Equally, it might just be that certain of your data and systems should not be in the cloud. At least not yet.
Lust: Don't lust over a cloud computing contract which covers off every risk. Getting back to my earlier point, you need to assess the business needs (paying appropriate attention to laws/regulations) and then get what is necessary to achieve those business needs while adequately protecting your business. If you really only want to get access to the cloud for some spare capacity to test a non-critical application, then it may be okay to sign the vendor's standard terms and conditions and get on with it. But do make sure you read them.
0 comments:
Post a Comment