To be \u2018enterprising\u2019 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. \u2018Analytics\u2019 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.\n\u2018Enterprising analytics\u2019 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.\nYes, that GDPR thing\nIf you\u2019re in any way involved in a data leadership role, you\u2019ll be aware of the European Union\u2019s General Data Protection Regulation (GDPR). If you\u2019re not, you\u2019ll 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.\nIt\u2019s 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.\nOther countries will follow suit. We\u2019ll see different approaches to the tricky subject of digital rights. Singapore is six years into updating its Personal Data Protection Act. They\u2019re 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\u2019s 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.\nWatch out for consumer litigation\nSo 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\u2019ve 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.\nMany people are looking at the size of the fines that the GDPR mandates. And, yes, they\u2019re big and scary. But they\u2019re 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:\nEach 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)\nAny 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)\nBasic security configurations will come back to haunt you\nThis 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.\nSo how is this going to play out? That depends on how you prepare and what sort of threat and opportunity modelling you\u2019ve done. If you\u2019ve concluded it\u2019s a technology issue, then you\u2019ll make a vendor richer. If you\u2019ve concluded it\u2019s a policy issue, then you\u2019ll write a couple of million words. If you\u2019ve concluded that it\u2019s a process issue, then you\u2019ll start a mapping and reengineering exercise. All of which are important and useful parts of the solution.\nBut 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.\nSaving on security is false economy\nThe 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.\nUnfortunately, most data projects put security discussions towards the end of the project management life cycle \u2014 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\u2019re asked, they\u2019ll meet specific security requirements. But that\u2019ll be the exception and not the rule.\nThis is because additional security work will come at a cost. Monitoring, logging and reporting isn\u2019t cheap. When general managers are costing data projects, security extras look like expensive luxuries. So they\u2019ll think back to their risk management discussions and make a calculated guess at what they can get away with. The problem is, it\u2019s these services that will make the difference between demonstrating an intent to meet the provisions of the GDPR or not.\nRisk will return to the data controller\nThe 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\u2019t be much help.\nThe 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:\n\nThe 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.\n\nMy 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\u2019s pipe, platform or web application. If GDPR-compliant functionality is available for the client and they choose not to purchase it, then this can\u2019t be the fault of the supplier.\nService providers have little incentive to take on your risk\nThis means if you\u2019re 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\u2019t much help. You will need to work with your providers to negotiate a common ground of responsibilities. If you\u2019re a service provider you\u2019ll want to avoid any contractual language that transfers GDPR compliance responsibility to your business.\nIf you take on too much compliance responsibility, then you\u2019re 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.\nThe 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\u2019s more likely than not that data controllers will be the ones to be held as being non-compliant.