There\u2019s a lot of confusing rhetoric around GDPR (General Data Protection Regulation). I\u2019d like to help clear up some of it. \u00a0I\u2019m not a GDPR expert; however, I am a chief information security officer (CISO) with pretty deep experience in the implementation of risk management and information security programs. I lead my own organization\u2019s GDPR readiness activities, and I\u2019ve studied, and passed, the C-GDPR-P Data Protection Officer\/DPO certification.A part of my job is to engage with security executives at a peer level: roundtables, focus groups, you get the picture. Despite my attempts to drive conversation down the path of cloud security, malware analysis, and micro-perimeterization, it seems that GDPR is the hottest subject at the moment.The biggest misconception about GDPR is whether you can control data under the regulation \u2013 and whether you should. First off, you can\u2019t control everything \u2013 in fact, as I\u2019ve been telling security leaders recently, 80% of GDPR-related data isn\u2019t even under the control of CISOs. Take the example of the CISO for a retailer with hundreds of stores. You don\u2019t have unilateral control as to where the data is, which departments have it, and for what reason they collected it.\u00a0 So how can you possibly take on the role of pseudo-data owner?To look at this another way, it\u2019s helpful to roll back the calendar by a few decades. Think about accountancy and marketing firms before we all had MacBooks. If GDPR came about when we were all using paper and filing cabinets for accounting, would you have asked the guys in the IT department to help you classify information, or perform a data flow analysis? You wouldn\u2019t \u2013 because that wasn\u2019t IT\u2019s job.\u00a0Why then have so many companies decided that all data and processes need to be managed by IT? Of course, critical business processes are digital \u2013 certainly the overwhelming majority are. But just because data resides in a digital form, on a server with flashing lights, doesn't mean that the designer or operator of said system understands the data that is stored or processed on it.GDPR is about empowering data subjects and putting them in control of how and where a company uses their information.\u00a0 It\u2019s about ensuring that controllers (and processors) carry out data processing in a transparent fashion.\u00a0 It\u2019s about making sure that information is not left lying around in servers ad infinitum just because it\u2019s no longer of immediate use to the company storing it.\u00a0 While the security function can help with the \u201chow\u201d of data protection, we are often very little use in ascertaining the \u201cwhy\u201d of data collection.When it comes to GDPR, what do CISOs \u2018own?\u2019I must write the following sentence 200 times a year: \u201cThe security function is there to apply controls commensurate with the classification of information, not to define it!\u201d Don\u2019t get me wrong: The CISO and her team are integral to information privacy. If we want to talk about \u201cownership\u201d of GDPR, I'd say that CISOs \u201cown\u201d principle 6 of GDPR accountability across business functions, which says that data should be \u201cprocessed in an appropriate manner to retain security.\u201d Teams need to define if information is being processed lawfully, if we know why we collected it, we\u2019re sure it is needed in an ongoing capacity, we have a process for updating the data, AND we only retain it for as long as necessary. After this has been determined, it\u2019s fair to discuss with the CISO how to protect the information.Risk management is a key consideration for the CISO and something I write about extensively (check out this four-part series on delivering meaningful metrics to boards). \u00a0The company information risk management framework needs to be flexible enough to measure not only the impacts to and likelihood of confidentiality, integrity and availability, but also privacy and personal data.\u00a0 The DPO and CISO need to work together \u2013 assuming they\u2019re not the same person.How can you possibly be compliant?Another important concept to keep in mind: GDPR isn\u2019t a magic, be-all and end-all tool for solving compliance. It\u2019s a regulation associated with data, ensuring that information that the organization collects and stores is for legitimate purposes, and that it is deleted when it is no longer needed. GDPR is not prescriptive in the way that PCI DSS is.\u00a0 For example, PCI DSS Requirement 5 talks about having and using anti-virus. There\u2019s nothing that prescriptive in GDPR \u2013 just some nebulous terms about using state-of-the-art security.Information privacy and security compliance surely requires a control framework for measurement, right? Let's look at compliance with PCI DSS, which is (relatively) easy. PCI DSS is a series of clearly laid-out control objectives, most of which are infosec-related. The security design\/crypto team ensures that payment card data is encrypted appropriately, while the security assurance team schedules the pen test and works to remediate findings. Once they\u2019re comfortable, they call in the Qualified Security Assessor (QSA). Compliance is given as a percentage.Now, let's apply a GDPR lens to the compliance example above. My issue with this premise is that QSAs will not exist for GDPR. This is not a security issue to solve. Granted, a QSA's assessment that you're \u201cPCI DSS compliant\u201d should not be taken as a rubber-stamp that you're breach-proof (just ask Target). But at least we have a line in the sand. With GDPR, the first time you know how robust your controls are will be at the time of a breach. Isn\u2019t that a little like taking your driving test once you've had an accident?Compliance is achieved against a set of prescriptive control objectives. Unfortunately for many, these don\u2019t exist for GDPR.\u00a0 GDPR is concerned with ensuring that organizations have a legitimate, legal purpose for the collection and processing of personal data.\u00a0 It is up to the CISO and team to use their SME knowledge when interpreting \u201cstate of the art\u201d security and ensuring that controls are commensurate with risk.\u00a0 I would say that this isn\u2019t a paradigm shift in GDPR land.\u00a0 We have, ostensibly or otherwise, been applying this methodology for a while!Is it a European thing? (No)Let\u2019s put some of this in scope: There is a misconception in some quarters that GDPR applies exclusively to companies with physical infrastructure in a European country. Wrong! If you\u2019re in Europe and you are buying a product or service in the EU, then yeah, you\u2019re covered. \u00a0Technically,\u00a0citizenship\u00a0isn\u2019t the key point.If you\u2019re an EU\u00a0citizen, living in the United States, buying U.S. goods, being shipped to a U.S. address, thenno, GDPR wouldn\u2019t necessarily apply. \u00a0There are some \u201cextraterritorial conditions,\u201d but that\u2019s a fairly solid rule of thumb.\u00a0 GDPR articles 3 and 4 mention that a non-EU country is in scope if it is processing information of a data subject in the European Union. If the subject is English or American, it doesn\u2019t matter.\u00a0 The origin of the processing is important.Non-European Economic Area (EAA) companies can show \u201cequivalency\u201d of controls \u2013 something that Americans currently deliver for the EU 1995 Directive through Privacy Shield. What is Privacy Shield going to look like post-GDPR? Many of the principles will remain the same, but the interpretation and enforcement will certainly be different.Technology isn\u2019t necessarily a silver bulletI appreciate that GDPR is going to be big business for security and risk vendors. However, there\u2019s a danger of \u201csilver bullet\u201d selling \u2013 that is, claims that a solution will give you a failsafe way to address GDPR.\u00a0 From my point of view, security vendors can help with GDPR in the following ways:Provide expedient and professional engagement with customers to assist with the completion of supplier assessments, and privacy impact assessments.Provide solutions that intrinsically provide \u201cprivacy by design,\u201d minimize data collection, and provide capabilities for obfuscation and pseudonymization.Offer solutions that allow for the retention of information within the EU.Provide transparency\/adequacy of controls when information is processed in third countries.Let\u2019s move away from the vendor claim of \u201cwe can solve GDPR for you.\u201d(In this post, a friend of mine lampoons over-promising vendors in a brilliant manner.) Once an organization understands where its data resides, there are technical solutions that can mitigate the risks of a data breach.To sum up, let\u2019s go back to the original premise of this article: that 80% of GDPR is out of the CISO\u2019s control. What, then, is a CISO to do about the external perception that this is a security issue?It follows that for the privacy of data to be protected, it would likely be a grave mistake to allow data to leak, the kind of incident against which safeguards should exist. The best defense is therefore a good offense. That includes technology and practice-driven defense-in-depth techniques, of which every CISO should be a competent practitioner. But it also means taking a role in educating our boards, executives, and fellow employees on their role in protecting data: choosing systems and practices that support GDPR principles and maintaining practices that safeguard customer data.