Kip Boyle: Hi, I'm excited to share that we have a new free bonus just for you.

Jake Bernstein: We've started publishing our very own quarterly cyber risk management journal. It's loaded with over 30 pages of useful content taken directly from our podcast. Here's how we make each new edition.

Kip Boyle: So we start by transcribing the four or five episodes that we've published in the previous three months.

Jake Bernstein: Next, we send our editor and designer the transcripts and our supporting materials for those episodes.

Kip Boyle: Then they revise all the text. They put clickable links in for all the resources, and they create the best look and feel for each episode.

Jake Bernstein: And finally we, Kip and I, make sure the finished PDF is ready for you.

Kip Boyle: So download the current edition now. All you have to do is go to b.link/crmj. That's the letter B.L-I-N-K/crmj.

Jake Bernstein: And if you like it, share it with your friends and encourage them to subscribe to the Cyber Risk Management Podcast. Now, on with the show.

Audio: Welcome to the Cyber Risk Management Podcast. Our mission is to help you thrive as a cyber risk manager. On today's episode, your virtual chief information security officer is, Kip Boyle, and your virtual all cyber security council is, Jake Bernstein. Visit them at cyberriskopportunities.com and focallaw.com.

Jake Bernstein: So Kip, what are we going to talk about today?

Kip Boyle: Hey, Jake. Well, we're going to talk about something that I think most cyber security people just don't like doing, but sometimes they're required to do it, which is to negotiate a data security addendum. So I thought we should walk through how I, and how you and I have collaborated in the past, evaluate a data security addendum whenever I've been handed one from a new customer, for somebody that I'm helping, and just share with the audience, how we do that.

Jake Bernstein: That sounds great. Have we talked about this before?

Kip Boyle: Well, a little bit. We've done two previous episodes on the topic in general of the cyber risk of large companies outsourcing to small companies, that's the context here. So June 23rd, 2020, we did an episode called, how to quickly and profitably close deals with your cyber security intensive customers, so that was the seller side of this arrangement. You're a fintech, or you're an adtech company, whatever, and you're selling to large enterprise. And then just a month later on July 21st, we did another one and it was called, why some companies are so intense about managing supply chain cyber risk, and that was the enterprise perspective on the topic.

Jake Bernstein: So each of those episodes provided a different position or perspective on this topic, the seller and the buyer, and that can be confusing. We're talking, in this case, let's just say that the seller is the company, generally the smaller one, selling services of some kind to a larger entity who's our buyer. And I just wanted to, this is obviously a, another one of those, well, heck, this episode is a good example of why this podcast exists, is that it's a combination of cybersecurity and law, and it happens all the time these days.

And I wanted to be clear that, we're going to take this episode from more of the CSO cybersecurity professional perspective, as opposed to my own perspective as a cyber security attorney. We'll also take a look at it from the typical in-house council's perspective, who's going to heavily rely upon the security team. And we'll talk about when you might need to bring in outside council to help specialist outside council. So with those caveats, let's go ahead. And it looks like today we are, like I said, taking the seller's position. So Kip, we have some assumptions about the person receiving the addendum. Why don't you tell us what those are?

Kip Boyle: So the things that I'm going to share today line up with this assumption. So listeners, if you work at a company that offers a product or a service that has some cybersecurity angle, and you're offering it at a competitive market rate with a modest profit margin, that's the context that I work in the most, when I'm helping sellers with navigating hurdles in their sales process that are related to cybersecurity. And I think this is important because, it's that market rate and modest profit margin that puts a lot of pressure on this situation, and it's going to come up over and over again, so that's one assumption.

The second assumption is that your cybersecurity team is likely, or I should say the cybersecurity team of the person you're trying to sell to is probably bigger than your entire company, and I've run into that over and over again, and so they think very differently than you do about what does it mean to do good cyber security, cyber risk management, and so forth. That's another big hurdle. That's another big pressure point. And then finally, I'm also assuming that your customer is highly regulated. Is probably a financial firm of some kind, perhaps a HIPAA covered entity, what have you, maybe a registered investment advisor, there's a lot of different markets that are highly regulated, and they're probably using a lot of formality when they're discussing their cyber security requirements and expectation with you.

