Conversational GDPR

By Dawn-Marie Hutchinson

© 2018 Conversational Geek

Conversational GDPR Published by Conversational Geek® Inc.

www.conversationalgeek.com

All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission from the publisher. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions. Nor is any liability assumed for damages resulting from the use of the information contained herein.

Trademarks Conversational Geek, the Conversational Geek logo and J. the Geek are trademarks of Conversational Geek®. All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. We cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

Warning and Disclaimer Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an “as is” basis. The author and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or programs accompanying it.

Additional Information For general information on our other products and services, or how to create a custom Conversational Geek book for your business or organization, please visit our website at ConversationalGeek.com

Publisher Acknowledgments

All of the folks responsible for the creation of this guide:

Author: Dawn-Marie Hutchinson

Project Editor: J. Peter Bruzzese

Copy Editor: Nick Cavalancia

Note from the Author

The General Data Protection Regulation (GDPR), slated for a May 2018 effective date, is the newest in a growing series of regulations designed to improve data accountability and reduce privacy concerns for consumers. This Conversational GDPR book is written in American, for Americans, by an American. The goal of this book is to help broaden perspectives and bridge the cultural gaps between Europe and the United States which hamper our ability to effectively address global privacy concerns.

From here on out, there will not be any discussion about achieving “compliance.” If you wanted a line-by-line explanation of the regulation you could search for it on the interwebs. This book is not legal advice; if it were, there would be a bill at the end. But it will share strategies to guide organizations in making strategic data protection decisions. A compliance-based, checklist-driven program is never as effective as an evergreen, risk-based program with solid data governance practices. This book is written for the information security professional tasked with building a data protection program with GDPR in mind.

Got it? Let’s get into it!

Dawn-Marie Hutchinson

The “Conversational” Method

We have two objectives when we create a “Conversational” book: First, to make sure it’s written in a conversational tone so it’s fun and easy to read. Second, to make sure you, the reader, can immediately take what you read and include it in your own conversations (personal or business-focused) with confidence.

These books are meant to increase your understanding of the subject. Terminology, conceptual ideas, trends in the market, and even fringe subject matter are brought together to ensure you can engage your customer, team, co-worker, friend and even the know-it-all Best Buy geek on a level playing field.

“Geek in the Mirror” Boxes

We infuse humor into our books through both cartoons and light banter from the author. When you see one of these boxes, it’s the author stepping outside the dialog to speak directly to you. It might be an anecdote, it might be a personal experience or gut reaction and analysis, it might just be a sarcastic quip, but these “geek in the mirror” boxes are not to be skipped.

Hi there! Within these boxes I can share just about anything on the subject at hand.

Read ’em!

GDPR

Let us begin with a brief overview of what the Europeans mean when they say “data protection” and what that means in the US. In the US, security and privacy are often viewed as distinct disciplines. They say you can have security without privacy but you can’t have privacy without security. In the EU, they might not appreciate the distinctions because they generally refer to “privacy” as “data protection,” and security is simply a requirement of data protection.

If we want to understand the intent of the GDPR, we must start with an understanding of our differences; GDPR is as much a cultural exercise as it is a compliance exercise.

In Germany, when the “don’t walk” sign is on, Germans DO NOT WALK. Obeying the pedestrian crossing signs is a cultural expectation that is legally enforced. Americans have the same pedestrian crossing signs but, culturally, they often are observed as a mere suggestion, reinforced by a laissez faire application of the law. In the US, the benefit of crossing the street without delay outweighs the perceived risk of harm, inconvenience, or legal ramifications. An American in Germany is easily identified by their willingness to trade adherence to legal and cultural expectations with convenience. The GDPR seeks to deter similar trade-offs between personal privacy rights and business strategy with penalties as large as 4% of a company’s global revenue or €20 Million (whichever is greater).

As we try to figure out how to reconcile these competing cultural perspectives, it may be helpful to think about some common ways information can be misused and the consequences for consumers. In a nutshell, there are three common ways to think about data risks for consumers: Mischief, Injury, and Anguish:

