Oktane18 Keeping Your Data Safe -- Identity, Security, and the GDPR

Tim MacIntyre: All right, good afternoon everybody. Thank you for being here today with us at Oktane, and we appreciate your taking the time from your busy schedules to join us and to talk about the GDPR. Some standard language there, our disclaimer regarding forward looking statements. And just a few words about myself before I begin. I'm Tim MacIntyre, the Associate General Counsel here at Okta, and I also serve as Okta's data protection officer. Under the GDPR the new regulation encourages but does not necessarily require companies to appoint a data protection officer or DPO. A DPO is charged with making sure that their organization's data privacy and practices are compliant with applicable law and that employees and customers and partners are given access to the tools that they need to succeed with respect to data privacy and security.

As an attorney I've been advising software companies for the last 15 years, and I can say that the GDPR is one of the most interesting and revolutionary developments really in the area of privacy law in our lifetimes. It's a pretty big deal. I'm going to be providing you with an overview of the regulation as well as some key points and will enter into some discussion topics as well at the end with some Q&A and my colleague Chris Nagle will also be speaking after me. He's our director of security and compliance, and he's going to talk about how Okta can help your organization meet its GDPR compliance needs, and we also want to note at the outset that any GDPR compliance needs to be a part of any impacted company's comprehensive compliance framework, but that no technical solution, not even Okta as good as it is, can be a silver bullet and solve every need. Every company is on its own GDPR journey. Smaller companies may be at a different stage in terms of their compliance, and larger companies may be a little further along, but no matter where your organization is, it's never too late to either work towards higher GDPR compliance or to iterate upon existing practices that you may have in place today so that you can be in a better position going forward.Before we dive in to start talking about the GDPR itself, I think it's important to provide you all with some background about Okta and our approach to data privacy. It's pretty simple, at Okta trust is our number one value. We put the trust of our customers at the center of everything that we do, and nothing is more important to us and the protection of our customer's data. So we say in our customer contracts, I know not everyone necessarily enjoys drilling down into the fine print of a software agreement, but we say very clearly that Customer Data is defined broadly to include any data entered electronically into the Okta service by a customer. We make certain promises and assurances with respect to our treatment of Customer Data.

Okta was born in the cloud. We started almost a decade ago, back in 2009. Back then the idea that companies were going to put their identity solutions, including all their data related to that, into the cloud was pretty radical, and through conversations with our customers and our intimate understanding of trust, security, and data privacy, we've been able to distill our approach to data privacy really down to three key points, and it forms a very simple framework. The first is that our customers data belongs to them. The second pillar is that we don't use it for any other purpose other than providing the service back to our customers. And third, it's our job at Okta to make sure that we do our best to protect and keep secure our customers' data.So we have a strong culture across the enterprise at Okta so that all employees keep these principles top of mind, and on the legal team we ensure that Okta complies with privacy laws and we help enable our customers compliance and using our Okta service.

There's really no finish line when it comes to GDPR compliance. And while Okta offers tools today that can help customers be GDPR compliant, we're going to continue to bring new tools to market over time to help our customers achieve compliance success. I think it's also good to kind of step back and think about the changes that are going on globally at a macro level in the field of data privacy. You know, the World Economic Forum describes the age that we're living in and what we're currently going through as the fourth industrial revolution, and with nascent technologies such as second wave cloud computing, artificial intelligence, the Internet of Things, blockchain based technologies, and more we're seeing an unprecedented proliferation of data. Individuals are expecting more personalized experiences than they ever have before, whether it's in retail, healthcare, or financial services. At the same time they're demanding that they be in control of how their personal data gets used. So companies must demonstrate that privacy is a top priority in order to be able to earn the right to deliver those state of the art user experiences and earn customers' trust.