So now, so if you meet those assumptions and I think you're going to get a lot out of this episode, if you are a buyer, so you're part of a team in a large enterprise and you are used to working with outside companies to manage third party risk, I think you're going to get a lot out of this episode too, because we're going to give you some insights into how these SaaS companies and fintechs actually think about these mammoth documents that you sent to them.

Jake Bernstein: Absolutely. Some inside baseball here, I think will be crosstalk. So step one is get the team ready. If you are not the CSO or CISO, get one involved. If you're not the lawyer or a contracts manager, get one involved. If you don't have one on staff, you should find one externally. If you're not in sales or business development, again, get someone involved because that's going to be critical as well. And then finally, if you have a cybersecurity steering committee, notify them you're evaluating the contract and will soon report your findings to them.

Kip Boyle: Now, let's take a moment and acknowledge that we just asked you to get a ton of people involved, which is a recipe for slowness. Because, you're going to ask a lot of people to weigh in on this data security addendum, and it's not going to be fast. But, it's absolutely essential, because in my experience I just don't know any one person who can do all of it, who can understand the legal aspects of contract language, but can also understand the nuances of what exactly the requirements are, and also understand from a sales perspective, can we afford to do that, or do we have enough social capital with this buyer that we can actually push back on them?

All that stuff is very important. It all goes into the mix, and I just don't, I've never seen a situation where there was one person who knew all that, could carry it around in their head. And some of the decisions you may need to make as a result of your evaluation could require massive change to your organization, which is why the steering committee is so important, because you're talking about changing the way people work. And for some reason that makes people cranky, right Jake?

Jake Bernstein: Yeah, it certainly can. And I just, I wanted to really reinforce what you just said about, how there's no one person who really has the complete perspective of what's going on. And from my perspective as a lawyer just in general, helping companies negotiate deals of any kind, the lawyer needs to know the business context, because we need to know what I usually just call bargaining power. And it really, as we'll, we'll probably talk more about this as we get into some specific examples, but you have to know at the outset, how much you're willing to give in any given negotiation.

Because, otherwise, you're going to be missing that measuring stick, and it's really hard to know what to do. This is a really simple brief example. Let's just say that your customer demands that absolutely everything be encrypted at rest and in transit at all times. And for whatever reason, just pretend you don't currently do that, and it's going to cost you all of your profits for the next five years to do it. You have to decide, is this customer worth that? It could be. Usually, it's rarely just a black and white obvious answer, but it's important to ask the question.

Kip Boyle: Oh, yes, absolutely. And that's why you want the sales or the business development person in on this, because they understand what's at risk? They understand how much negotiating power they have, and they're negotiating on a lot of stuff, price points, warranties, gosh only knows. And so, while we are preoccupied with cybersecurity, that's not their only concern.

Jake Bernstein: Exactly. Liability sharing too, is a huge one. I didn't mean didn't mean to talk over you, but that's one of those things that gets negotiated heavily.

Kip Boyle: And I could see trading off accepting more liability in exchange for doing less cybersecurity stuff, or something like that. That's in the mix, and it's not what we are going to talk about, but it's absolutely part of the process. So you've got your team involved. Now, I have felt the need to get good at reading contracts. Not saying that I'm a lawyer, I'm not a contracts manager, but I have just felt the need to get better at it. So I've been paying attention for year now at how, when I bring clauses, paragraphs and terms to a contract manager or to a lawyer, when I say, what does this mean? And they help me decode it. I try to keep that information, because it just, I think it helps me do a better job of flagging the stuff that's really important.

And so, I would encourage you if you're are a CSO, or you aspire to be a CSO, or you're working for one and you're doing this stuff, try to grasp onto some of these things. It's going to just make everything go faster, and I think you're going to get a better outcome in general. All right, so you've got your team ready, and now what you want to do is, you want to have the team evaluate every requirement in the data security addendum. And typically what I see is you just give a copy to everybody who's involved and you just say, mark it up.

And as you do that, I'll just tell you how, the things I pay attention to is I also, as I'm evaluating the, and I'll just call it a DSA, the data security addendum, I'm looking at its language, but I'm also thinking about the other DSAs that I have reviewed for other customers that we have. And I'm also asking myself, do I see anything in here that we already do? Can I just get some easy wins? Where can I get all those easy wins? Boom, boom, boom. Because, what I'm trying to do is, I'm trying to isolate the tough stuff.

