Data Residency: Who is Shouldering the Burden of Compliance?
This week in Berlin the Object Management Group (OMG), whose self-described mission is to develop technology standards that provide real-world value*, conducted the first workshop meeting of its new data residency group, a working group that NuoDB initiated.
Now you might (maybe) be thinking, what exactly is data residency? Briefly, it’s the need to only store certain data in certain geographic locations to meet the data privacy laws of those geographies. I used to think that was something that mostly concerned relatively few places and that Safe Harbor agreements meant we didn’t have to worry about it anyway. It took me about 10 minutes research to discover how wrong I was. It gets more complicated pretty quickly, as evidenced by the number of international law firms who seem to specialize in it!
And it is a very real challenge for organizations who need to do business across national boundaries in many parts of the world. In a recent conversation I had with a notable industry analyst, he reported that in the frequent conversations he has with his clients about data residency, they often suggested that the simplest solution was to deploy in the cloud – to effectively make it the cloud provider’s problem. Many people think the cloud providers must have this sorted, right? Well apparently not: A staggering 70%+ of cloud providers do not comply with European data privacy legislation in their stacks. They are in turn making it their customers’ problem, forcing cloud users to themselves ensure their applications’ databases comply.
And that’s why NuoDB are interested in data residency; we increasingly found ourselves having these conversations with prospective customers. It became so frequent a theme that our CTO has committed to leading the OMG’s Working Group for Data Residency. And we are already reflecting data residency requirements into the NuoDB product. Our latest version, Robins Release 2.3, introduces a preview feature called Storage Groups that allows users to decide what data is persisted where, in a geo-distributed NuoDB instance. There are other uses for Storage Groups (for example Data Locality – making sure data is stored close to the users that are most likely to access it) but it gives our users the power to not just comply with regulatory requirements, but to be seen to be complying. There is no dependency on application code changes; that runs regardless of how the storage of data is segmented. As an organization moves into more geographic regions, or as legislation changes, these changes can be reflected in the database configuration without any impact on the application code at all.
Sorry to all the lawyers who don’t get involved sorting out a tangled mess after non-compliance incidents are exposed.
*As opposed to standards bodies whose mission is not to provide real-world value? Hmm, well ok, maybe there are some of those.