Okay. So let's dive into the GDPR itself. The GDPR stands for the general data protection regulation, which is a landmark regulation that governs how companies can process, store or otherwise use the personal data of EU individuals, and the GDPR actually goes live so to speak this Friday. It's actually been on the books for a couple of years. It's a law today at the moment, but the EU data protection authorities have given organizations essentially a two year grace period, and as of Friday they can begin exercising their enforcement power. The Irish data protection authority was ... I heard her speak recently. She was joking that everyone keeps coming up to her and asking her, "Is there are compliance period?" And then "Is there going to be a grace period as well?" And she keeps saying, "Well, this is the grace period." You know, "It comes to an end on Friday. If there's any grace period it'll be maybe until Monday. You'll get the weekend, and then after that everyone's got to got to get it into compliance."

So just how big a deal is the GDPR? I think this statistic, this was interesting, I saw this on the airplane coming in from Oakland. According to Google search volume just in the past couple of weeks GDPR as a search term has overtaken Beyoncé say as a search term, and Beyoncé has over 100 million Instagram followers, right? Maybe the biggest pop star on the planet, and when you have a data privacy law overtaking her as a search term, even if it's only temporary, I think that's sort of goes to show the level of interest around the planet in the GDPR and underscores how seriously people are taking it, or at least how curious they are about it, which I view as a good sign.

You may be out there in the audience today and you might be thinking to yourself, "You know, I work for a midsize company. We're based in the United States. We don't even have an EU office. Does the GDPR really apply to me? Do I need to be worried about this?" And the answer is yes, in all likelihood. The GDPR applies to any organization that processes the personal data of EU individuals, so in today's global age, that means that if you have users who are in Europe or if you do business with companies that are based in Europe and you have information about contacts at those companies or if you market to the European region, there's an overwhelming chance that the GDPR applies to your organization. This is really an extraordinary piece of legislation because it regulates overseas companies activities in a way that's never been seen before. So if an overseas company is subject to the extra territorial reach of the GDPR fines and penalties can be assessed against it regardless of whether it even has an office in the EU. So that's a big C change.

Coming back to the regulation, the GDPR applies to personal data and you've heard that term probably in countless online articles. You hear it in the emerging parlance of the year, personal data. What does that actually mean? The GDPR doesn't actually define personal data, but data protection authorities in Europe have given some preliminary guidance as to what they're going to take to mean to be personal data. The obvious ones, names, email addresses, phone numbers, physical addresses like home address, even IP addresses. If you have a smartphone, there is an IP address attached to it. Other IP addresses, you know, you may be able to sort of think through the scenario where an IP address attaches to an organization or a group of users, not necessarily to a user, him or herself. But the GDPR was designed to be future proof so that pieces of data, if they can be used to triangulate back to an individual and identify him or her, those can be deemed to be personal data. The EU is basically reserving the right over time to interpret what it is to be personal data and how that's going to be defined. So it's important that everyone stay up to speed on how courts in the EU we're going to define it. I think we'll see more guidance after May 25th. Right now it's a bit of a parlor game. Everyone's watching and waiting to see what kind of court decisions are issued by the EU with respect to some of these clarifying points, so we will see.

So who does the GDPR apply to? It covers EU data subjects. Data subject is just a person, an EU individual that you'll hear that term a lot. Data subject. It's just somebody who is from the EU. Wherever they may be in the world it applies to them. So EU citizens who are working in the US, it could encompass spouses or family of employees. If there are EU citizens who are customers or users of your organization, they would be covered by the GDPR and I think a lot of companies are reaching the conclusion that because solving for the GDPR, if you will, is sort of the toughest, most challenging global jurisdiction from a privacy level to solve for it. You solve for Europe, you basically, I can't say this with 100% certainty, but you've essentially solved for the world.