Jake Bernstein: That's right. And I think one of the first things that you're going to be looking for when trying to isolate the tough stuff is the definitions of critical terms. Are they clear? Are they unambiguous? And are they reasonable? We've seen DSAs define non-public personal information, often abbreviated NPI, with reference to the Gramm-Leach-Bliley Act of 1999. That's where that NPI term comes from. But, another DSA can define it without explicit reference to any standard, and that can be tough to compare the two. Ideally people standardize to certain defined terms, but that doesn't always happen. One benefit of large scale regulations like GDPR, California Consumer Privacy Act, which is now the California Privacy Rights Act is, or I should say, tends to be more universal definitions. I see a lot of DSAs and DPAs, which are data processing addendums that will just straight up reference GDPR, for example, so that's definitely a place to look.

Kip Boyle: It's very helpful to have clear definitions. I've absolutely seen situations where I'm trying to reconcile two DSAs, but it's really tough because NPIs defined one way in this DSA it's defined completely different way in this other DSA, and it becomes a scoping issue. Where I'm trying to put a nice clear line around, what is the non-public personal information that we have in our possession? What's in scope? What's out of scope? And sometimes it ends up being like a venn diagram. And I don't, it's like, ah, I don't want everything in scope. It makes everything harder.

Jake Bernstein: And what's really hard in this very specific arena is that the definition of personal data, personal information, sensitive personal information, personal identifiable information, non-public personal information, et cetera, is all changing rapidly, and it's evolving. My guess ultimately is that everyone standardizes around the GDPR and CPRA definition, which are so broad that basically any pieces of information that can be linked back to an identifiable natural person, i.e. someone who's living, is going to fall into these definitions. Anyway, this episode is not about just personal information, but in terms of the most important definitions in a DSA, it is definitely one of them.

Kip Boyle: And that's just one example. You're going to see lots and lots of terminology. Some of it is going to be defined explicitly, some of it will not. And so, a whole contract can turn on the definition of a single word, so that's why we have to be careful.

Jake Bernstein: You sound like such a lawyer, Kip, it's great.

Kip Boyle: I told you.

Jake Bernstein: And one other place to look is, yes, there's the personal information concerns, but oftentimes you'll see the name of the company, followed by confidential information or some variation thereof. And what they're doing there is creating obligations based off a definition, and it's specific to the customer. So be very aware of that. That's a variation on these things. So what else, Kip? For example, are requirements clear, unambiguous and reasonable? Do you have any examples of that?

Kip Boyle: Yeah. So once you've sensitized yourself to the need to have clear terms, now just start looking at the requirements in general. And I can tell you that, here's a good example of something I struggled with in the beginning when I first started doing this work. So I would see a DSA that would say something like, contractor will at all times, performance obligations, yada, yada, yada, and it would talk about what those obligations are. And then I remember having an attorney, could have been Jake, say to me, oh, no, strike that. We will not, at all times. We will take reasonably, or commercially reasonable steps. And to the non-lawyer in the audience, you're like, what's the difference? Jake, tell us what the difference is please, or give us some sense.

Jake Bernstein: So ultimately it's about breach of contract, and what's going to constitute a breach of contract. And if the wording is contractor will at all times, performance obligations, et cetera, then there's basically zero, there's potentially zero wiggle room. Whereas, if you revise it to, we'll take commercially reasonable steps, then what you've basically said is, we're not going to make this a binary. I'm either doing it at all times and therefore in compliance with the contract, or I've slipped up once, and now I'm suddenly in breach of contract. Instead it's more nuanced.

Kip Boyle: It is more nuanced, and it's good. That's a good revision. And I didn't understand or appreciate a nuance like that when I first started doing this work. I just thought, will at all times and I thought, sure, of course. We're going to do our very best here, and that language seems okay, and really it's not the best language.

Jake Bernstein: And something just occurred to me as a, that's an underlying assumption that I think I take for granted, but many don't is, here's the reality. Most of the time nobody cares about the precise language in the contract, in terms of the business day to day execution of a contract, rarely are these things an issue. When it matters is when you go to court and there's a dispute. And so, every fight over contract language that has ever occurred and ever will occur isn't generally about what the other side will think when everything is hunky-dory, and everyone's humming along doing business. It's always about what happens when things break down, and someone screws up, there's a dispute, and we have to go to court. That's when this language matters. So maybe that's obvious, maybe it's not, but...

