To manage GDPR data risk, pay attention to your service level agreements

To be ‘enterprising’ is to be eager to undertake or to attempt. To show initiative and be resourceful. These are leadership traits, so to be enterprising is to lead. ‘Analytics’ is how we use data to inform decision making, in the context of achieving business objectives. These are management practices, so analytics is about management.

‘Enterprising analytics’ is about being creative, resourceful and adventurous with decision making to achieve business objectives. It is about the set of leadership and management practices that need to be in place for an organization to make the most of its analytics investment.

Yes, that GDPR thing

If you’re in any way involved in a data leadership role, you’ll be aware of the European Union’s General Data Protection Regulation (GDPR). If you’re not, you’ll read about it on the way out the door. In the short history of privacy regulation, the GDPR is the biggest change since the 1973 Code of Fair Information Practices. Michael Nadeau gives a good overview on CSO.

It’s easy to get lost in the detail of the GDPR (which, of course, is where the important stuff is). Regulation the size of the GDPR is all about managing compliance obligations. Before we complain too much, we should remember that regulation follows changing social norms. In this case, society has become interested in how organizations harvest, store and process people’s data.

Other countries will follow suit. We’ll see different approaches to the tricky subject of digital rights. Singapore is six years into updating its Personal Data Protection Act. They’re getting ahead of the Internet of Things complications that the GDPR is silent on and are also taking a different path on the issue of consent. The GDPR itself is only one half of the EU’s work to regulate digital rights. The ePrivacy Regulation is lagging behind its sibling but when it catches up, it will likely end up as the bigger and more important of the two.

Watch out for consumer litigation

So being responsible for digital transformation means also being responsible for digital rights. Data leaders will have a duty to execute the responsibilities for which they’ve been hired as well as a duty to protect the rights of data subjects. Every company will have a different take on what this means. Which means every company will have a different risk management conversation about what they should do, what they can do and what they can get away with. These conversations are going to come down to two things: what people think will protect them, and what will actually protect them.

Many people are looking at the size of the fines that the GDPR mandates. And, yes, they’re big and scary. But they’re taking too much of our attention. One of the fishhooks that the GDPR has for unsuspecting data analytics leaders are the provisions for consumer litigation and class action lawsuits. As Paige Bartley of Ovum explains, the problem comes down to two key GDPR articles:

Each data subject shall have the right to an effective judicial remedy where he or she considers that his or her rights under this Regulation have been infringed as a result of the processing of his or her personal data in non-compliance with this regulation. (Art. 79, GDPR)

Any person who has suffered material or non-material damage as a result of an infringement of this Regulation shall have the right to receive compensation from the controller or processor for the damage suffered. (Art. 82, GDPR)

Basic security configurations will come back to haunt you

This means the lawsuit coming your way might not have an official-looking EU stamp on it. Consumers can authorize privacy not-for-profits to advocate and litigate on their behalf. As with any issue of law, specialized firms will form around these litigants. All that is needed to kick off litigation are consumers who know their rights.

So how is this going to play out? That depends on how you prepare and what sort of threat and opportunity modelling you’ve done. If you’ve concluded it’s a technology issue, then you’ll make a vendor richer. If you’ve concluded it’s a policy issue, then you’ll write a couple of million words. If you’ve concluded that it’s a process issue, then you’ll start a mapping and reengineering exercise. All of which are important and useful parts of the solution.

But what will get you in trouble are the service-level agreements with your technology suppliers. These suppliers provide a pipe, platform or other web-based application to enable their clients to do business over the Internet. Unless the client has stipulated their security requirements, the supplier is likely to only provide a basic security configuration to ensure they meet their availability obligations.

Saving on security is false economy

The reason why we should focus on security is because, in practical terms, where security goes, privacy will follow. Normatively, privacy leads but when it comes to putting privacy legislation into effect, it is your security posture that will make the difference.

Unfortunately, most data projects put security discussions towards the end of the project management life cycle — which is a reliable pathway to building expensive data sieves. Technology suppliers will seek economies of scope and scale by reusing their infrastructure to reduce costs and maximize delivery efficiency. If they’re asked, they’ll meet specific security requirements. But that’ll be the exception and not the rule.

This is because additional security work will come at a cost. Monitoring, logging and reporting isn’t cheap. When general managers are costing data projects, security extras look like expensive luxuries. So they’ll think back to their risk management discussions and make a calculated guess at what they can get away with. The problem is, it’s these services that will make the difference between demonstrating an intent to meet the provisions of the GDPR or not.

Risk will return to the data controller

The advice data leaders receive about ensuring they have GDPR-compliant policies is good advice. But the key evidence these policies rely on will come from the behavior of the service providers. Without the evidence that service-level agreements are putting internal data management and use policies into effect, those millions of words won’t be much help.

The big question here is whether making a claim that both organizations are equally responsible for GDPR compliance will effectively spread the risk. As Michael Nadeau writes for CSO:

The GDPR places equal liability on data controllers (the organization that owns the data) and data processors (outside organizations that help manage that data). A third-party processor not in compliance means your organization is not in compliance.

My sense is that the risk will return to the data controller (the client) rather than end up with the data processor (the supplier). This is because it is up to the client how they use the service provider’s pipe, platform or web application. If GDPR-compliant functionality is available for the client and they choose not to purchase it, then this can’t be the fault of the supplier.

Service providers have little incentive to take on your risk

This means if you’re working on GDPR compliance you need to get your service providers on board ASAP. This is just like the project cycle: adding security discussions at the end isn’t much help. You will need to work with your providers to negotiate a common ground of responsibilities. If you’re a service provider you’ll want to avoid any contractual language that transfers GDPR compliance responsibility to your business.

If you take on too much compliance responsibility, then you’re opening yourself up to a world of pain. A better route would be to commoditize elements of your service offering to help your client segments better meet their compliance expectations. But whatever the case, you will want to buffer yourself from becoming a responsible party to GDPR requirements.

The reason for all this caution is that the issue of what is compliant and non-compliant will likely be determined by the courts. Whichever party fails to provide evidence they were performing as defined under their respective contractual obligations will be the one found to be non-compliant. Where there were remedies available to data controllers that they chose not to deploy, then it’s more likely than not that data controllers will be the ones to be held as being non-compliant.