• Mischief: Information, correspondence, and interaction that might leave an individual feeling creeped out or annoyed. i.e. Targeted marketing, listening devices, unwanted calls or emails, etc. What if we buy information about you from others and you don’t (or can’t) know about the purchase, or even know how that information might be used?

• Injury: Non-public information that, if disclosed, could increase the risk of financial loss or future fraud. i.e. Financial information, government identifiers… content personalization and advertising---what if we charge you

more or don’t make you an offer for a home or car because of things we learn about you?

• Anguish: From the company’s perspective, the information disclosed was not that bad, but the disclosure of it could have social or emotional consequences for the subject of the data. i.e. Internet browsing history, association with clubs or other organizations.

The GDPR is supposed to help manage expectations of handling data across borders and, ultimately, close the cultural gap and reduce the likelihood of mischief, injury, and anguish by establishing practical rules concerning how information is collected, used, and shared.

In this particular instance, it’s important to remember the words of comedian Louis C.K.: When a person tells you that you hurt them, you don't get to decide that you didn't. All this really means is that your organization does not get to tell the data subject that the information you have on them isn’t a big deal. It might be a very big deal to them and companies don’t get to decide what is or isn’t based on their own business interests.

Sensitive Data A book about a regulation would not be complete without a list of the data elements that are specifically identified by the regulation. Just as some people are more sensitive than others, some information is more sensitive than other information. And, as the adage advises not to talk about money, politics, or religion at a dinner party, so too does the GDPR provide guidelines on when and how you can share sensitive information.

In general, mischief, injury, and anguish are the things that tend to make information sensitive, whether under GDPR or any of the other nearly 200 US federal laws regulating privacy

and data protection. While a compliance-oriented, checklist-driven approach would let an organization focus on the trees that are data elements, it would ignore the forest—that the reason we care about these data elements is because if we misuse or abuse the trees, we harm the forest, and the forest represents real people; our customers, our families, our friends, our kids.

Don’t get me wrong. Early in my career, I supported many IT audits and I know that

there are some of you that really, really, like hard-and-fast rules; the same people who are

likely most unsettled by this regulation that implores you to use best judgment and a

sound risk methodology instead of the familiar checklist of must- haves.

So here it is…sensitive personal data under GDPR applies to:

• ‘Personal data,’ meaning any information related to a person. I get that is a pretty broad statement, but if a person can be directly or indirectly identified by the data you collected, it is in scope for GDPR. Anonymization or pseudonymization you say? Well, that data, despite your best efforts to de-identify, may still fall into scope for GDPR depending on how hard it is to put all those pieces back together and re-identify the person in real life or with other publicly available data sets.

o Basic identity information such as name, address, and ID numbers

o Web data such as location, IP address, cookie data, RFID tags, and iTunes playlists.

o Affiliation, or identification with an organization (religious, political, NKOTB fan club, or shopping habits from “that” store…you know the one).

• ‘Sensitive personal data’ is another thing altogether. Not surprisingly, it is the more-sensitive kid brother of personal data and pretty much includes anything of a biometric or scientific nature. Generally, it is stuff like DNA, facial recognition information, fingerprints, race, or ethnicity…all things we cannot change following a data breach. You will need to ensure extra safeguards are in place for this data type and, if you have it, you should check in with Article 10 of GDPR to ensure full and complete understanding of the rules.

Ultimately, we are looking at information used alone or in connection with other information that can positively identify an individual. Information that, when inappropriately used or disclosed, could cause mischief, injury, or anguish to the individual.

Sorting Out Who’s Who Before we begin, we have to talk a bit about GDPR lingo, those magic phrases that, if mastered, will help you dazzle your bosses, outside consultants, and maybe even pesky know-it-all lawyers. When you get it right, you’ll get respect. Get it wrong and you’ll watch the know-it-all eyeballs roll. So, in GDPR lingo, there are a few key terms which refer to real and actual people. These people are:

Data Subject

The people whose personal information we are talking about. This person willingly (hopefully) provided their personal information to someone, the “Data Controller,” which I’ll get to in a minute, with the understanding that it will be used for a specific business purpose. And, when done as GDPR requires,

the data subject was provided notice on how that information would be used…

“in a concise, transparent, intelligible and easily accessible form, using clear and plain language, in particular for any information addressed specifically to a child.” (Art 12 (1))

Data Controller

The person (most of the time an organization) who collects the personal information from the data subject and usually has direct contact with the data subject is called the “Data Controller.” They have the business relationship with the data subject and have provided the person – see how I did that, reminding you that this is about people and not checklists – with a clear communication about what the Data Controller will do. This communication explains what the information is used for, how it will be processed, and the data subjects’ legal rights. Just like when police officers make an arrest and must read the person they are arresting their rights, so too must data controllers generally do something very similar for data subjects whose data is in their custody. Data controllers are responsible for the relationship and, therefore, will be at the center of all communications with the data subject.

Data Processor

If you’re like me, you know that you can’t do everything involved with running your business. You need some help, and these “helpers” in GDPR lingo are called “data processors.” In many ways, they can be like the little green creatures in the movie Gremlins. They’re initially cute and huggable but, without careful monitoring, they can be the source of an enormous amount of mischief, injury, and anguish.

To help avoid these challenges, the GDPR created a special label for the people who do things for other people—the “data processor.” Data processors perform business functions or

process data, on behalf of data controllers, which needs to be documented. They must:

• adhere to the data protection controls,

• avoid sending the data off to another processor without permission by the controller, and

• be able to execute on the data subject’s rights to access and erasure.

In short, a data process must adhere to all the things the data controller has to, from a compliance perspective, without the requirements of defining the relationship to the data subject; so all the pain of making mistakes PLUS the likely risk that the person they’re working for will seek to hold them accountable.

Supervisory Authority

GDPR also introduces a new person with whom many Americans may be unfamiliar when it comes to information management risk. We’re all conceptually familiar with regulators but, with GDPR, the saying “we’re from the government, we’re here to help” takes on a whole new meaning. One handy way to think about the supervisory authority is to think of them less like you might think of a traditional regulator and more like a mediator or a referee.

The GDPR is written with data subject rights in mind, but the regulation recognizes that data controllers and data processors need to be able to conduct business. The supervisory authorities are in place to referee these relationships and, ultimately, to protect data subjects while taking into account the needs of data controllers and data processors. Recognizing this role, knowing who the mediator is, how they think, and what their aims and goals are can help manage expectations and meet business goals.

To put it all together, let’s use an example:

Abner borrows a book from the library. The library is the data subject because they own the text. Abner is the data controller, because he has a contractual relationship with the library. Abner has agreed to lawful use of the information and has vowed to protect it and return it when required and to notify the library if something happens to the book.

Abner and Bruce are working together on a research project. Bruce borrows the book from Abner. He agrees to care for and protect the book the same way that Abner has. If he loses the book, he must tell Abner as soon as possible so that Abner can communicate with the library. Bruce is the data processor.

Bruce also has a library card for the same library which means he also has a direct relationship with the library for book borrowing. In this circumstance Bruce would be a data controller for all the books he borrows from the library directly, and a data processor for the book he borrowed indirectly via Abner.

Abner and Bruce are fictional characters used by my late law teacher Walter Lubelczyk

(Manchester High School West, Manchester, NH) to demonstrate parties A & B in case law. They are used here in memory of him, and in honor of the base of knowledge he gave me

for this job. Think of this both as a dedication and a citation. To help you understand,

search “Seth Meyers tribute to law teacher.”

The Rules of Play So now we know who the players are, the team, and the objective of the game. Let me see if I can help articulate the rules of play.

Lawful Processing