Kip Boyle: Oh, it wasn't obvious to me when I first did this, not at all. Because, what's my day to day world like? My day to day world is binary, either the access controls are correct, or they're not, that sort of thing. And I think about the here and now, and what's valuable for our contracts manager, or a lawyer to help in this situation is exactly what you said, what if this ends up in litigation? Which will be horrid, horridly expensive, horridly time consuming, horridly distracting, and-

Jake Bernstein: As you now know. Not because you've been to, but because you've been an expert witness in a case.

Kip Boyle: That's right.

Jake Bernstein: That's probably the single best way to learn litigation is, to be an expert witness, because you get a lot of-

Kip Boyle: Short of being an attorney.

Jake Bernstein: But, well, in some ways even nicer than that, just because it's not nearly as painful.

Kip Boyle: So let's keep going. So we've talked about, get the team together, make sure that you are focused on definitions of critical terms, and then now you're going to start to look at requirements. Are the requirements clear? Are they unambiguous? Are they reasonable? And you're going to circle the ones that are not, from your point of view. So an attorney, or a contracts manager is going to circle a will at all times, that's not acceptable language. I'm going to circle other things like, or anything that we're doing today that is similar to anything I'm seeing in this DSA, or anything that's not at all similar, so I've got an example. So I was going through a DSA and it said, contractor will protect the data centers, or their facilities perimeter through access control, delivery screening areas, alarms, video surveillance, perimeter guards, and robust response capabilities.

And as I was reading this, I was like, well, what do you think I am? An air force base, or an NSA installation. It's like I'm representing a small SaaS company. We don't even have an office. We're a cloud first kind of a thing. And so, I really had to sit there and I'm like, we're not doing any of that. But then as I talked with other people what we realized was, actually that stuff is being done because all of the applicable information that needs to be protected is where? In an AWS data center, and they're doing all of that. So it was like, we can take credit for that, because it is being done, so it was interesting.

Jake Bernstein: That's a really important point, is to remember to take credit where you can, even if you're not doing it. If you have an external data center, if you're in the cloud, chances are high, although not guaranteed, if you're using AWS, or Azure, or someone, a big name-

Kip Boyle: Your Google.

Jake Bernstein: ... Then you're probably getting that. But if you're using a smaller or a private cloud, you should check because you may not have that same level of security at the actual data center.

Kip Boyle: And you could check by looking at your service provider's statement of controls, their SOC two report, there's SOC one report, whatever, so that's how you can check that out. Because, the idea that you're going to call them and say, hey, I want to chat about the perimeter protection at your facility, that is not going to happen.

Jake Bernstein: Well, and speaking of that, you have to be careful, because sometimes what you'll see is an audit provision. Most DSAs have some kind of audit provision. You have to be careful, because if you are a cloud first company you probably don't have any ability to bind Amazon to allow one of your customers to go into Amazon's data center and look around.

Kip Boyle: That's right.

Jake Bernstein: So you have to remember to exclude, if you can, just get rid of the audit, but if you can't, and it's reasonable in some cases to have some form of audit, at least from the buyer perspective, but make sure you carve out for those cloud companies, your cloud service provider that you just can't. You can't bind them. You can't include them in the contract. So that's really a good, it's a really important thing to remember.

Kip Boyle: So now, so just to recap, so at this point you're looking for everything in the DSA that you are doing. And you're circling all that, and you're taking credit for everything that you can. Now, you may come up, you may find things as you're doing that in the DSA, things that you're not doing today, but that you could do for either no cost, or a reasonable additional cost. Nothing really material that's going to blow the profit margin on the deal. But, so here's a couple of examples. So one time I was looking at a DSA, and the customer wanted us to use an enterprise grade data loss prevention system. And I mean, one of these types that would screen all outgoing and incoming email using regular expressions to meticulously search for forbidden things like credit card numbers, and social security numbers, and all that stuff.

