On today's episode of the Contract Lens Podcast, Hemanth Puttaswamy, CEO and co-founder at Malbek, and Caroline McCaffery, CEO & Founder of ClearOPS, discuss the intersection of data security and contracts. Caroline begins by introducing some of the many acronyms in data security and explaining where they come from and what they mean for you. She further explains some of the most common data security sticking points in the contract negotiating process and touches on how to align IT and legal so that data security is reflected in your legal documents. Using real world examples, Caroline outlines what your policies should look like to ensure that they drive the correct behavior and are actually followed. So grab a glass of wine, and let's talk contracts!
Intro:
Welcome to the Contract Lens podcast brought to you by Malbek. In this podcast, we have conversations with contract management thought leaders and practitioners about everything contracts and its ecosystem. Today's episode focuses on data security and privacy and what it means for your contracts. We are joined by Caroline McCaffery, CEO and founder at ClearOPS, a company that automates the manual tasks around privacy and security in sourcing and vendor management. Caroline is a lawyer, an entrepreneur, and a privacy and security expert in the technology field. So now it's time to relax, grab a glass of wine and let's talk contracts.
Hemanth:
So welcome to the Contract Lens podcast. Today, we have Caroline from ClearOPS. Caroline, welcome. We are so excited to have you for this episode of the Contract Lens podcast.
Caroline:
Thank you so much for having me, Hemanth. It's really exciting to be here and I look forward to our discussion.
Hemanth:
Sounds good. To start the conversation, let's look at the acronyms that get thrown out quite a lot these days, GDPR, CCPA, and so many other acronyms that comes across when you're working in any business to business transactions or business to consumer transactions. So Caroline, let's start with that, let's demystified those acronyms for our viewers.
Caroline:
Sure. Working in both privacy and cybersecurity I feel like my life is acronyms, but to start with the, I think, probably the most common and most heard one that you mentioned, GDPR, stands for the general data protection regulation. It is the regulation that covers all sorts of privacy initiatives that happened in the EU. It went into effect on May 25th of 2018, and before that there actually was another regulation that was its precursor. But for those like me, a privacy lawyer, I started to hear about GDPR in probably about 2015. And the biggest change that we all started talking about in those days was that it was applicable to EU residents rather than citizens, which meant it was going to affect the entire world, because it's very, very difficult to determine online who's a resident where. We just knew that that was going to make it much more international.
Caroline:
But then, as you mentioned, a lot of regulations have popped up since then and continue to. Virginia just recently had a new law that I think is being referred to as the CDPA, Consumer Data Protection Act. You've mentioned the California one, the CCPA, the California Consumer Protection Act. California has a second one that's going into effect, I believe in 2023, I think, but the California Privacy Rights Act, it just goes on and on. And then you also mentioned DPA, so even the ones we were just talking about where all regulations or acts that are laws, but then even within those regulations and laws, new acronyms have come out. So DPA, Data Protection Authority, there's DPO, Data Protection Officer. There's also DPA, Data Protection Agreement, so one acronym can mean many things.
Hemanth:
That hopefully is a great starter for the conversation. And correct me if I'm wrong, but GDPR was set up to protect the consumers specifically, and it was meant for mostly business to consumer applications like Twitter, or Facebook, or Google and others. And then it has crawled into business to business space and other spaces, is my understanding correct, Caroline?
Caroline:
I think a lot of speculation is that you are correct, and when I say speculation is because GDPR, that regulation codified into law certain things that weren't there before. Sort of like the right to be forgotten, which was a case that was litigated in Europe, and it was about an individual user being able to have their data no longer be in the system. And most of the companies that were targeted for this type of rights enforcement were companies that you mentioned, Facebook, Google, Twitter. And so there was a speculation that GDPR was written with a view towards protecting the users of those types of platforms. But it absolutely has had a massive effect on business to business relationships across the world.
Hemanth:
Right. So there it gets very interesting, right? I mean, for example, right to be forgotten for an employee, if an employee says I'm using this particular SaaS application and I want my data to be cleaned, right? So that becomes a gray area, isn't it? Whether the company owns that data or the employee owns that data?
Caroline:
Yes. Oh gosh, such a complicated area. I mean, because what is the employee's data? I mean, you can argue that the company keeping a record of that employees' conversation about a customer, just some notes that an employee took about a customer, a company could argue that that's their data. But the employee could say, "No, no, no, because the notes I took the customer told me how awesome I am, and so that's my data, because that's about me." And so going into that analysis is extremely difficult, and don't even get me started on the fact that companies can't even segregate and figure all that out in a streamlined way.
Hemanth:
Exactly, exactly. It becomes a gray area, and often in the negotiation that becomes a sticking point for many business to business contracts.
Caroline:
It does, and I think it is a sticky point because also, if it's a negotiation between lawyers, lawyers can even interpret the regulation in different ways.
Hemanth:
It's so interesting. So now let's switch gears and let's talk about security in general, Caroline. You are a security specialist and as a part of the contract negotiation, one of the things that comes up is the data security and security breach kind of provisions. So now, just at the highest level, give us an idea of what kind of sticking points there can be during the contract negotiation.
Caroline:
Sure, and I could talk about this forever. So I'll start with what you mentioned, which was the breach notification. The first main sticking point is, what is a breach? Is a breach a confirmed loss of personal data or of sensitive data, or is it a suspected loss? And it's such a huge negotiating point, because then the language goes on to say, if you have a breach, we're defining a breach, is it suspected or is it confirmed, is it both? Then you go onto to just say, well, once we define the breach, then we say how long you have until you can tell us that you have to notify us that you experienced that breach. But a suspected breach, you might suspect a breach and it could be a complete crying wolf situation where you don't actually have a breach. So you don't want to go and tell your customer, "Oh, we think we might have had a breach." And frankly, the customer doesn't want that either, because then they have to do something about it and they don't know what, because they don't even know if it really is a breach yet.
Caroline:
But if the language says within 24 hours, you have to tell us of a suspected breached, the other side might be getting breach notifications left, right and center, or it could be that nothing happens. There's no notification, no one even realized that that language was in the contract, and therefore there's now all sorts of liability being created. And so, if and when down the road a breach does happen and there were many many suspected breaches that are happening along the way that weren't notified, well now you just gave the other side an ability to sue you and win. It's full of pit holes, just talking about incident.
Caroline:
And then if you go into the part of incident management and breach, and the next part that it cuts to is what the notice needs to look like. And oftentimes it's a very detailed section that says, the noticed must provide what happened. And if you are experiencing a breach, I can tell you, it can be very damaging for you to tell someone exactly what happened on a piece of paper, in a notice right as it's happening, because that piece of paper is going to be used for litigation. And you have to write that thing in 24 hours, yeah.
Hemanth:
Yeah. I mean, you addressed that the specific provision where it gets stuck, okay, how soon should I be able to send the notice, and what should be in it? That becomes a sticking point. And it's amazing actually, the GDPR, instead of causing a positive effect, sometimes it can cause negative effect, particularly in the business to business relationship, because of issues like this. It is supposed to do something good, but as you said, each lawyer can interpret that differently. So any advice on that?
Caroline:
For incident response, the best thing that a seller can do is make sure they have a policy and then make sure that the incident response language matches what they actually promised to do in their policy. On the buyer side, I think letting go of the suspected breach language, because the reality is, is you don't want to know if there's a suspected breach, you might think you do, but you don't, because you might again, be getting a lot of false alarms.
Caroline:
I'll tell you actually a little bit of a story, it's actually from a real case, which is the Delta Airlines versus [24]7.ai case. Delta suffered a breach and they found out the breach was caused by their vendor, [24]7.ai. And [24]7.ai provided a chatbot to Delta on its website. You may actually remember the breach, it was quite a while ago. I think it was 2017, 2018 maybe.
Caroline:
Anyway, so here you have a chatbot company who had to go through a request for proposal with Delta, big deal, right? I mean, that's a major airline, a big awesome win for that company. And they made all sorts of security assertions to Delta in the contract to win the deal. Then the worst case scenario happens, they suffer a breach that causes Delta to suffer a breach. Delta takes a look at their documentation and says, "All these security things that you said, you didn't do." So now they're being sued for fraud, breach of contract. Yeah, I mean, I could go on, there's negligence, there's a bunch of claims in the actual lawsuit.
Caroline:
So, on the buyer's side... When you get to this point where you have a litigation over who's at fault for the breach and then all the notices and everything that had to go out, obviously that's the worst case scenario and no one wants to be in that position. But on the buyer side, you're worried about your users, you're passing user's information onto this third party, and if that trust is breached, you have to act on it. You have to do what's right for your users. And so that's what you should be concerned about when you're getting those incident response notifications, is thinking about, who is really going to benefit from the getting this 24 hours notice? And also, do I want to send my users a notice that says there may have been a breach only to follow up and say, "Oh, nevermind. There wasn't actually a breach you're okay." And then maybe after that go, "Actually, no, we were wrong again, there was..." That's not good either for anybody.
Hemanth:
True, and credibility is also on the line. And the right way to do that, I mean, it typically takes longer than 24 hours to even... First you detected a possible breach, and then it takes a long enough time to ensure that it is indeed a breach. And if it is from where it is coming from, all those root cause analysis that you have to go through to ensure the information that you're providing to your customers is credible, right?
Caroline:
Yep, exactly. And not to mention that you're also at the same time, if you're the victim of the breach, if you're the one whose systems have been breached, you're trying to close all those unauthorized access ports as fast as possible. So you don't even care about anything else, that's the number one priority.
Hemanth:
Exactly, that she'd be the number one priority. Absolutely agreed. I mean, that's the advisers, that middle of the road kind of agreement, that is the right thing to do. And you said, from what you're saying, two things I could deduce from it. One is, for any vendor, the security practices is so important and you need to document it, and that is part of the SOC 2 and other compliance requirements. But don't just document for documents sake, but you need to follow it. And the second part is, while negotiating the contract, make sure the provisions are set up in a way that you can accomplish whatever is put on the paper. Am I right on that?
Caroline:
Absolutely. I mean, I didn't get into this other part, but just to kind of drive that point home, because it's so important what you just said. The communication between the lawyers who are negotiating the contracts, for example, we talked about acronyms, DPA, Data Protection Agreement. These agreements oftentimes will have security provisions in them, mostly because the standard contractual clauses, SCCs, another acronym, they do require that vendors or processors provide some security attestations. And lawyers, obviously, are the ones who are reviewing these documents, because it contains a lot of legal provisions.
Caroline:
However, that being said, your security team or your IT team, or whoever you have in your company who's responsible for security, may at the same time, and this is a little bit the corrupt side, but may be responding to security questionnaires. And those documents, the lawyers don't necessarily read, and of course, on the other side, the security team isn't reading the DPA. And yet there are questions or representations the lawyers are being asked to certify in the DPA that are also contained in the security questionnaire. And so not having that communication, that collaboration means that there may be promises made in one document that are conflicting to promises made in the other document.
Caroline:
So to your point, when you're looking at documents and you're talking about your security practices, it's best to make sure that you're looking at whatever your company has, whether it's a SOC 2 audit report, like as you mentioned, or a secure questionnaire or whatever it is that your company is constantly being asked to produce from the security team is actually also being reviewed by the team who's making the representations on behalf of the company. So that you are not just practicing what you say you're doing, but you're also making sure the contracts themselves are accurately reflect reflecting it.
Hemanth:
Got it. No, thank you so much on that, Caroline. Now on the similar topic, the interesting SolarWinds breach. A lot of these breaches come within the company, so what are some good security practices, some common sense things that companies can do to ensure those kind of silly sometimes, but very costly breach does not happen from within?
Caroline:
I'm so glad you brought up SolarWinds, and I'm going to just quickly add onto your mentioning them that it has come out that although there were other factors, one of the factors of the SolarWinds hack was that an intern had created and put a password that was SolarWinds123, so very simple, fairly easy to guess password. And then they had put it, I believe in one of their GitHub repositories, so it was something that was easily viewable, and that certainly contributed to what happened at SolarWinds. And the company has come out and said, "Well, that was not our policies. That was against what we tell people should be the common practice."
Caroline:
And so you sort of wonder, you're like, "Well, that's bad, right?" I mean, your policies should be driving behavior, there shouldn't be a way for people to circumvent the policy. However, I would argue that this is very common. I mean, most people that I know don't like policies. I think, as a lawyer, I like policies. I like to read, I get paid to read, so of course I like it. But as a general person in the population, you tell me to read a policy and I'm going to kind of roll my eyes and be like, "Oh gosh, I don't want to spend half an hour reading some 10 page document."
Caroline:
So how you build that into the culture, to your point of making sure that internal threats like that are not possible, there's certainly a big movement towards trying to create technical measures that support any sort of policy that the company is trying to enforce. But really, as far as I'm concerned, you have to be talking about privacy and security and you have to be training as much as possible.
Hemanth:
So true, so true. This is so interesting, right? I mean, for any company having the right security posture is so important, as you said, policies can be boring, but do it in such a way that at least it's easy for every employee to understand. And they're trained on a regular basis to ensure, for example, like you said, setting that silly password, or getting phishing emails, right? [crosstalk 00:18:42] those, it's so important to ensure that they keep their security posture in the right place, otherwise it can be really expensive.
Caroline:
That's right, yeah. I definitely am a believer in less is more when it comes to policies, so don't try and write a textbook for every single one. The longer they are, the less likely someone is to read it. And I actually gave this advice earlier today, I was talking to a customer about drafting a policy. And I said, "At your stage, you only have a few people, you definitely don't want a long policy." But the worst part is, you suffer an incident, a breach of some kind, and you're pulling out a policy that takes you an hour to read and then you're trying to figure out if you're following it or not, and you're trying to do everything right and you're panicked because you're having a breach and you're... That's the worst time to be looking at a 20 page document and trying to figure out that you're following it, you really want to have it... You want the policy to track what you actually will be doing, but then also you really do want it to be fairly concise.
Hemanth:
So true, so true on that, Caroline. And it's not just the security dean who is aware of the policy, it is so important to ensure that the whole company, at least the ones where employees have to follow, they need to know. Otherwise, it's good on the paper, but not good in practice.
Caroline:
Yeah, absolutely. I totally agree with you.
Hemanth:
No, this is so helpful, Caroline. I mean, I learned so much. Hopefully our listeners learned quite a lot about the importance of security and how the contracts and the security intersect, what you put on the paper and what you really follow as security practice. So thank you for enlightening us with such an interesting advice in your area of expertise.
Caroline:
Well, thank you. I appreciate you saying that. It's definitely something I am passionate about and I love helping people, that's also something I'm passionate about. So it's fun to be able to bring the two together.
Hemanth:
And thank you, Caroline. And before we end the podcast, maybe you want to talk about what you do, the business that you're in, so that any listener who was interested in learning more about your business, they may be able to contact you for more advice.
Caroline:
Sure, thank you. I appreciate that. Yeah, I run a software company called ClearOPS, we're a B2B SaaS company in privacy and security. And the technology that we have, we call it questionnaires as a service and vendor management. And when I refer to questionnaires as a service, I mean, security questionnaires, vendor risk assessments, privacy impact assessments, we keep track of them and help you answer them much more quickly. We're very much focused on the vendor side, so the response side to those problems.
Hemanth:
Thank you so much, Caroline. Again, it's a pleasure having this podcast with you. And again, I learned so much, thanks for taking time to share the knowledge.
Caroline:
Thank you for having me. It's been a pleasure talking to you and it was really fun.
Hemanth:
Thank you.