Why do you need to be compliant? This seems pretty straightforward, but there is a reason I am calling it out here. Your organization should be prepared to show legal justification and consent for processing information of residents of the European Union.

As we think about lawful processing, it may be helpful to remember Abner and Bruce and their library books. As you review your collection practices, you should question how and why information is collected. This is like knowing which books you have, where they came from, when they’re due, what they’re about, and why you checked them out in the first place. Just as there are rules for how Abner and Bruce can borrow books from the Library, there are rules for how your organization can and cannot process personal data. Knowing the rules and being able to explain your knowledge is essential to making sure you can check out books and keep the librarian (the “supervisory authority”) and the library (the “data subject”) happy.

The GDPR defines the rules for the collection and processing of information, but since this book is for the tech set, I recommend you leave the lawfulness of processing analysis to counsel; one of the best ways I have seen security officers minimize their role in the executive team is by deviating too far outside of their lane. The reason I call it out here is that you will need to conduct an inventory of all the data and assess the risk posed to that information. Your work in these areas will support your management team in supporting the lawfulness

requirements. If the C in CISO is “silent,” having the data to support their business and legal decisions will change that.

The Team Captain

GDPR is a team sport and you are often the captain of the data protection team. If you have not met the general counsel of your organization, I recommend putting this book down and picking up the phone. Think of yourself as the defensive coordinator where the general counsel or chief privacy officer is the head coach. You are likely responsible for technology risk, but data risk encompasses more than just data protection; it involves the lawful collection, use, disclosure, and destruction of data, which are generally things easily outside your lane.

Depending on the nature and scope of processing activities, your organization may need to appoint a data protection officer. I recommend seeking legal guidance on interpretations of the GDPR. If your interpretation is later called into question, it is valuable to have documented legal guidance; let’s just call them the “special teams.”

In my experience, I have found American IP, technology, and data lawyers with global experience are better suited to address the needs of American companies in this regulation than European lawyers with limited experience with American companies. But, then again, “Potato, Po-tah-toe.” Things won’t go well for you if you bring a football to a soccer match, so mastering the lingo and understanding differences in the games can help ensure your success.

The Game Plan

Once you have assembled the team and begun assembling a list of where your data comes from, you should begin data inventory and mapping exercises. Together with business leaders, identify how the data moves through your

organization and where it lives. In my experience, clients discover latent business processes that receive, store, and process data unnecessarily. They find business processes that are in place because they “have always done it that way.” The unintended benefit of this activity is business process redesign. Consider why and what data is available in each process and challenge business owners to justify the use and limit access.

When we think about data inventory and mapping exercises, it is handy to think of it like accounting. This doesn’t have to be completely exhaustive and, often, the “maps” are out of data before they are even completed. This is not a matter of documenting every tree in your forest but, instead, of understanding the varieties, where they’re planted, why they’re planted, and their broader relationship to the forest.

While data inventories are important for good data governance, IT pros should be wary of consultants coming along as forestry managers insisting that GDPR requires that we catalog every leaf on every tree in the forest. We don’t have to record everything, that would be impossible. But we have to do enough to be able to understand how we collect, use, and disclose information and to comfortably assess things. Just as Abner and Bruce don’t have to know every book in the library, they still need to know the types of books they borrow and lend to each other, and when they’re due.

The GDPR requires a “Record of Data Processing Activities” for all in-scope data, but it is a good idea to conduct this activity for all the data moving through the organization. Let’s not act surprised when more regulations of this nature come down the pike… To support your documentation and computation, consider the following method of information accounting using the question words.

• What – Describe the data element. Include the level of sensitivity or classification

• Why – Document the business requirement or legal justification

• Where – Define which systems process or transmit this data, where it goes in the organization, and any 3rd parties which send or receive this information

• When – Define the data destruction policy for this type of information

• Who – Identify the business partner or unit responsible for the data

• How – Establish minimum data protection safeguards