And I was like, no, we're not that big. We're not that well resourced. We can't do that. So we looked around and we said, well, let's go back. What's the definition of data loss prevention? And we looked at that. And then we started looking around and we said, you know what, we're actually doing a lot of stuff to prevent data loss. And so we just compiled it into a list, and then we said, you know what, let's put a DLP label on all this stuff and just call it out as a dedicated program. Things like, nobody was a local admin, things like that. So we just piled up all these controls that we were doing. We put them under the label of DLP, and they were happy. We got credit for it. And it only cost a couple of hours of document writing, so that's a good example. Another example that I'll share is, there was a customer who said that, with respect to data deletion, the deletion of sensitive data, they wanted us to do crypto shredding.

Jake Bernstein: What's that? I've never heard that term.

Kip Boyle: I hadn't either.

Jake Bernstein: Because, they made it up.

Kip Boyle: And I was gobsmacked

Jake Bernstein: It's a made up term.

Kip Boyle: Well, I wasn't sure. It had that shine of standardization or whatever, crypto shredding. It just sounds so formal. At least I thought it might, but I so had no idea what it meant. And I was just like, man, these days that doesn't happen very often, where I see something I've never seen before. Well, so all it really meant once we, there's actually a Wikipedia page on it. That's how I knew it was legit. But, what it means is that, when you're getting rid of sensitive data, if you can just delete the decryption key, then if you can just throw the key away, then you don't have to actually delete the data, because as our friends in the ransomware industry have taught us, you can actually possess the data, but not be able to actually read it.

Jake Bernstein: That's true. I've also seen just secure deletion, and there's actually, I think both ISOs and NIST standards for secure data deletion, and the number of times you have to override the bits, things like that. crosstalk

Kip Boyle: And that's what I'm used to seeing. But, this crypto shredding thing's pretty cool because, let's say you've got a laptop, or a workstation and you've turned on BitLock or you've turned on the macOS equivalent of that, and now you want to dispose off the asset. Well, it costs money to have a technician or somebody stand there and kick off some kind of a disk wiping utility, that's the way we used to do it. But now, if you can just go into active directory and delete the BitLocker recovery key, done, that's it.

Jake Bernstein: That's true.

Kip Boyle: Finished. So it's really cool. And especially if you're an AWS, or Azure, someplace, and you've got massive, a data lake, love that term. If you've got a data lake that's encrypted, just throw the key away.

Jake Bernstein: I think that's a really good way of handling what would otherwise be an incredibly laborious process. So, but let's talk about the opposite of this. What happens when a requirement is beyond your reach? Because, I see this quite a bit and I suspect that you do as well. And I'll give one example of things that I like, or that has amused me. This is basically a requirement that the seller will be required to do it's, protect the accuracy and integrity of financial statements through the use of fraud prevention detection and investigative capabilities. That basically comes out of Sarbanes-Oxley or SOX to be differentiated from SOC. SOX is Sarbanes-Oxley. SOC is service organization controls, are very different.

And it's oftentimes, the customer might be too small, our customer, or the seller here is often too small to afford the level of control. And at least the question I tend to ask is, look, we're not, this isn't relevant. Because, this transaction is about some basic SaaS product. What you see more than anything out there is a standard DSA, and Kip, you know this because you've worked with me for a while, but it drives me nuts when companies have the same master service agreement, or in this case data security addendum for the guy who delivers the new water jugs all the way up to the company that provides the back end for the entire CRM backbone or something. It's like, there's no differentiation between low access contractors or suppliers and high access contractors or suppliers. And it just, it creates extra work for this on the supplier side, and that's really what we're talking about is, if you get hit with something, here's an example.

Salesforce is a supplier. They're ultimately a seller. It just so happens that their enterprise grade themselves. So for them to take enterprise class controls to protect your data is not only, no problem, but basically required and expected, and then they're going to, that's one of their competitive advantages. But, for a lot of our SMB sized customers who are our, sorry, I keep saying that our customers, our clients, they're the sellers, they're not the size of Salesforce. Maybe they want to supply something to Salesforce. That's a very different situation.

Kip Boyle: And this one size fits all approach and this inability of large buyers to understand what it's like to be a smaller supplier and what the real constraints are, is a source of a lot of friction and a lot of difficulty. And so, when I see something like that, what I tend to respond with is simply say, the control as stated is not justified for a company of our size. And I just put it in plain language and just hand it back to them. And I have encountered so many people in cybersecurity, information security, who are afraid to do that. Who are like, we can't say that we don't have that control. We should have that control. They almost fight for this small company to adopt a control like that, because they like controls, they like to control risk and I get it. That's the knee jerk reaction, I guess, but I'm here to encourage you. Just say, no, this just doesn't make any sense.