There are so many privacy regimes around the world. There are discussions around emerging legislation around the world and there's a lot of sort of Venn diagram overlap between these various frameworks, but the GDPR is by far the most comprehensive, so if you saw for the GDPR, you've probably solved for the rest of the world for the most part. As a result of that, companies are taking a broad approach to the GDPR. You've probably seen a lot of announcements this week from very large companies saying that they will treat all users the same way. Every user gets GDPR rights. They're not going to segregate users based on geographic region. They're like in a bucket, American users, EU users. It's hard to know, first of all, who is an EU individual or who it is not. I grew up in America. My Dad's an American. My mom is from England, so I have dual citizenship, so for me, even though I work in California and covered under the GDPR, so that's just one example of how this will kind of play out. I think it's a lot easier if you just treat all users and individuals equally. It makes it easier to solve for.

I think it's also useful for us to anchor on two foundational concepts today. Under the GDPR it's a dense regulation, it's 88 pages, and as lawyers we can really geek out on some sort of edge case scenarios and try to sort of game out how courts might interpret certain things, but at the end of the day, taking a more practical approach to it I think is the best way to think about it. And at its core at the heart of this 88 page regulation would be two definitions: data controller and data processor. Thinking about the Okta customer relationship in that relationship that we have with our customers the customer is the data controller. A data controller is an entity that makes sophisticated controlling decisions about how data is collected and how it's used. So, kind of walking through that a customer would decide who to give subscriptions to, right? They're going to let certain users use the Okta service. They're going to decide which personal data is taken into the service. Whether the personal data needs to be changed. For example, let's say a user changes his or her name, the customer as the controller would be in charge of that.

Now, by comparison Okta is the data processor. Okta decides how to collect the personal data at a software level. How do we actually take it in? How do we ingest that data? How do we store the personal data? For example, we run our application on AWS, so we have made the decision to store it in that way. We also decide what security measures should guard the personal data. We have a great story to tell about security and Chris will touch upon some of those topics when he speaks. Okta as a data processor also decides what methods can be used to retrieve the data and to delete the data when it's no longer needed, and the data processor essentially act systematically and robotically at the direction of the controller. So you think about the Okta service, it's a hosted web offering. We have the same stack essentially for our thousands and thousands of customers around the world. So when those inputs come in from the controller, we act in the same way with respect to each customer as a processor. And there are different legal obligations for the controller under the GDPR as there are for the processor. A given company can be either a controller, a processor, or both in the way it conducts its business.

So how are companies preparing for the GDPR? What are they thinking about as they approach the May 25th go live date? A recent survey of software industry professionals revealed that 87% of CIOs were concerned with their current security policies with respect to GDPR prep. About a quarter of CIOs said that they wanted to tighten up their data sharing practices. So thinking about the way the data is taken in by a company and then shared with its business partners, that's becoming a little more strict under the GDPR. And about three quarters said that their company plans to spend at least $1 million on GDPR compliance. So people are making a real commitment to put data privacy at the forefront, and I think that's a good thing. Another topic to discuss here would be ... it's an interesting topic that's introduced by the GDPR. It's it gets to the way that data is anonymized or pseudonymized. So the GDPR, remember, it covers personal data, but there's a reward if you will if you anonymize that personal data, if you take that personal data and in whatever technical way you choose, if you obfuscate it, render it unreadable, you scramble it, encrypt it, whatever the case may be. If you do it in such a way as to make it essentially useless or unreadable and you fully anonymize it by speaking metaphorically, you throw away the key so that if it were ever to be released out into the world as part of a breach there would be no bad consequence.

You're rewarded for doing that because the GDPR excludes anonymized data from its scope. So you would have no security breach obligations under the GDPR if you take steps to anonymize personal data. So that's a very powerful tool for organizations. Pseudonymous data is a little different. It would be the scenario where you take the personal data, again, you render it unreadable, but instead of throwing away that key you store the key. You keep it somewhere safe and secure, but you still have it, so it's still possible either theoretical or more than theoretical to go ahead and connect the two back together to reidentify the person. If you do that, the standard is a little different. It's a little more relaxed than say, for completely plain personal data that's personal data on its face. But the GDPR still regulates pseudonymous data. Those are some important categories to think about as you look to solutions to use as part of your own company's GDPR compliance efforts. Next, I'm going to talk about what are known as DSR's. DSR's stands for data subject rights. One of the key principles of the GDPR is giving individuals control over their own data privacy. Individuals under the GDPR are allowed to exercise certain rights. Under the GDPR, you have the right to erasure, also known as the right to be forgotten, where individuals can reach out to controllers, and controllers, if requested, would need to erase a person's data if the data is no longer needed for its original purpose, if the individual user withdrawals his or her consent, or if there are objections to the processing. A real world example might be, let's say you gave consent to a company and you allowed them to send you marketing communications, and at some point you changed your mind, and you wanted that company to delete you from their list. You have the right to reach out to that company and inform them of that right. That company better have a good operationalized set of processes in place to honor the request that's coming in. You have 30 days as an organization to honor those requests.