Now that we have built our team, picked our positions, nominated a team captain, and built our playbook, let’s talk about the “fans” (data subjects) and their expectations for “rules of play” in this exhausted sports metaphor meant to make this all a little easier to digest.

Data Subjects’ Rights Again, this section is likely why you picked up this book, but there are some components of the data subject’s rights that are operational in nature and have technical ramifications. In fact, most of the questions I get about GDPR focus on how to operationalize the data subject’s rights. It is critical that the organization document how it intends to respond to each of the following requirements. Remember, “show your work,” think through how you will support the data subject’s rights, and then work on the technical solutions. You will likely need to build or buy a mechanism for receiving requests from data subjects. My recommendation: whatever you buy should have the capability to feed your ticketing systems for workflow processing, documentation, and timely responses.

The GDPR provides the following rights for individuals:

The Right to Be Informed

Do you remember the fast-talking Micro Machines commercials? You cannot provide your data subjects with the fast talking, hard-to-follow disclaimer statement of your data use. And you can also forget about the multi-page, 6-pt font privacy policy. The right to be informed means that the organization will provide the data subject with a statement that clearly and concisely states what the organization plans to use the information for.

The Right of Access

Data subjects have the right to ask you if you are still processing their information and, if so, for what purpose; and to validate the accuracy of the information you are processing. This allows the data subject to validate the lawfulness of the processing of their information. When requested, organizations will have to provide the data record showing what data is stored and a list of all of the processing activities on that record. Don’t forget every business process leveraging unstructured data; perhaps the most technically challenging implementation in GDPR.

The Right to Rectification

Are you starting to see a pattern? The data subject’s rights are purpose-built to hold organizations accountable for the information they collect, store, and process. In the right to rectification, the data subject can request changes to the information. Like the right of access, this is technically challenging and requires a one-month response time by the organization. Tick-tock.

The Right to Erasure

This is more commonly known as the “right to be forgotten.” This is the most commonly asked question amongst technology

professionals because, on the face, it is technically challenging. Remember how I told you about the “legitimate business interest” clause in the Lawfulness section? Data subjects do have the right to ask organizations to stop processing information about them. That means deleting the record from nearly all places it exists EXCEPT if the organization has a legitimate business interest to maintain the record.

Go back to the three-part test to justify business interest:

1. Purpose test: Are you pursuing a legitimate interest? 2. Necessity test: Is the processing necessary for that

purpose? 3. Balancing test: Do the individual’s interests override the

legitimate interest?

Information that commonly meets the business interest requirement is data backups or operational data such as system logs. Things that you require to run the business, but which have limited effect on the privacy of the individual. Also exempt from the right to be forgotten is any information that has another law that requires storage; financial transactions or human resource records, for example.

You will, however, need to find the individual in every instance of unstructured data formats… Remember that part about business process re-engineering? Consider what business needs are not being met when a business unit creates high volumes of data in unstructured formats and figure out how to help solve the business problem.

The Right to Restrict Processing

The data subject can ask you to stop processing information but may not ask you delete them altogether. This can introduce another technical challenge, but one which can support GDPR: Consider moving the information to a separate system, or

leveraging your identity and access management program to restrict system and user access to this type of data.

The Right to Data Portability

Make sure your data subjects can pack up their data and take it with them in a structured, commonly used, and machine-readable format; within a month of the request. Again, technically challenging, but the GDPR does not say that your organization must install any system for technical compatibility. Focus on what your organization can do and build a roadmap for what you will do in the future. Do not forget to verify that the person asking for the data record has the right to receive it.

The Right to Object

More commonly understood to be “opt out,” a data subject may request that you discontinue processing for marketing, profiling, research or statistics. This category allows the data subject to object to the processing of their information in public interest or legitimate business interest activities. Unless you can demonstrate that there is a legal claim, or that the business interest overrides the interests, rights, or freedoms of the individual, you must stop processing.

Rights in Relation to Automated Decision-making and Profiling

During your data mapping exercise, identify all instances of automated decision-making or profiling activities which do not involve any human interaction. There are legal nuances and you should consult counsel during your data mapping activities if you identify this type of data processing.