Jake Bernstein: Well, and this goes to one of the more esoteric sides of being an internal cybersecurity professional at a company is that, your internal credibility and political capital matters. It's one of your greatest resources. And if you don't fight for your client, for your employer, then you may be marginalized. But if you push back and say, no, when you can, then when you can't, and you tell your employer that we really, we actually need to do this, the chance of being listened to is much higher.

Kip Boyle: That's right. And don't forget, who are you ultimately serving here? You're not ultimately serving some abstract, greater good about data protection, at all times, at all places and at all costs. That's the boy scout way of thinking about this, or the girl scout way of thinking about this, but really you're trying to help your company, your employer, your client win. And so, that's really, I think, where you need to be, unless it's unethical, illegal, whatever, that's different, so anyway, so just say no.

Jake Bernstein: The way to say, idealism is commendable, but practicality keeps your job.

Kip Boyle: Well done. That's crosstalk

Jake Bernstein: I just made that up, but that was really good, huh?

Kip Boyle: I'm going to excerpt that from this recording.

Jake Bernstein: That'll be worthwhile for sure.

Kip Boyle: Turn it into a Max Headroom. Damn, I just told everybody how old I was again.

Jake Bernstein: So here's one more example. Vendors shall agree to participate in a collaborative BCM exercise workshop conducted by a customer.

Kip Boyle: BCM, business continuity management, everybody.

Jake Bernstein: Or sometimes they'll just call it a red team, or a tabletop, it doesn't really matter. We don't have anything against that, but you shouldn't... I think one of the big mistakes that suppliers and sellers make is, they don't say, yes but, is a very powerful phrase just in life. But in this particular instance, you can say, yes, if you pay. In other words, if what they're asking you to participate in or do, seems like could do it, but it's going to cost and you don't want to cut into those profit margins, which are important, then you can always just say we'd be happy to do that, but that's not priced into the product, so we're going to have to charge a surplus, or a surcharge rather.

Kip Boyle: Absolutely. And sometimes I coach my clients who are small SaaS providers, fintechs, adtechs, and that sort of thing. You like, look, if you're going to provide a lot of due diligence support to this buyer you need to have a limit, whatever it is. Is it four hours in pre-sales? Is it four hours in post sales, whatever it is. You need to have a limit and pass that limit, and you need to tell them, look, if you want us to do additional due diligence or you want us to implement additional controls that are only going to benefit you, then you're going to need to pay for that. It's a service that is above and beyond the quote that we gave you for what it is that you're primarily here to purchase.

Jake Bernstein: Exactly.

Kip Boyle: So anyway, so don't be afraid to charge, I guess, is the bottom line. If somebody really wants something and they have to have it, tell them yes, but you have to pay. And you know what, I've seen it go both ways. Sometimes they pay, sometimes they don't. And isn't it interesting when they don't pay and they just drop it? It's like, oh, I guess, you never were really interested in that in the first place, so that's funny. So again, you're evaluating a contract, you're looking for requirements that you already satisfy, that you could satisfy without too much extra effort that are totally beyond your reach. And your answer is, no, but if you pay, we'll do it. And sometimes there are requirements that are absolutely not applicable. And this is coming up a lot these days, because with cloud first sellers, they're just like serverless applications. It's serverless. And you, as the buyer want me to do all this server security stuff, no, it doesn't make any sense.

I'm using a form of technology that doesn't even consist of that, so, no, or another example is, I read a DSA where they said, well, you have to run antivirus on your servers. And so, we looked at our servers and we said, what do we have here? Well, we've got a Linux distribution, CentOS, and we've installed SELinux, security extensions for Linux. And it's in a virtual machine, and it's in pool of virtual machines. And so, first of all, it's silly that we're going to find a product, an antivirus product to run on this. And moreover, that's just really not the way to do it.

The way to do it is, if something gets malware on it, if a CentOS with SELinux gets malware on it, just throw it away and spin up a new one from a known good image. So, it's just a completely different way, and completely valid way of satisfying a requirement that is based on an older way of thinking. So it probably came from an enterprise with tons of legacy data centers, and they're still doing things in old ways. And it's very common for newer companies that are disrupting market spaces to be doing stuff in completely new ways. And it causes a lot of trouble, because these older bigger companies, they're not doing this stuff yet, so they don't understand how it works. They don't necessarily trust it, and it causes a lot of friction.