If a data subject asks to have their personal data deleted, it's critical that organizations understand all the places that that data is going to be stored. If you're going to delete it, you can't thoroughly and properly delete it if you don't know where the data resides. So you think about all the places that someone's data could live nowadays, especially in a Cloud first world. You think about Slack, you think about Workday, you think about Salesforce, all the popular Cloud applications. If you have mapped out your company's data flows in a way that's comprehensive and accurate, if and when you receive a right to erasure request, you'll be well positioned to honor it because you'll know where all the data may be.

Another right that individuals have is the right to data correction. Under the GDPR, individuals can request that controllers correct or update their personal data. So for example, a new phone number, name change, physical address change. They can reach out to the controller and request that those be updated or corrected. In addition, a data subject has a right of subject access and data portability. So if they want copies of the data, if users reach out to you and say, "Hey, I need a copy of my data," you need to be able to provide it to them. So again, this comes back to the issue of data mapping. It's critical that you know where data resides, where it's being transmitted to, and which applications have copies of it, so you can honor these requests. Up next, enforcement: the business bottom line. As we say in the legal world, the GDPR has real teeth. Fines of up to 20 million euros, or 4% of a company's annual revenue can be assessed against a GDPR violator. While that can be a very powerful shtick to encourage organizations to comply, I think it's also important to think of it as a caret, and it can be a really good way to get your organization to start to put, if they're not doing it already, data privacy at the forefront of people's concerns as part of the way that a company operates, and really make it part of its own internal DNA.

This is a great opportunity to consider the perspective of the user. What is the person's expectation when they give you that personal data? What do they really expect you to do with it? If they're purchasing a service from you and they want to get that service, and you need to process that personal data as part of the provision of the service, that's expected. If you're taking that data and you're doing something completely novel and unexpected, you probably want to push the pause button and really kind of think about, with your internal teams, whether or not that's something that's going to require additional disclosures to your users, customers, or perspective customers. So to sum up before I turn it over to Chris, in terms of best practices, mapping your personal data flows at your organization is so critical. That's the critical first step. It should be done from time to time. I think the emerging consensus is that it should be done probably quarterly. If you can do it more often than quarterly, all the better. You also want to make sure that you are equipped to handle right to erasure requests as well as any other data subject requests that may come in. If you do those things, I think you'll be in a pretty good spot. And with that, I'll turn it over to Chris. Thanks.

Chris Niggel: Hi, thank you. So now that you're all GDPR experts, who's ready for Friday? Okay, who's taking Friday off? Yeah, that's me. My name is Chris Niggel. I'm the director of security and compliance at Okta. What that means is that I'm responsible for our product compliance programs, SOC 2 Type 2, ISO 27001, FedRAMP, and in the case of GDPR, being the technical lead for our GDPR program. Now, as a compliance person, I also look at things in the forms of risk. Risk is a combination of impact and likelihood. Now for GDPR, we understand what the impact is. It's a 20 million euro, or 4% of our company's global annual turnover, so that's a pretty big number. That's not a number that I can change. The second part of risk is likelihood, and that's something that I can affect. I can put controls in place, and put protections and processes to help reduce the likelihood of Okta seeing one of those huge fines. I'm going to approach GDPR from a risk management perspective. When I look at managing those risks, we do that with a four step process. First place is to identify the risks. We've essentially done that. We know what GDPR means to us, and what we can expect to see in the terms of subject access request, right to erasure, and the like. My next step is going to be to reduce the risk anywhere that that's possible. What I can't reduce, I want to control, put things in place to help minimize the remainder of the risk. And then the last piece is to review and test those controls to make sure that they're effective. Now, when we look at GDPR at Okta, as Tim mentioned, we're both a controller and a processor. We're a controller for our employee data, and we're a processor for our customer's data.