Profiling is defined by the GDPR as:

“Any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person’s

performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movements.” [Article 4 (4)]

Data Protection Responsibilities In the United States, our compliance activities tend to be checklist-based, easy to understand, and easy to audit. Some say that the GDPR is more ambiguous, but I would argue that it provides focused attention on business-aligned and threat-aware security programs. It allows security professionals the flexibility to build appropriate controls for the way the business operates. Under the GDPR, the organization’s varying degrees of program maturity, processing activities, expertise, and budget will ultimately determine how it approaches the imprecise nature of the regulation.

Under the GDPR, organizations have an obligation to implement technical and organizational measures to show data protection has been implemented “by design and default.” The regulation states:

“Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organizational measures, such as pseudonymization, which are designed to implement data-protection principles, such as data minimization, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of

this Regulation and protect the rights of data subjects.”

That’s it. That’s all. Now that isn’t so scary, is it?

Reasonable Security

Every business is different and, as such, processes information differently. The GDPR builds in a level of flexibility to respond to those differences by mandating that companies provide a “reasonable” level of protection for personal data, but does not define what constitutes “reasonable.”

If I send my 9-year-old twins to clean their room, chances are they will come back in 10 minutes and tell me it is clean. Meeting the GDPR security requirements are similarly as vague as a child being told to clean their room. Do they have the experience to know which tasks to do, in what order and when? Do they have the skills and tools to perform those tasks? Do they have the maturity to understand my expectations? Did they seek third party consulting or validation from their older, more experienced sister? As the parent, I will judge how reasonable their effort was based on my experience and expectations. They cannot know or understand, and that is the trickiest component of the GDPR.

Reasonableness is, effectively, crowd-sourced opinion; if we gathered a group of security professionals, would they believe the program I have built here meets the “reasonableness” threshold? If we watch the Twitter feed load up expert opinions on the latest breach, it takes mere minutes to determine if the facts of the disclosure lead experts to believe that the security program was “reasonable.” A better way to approach determining “reasonableness” is to have an established third party perform a program maturity assessment. As I mentioned before, GDPR is not prescriptive and, therefore, not subject to check-the-box assessments.

What about a framework gap assessment? No… Just no. Trying to force GDPR and data protection programs into myriad check box-auditable formats leads to high-cost, low-effectiveness programs categorized by impaired business operations and executive friction. Why? Because the focus is on the control and not the business, the data, or the threats to either.

The National Institute for Standards and Technology (NIST) and the International Standards Organization(ISO) maintain industry-recognized frameworks for cybersecurity that guide organizations in building security programs. Security frameworks are not, historically, data-centric and most controls focus on the information systems. Remember when I said “you can have security without privacy but you cannot have privacy without security.” Focused framework alignment puts the focus on building security programs, but does not necessarily support an effective data protection strategy. To be clear, NIST and ISO have their place in building security programs, but a heavy technical focus and variations of control maturity provide little in the way of assurance for a business-aligned, risk-based, threat-aware security program.

Secondarily, we may achieve framework alignment, but the additional technical controls may unnecessarily inhibit business operations. If I have said it once, I have said it a hundred times: a door can have 50 locks on it, but it becomes a terrible door. The business of the door is to provide an ingress/egress point for a building, room, or spaceship; too many locks inhibits its core function. Worse, people will find another way to get in or out… possibly a route you aren’t aware of. Instead of unnecessarily burdening the business with every type of control available, we should design our locks for the kind of door and sensitivity of the space behind it. In other words: your technical and organizational controls should align to your business, first and foremost.

Where Do We Start? Let us talk about some pragmatic strategies to ensure you meet the “reasonable” threshold.

Objectivity Versus Subjectivity

