We’ve talked a lot recently about how important it is to stay up to speed on regulations. In this episode of Payments on Fire, George Peabody and Chris Uriarte are joined by Michael Borgia, Partner at Davis Wright Tremaine LLP, to discuss data security and privacy and the steps regulators are taking in this space.
For additional insights on this topic, click here to register for the 1-hour webinar “Data Privacy and Security Considerations for Fintechs: 5 Priorities Heading into 2023”, jointly hosted by Glenbrook and Davis Wright Tremaine on Wednesday, December 14 from 12-1pm PT.
George Peabody:
Welcome to Payments on Fire, a podcast from Glenbrook Partners about the payments industry, how it works, and trends in its evolution. I’m George Peabody, co-host of Payments on Fire, and today it’s my great pleasure to be co-hosting this episode with Glenbrook’s own Chris Uriarte. Great to have you here, Chris.
Chris Uriarte:
Good to be here, George. Good to have the opportunity to chat with you and to dive into two of my favorite topics today, data security and privacy.
George Peabody:
Well, knowing how complicated they are, I could say you’re a glutton for punishment given those two topics, but they are enormously important if you’re in the payments industry. And to your point, they’re increasingly rising into the level of discussion that’s going on in… Yes, new APIs or a new method of payment that’s applicable to a particular market, yeah, those are important, but it’s the regulatory context that payments really operate in. And regulators are really looking hard now at data security. And we’ll be talking about it throughout this conversation about the tension or yin and yang, if you will, between security, which is often, “I want to know as much about everything as I possibly can,” and privacy, the real tension between those two.
Chris Uriarte:
Yep. And I think security on one hand, George, means many things to many people. And I think traditionally to a chief information security officer, a CISO, it means protecting the network from bad actors, so all those folks that are doing data breaches and ransomware attacks and denial of service attacks. But when you shift into the payments and banking world and you look at the operational side of the business, the definition of security really changes based on what your role is. So for example, risk operation folks might look at security about determining authorization or authentication for specific users. And if you’re a trust and safety person, that lends a focus on more what someone’s doing, what they’re selling on a marketplace, for example, or how they’re interacting with the community.
And privacy is, as you said, the yin and the yang is about protecting sensitive information offered by legitimate users, but also ensuring that you have the right amount of data necessary to perform the service that you want to perform. So all this has to work together across the value chain. So everybody in that value chain, every organization, every stakeholder needs to pay attention to these issues.
George Peabody:
And regulators are really focusing on those. And one of the things-
Chris Uriarte:
They absolutely are, yeah.
George Peabody:
One of the things I love about regulators is that they really move a market.
Chris Uriarte:
They can.
George Peabody:
If you want to play, you better pay attention to regulators are saying and talking about. And this has happened globally. And again, these topics have really risen to the top of regulatory agendas. And so we’re really grateful to have Mike Borgia, who’s a partner at the law firm Davis Wright Tremaine, to talk about the ins and outs of this topic. Mike, welcome to Payments on Fire. Really glad to have you here.
Michael Borgia:
Thank you for having me. It’s a pleasure to be here.
George Peabody:
So Mike, before we jump into the specifics, I want to give our listeners a sense of what you do. Obviously you’re an attorney, but when Chris introduced the idea of having you on our podcast, you said you often find yourself in the role of breach coach, and I love that phrase. What does a breach coach do?
Michael Borgia:
Yeah, breach coach is an interesting term and I suppose I have a bit of a love-hate relationship with it. But a breach coach is a term that’s come largely out of the insurance markets and it refers to basically outside counsel. So it can be confusing. That doesn’t sound like a lawyer, but it is a lawyer. And it is someone who works with you on what the insurance would call first party part of it, your losses, the attack on your network, what you have to do to meet legal requirements, to meet your contractual requirements, to get your network back, make your notifications, things like that.
I think the good part about this term is it does admit how much of this job as a lawyer can be non-lawyerly. There is a certain aspect of coaching to it. Anyone who’s been through a data breach of any significance knows there’s a ton of work streams, there’s a ton of stress. It’s a very, very difficult situation. And so it just takes a lot of work and a lot of coordination and a lot of counseling, in a way, not in the legal sense, in the emotional sense. On the other hand, the legal piece of this is extremely important and it’s becoming more important. So I think there is a risk sometimes say, “Well a breach coach, it’s not so lawyerly.” That’s becoming less and less true. Not only are the breach requirements being more enforced, they’re becoming stricter in terms of deadlines. There are more requirements around notification, not necessarily tied to breach, more risk, more class actions, things like that. So a lot going on here encompassed in that pretty loaded term.
George Peabody:
So breach coach and the lawyer role are really one and the same. And right now you’re telling the priority, what to do first, what to do second is getting clearer and clearer.
Michael Borgia:
Yeah, exactly. It’s a fascinating area to practice legally because the lines between what’s legal and what’s not can be blurry in a sense. If you think about a litigation, you’re arguing in court, you’re writing briefs, just legal stuff. There’s no question. Or you’re working on a transaction, you’re editing contracts and negotiating. In this space often, especially in the breach response part, but in really all of it, you really do a lot of different things. You do very pure legal, like drafting notices, I’m reading the statutes. And then it’s a lot of things you might call project management or just strategy around how are we going to deal with this? How are we going to navigate the politics of this internally, externally, media? It’s a very, very hybrid practice in that way. And that is a virtue of that term is you do a lot of different things. And it’s why it’s not… Including myself, a lot of us in this space have transitioned from different roles at different times, legal roles, non-legal roles, because you really do wear a lot of hats here.
George Peabody:
Yeah, cool. Sounds fascinating. So let’s apply that overall description of what you do to the payments industry. If you’re a payments company playing in the payments ecosystem, who in the industries needs to pay attention to these twin poles, security and privacy? Who comes to mind first?
Michael Borgia:
Yeah, I mean, it’s a cliche of course, everyone really, and it’s true. I mean, it’s true because… Not just in sort of a feel good, “It’s everyone’s job,” kind of thing, although it really is, but the technology is the backbone of… The line between payment firms and technology firms is really increasingly blurry and so much of the real core value of a lot of our clients in the payment space are the technologies that they’ve developed in house and in the technology partnerships that they have. So it really becomes everyone’s responsibility for that reason because of what you’re doing. If I had to pick some people, I mean certainly you’ve got anyone now that’s working in IT in any kind of role, and those roles are obviously increasingly diverse, security and privacy have to be among the top considerations without question in both of them. Because one, privacy, certainly all of the personal data, the massive amounts of personal data that these companies are handling and processing puts privacy to the forefront. And security too. Security obviously is based on data security, based on personal information among other things.
But it’s important when we talk about the interplay of these two disciplines that it’s not just about personal information anymore, as in access to it or misuse of it. There are more pure security concerns, your ability to do business. And if your systems are shut down or compromised, you can’t process orders, you can’t process payments, you’re just losing money. And not only is that a huge issue, the regulators are really thinking more broadly about cyber risk than they used to be. There was a time when regulations were very data breach focused. “Did anything happen to the data?” “No.” “Okay, not much law has to say about it.” That’s really changing and we see laws focusing much more on operational and systemic risks.
Chris Uriarte:
Yep. Yeah, very interesting, Mike. And when you’re working with your clients, let’s say you’re reviewing a contract or part of a deal, maybe a transaction that’s going on or even just a supplier type contract, what questions typically come up? What’s front of mind these days when it comes to security and privacy?
Michael Borgia:
I think there’s a few things. One, certainly still for as far as the eye can see, around data, especially personal data. What is that data? What can it be used for? What is the sensitivity of it? So both in a security standpoint, from a standpoint, “How would we use this data? How could it be misused?” And also a valuation standpoint. I think what we’ve seen that’s very interesting… Here’s an example. You’ve got a long running deal between two partners in the payment space and the deal was entered into in 2014 or 15 or something and doesn’t have very clear rights around who owns the data. Well, now they really, really want clear rights around who owns the data because they’ve realized how incredibly valuable that data is.
And so that’s a trend we’re certainly seeing in transactions, is a strong desire to define very clearly who owns what and how and why, and then to understand how that is valued. And then of course that gives rise to all the other privacy and security considerations because they realize, “Hey, even if this isn’t data that would be notifiable…” Maybe it’s tokenized, it’s not a huge security risk as security risks go. It is, but it could be worse. “We still have a very strong interest in keeping this confidential and managing it because of the incredible value that it provides.” It becomes like IP in that way.
George Peabody:
Well, from my point of view, security and privacy as enterprise activities, they’re largely costs. That’s one of the reasons that regulators have stepped forward to say, “Hey, yeah, you’re focused on top line activity, but these are important functions that you need to really pay attention to. Sorry that they’re costs, but got to do better.” What are you seeing in terms of regulation? Let’s start in the US and we’ll certainly refer to what’s happening globally a little bit later. How are regulators thinking about this in the last year or two and what’s showing up in proposed legislation?
Michael Borgia:
Well, they’re thinking about it a lot at basically every level and it’s been a fascinating and very busy year for people in this space because of that. You’re seeing proposals in Congress and federal agencies, you’re seeing action in federal agencies, you’re seeing a lot of activity in states. And that encompasses a number of things. So certainly your traditional state data breach notification laws that we’re familiar with, we get the letters and the credit monitoring offerings. Those exist. They still exist and they’re becoming stricter and more stringent timelines, more data being encompassed, more litigation around that after reporting a data breach, class actions, regulatory enforcement, things like that.
We’re also seeing a lot of effort, particularly in the federal government level, but not just the federal government level, again, around systemic risks, thinking more about pure data and particularly cyber security issues, not necessarily tied to data. Great example is the banking regulators, the OCC, Federal Reserve Board, the FDIC earlier in 2022 published a 36 hour notification rule. And it’s a very interesting rule, a bit complex, but it’s an interesting rule in that it’s not primarily about data breach. There is a component of data breach to it, but ultimately this isn’t the kind of thing where, “Oh, we mailed the wrong document to the wrong person and got to notify that one person.” That could be under state law but not here. This is really about systemic and operational risks, both in the sense that it is requiring banking organizations and their service providers to provide notification of large scale incidents, large scale business disruptions, and also providing information to the government to try to address those.
George Peabody:
So we’re looking at issues of systemic resiliency as well as national level cybersecurity concerns.
Michael Borgia:
Exactly. CISA, the Cybersecurity and Infrastructure Security Agency, as part of DHS has really taken a huge lead here. And Congress actually passed law. They don’t always do that, but they did that this time. They passed a notification law for cyber incidents related to critical infrastructure. And certainly much of financial services and other types of firms will fall into that. And CISA is developing regulations around that. But that’s another example of notification requirements, not primarily about data breach. They are about operational resiliency, business continuity, and systemic attacks, trying to understand attacks against many parts of an industry. How do we feed back information to the government that could then be distributed out to other actors in the industry?
George Peabody:
I love what you’re pointing at is that the requirement for reporting sounds like it’s rising. One of my actually personal frustrations has been the US where we haven’t been obligated, payments systems, to report fraud, for example. And what’s the old saw? You can’t improve what you don’t measure. So I’m encouraged to hear this reporting requirements coming at the federal level.
Michael Borgia:
It’s diversifying for sure, meaning there are more requirements in more circumstances. There’s breach notification. I accidentally released someone’s SSN, got to report a data breach, we’re more familiar with that. And then now there’s what I might call incident reporting that is really about not the breach of data itself, but is about the operational and systemic risks. So two different ways of thinking about this, and they’re concurrent. So not replacing, but I think recognizing that there are different types of risks here and there are requirements to address those different types.
Chris Uriarte:
Yeah, I think one other thing, Mike, that we often find frustrating about all of this is this immense patchwork of different laws and regulations that you’re talking about. And it often makes it incredibly difficult for an organization to understand what they need to adhere to and what is within their sphere that they should be paying attention to. Because you have pure laws and regulations at the state and national level, or if you’re in the EU, you might be at the country level and at the European Commission level as well. But then you’ve also got all these different rule-making bodies, which maybe even aren’t government entities. So for example, in the payments card industry, PCI is treated almost as law with everybody in the industry and needs to be adhered to. But certainly there’s no national laws around PCI, but we see a lot of evolution in this area. Can you talk a little bit about PCI and what you’re seeing with maybe the introduction of the new PCI 4.0 standard or any other things that your clients might be concerned about?
Michael Borgia:
Yeah. And I’ll just start out by saying, before I get in the meat of that question, that we are seeing a little bit of a trend around laws related to PCI. Nevada has a law that says if you process payments, you have to follow PCI, if you’re doing business in the state. What comply with PCI, I’ve come to really… When I first started with PCI, I thought that would be an easy question and I’ve come to realize that it takes a career to understand what does it just conceptually mean to comply with PCI.
So what that law exactly means is hard to say, but there are a number of other laws that have come out that have more of affirmative defenses or safe harbors. So you’re not required to comply, but if you had a breach and you were able to say, “Look, we comply with PCI,” presumably as relevant to this system that was compromised, the data that was compromised, “We have protections, limitations for ability to be sued or ability for plaintiffs to seek punitive damages and things like that because we comply with PCI.” So we are seeing clear legal incentives to doing that in addition to what already existed.
Chris Uriarte:
Very interesting. Yeah.
Michael Borgia:
In terms of 4.0, I mean, I think a lot of clients are really just starting to get their heads around it. And since we’re not as involved in the technical aspects of it, I think what we’re seeing a lot of is just a lot of people digging into the guide. And I do think the council did a good job in 4.0 providing a lot more guidance about scoping. Now, one may not love the outcome of that guidance, but with the various version threes that we’ve been dealing with for a long time, there were always these issues kicking around of, “Do I have to do PCI? When do I have to do it? Is this in scope? Is this out of scope?” And I think they did a much better job this time perhaps picking up on that to say, “This is how you are in scope. These are the ways you are not in scope.”
Obviously they take a very broad view of scope, but we deal with a lot of clients in this space that, going back to my point about the blurring of payments and technology, we deal with a lot of clients that come into this space almost tangentially where often it’s a difficult problem to figure out, are you covered? Are you a service provider? Are you a merchant? Because I still think to this day, the regulation, understandably… Not the regulation, but the standard rather, DSS, was written with this assumption in mind of, “You got a store, online and physical, whatever, and then you got a payment processor and the data goes and it comes back and it’s pretty clear.” And that’s really, really deteriorating where you’ve got so many different parties and processors and service providers and fintechs.
And I do think the guidance has become more helpful. Again, not to say that it’s necessarily a great outcome for some of those clients, but it is more helpful. It takes a clear position about what brings you into scope and how you need to address that and things like that. So I think that’s been helpful for clients to at least start to get a clearer sense of… Especially these clients that are not a traditional merchant or a traditional payment processor, getting their heads around, “Okay, what do we actually have to do for PCI?” And I think for a long time they just tried to skirt the issue because there was no clear answer.
Chris Uriarte:
For sure. The landscape of fintechs out there and what they do is quite broad. And of course not all fintechs are payments companies, but as we’re seeing, payments is a critical foundation to a lot of the functionality that these fintechs are bringing to market with their products. So it is a surprise to a number of the fintechs that we work with that we introduce concepts of PCI or some of these security aspects in the payments world to them. And all of a sudden they realize that yes, they are a payments company. Maybe they thought they were a, quote unquote, “embedded finance” company or something else that they were doing, but at the end of the day, they’re certainly being treated as a payments company by Visa and MasterCard or by some of the other regulations that are out there.
Michael Borgia:
There are many companies in many spaces that have tried to say recently, “We are just a technology company.” And the success is mixed. Regulators don’t always see it that way certainly and certainly the council and the card brands take a very broad view of who is in scope. And related to that too, I think they did a good job in 4.0 discussing more about the relationship of cloud. Because we have clients that are cloud service providers. We have many clients… All our clients certainly use cloud to some degree. That is helpful as well to try to clarify those relationships and what’s expected there. Just another example of more parties entering the scope of these and trying to understand how is that party related? Is that a service provider? What if they don’t have access to the data? Are they still a service provider? So there’s a lot of iterations that we are working through.
George Peabody:
Mike, one of the things that I’ve heard of and read about is, well honestly, that there are companies that will choose an auditor for PCI and if they don’t like what they get back at the first level, they might go to another auditor who might be more lenient in its judgments. I’m hearing that with 4.0, that the wiggle room for the… Or really, the instructions and guidelines for auditors are going to get tighter and tighter. Would you expect that?
Michael Borgia:
Yeah, I would. And I’ve heard that as well and I think we’ll see that, which makes sense. I mean, there’s what we call an analogous context of forum shopping, trying to get the answer that we need. I mean, first of all, as a strategic matter, that sounds like an incredible amount of work. Not a recommended approach because going to a third party audit for PCI is really, really hard. And it can be an exhausting process. So to do that and then say, “Well, we got to do it again.” I mean, your IT team is just going to quit because it’s all they’re going to be doing for six months.
George Peabody:
Not a good strategy.
Michael Borgia:
No. What you can do… I don’t know… I never seen PCI take a negative view of this. You can hire firms for two engagements and you can go to a third party auditor, a QSA firm, and say, “Look, it’s phase one. We don’t want QSA assessment. What we want is we want you to come in and consult and give us a view and tell us what’s a problem.”
And these firms will typically bifurcate. I mean, I think it would be very problematic if literally a QSA came in and said, “Fix this, fix this, fix this,” and then came in and said, “Okay, everything is good.” But the firms will do that and certainly the firms have a sense of how their own auditors look at these things. So I mean, to me that’s a much better strategy is to say, “Look, let’s come in, consulting team come in, evaluate, help us out, help us get ready, and then we’ll bring in the QSA and the QSA will be totally different and they’ll be screened off, but then they’ll come in and do it.” I think that’s going to be a much more effective approach than-
George Peabody:
So that step makes me think that it really is useful to senior management and to the board in terms of looking at their exposure as well as what the costs and time is going to be required to accomplish the certification.
Michael Borgia:
Right. I’d agree. And QSAs are… Again, it’s a rigorous process, so that’s not a process you can wing. I think that doing the work upfront to make sure you’re ready and are going to have a successful QSA audit makes a lot of sense and is worth it. And QSAs, I don’t think want to… In my experience, they don’t want to fail you. That’s not what they’re trying to do. But you’ve got to be ready and you’ve got to be in good shape to have a successful audit.
Chris Uriarte:
Yeah. Mike, I think your recommendation is a great one. And we’ve made similar recommendations to organizations that are making the leap from, say, a lower level PCI compliance level where they just need to fill out a certificate or an assessment form versus going through the full QSA audit and they see their business growing and all of a sudden they know they’re going to get into the area of PCI Level 1 compliance where they need a full QSA. So we often say to them, “Bring in the QSA first. Go through a consulting exercise where you essentially identify or create a gap analysis between where you are now and where you need to get with PCI Level 1. And then once you actually go into the exercise of the audit, if you’re able to remediate what was found in the gap analysis, the audit should be a much, much better and much easier exercise than if you were just going to go at it from scratch.”
Michael Borgia:
I think that’s absolutely right. And the reality here, like many things, but especially in something that’s an industry standard, is PCI’s a bit of its own world. And I think many QSAs will be honest with you that when there is ambiguity in what the requirement is, a lot of it comes down to what do the acquiring bank, what do the payment processor, what do they expect to see? And so I think bringing in a firm that understands the landscape, understands what the parties that really dictate a lot of the requirements are expecting and what they think is acceptable and not acceptable, is very helpful.
Sometimes clients come to us and say, “I read this requirement. What does it mean?” Well, we can go through what it could mean, but what is a QSA, what are they going to find an acceptable interpretation of that? There’s no better source than a QSA. And the QSA is going to do it based on the lots of audits that they do, the conversations that they have with the card brands and with the acquiring banks and with payment processors. And so it’s just a practical way to do it too that I think is more successful than trying to figure it out on your own.
George Peabody:
Cool. Mike, before we jump into privacy, I want to just ask you about what are their obligations? What regulation is being applied to them? Of course, I suspect those obligations are both in the security and privacy area, but what are you seeing in terms of regulation that apply to those two groups?
Michael Borgia:
Of course, boards and senior management have general legal obligations, and we don’t need to make a lesson on corporate law, but of course, they’ve always had obligations to act as fiduciaries, to exercise good judgment, due diligence, and that would include cybersecurity because cybersecurity and privacy, they’re part of the company. So it’s not that those obligations are new. However, they’re becoming much more specific. So we’re seeing proposals and promulgated regulations as well directly requiring oversight and certain engagement by the board and by the senior management into cybersecurity matters.
One great example is SEC. SEC has proposed many things. They’re kind of on a regulatory tear. But one of the things they proposed earlier this year was a set of disclosure rules around cybersecurity. The four day incident reporting piece took most of the headlines, but there’s a lot of requirements in this proposal, just a proposal right now, to disclose things like what does your senior management, your board do? What’s their role for data security, cybersecurity? What experience do they have? Does the board have any experience in cybersecurity? How often is the board briefed on cybersecurity? How does the board engage with cybersecurity?
Now, like many things in the SEC, they’re not requiring that the board do this, but that’s the implication. You don’t want to go and say, “Our board has no particular role in cybersecurity and they don’t know anything about it and they don’t talk about it very often.” You don’t want to put that in your investment prospectuses and your 10-K and things like that. So you’re going to want to have a board that you can say, “Our board is well-versed in cybersecurity or we’ve got an expert on the board. We talk about it regularly. We manage it. Same with senior management.”
The New York Department of Financial Services, the state level, we talked about federal and state really, yesterday they published a series of amendments to their cybersecurity regulation that applies to banks and financial services institutions, insurers and others regulated under certain laws in New York state law. And that has a number of amendments, but one set of those amendments is around the requirement for the board of directors or governing body of the organization to exercise oversight and provide direction to management on cybersecurity risk management, requires executive management to develop and maintain the cybersecurity program. So we don’t need to get into all of it, but what we’re seeing is more and more legal requirement saying the board and senior management have to be involved.
Also, there’s also requirements in here about independence of the CISO, which is a long-running issue that we’ve seen for many clients. Where should the CISO sit? If the CISO sits under the CIO, is that a conflict? If one’s focused on usability and availability and the other one’s focused on security, does that always work? So really fascinating issues that are being brought up by these laws. And I think the bottom line here is that the senior management and the board are going to see that they have direct legal obligations to engage in these things. It’s not simply going to be, “Well, we have to do our duty,” but, “We’ve actually got explicit obligations to do that and to have a meaningful role in cybersecurity.”
George Peabody:
So the bar is really being raised. So this has been great. Let’s jump over. Well, we’ve got some time to talk about privacy, which is the other side of this discussion. And we’ve got the CCPA, California Consumer Protection Act, and Europe, the GDPR. What all’s rolling out? What kind of impact are you seeing? What do people have to do?
Michael Borgia:
Yeah, I mean really, a tremendous amount going on in this area as well and largely, although not entirely, at state level. The FTC has started a process that could lead to rule-making for privacy rules. So we’ll wait to see. That would be a very long process. It may not be successful, but the FTC, Federal Trade Commission, is working on that. And there’s always rumblings. There was a proposed law in Congress around data privacy. So a lot of rumblings in that area, but most of the action has been at the state level in terms of what’s actually been passed and what you actually need to do. You mentioned California. Virginia, also Colorado, Utah, and Connecticut, and there are some similarities to these laws.
George Peabody:
Thank God. I’m just thinking, how do you comply with-
Michael Borgia:
The news is not all positive. I mean, there are similarities and the core of these laws is disclosure and consumer power in the sense that you have to say, what do you collect? What do you do with it? Things like that. Those were existing requirements and they’ve been beefed up. But then there’s also these subject access requests that we saw under GDPR and are now coming in through US laws. And I think they are deceptively hard to comply with. So on the surface, it says things like, “If a consumer says, ‘What data do you have about me?’ you have to respond to that.” Okay, seems easy enough. Or delete the data, things like that. On the surface, that might not seem like it’s that hard, but there’s a few wrinkles. One wrinkle is California, that applies to employees.
So if you’ve worked in any company ever, you can imagine an employee coming to you and saying, “What data do you have about me? And where is that data?” Where is that data is a better question, especially if that person’s worked there for any long meaningful amount of time. But even with consumers, your customers, you think about a complex organization, how do we find that? How do we know what data we have about them? And there’s all debates happening in regulations that are being promulgated and just amongst attorneys and others in the space of to what extent… Well, what if we’ve got different databases and there’s different identifiers and different people, what do we have to do to put those back together? How would that work? Deletion, can we delete it? Legally can we delete it or can we just delete someone’s data and not screw everything else up? How would that work? Portability is another right, so allowing people to take data with them. It’s a great idea in practice, but… In theory rather, but in practice, that’s extremely complicated of what does that look like?
The ground level, it’s a massive IT requirement, which I think has been looked over, is that what these laws really call for is real strict organization and mapping of your IT environment in a way that hasn’t been required, to really understand where is our data? What does it look like? How do we retrieve it? We work with clients that get these requests and it becomes an e-discovery exercise. They’re loading thousands of records into an e-discovery platform and running searches. And that’s not a sustainable process. If you’ve ever done e-discoveries, you know that is not like a BAU style process. So that’s very challenging. And the laws do not entirely match up. And there are conflicts around where they apply, to whom do they apply, what rights are available, what rights are not available, under what circumstances can you share data. So that’s another big thing. It’s existing in privacy laws and in GLBA, but it’s very much a focus of these laws, is when can you share data with a third party? When can you sell data to a third party? What’s a sale? So we’re seeing that everywhere as well.
Chris Uriarte:
I think, Mike, where this is really complex, we’ve talked a lot maybe over the last decade or so about the concept of security by design, really building security in from the ground up and now we’re starting to hear a lot about privacy by design. It’s sort of the same concept where from both the product and the technical level and the operational level, you’re always keeping privacy in mind from the first point of when you start building something. But if the waters are murky or as complex as you’re describing, I find it incredibly challenging for how a product manager, a product owner, chief technology officer, can even understand where to start with this stuff. So I think from a practical level, the type of situation that you’re describing poses a number of challenges to those of us that are in the trenches actually building things.
Michael Borgia:
Yeah, I’m glad you mentioned privacy by design. It’s a fascinating term and it’s a term that really in much of its life has meant… More like a product term. Like, “We’re designing an app. We have to have privacy by design.” But in this sense we’re talking about a new life of privacy. It’s like a network architecture, IT architecture privacy by design. Is our technology stack, our environment, broadly construed our on premises network, our cloud systems, our SaaS systems, are they being designed and put together with privacy as a consideration? Both in terms of access controls and things like that, but also ability to have transparency. Can we be transparent or do we know what we do? Could we retrieve the data? How would we delete it?
That is really when you are designing a network, designing a system, something you now need to really keep in mind. It’s a huge challenge and it’s especially a challenge for companies that have grown through acquisition or, like many companies, “We just got systems and we added systems to those systems and it’s just how it’s gone. It wasn’t a 20 year plan. Technology changes and we bought new stuff.”
Chris Uriarte:
Absolutely.
George Peabody:
Well, I just can imagine if I’m charged with being concerned with this challenge and I want to operate across the country, now I’m subject to state laws and how they vary. What do you tell clients who are in my position where I want to stand up a service that’s got to respect privacy? Do I use CCPA as a benchmark and that should cover you? I mean-
Michael Borgia:
It depends on the client, of course, where they are and the percentage of business they do and things like that. But generally, I think there’s two major principles you can follow. One is what we were just talking about, build that foundation. If you have a foundation… And this is way easier said than done, but if you have an IT foundation where you know where your data is, you can retrieve it, things like that, that is going to serve you for any privacy requirement that will ever come up. I’m not saying it’ll be enough to comply with it, but understanding where your data is and how you manage it and being able to track it and things like that is always going to be a game-changer for privacy compliance, no matter what the legal requirements are. So start there because that’s always going to help you.
Second, yeah, I think for national companies, you got to look at what your leading edge is. Unless you’re going to build a separate system or have totally separate processes for different states, what we are seeing is that many clients elect to say, “What is the strictest requirement? And we’ll just apply that across the board because operationally we can’t do that.” There are exceptions. Company says, “Look, we’ve mostly got customers here, we have a few in that state. Sure, we’ll stand up a special process. We can do that.” But that’s often not going to be feasible.
Chris Uriarte:
Great. Well, Mike, we’ve covered a lot of ground today and before we wrap up, I wanted to make sure that our listeners know about the upcoming webinar that you’re going to be hosting. So maybe just talk to us a little bit about that.
Michael Borgia:
Sure, I’d like to. And one last point I just wanted to make on privacy. I’d be remiss if I didn’t for our…
Chris Uriarte:
Yeah. Sure.
Michael Borgia:
… listeners. When you’re looking at these privacy laws, many of them have exceptions for data and/or institutions regulated by GLBA. So that is a really important place for you to start if you are a financial institution under GLBA, and I’m sure many of your listeners are, because it will actually exempt you from not all, but many of these requirements. So take a look at that first and that first step before you go and build a whole compliance regime around a law that doesn’t actually apply.
Chris Uriarte:
Great piece of advice. Yeah, for sure.
Michael Borgia:
Yeah, so we’re really excited about this webinar. We have done a ton of work in this space with the intersection of privacy and security and the payments and financial services. That’s a fascinating area. The laws are complex and, as I just referenced, they can interact in complex and interesting ways. So we, on December 14th, will be hosting a webinar in conjunction with Glenbrook, with you guys on data security issues in particular as related in the payment space and how the payment ecosystem and data security requirements are interacting. We’re looking for something that’s going to be very practical, a lot of take-home points, a lot of things to think about and take home with you around what are the major requirements, what are some practical… We talked about here today, what are some of the practical strategies to get started in this and make sure we understand it? It’s a super important topic and I think with all of the action in privacy right now, some of the data security stuff has fallen into page two, so we’d like to correct that.
Chris Uriarte:
Yeah, for sure, for sure. So we’re really looking forward to that and we’re looking forward to participating and also looking forward to speaking with you again and having you back on our podcast. This has been a really great discussion, some really fascinating topics, and there’s always new things that are happening in this space. So thanks so much for being here today. And to our listeners, thank you all for listening. We’ll put some details about this upcoming webinar in the show notes as soon as we get them and we’ll put them online. But appreciate everybody listening. And George, great to be back with you-
George Peabody:
Great to be back with you, Chris.
Chris Uriarte:
… and thanks for listening to Payments on Fire. Thank you.
Michael Borgia:
Yeah, thanks again for the opportunity. It’s great to speak with you guys today.
George Peabody:
Super. Well, until next time then, hope all’s well. Do good work.
Chris Uriarte:
Take care.