So I have to look at this from two perspectives. I need to look at both the corporate risk the GDPR provides, and the product risk. Those are two very different sets of data. GDPR is fairly interesting in that it actually specifically calls out HR data. Before GDPR, we had Privacy Shield, and before that, the Safe Harbor program. Both of those kind of tangentially touched upon HR and the data that we as a company have about our employees, but they didn't specifically call it out. As a result, companies are very well tuned to the types of data that they're holding about their customers. So things like name, address, phone, email, visit data, usage data, maybe a customer ID. But we're not as good at tracking the information that we have about our employees which, there's a fair amount of overlap, but there are some unique data points around employees as well. Things like gender, birthdate, medical data for your benefits, or a national or tax ID numbers. We need to have a good idea of both of those different scopes in order to get a good hold on the risk and controls. We're going to look at GDPR from two perspectives. The first one is from a corporate point of view. From a corporate perspective, my concerns are primarily around right to erasure, so employees who have left the organization may ask for me to remove their data since we no longer need it for processing, tracking of consent, because part of our corporate business is of course marketing, so we need to ensure that we are appropriately tracking consent to the marketing, and then breach reporting. A lot of the news around GDPR has been focused on the 72 hour requirement for breach notification, so that's something that's going to be top of mind for everything that I do. Looking at my corporate risks, GDPR doesn't override existing spam laws. So things like the Electronic Mailing Act in the UK still take effect and still take precedence around how we need to collect and maintain consent. So I still have to pay attention to those types of laws, to the UK law, as well as the CAN-SPAM Act in other worldwide email marketing regulations. From my perspective, I think marketing complaints are going to be the most likely driver for investigations. When you receive a request to unsubscribe, that's going to be extremely important. From a corporate perspective, we have a good process to deal with that because it's far more likely that if we fail to unsubscribe that user, and we continue to send them more mail, that we will receive a complaint against the ICO.

As we mentioned, GDPR specifically calls out HR data. From a corporate perspective, we have to look at that and how we're handling the data for our employees. Now, Okta is an excellent place to start in getting visibility in reducing the risk around access to that HR data. First piece is to understand what applications that you're using. Tim mentioned to map your data flows. By tying cloud applications into Okta, you have one single place where you've got the visibility into the applications that you're using, and the permissions that people have inside those apps. By comparing the permissions provided in Okta versus the permissions provided in those applications, you have the ability to identify where you may have provided users with more access to employee data than they should have. The application assignment workflow is an excellent tool as well that I used in my previous job as an Okta administrator, to help reduce the exposure to personal information to my employees, while retaining ownership of applications. Probably the biggest hurdle that I had to overcome in deploying Okta was that feeling of ownership for the business units of the applications that they have. So sells for example, wanted to run Salesforce, and they had a whole shadow IT group specifically tuned to that because let's face it, they know more about how they use that data than I do, in IT. The last thing they wanted was for IT to insert themselves into the process and slow down getting new accounts created, because if a sales guy doesn't have access to Salesforce on day one, he can't be productive and he can't make his numbers. With the application assignment workflow, I had the ability to keep the visibility and the ownership of personal data within IT, but keep the ownership of the application with the business unit. Now, when a new sales person came on board, they could click in Okta, ask for access to Salesforce, that access would go to the business owner, doesn't show any more personal data than is absolutely necessary. Business owner clicks accept, they're happy, and I'm happy in IT.