Have you ever been walking through a crowd and see someone with incredible “style?” You know the ones. You’re sure they do not own a mirror. This person left the house this morning thinking “wow, I look good.” From their perspective the efforts they made in getting ready made them happy and confident in their appearance. In their social circle they may be right, they really do look great, but to an objective third party they have missed the mark. One way to establish reasonableness is to engage an objective third party to assess the organization’s data protection program. The singular focus of this activity is to identify which areas of the organization’s program need improvement and to create a roadmap to get there. Organizations should focus on four areas that are required to meet sustain program maturity and reasonableness:

• Data Governance

• Incident Response

• Data Protection Impact Assessments

• Third-party Risk Management

Data Governance

Data governance is not, historically, a strength for many US-based organizations. To be fair, it is unclear that we have all agreed on what data governance actually is, and we have been fighting the tide on defensive and detective controls with an ever-changing threat landscape. It is not uncommon to see a security organization operating without a well-defined data governance program or complete asset inventories.

Begin by mapping your data flows. This is your first stab at identifying business processes that collect, use, and disclose personally identifiable data. Document all the ways your organization collects information. Where does it all come from? Do not skip this step, the regulators will want to see that your organization understands the obligations under the rule, and the best way to demonstrate understanding is documentation. Think of this like long division; the teacher will give you partial credit for showing your work even if the answer was wrong.

Where it comes from should also establish why the GDPR applies to the data you

process. If you provide a service either in a physical location in Europe, or by way of the

interwebs, you will be required to conform to the regulation. If you are in the US and an EU resident interacts with you here, and you do

not collect information for a secondary purpose, you are not required to be

compliant. Having a business interaction with a EU citizen does not automatically require compliance under GDPR. What you do with

the information does.

Data governance has been a challenge for American companies and, most often, is the program that will require the most attention in your race to compliance. As you document where your organization collects data, record what the privacy policy says you are going to do with the information. This is the equivalent of checking your computation in a long division problem. The quotient multiplied by the divisor should give you the dividend if you have done the computation properly. Checking that your privacy policy reflects the processing activities can ensure proper computation of privacy principles.

Organizations that build data protection policies and procedures with the data sensitivity principles of MIA in mind will have an easier time adhering to the rules than organizations that put revenue over integrity. When I took the CISSP exam (oh, jeesh ages ago), when I was presented with a multiple-choice answer that related to protecting human life, that was always the answer. The same is true when evaluating data handling practices under the GDPR. The data has real consequences for real people, so the answer should always be protecting the rights of individuals first, above all else.

Incident Response

Abner and Bruce are busily working hard to ensure that they have consent for data collection. The information processing is all on the up-and-up. They have also invested in people, process, and technology to ensure that the information in their care is secured, accurate, and available. Despite all their best efforts, the data is stolen, or the systems are unavailable and the information unusable. What do they do now?

I am not now, nor have I ever been, a fan of mandatory reporting timelines. In my opinion, it takes at least 6 weeks to undergo a forensic investigation to determine not only what happened but if it is still happening. Forensic teams comb through terabytes of data looking for clues, piecing together the incident, and identifying what, if any, information was stolen. Mandatory reporting timelines do not consider technical limitations or the complex nature of incident response. That being said, apparently the regulators don’t really care what I think… or maybe they do. The words “where

feasible” are also in the rule. This is why you have this book in your hands; I’m not sure why, but this nugget of information is rarely discussed. So here is the actual text from the regulation.

“In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.”

So, what does that mean? It means have a plan. The GDPR doesn’t specifically state that you must have an incident response plan that is regularly tested that includes provisions for enterprise-level incident response. It says respond without undue delay and, to do that, you’d better have a plan. The better your plan, the better your reasons will be if you cannot accommodate the 72-hour notification requirement. Again, this is a place where we show our work to get partial credit.

You must ensure that you have adequate visibility of indicators of compromise. My friend and colleague Steve Naphy always says “that which we cannot defend we must be able to detect,” or something like that. Basically, he is saying security incidents happen despite our best efforts, but when they do happen, we have to be able to detect them. My advice is to invest in your incident response programs, look at the people, process, and technology that support your IR plans, and ensure adequate maturity of your detection and technical response capabilities.

