A shift is happening in the overall data space – it’s in part due to the GDPR, but it’s also in part due to the actual possibility of addressing it.
That may sound weird, but the shift that we’re starting to see is that customers of one of our global services are starting to care more and more about where data is stored, and how it’s intermingled with other data, vs. just that it’s protected.
The ramifications of fulfilling these requests are not trivial.
There is still much to be defined in how data is “owned” and managed on a legal basis. The thing we’re hearing more and more (it’s not like it’s a landslide, but it’s more than a trickle) is that some customers are interested in the option to house data in the same geographical (and therefore legal) area as they are located. In addition, the security of the data – by segregating it from others, providing the ongoing end-to-end encryption, and providing access controls is a discussion point and, in some, a requirement. This may seem pretty obvious, but the service is akin to a registration service – one that uses SQL Server as the backend and runs these registrations, reporting and usage and such for the service in question. To segment out customers is not a huge deal with our architecture, but it is inefficient in some cases.
These are not easy questions from a legal standpoint though. From the “ownership” and protection of data from a legal perspective is more than “you better take good care of my information” – it’s planning for recourse and avoidance. The recourse is clear – the GDPR is looking to lay out rules and regulations around what happens if there is a breach. The avoidance is a new train of thought though. In these new cases, they’re looking to avoid access by specific nation-authorities.
On the surface, this is paranoia. It’s not reality. At a government level, this isn’t interesting data (it’s event registrations). But the fact that people are starting to worry now about government overreach, and see geographic location of data stores as a method of mitigating that unwanted access, *is* a new thing. Previously it was more of a question, now we’ve seen it as a requirement in a few cases.
This has meant some architecture changes in our systems to first define what types of information need to live where, and how to configure the systems to seamlessly access that information across these boundaries. What seems like, in essence, simple connection strings, leads to all sorts of questions and even legal ramifications. It leads to dealing with billing changes (now there are more server instances to take care of, to monitor, and ultimately to pay for). On the one hand, the technology can be made to support it. I’m not sure the organizational ramifications are known yet, and I think there is much to be seen about a split application and the impact that a “some data here, some data there” type solution may have on everything from performance to government “requests.”
It’s very interesting to see people’s expectations in making the requests, then sit down and find out why, and what they’re trying to accomplish. This has proven to be a critical step in the whole understanding of what needs to be done. In many cases, it’s more of an exploration of options, but in some, it’s a very hard and fast rule. It’s likely that, as the laws fill out and become tested, requests will morph a bit as well, possibly clarifying and possibly changing these types of requests.
Are you seeing requests such as these from your own customer bases?