Now, the second piece is that Cloud adoption. How many Cloud apps do you actually have in your environment? A 2016 report from Sky High ... If there's any Sky High folks in here, I'd love to see your new report, these numbers are a little bit old ... found that the average enterprise employee used 36 unique Cloud applications every day, and the average enterprise organization had over 1400 Cloud apps in use. Now remember, GDPR has a very broad definition of PII. It could be as simple as email address, which of course we all use as our user names. Do you know all 1400 applications that are in use in your organization? Because, you may be held liable if you receive a request for deletion, to pull the data from those applications. I took a quick look at Okta about where some of my personal data was, and this is what I found. The systems, we kind of expect. Our HR system and Workday is going to have PII about me that's going to be pushed into Okta, so it can be provisioned to downstream apps, so that's expected. But then we have OrgWiki, our org charting tool. That's going to have PII in me as well. And then, our business card printing site has got personally identifiable information in there as well. If I send Okta a request to be forgotten ... well actually I can't cause I'm a US citizen, but Tim could ... we would have to find all of these locations and make sure that the data is removed from every one of them. If you're using life cycle management and you have provisioning and deprovisioning tied into these applications, you can do that automatically. Remove the account in Okta, and everything downstream automatically gets removed as well.

Second piece is control. We need to be able to control access and protect access to PII. Our contextual access management gives you that capability by putting MFA where it's important. We had an excellent demo about getting rid of passwords entirely, and we all want to do that, but until we get to that point, we still have the challenge of deploying MFA in our environments. As an administrator, the biggest hurdle that I have for MFA was of course, our employees had to keep that token with them, had to keep their phone with them, and if they left it at home, then they weren't able to do work. Or, if they left it on their desk, they might be unable to start that sales call with Webex. It doesn't make sense to put MFA everywhere. We want to use contextual access management to put MFA where it makes the most sense. If we put security controls in the wrong places, we teach our employees to circumvent them, and then we end up in a worse position that we started.

Finally, for corporate, we want to test those services. We want to make sure that our incident response teams, and our IT, and security teams have access to the data they need to respond to security incidents, or we're never going to make that 72-hour breach notification window. However, if we give those teams too much information, they're not able to respond. So, 40% of administrators admitted to ignoring alerts due to fatigue. They get too many false positives. And again, another 40% of admins ignored alerts because they weren't actionable. They didn't have the information that they needed to respond to those effectively and implement corrective actions. We want to ensure that our tools provide reporting capabilities and tie into our SIM, and are security orchestration tools that give our employees actionable information, so they can respond to suspicious events. The second piece is, GDPR in our product, or GDPR for ...

Chris Niggel: Piece is GDPR in our product or GDPR for our developers. Now, as a product, we have to protect a very different set of data and so the risks are a little different, as well. We're looking at subject access requests, data deletion requests, and then of course, that breach reporting. As we mentioned, our scope is a little bit different and we should expect on Friday to start receiving subject access requests. In fact, at Okta, we've already started seeing those from our EU customers. You want to ensure that you have good processes in place now to be able to respond to those quickly and in a cost-effective way because you're not allowed to charge an unreasonable amount to provide that data to the users. We want to ensure that we also have processes in place to delete data after a customer chooses to terminate their account, because at that point you no longer have a business need to process that data. Under GDPR, it does need to be removed. A good way to do this is to try and make use of pseudonymous data. Tim introduced us to the concepts of anonymized data and pseudonymous data or data that has had the personal information removed from it and placed in another store, so if a person does not have access to that secondary store, the data about them cannot be associated with a person and is therefore not personal data. If we can find ways to do that inside our applications, we can take more of our system out of scope for GDPR and really simplify our compliance. The first step is to map our data flows and our requirements. Our customer data is going to go into production. We'll have a secondary database that's populated using different methods for marketing. At Okta, we never use customer data for marketing purposes, but that production system may also be replicated into other areas. It may be cleaned of all personal data and placed into a development environment for other research. It may be backed up in those backups stored for disaster recovery.

