What if you could do both, and in a secure and technically superior way?

It’s no longer an acronym constantly in the headlines, but GDPR (the General Data Protection Regulation) remains a challenge for any organisation trying to operate in the EU. Since ratification in May 2018, the total fine count for member states up to June this year is over $330m.

The need to be able to securely and accurately place, move, archive and audit data in multiple applications and meet GDPR (and, of course, parallel regulations, like California’s GDPR-like Consumer Privacy Act, or industry-specific ones like healthcare’s HIPAA and the payments industry’s PCI DSS) is hard enough. That complexity goes up several notches when it is across multiple countries, and doubles again when these countries are in not just one but many regions, initiating as that does all kinds of cross border, multi-data protection legislative norms.

In addition, not having the appropriate controls over that data is bad enough. Not having the appropriate controls in each and every geographical location could not just pretty effectively disable your ability to trade, it could also be an existential risk for the company if you end up incurring some kind of financial penalty as above. So data governance and geo-location should be a number one priority; but, just as critically, you also need to be constantly shoring up the corporate defences against cyber security threats, which the FBI says is increasing “exponentially.

Why two parallel processes?

So, two very important business processes about securing data – one compliance-oriented, one IT security-oriented. Compliance is ultimately about telling the organisation to look after the data, and on the security side, the practice of making data handling functions as secure as possible. Regulations like GDPR are all about you being able to always know where the data is and who is handling it, and whether it can be shared with somebody else; security is about systems where you have identified the sensitive data and putting roles around it to make sure that only the right people can handle it and that it can’t be accessed illegally. But patently, there is commonality here; both are about data, yet we pursue them not as one task, but two. Why?

Until now, enterprises have found it simpler to deal with the twin challenge with two different groups of specialists: compliance people who are looking after the regulations like GDPR, HIPAA etc, and security teams who are tasked with looking after the security of customer and company data to ensure that it can’t be taken by hackers. They have ended up as discrete specialties because there have historically been additional layers of work needed on each side in both implementation and technical terms, and as a result the CEO essentially must talk to two different sets of practitioners about his data.

But at the end of the day, the objective of that CEO’s compliance expert is setting out the principles that only the people who need to see the data can handle it – defining its proper use. But isn’t that what their security colleague is also trying to do? Although organisations for technical reasons tend to split them into two, they are very co-dependent on what each is doing. So, is this continued bifurcation of compliance and security defensible?

There are ‘good’ org chart reasons to keep them separate, and it comes down not so much to structural, technical or domain reasons but about who we needs to deal with external regulators or auditors; we are positioned internally like this to answer the people who could ask us the tough questions, e.g. a GDPR or financial regulator to whom we direct a team focused to answer, and at the IT security level they stand ready to help the CIO or CEO when they ask after a bad ransomware attack hits the news, are we doing everything we can from a technical level to prevent this happening to us?

A data solution that gives 90% of what both sides need

Different answers and different people ready to provide them, but they actually want the same thing out of the technology that they’re securing. And what if, instead of twin approaches to what aren’t really two problems at all but one, with all the inefficiency and duplicated effort that risks, there was one approach that actually reinforced the intrinsic quality of the data we want to protect and so continuously raised the bar for both needs?

The good news is that recent database industry advances mean there is just such a unified way forward, and which gives you a core that delivers 90% of what both sides need that merely then requires the additional 10% to be added on for specific purposes. This is the shift to microservices and full exploitation of Web-based data and development disciplines. At its heart is a new way of managing data in a database, which actually becomes the critical engine of the unified approach. It must be secure, and it must be resilient, and it also must be able to manage where data is stored and how it’s transmitted.

So, if you can build a database which has all these characteristics, you can easily also run it in multiple compliance/data protection jurisdictions, storing data where created or where owned, but also be able to work with it securely on a global scale. This can only really happen, however, if you can abstract out data and how you want to work with it from the specific software implementation(s) you want to store it in, separating the transactional and the analytical sides.

‘All this important data heavy-lifting with just one cloud database’

I do immediately have to say that until now there have also been technical reasons why GDPR and security couldn’t share the same tools. If you had to manage three or five databases or one for every jurisdiction, if you had to develop different code and different solutions to sit on top of it, your agility as a business is radically diminished and your costs would just go up unacceptably. But what if you could do all this important data heavy lifting with just one cloud database that could be used for all these different needs in different locations, and which also simply required familiar SQL to access and manipulate?

By using the latest in open-source database, combined with agile and CI/CD (continuous integration and continuous delivery), moving to a common core of quality, scalable and secure data management across all your business and legal needs will lower costs and improve ROI. Crucially, it also enables you to respond much more quickly and nimbly to both on-going compliance needs with all its associated regular change and the eternal “war” against the hackers.

And if you don’t do it? You will continue to have separate teams, separate development costs, separate workflows and separate stakeholders and process owners. And while that has made sense for a long time, it doesn’t now – so why not see if it could work for you and your organisation too?