From the Author of The Agile Architecture Revolution

Jason Bloomberg

Subscribe to Jason Bloomberg: eMailAlertsEmail Alerts
Get Jason Bloomberg: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, SOA Best Practices Digest, Microservices Journal

SOA Best Practices: Article

Cloud Computing: Legal Quagmire

Legal pitfalls of Cloud Computing

If you don’t realize by now that Cloud Computing has its risks, then, well, you must have your head in the clouds. But then again, without risk there is no reward. When you place a bet on the Cloud, you know you’re betting on an emerging set of capabilities. And in any case, there are risks everywhere in business. Why should the Cloud be any different?

Even if you are willing to take on the risks of the Cloud, you must still do whatever you can to mitigate those risks. And unfortunately, risk means liability, and that means lawyers. To help make sure you and your lawyer are up to speed on all the legal ramifications of Cloud Computing, we’ve assembled the following list of concerns. Ignore the items on this list at your own peril.

Liabilities related to the geographic location of your data in the cloud

  • Legal jurisdiction – Where your Cloud provider is physically located may impact the legal jurisdiction that applies to your contract with the provider. How will you know which laws apply to your data if you don’t know what country or state your data currently reside in?

  • Regulatory Compliance – There may be regulatory constraints that limit where you locate your data. There’s no guarantee your Cloud provider will locate your data in your country—unless, of course, you pay them for that guarantee.

  • Disputes – If you need to arbitrate with or sue your provider, where do you do that? The business location of the provider may not be the same as the physical location of the data, complicating this issue.

  • Moving data across borders – The European Union is very particular about this rule. You can be held liable for moving customer information across borders without their permission.

Third-party access to your data

  • Search warrants – If a law enforcement agency has a search warrant for the server or hard drive that hosts your data, then they can remove the hardware from the provider’s data center and put it into evidence. For a long time. If you’re up to do good that’s one thing, but they may be going after suspected criminal activity for another one of the provider’s customers that happens to share space with you on the same physical server or drive.

  • PATRIOT Act seizures – if the FBI or other US federal agency suspects terrorist activity, they don’t even need a search warrant. They’ll simply walk into the provider’s data center and take whatever equipment they want. Think you’ll see your data again? Not likely. Does this sort of thing only happen in the US? I wouldn’t count on it.

  • eDiscovery/subpoenas – Even if no one suspects criminal activity, if you or someone else on the same server is party to a lawsuit, the opposing counsel can subpoena the data on the server. And just as with a search warrant, it may be many months before they return the hardware to the provider. Another question for your provider: what is the nature of their response to a subpoena? Do they need to inform you when a subpoena affects your data? What are your responsibilities in the face of a subpoena? For example, it may be illegal for you to delete data, even if the subpoena doesn’t explicitly specify such a restriction.

  • Provider employee access – what access do employees of the Cloud provider have to your data or machine instances? They have some level of responsibility for administering your account, but does that mean they have access to your data?

  • Trade secret & attorney/client privilege protection – If you have privileged information in the Cloud, either trade secrets or attorney communications, then making that information available to a third party can remove the privilege—even if the third party in question is just an admin at the provider backing up a server.

  • Liability of rogue employee – Employees of your Cloud provider aren’t the only risk. What if one of your own employees uses your Cloud account for illegal purposes? How much liability does your company have, and how do you mitigate such risks?

Responsibility and how to allocate it

  • Insurance in case of disaster – Do you have the proper insurance? What sort of disasters would be covered under your provider’s insurance, and which ones to you need to insure against yourself?

  • Liability for breach of privacy – Somehow your confidential data are leaked to the Internet. Under what circumstances is your provider liable for such a breach?

  • Liability for commingling with illegal data – sharing hardware with criminals and other unsavory types can lead to those pesky search warrants and subpoenas, but you should also understand your liability for having your data in close proximity to illegal data. Innocence may be no excuse when the feds find child pornography on the same server as your machine instances.

  • Liability for hacking – Hackers compromise your data or your machine instances. The weakness they targeted may have been your provider’s fault, but then again, maybe your own people misconfigured your machine instances, allowing the bad guys in. How do you determine the liability? What if the hackers installed a botnet in your machine instance that they used to penetrate the security of another company, who now wants to sue. Can they sue you?

  • Risk allocation – in those situations where perhaps you’re partly to blame for a disaster or a breach, how do you allocate the risk between your company and the Cloud provider? And will your insurance company pay a claim if you are partly to blame?