We also have employees who have access to customer data, right? Customer support. In order to be able to provide you with support services, have to have access to some personal information about the users, so we wanted to ensure we mapped that out, as well. What employees have access to data? Is at actually required and then how do we ensure that that's removed if we do receive a right to erasure request? The second step is to reduce that data. By using Okta for customer identity and access management, you can pull a lot of that personal data out of your database and just map the application and the usage data using a unique user ID. That could turn your application data or your usage data into pseudonymous data. Now, you fall into that secondary category of data under the GDPR and have fewer controls and fewer requirements underneath the regulations. This next control is for subject access. As I mentioned, when it comes to the 25th, I get a lot of questions. Are the data protection officers going to make an example of someone and throw out a huge fine and then we'll all be running scared after that. That's not going to happen on Friday, but what we are going to see are more subject access requests, so we have to have a good solid process to handle those requests in a reasonable amount of time and at a reasonable cost to the company. We also have to ensure that we're responding appropriately to these requests and providing the data to the right person.

The UK ICO recently fined and organization for providing personal data to an attacker because they were not appropriately validating who was making the access request. Using Okta and 2FA and deviceTRUST gives you a good opportunity to authenticate who is asking for data and then use our APIs to pull that data from Okta and provide it to the user in an industry standard format. Then, the last piece is the right to erasure. The other question I get is, "Well, if I receive a right to erasure request, do I have to go through all of my backups and delete the user from there?" and the answer to that is no, you don't. It's not only too expensive, but your backups are critical to your company's ability to business, so it's acceptable to keep that data under GDPR. Also, you have to have a record of who asked for you to remove their data from their system so it doesn't accidentally go back in there, so you are allowed to retain personal data of somebody who's made a deletion request if it's required for the operation of your business. Now, we need to test those controls. The first test is our processor compliance. At Okta, we are a processor for you, for our customers, and we have sub-processors. Okta is built on the AWS infrastructure cloud. We also use other services such as Twilio and Splunk to provide you with the Okta platform. We have to ensure that our sub-processors are compliant with GDPR just as you as controllers have to ensure that us, that Okta, is compliant with GDPR.

Take a look at all of these sub-processors that you use not only for your corporate environment, but also for your product to ensure that those contracts include things like breach notification requirements, notifications for changing of sub-processors, and ensure that there are appropriate agreements and legal frameworks in place for the processing of personal data. GDPR is going to be a continuing process. We're not going to hit Friday, say we're ready, and be done with it. It is going to continue to evolve as we get more feedback from the working groups and the industry. Try and get ahead of this by importing the GDPR requirements into your GRC program. Compliance has been an excellent tool for me to improve security at Okta and improve protection of your data. GDPR is just one more tool that I now have to ensure that we are the leader in data privacy. Test those subject access rights. You don't want to find out that your data deletion system doesn't work when you're responding to an actual deletion request. In the same, ensure you've tested those incident response plans. The GDPR gives us a very short amount of time to notify our users and notify the information commissioners about a data breach. You want to be able to have as much information as quickly as possible. Finally, there's some great resources out on the internet. I've mentioned a few times the UK Information Commissioner's Newsletter and blog. It's an excellent resource to find out what's going on there. The Irish data commissioner has a similar blog as well as other ones inside of the EU. Find the ones that are relevant to you and your industry and subscribe to those. There's a wealth of information and we're all going through this process together.

To close out, the first thing that you need to do is map those data flows. If you don't know where personal information is, you're not going to be able to adequately protect. Ensure you can accommodate right to erasure and requests for data and data portability. In my opinion, this is where we're going to see the most traffic for GDPR is going to be those requests for data and the request for erasure, and that's what's going to generate reports to the ICOs and bring attention to your organization, so if you can respond to those quickly, you'll handle I think the most significant risk to GDPR. Then finally, provide your teams with actionable information. Give them visibility into where data lives, who's accessing that data, and what's happening with that through your logs, through your SIM tools, and make sure that when there are suspicious incidents, they can be responded to. With that, thank you very much. We do have a few minutes left for Q&A and Tim and I are happy to answer any questions you have.

