In many respects, cloud usage in enterprises is a lot like gasoline: both are tremendously useful, but also require...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
handling with care. What makes the analogy particularly apt, though, is the connection between those two points; it's the same characteristic of gasoline -- the flammability -- that is in large part responsible for both the upside and the downside. If gasoline weren't flammable, then it'd be less dangerous and less likely to cause accidents -- but then how useful would it be?
For cloud services, much of the value comes about because of the layer of abstraction below the services that enterprises lease from the provider. In other words, to make use of a cloud service, enterprises don't need to constantly worry about the inner workings of how the service is provided; they can lease what they use and leave the day-to-day operations of keeping it running up to someone else. That's powerful. But like the gasoline analogy, this is exactly the same characteristic that enterprises need to watch out for in many situations. From a security, risk, legal and regulatory point of view, what's under the hood of the cloud service matters. And data residency is one of the areas where it can matter the most.
Cloud data residency challenges
Cloud data residency matters for a few reasons. First, there can be explicit regulation -- based on jurisdiction -- governing how data is stored, processed, transmitted and how it can be used. Most famously, the European Union's Data Protection Directive (95/46/EC) limits the transmission of the personal data to certain localities such as the U.S. The recent October 2015 ruling from the Court of Justice of the European Union (CJEU) invalidating the Safe Harbor agreement between the EU and the U.S. has muddied the waters somewhat for many firms, and it'll likely take some time before the full ramifications are understood.
But that is only half of the equation. There are also regional differences in how government authorities -- such as law enforcement -- are granted access to data that is stored in a provider's custody. A jurisdictional-based difference in surveillance powers, such as the USA Patriot Act, could potentially grant levels of access to law enforcement or government agencies that might be unpalatable to an organization based on internal policy, risk analysis, or other relevant cultural and contextual factors. Moreover, though legal requirements of course matter significantly, these may not be the only constraints at play. Individual firms might have contractual requirements that limit information storage. For example, a government contractor that handles controlled unclassified information (CUI) might have clauses with their subcontractors that limit access to data from "foreign nationals" -- other firms may have contractual relationships that limit offshore outsourcing and, by extension, access to data from overseas localities.
In a cloud data residency context, because the end user is purposefully "shielded" from the underlying mechanics of how the service is implemented, a question such as where data physically resides in terms of geographic regions is not often something that can be easy to determine or change. While larger service providers will often give the option to end users about which regional data centers host their data, allowing users to have some control over where data resides, having this option at a subset of the largest providers does little to address the full scope of the issue. What about smaller providers? What about cloud usage that might be "under the radar" within a particular business unit, such as shadow cloud adoption? Enterprises need to consider these questions as well.
The complexity is further compounded because neither cloud services themselves, the way organizations use them, or the business processes they support, are static. Just because a cloud provider only used data centers in California and Connecticut three years ago doesn't mean that's still the case now. Likewise, just because a business unit was only using a service to store public data the last time an enterprise checked, doesn't mean they haven't started storing more sensitive data there since then.
Getting a handle on cloud data residency
For the practically minded, the key question is what to do about it to ensure legal, contractual, policy and other requirements are met. First, enterprises need to know what those requirements are. As such, enlisting support from the various stakeholders who can speak to these requirements is a must. Enterprises should involve teams like legal, for example, which can speak to regional laws and purchasing, which can speak to contractual requirements.
Enterprises also need to have some way to evaluate service providers, such as a mechanism to assess where specific service providers store information, what information they are going to store, and who has access to it once it's in their custody. Again, this might take some legwork. It'll involve support from different business teams to understand specific usage scenarios and support from technology peers to understand how that usage ties together with the broader technology infrastructure the enterprise has in place. It's possible, though less likely now than it used to be, that some service providers may be less than forthcoming with residency-related information, adding to complexity in the vetting process and potentially slowing down contractual negotiation processes.
But it's important to note that contractual requirements are only the first step. Keep in mind that enterprises may not be able to enforce every residency requirement contractually for every cloud service they use. Remember that nobody starts with a greenfield, so doing a thorough job means understanding what cloud usage exists now and ensuring residency requirements are met. If organizations don't already have a complete and reliable inventory of cloud relationships, and most organizations don't, now would be a good time to start putting one together. Automated discovery tools can help here, but don't discount the value that partnerships with internal audit and disaster recovery and business continuity planning teams can have. Internal auditors canvass quite a bit of the business' activity in the course of doing their jobs -- having them as a data source to find cloud usage, such as shadow usage, can be helpful. Likewise, BC/DR teams tend to stay alert to business processes changes since that can impact recovery goals; having them support your efforts can also provide a valuable data source.
It's possible, depending on what the residency requirements are, that during this process enterprises will discover relationships where the horse is already out of the barn, and data is already somewhere it shouldn't be. Should that occur, enterprises will need to craft solutions to address those areas. This might involve the use of technical controls such as encryption to limit the scope of where cleartext data resides. It could also involve looking for creative alternatives for cloud services that can't be remediated or working directly with service providers to find workarounds.
Cloud data residency is a complicated equation that takes planning and forethought to meet head on. It can be a thorny problem, but one that is not insurmountable with a bit of discipline and elbow grease.