Jake Bernstein: Absolutely. That happens a lot. I think the bigger the company, the more higher the chance that it has some form of legacy systems to operate, the higher chance that they're maybe not as fully modernized as you, the new SaaS provider are. So I think paying, again, don't be afraid to push back, but at the same time, know your limits. Know the limit of what you can do. There are some potential buyers out there who just, they won't negotiate anything, and that's a real problem. And what I would do in that situation is, run that one straight to the top of your company. One of the people we didn't include that we probably needed to is the executive team up to, and including the CEO sometimes. Some of these decisions are CEO level, so don't be afraid to have that fallback. And if you've never had that conversation, have it beforehand. There's no reason to wait until a deal is at stake before you approach executive teams and say, look, what are we going to do in situation XYZ?

Kip Boyle: And that's why we said in the beginning that you want to get your team together, so the security steering committee, you should have one. Even if you're a small a company, you should have a security steering committee. I'm telling you, it really makes all the difference. Because, when you go to the steering committee and you say, here's a requirement, and it's stupid, it doesn't make any sense at all, here's why we have to push back. We have to say no, or we need to figure out some other way of dealing with this. You, as the person evaluating the DSA, don't want to be on your own with this, This really does need, we've said it before, Cybersecurity is a team sport. Here you go. Is another example of the power of taking a team sport approach to this. This is just too much water for you to carry all on your own.

Jake Bernstein: Indeed.

Kip Boyle: So we're getting to the end, right?

Jake Bernstein: Yeah. Let's wrap this up.

Kip Boyle: Cool. So once you've completely analyzed the heck out of this DSA, and you understand all the different requirements, both the things you can do and the things that you will not do, now, what do you do? So how do you bring this thing to conclusion? So Jake, what do you recommend?

Jake Bernstein: Well, so the first thing you do is negotiate every requirement down to the least that you have to do. Get to the minimum viable. And another way of saying this would be, get to what is reasonable.

Kip Boyle: Reasonable for you, and crosstalk for your size.

Jake Bernstein: For your size, yes, reasonable for you. Connect the cost of the additional controls to the value of the service you're selling. In other words, if you've under priced yourself, because you didn't realize that you were going to actually have to implement all these different security controls in order to sell the product-

Kip Boyle: For every customer.

Jake Bernstein: ... for every customer, then increase your prices. Because, you can't sell your product at the price point you wanted to, so you'll have to make adjustments. And then charge customers for due diligence and additional controls in excess of a reasonable amount. If the customer really wants it, your customer, in other words, if the buyer really wants something, they may pay for it. If they don't, you've at least asked. And I think, Kip, you have an example of that?

Kip Boyle: Yeah. We've covered actually lots of examples of that already. If somebody really wants us to participate in their annual business continuity exercise and they're willing to pay for us to do that, then, hey, we're there, and we don't really care how long this takes. Take all the time you like. Make sure it's right for you. We're right here. We're part of the answer. We're members of the team. But, we cannot do that if we don't have the resources to do it. You're getting a great deal on this SaaS service, but we can't give you that great deal if we have to pay for all this stuff on our own, especially when we have no idea how long it's going to last.

Jake Bernstein: Quite true. So, I guess, we're-

Kip Boyle: So, I think that's a wrap, right?

Jake Bernstein: We got to wrap. We're going over.

Kip Boyle: We don't want to do that. Folks, thank you for hanging in there, and we're wrapped up. And today, what did we do? Well, we walked through how to get ready to negotiate a data security addendum when somebody slaps it down on the desk in front of you. I guess, nobody really does that anymore, do they? They just drop it into a Slack channel or something like that. Well, anyway, that's what we did today. Thanks for being here. We'll see you next time.

Jake Bernstein: See you next time.

Audio: Thanks for joining us today on the Cyber Risk Management Podcast. Remember that cyber risk management is a team sport, so include your senior decision makers, legal department, HR, and IT for full effectiveness. So, if you want to manage cyber as the dynamic business risk it has become, we can help. Find out more by visiting us at cyberriskopportunities.com and focallaw.com. Thanks for tuning in. See you next time.