Speaker 1: No.

Chris Niggel: Nope?

Speaker 2: Is  it possible to receive multiple fines in a given year?

Chris Niggel: Is it possible to receive multiple fines in a given year?

Tim MacIntyre: You could. Theoretically, yeah, if you were a chronic violator or you violated the GDPR once, were assessed a fine, and then didn't remediate, it's possible. I think it's probably pretty unlikely. You'd have to be an outlier, but yeah, nothing to prevent it in the law itself.

Speaker 3: My question is who defines how much you're going to be fined? That's my first question, and then who actually gets the money when the company is fined? Is it some GDPR organization or the individual who actually asked for the information to be removed?

Tim MacIntyre: It's a great question. Every EU member state, each country has a data protection authority and under the GDPR, DPAs as they're known, Data Protection Authorities, can reach out to violating companies depending on where the violation occurred and the funds that are taken in as a result of fines are brought to the country that brought the action in the first place. There's been a little bit of cynicism. People have said, "Well, the money's being taken in line the coffers of these DPA agencies." I won't comment on that. I can understand how people would have that concern. It remains to be seen how these enforcement actions are going to play out. I think it's going to be really interesting over the next six months and the next year to see which companies are hit with fines. Chris and I recently were meeting with the Irish data protection authority and she was being very circumspect in her comments. She wasn't indicating. She wasn't going to call any company and say, "We're going to go after Company A, B, and C" at the start, but she was suggesting that a company that violates the special rights of children's privacy, for example, would be probably a pretty easy target. She didn't say that she had any app providers in mind, but something like that would be ... If I had to guess, I would say that that would be one of the first companies that gets called.

Speaker 4: All right, I have a question about the reach of the right to access and the right to portability. I'm also a data protection officer and if a data subject recourse, access, and portability of their data, does that include all metadata and business data such as CRM data about that data subject, or do you draw the line at someplace and where?

Tim MacIntyre: Yeah it's a great question. I think there has to be a line drawn at some point. Metadata, data about data, you can sort of extrapolate further and further out. If the data in and of itself is personal data, if it contains personal data, for example if there's log data when an individual logged into an application and that contains his or her email address, I think that has to be considered. In my mind, that's personal data. Now, the controller or the entity with that log data may have an overriding reason to keep a copy of that data. You may have data subject requesting access and a copy of it. You can give a copy back to them, but as Chris was alluding to, you may still have a valid lawful reason for maintaining that data in order to operate your business. One thing we didn't go into in this presentation is other the GDPR, you need to have one of six legal bases as a company to process personal data. One of those legal bases can be to keep a system secure and up and running.

Speaker 5: Is GDPR overruling industry-specific regulations around privacy? If I'm the financial sector and I have to keep a transaction record for an X amount of time for a given subject and they say I want to be erased, who wins?

Chris Niggel: The most restrictive regulation wins. GDPR specifically calls out that it does not override other regulations. One of the pieces of data we had on the slide was a HIPA, for example, so medical data needs to be retained for seven years. If we have a workman's comp issue, we may be required to retain that data for seven years even if it's requested. There's a right to erasure request, we must legally retain that data.

Speaker 6: Quick question. Just kind of follow up with those two gentleman. If we determine that there is a limited amount of their data that is necessary for our operations, can we pick and choose and defend to the accusation or auditors or whatever showing our business case for why we're retaining this data, but not this one?

Tim MacIntyre: Yeah, you touch upon a really interesting topic that GDPR watchers are sort of keying in on. If you go back for a minute to those six legal bases-

Chris Niggel: All right. We're getting kicked out.

Tim MacIntyre: Getting kicked out.

Chris Niggel: We're happy to answer your question outside the room. Thank you all very much for attending and we'll see you next Oktane.

Tim MacIntyre: Thank you.