You will not be able to defend against every attack or well-intentioned, misguided insider; but you can reduce the mean time-to-apology by ensuring that you can see what is happening with your data. At the end of the day, the regulators

want to minimize the risk to the data subjects by minimizing the amount of time the data is in the wild and causing injury and anguish. Minimizing the risk has less to do with how fast you notify the regulators and more to do with how fast you detect the data loss. Detect fast, investigate carefully, and notify with alacrity.

Third-party Risk Management

You will need to identify all your business partners who have access to information. Whether they are coming in to your network to perform a service or you are sending information to them for processing, you will need to ensure that their data protection program meets the letter of the law. Shameless plug: Send them this book. That means not only requesting attestation from some, but also conducting assessments on others. Time to bump your third-party risk management strategy up the priority list.

Many organizations still don’t know who their third parties actually are. Sometimes it is organizational structure, sometimes it is autonomy, and sometimes it is as basic as shadow IT. Whatever the case, I find the best places to start are remote access provisioning and accounts payable. Find out who has access and/or find out who you are paying and start considering how you will build those people into your third-party risk program.

The Privacy Tax There has been a lot of scuttlebutt about compliance with the GDPR and how fines will be levied. Between you and me, we will call these financial penalties the “Privacy Tax.”

Firstly, the fines and penalties have been set at graduated levels commiserate with the level of non-compliance that resulted in the grievance. These include:

• Requirement for remediation

• 2% or 10M Euro for failure to meet the following

o a) the obligations of the controller and the processor under Articles 8, 11, 25 to 39 and 42 and 43;

o b) the obligations of the certification body pursuant to Articles 42 and 43;

o c) the obligations of the monitoring body pursuant to Article 41(4).

• 4% or 20M Euro applied for failure to meet the following

o a) the basic principles for processing, including conditions for consent, pursuant to Articles 5, 6, 7 and 9;

o b) the data subjects’ rights pursuant to Articles 12 to 22;

o c) the transfers of personal data to a recipient in a third country or an international organisation pursuant to Articles 44 to 49;

o d) any obligations pursuant to Member State law adopted under Chapter IX;

o e) non-compliance with an order or a temporary or definitive limitation on processing or the suspension of data flows by the supervisory authority pursuant to Article 58(2) or failure to provide access in violation of Article 58(1).”

The Big Takeaways What is the point of picking up this book and getting this far if, in the end, we have to go download the regulation from the internet anyway?

All you need to know is this: the fines are graduated. You are subject to the first tier if you fail to build a security program that supports the regulation’s underlying goals of data

protection, and the bulk of higher tier two fines will be levied on organizations that do not meet the principles of data protection or observe data subjects’ rights. The latter should conjure memories of the section about lawfulness of processing where I said “I recommend that you leave the lawfulness of processing analysis to counsel.”

For companies processing European data who are, perhaps, a bit more reluctant to take on the array of activities and establish the standards necessary to avoid GDPR non-compliance, the Code of Ethics required by Sarbanes-Oxley mandates organizations to comply with all applicable laws. If management spends too much time concerning themselves with the what-ifs and data is compromised in the interim, just wait until the Securities and Exchange Commission get their hands on them. Awareness of non-compliance brings the kind of hurt that makes management wish for only 4% of total revenue. Let’s not forget about the damaged brand image and increased regulatory scrutiny that follows.

In short, this text was written to help you have better conversations with your management team about GDPR and data protection, in general. I implore you to stay in your lane and focus your attention on executing the challenging requirements in the most reasonable way possible. We know there are technical limitations and we know that you are likely battling a management team that is walking into this regulation slowly and begrudgingly, and that you may feel like you are responsible for keeping the company assets out of the fire.

Remember GDPR is a team sport – legal, privacy, and security will need to work together and take equal accountability for building an evergreen, risk-based data protection program.