Logging and auditing requirements and risks

  • Supporting legal requirement for logging – Some regulations provide for specific logging and auditing requirements. For example, HIPAA requires you to maintain an audit log of everyone who accesses an electronic health record—even if it’s an admin at the Cloud provider. Make sure you communicate your specific logging and auditing requirements to your provider and include those requirements in your contract.

  • Privacy of logs – Sometimes the audit logs themselves contain confidential information. You must contract with your provider to properly encrypt that information, and you also need to mitigate the risk that such encryption is inadequate, allowing the logs to be compromised.

Other regulatory compliance issues

  • Regulations specific to your industry – The web of regulations is both extraordinarily complex and entirely arbitrary. It is your responsibility that you don’t run afoul of any regulations that pertain to storing, moving, or using data in the Cloud.

  • Risk of regulatory change – For the most part, today’s regulations that apply to the Cloud were around before the notion of Cloud Computing took off. Once regulators get a handle on the issues Cloud presents, however, you can expect new regulations to follow—and of course, it’s impossible to fully plan for them.

  • Requirement for provider audits and security certifications – You may also have regulatory priorities that require your Cloud provider to conduct its own internal audits or obtain security certifications. As regulations develop, expect such certifications to proliferate as well.

What if your Cloud provider declares bankruptcy?

  • Salvage rights to data – one day everything seems to be fine, but the next your provider is out of business, and they’re liquidating their assets. That means the servers that held your precious data are now on eBay, and they’ll soon belong to the highest bidder. To avoid this nightmare scenario, you’ll need to put in place some ironclad protections that will survive even a liquidation bankruptcy.

  • Escrow of provider data, code, and configurations – your own data aren’t the only things you might want to protect should your Cloud provider go belly up. Depending on how you’re using the Cloud, you may want to require your provider to escrow its own data, code, or configuration files, in the admittedly slender hope that if their servers go on the auction block, there’s some way to rebuild your Cloud application without starting from scratch.

The ZapThink Take
You probably picked up on the general assumption that this article is discussing Public Clouds in particular. That assumption is generally true, but it’s important to realize that Private Clouds have many of the same risks. You must still comply with regulations, deal with rogue employees, and potentially even respond to subpoenas or search warrants, after all. The list goes on.

Instead of focusing your efforts on insuring you’ve put together an ironclad agreement with a third-party Cloud provider, you must now serve as provider as well as customer if you’re building a Private Cloud. Yes, you have greater visibility and control, but you also have even greater responsibility and liability than if you are working with a Public Cloud provider. After all, having one throat to choke is no consolation when the only throat available is your own!

More Stories By Jason Bloomberg

Jason Bloomberg is the leading expert on architecting agility for the enterprise. As president of Intellyx, Mr. Bloomberg brings his years of thought leadership in the areas of Cloud Computing, Enterprise Architecture, and Service-Oriented Architecture to a global clientele of business executives, architects, software vendors, and Cloud service providers looking to achieve technology-enabled business agility across their organizations and for their customers. His latest book, The Agile Architecture Revolution (John Wiley & Sons, 2013), sets the stage for Mr. Bloomberg’s groundbreaking Agile Architecture vision.

Mr. Bloomberg is perhaps best known for his twelve years at ZapThink, where he created and delivered the Licensed ZapThink Architect (LZA) SOA course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, the leading SOA advisory and analysis firm, which was acquired by Dovel Technologies in 2011. He now runs the successor to the LZA program, the Bloomberg Agile Architecture Course, around the world.

Mr. Bloomberg is a frequent conference speaker and prolific writer. He has published over 500 articles, spoken at over 300 conferences, Webinars, and other events, and has been quoted in the press over 1,400 times as the leading expert on agile approaches to architecture in the enterprise.

Mr. Bloomberg’s previous book, Service Orient or Be Doomed! How Service Orientation Will Change Your Business (John Wiley & Sons, 2006, coauthored with Ron Schmelzer), is recognized as the leading business book on Service Orientation. He also co-authored the books XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996).

Prior to ZapThink, Mr. Bloomberg built a diverse background in eBusiness technology management and industry analysis, including serving as a senior analyst in IDC’s eBusiness Advisory group, as well as holding eBusiness management positions at USWeb/CKS (later marchFIRST) and WaveBend Solutions (now Hitachi Consulting).