Pensions, Benefits & Investments Briefings

Ransomware and other cybersecurity attacks have made national headlines during the past 12 months, and public pension systems are as susceptible to these attacks as any other organization. In this episode of Pensions, Benefits & Investments Briefings (formerly Public Pensions & Investments Briefings), Thomas Dover and Ashley Dunning discuss the protections public pension plans can put in place today to ensure these kinds of data privacy attacks are kept at bay. They also discuss other intellectual property issues every public pension plan administrator should be aware of in order to maintain the health of their organization.

Transcript: Managing IP, Data and Privacy Risks of Pension Administration Systems

_{0:00:00.9 Ashley Dunning: Now, more than ever, cyber criminals have been targeting large organizations in an effort to steal personal, protected information. Today, we’re looking at best practices and improvements to public pension administration systems to protect personal information from potential attacks.}

_[music]

_{0:00:27.8 Intro: Welcome to Public Pensions & Investments Briefings, Nossaman’s podcast exploring the legal issues impacting public pension systems and their boards.}

_{0:00:49.9 AD: Welcome to another episode of Nossaman’s Public Pensions & Investments Briefings. I’m Ashley Dunning, co-chair of Nossaman’s Public Pensions & Investments Group, and I’m joined today by my law partner, Thomas Dover, who leads Nossaman’s intellectual property practice and is co-chair of the Privacy/Data Security Group. Good afternoon, Thomas.}

_{0:01:11.9 Thomas Dover: Hello Ashley, I’m happy to be here, I am always happy to talk with you.}

_{0:01:17.6 AD: And I’m glad that we’re going to be able to talk about this interesting topic today because everyone is currently concerned about hacking and ransomware. And the first question I’d like to ask you is, what we can do or what public pension systems can do to protect their pension administration systems and data on those systems.}

_{0:01:39.8 TD: I share the concern, and we see it in the headlines across the internet and newspapers almost on a daily basis, some kind of hacking or ransomware. The issue is really, if we boil it down to two major buckets, we have privacy obligations that pension systems are required to conform to, and we have data security requirements that we should be expecting of ourselves, for the pension system, and for the developer. The struggle then becomes, who is going to be responsible for what, and at what stage? The first calculation that I think we always make is as to the pension administration system structure, historically, you and I know that most of these systems were maintained at a local level, meaning they were on servers that we owned and maintained very often in our offices, in our buildings in that cold room that nobody ever went into.}

_{0:02:39.4 TD: Now, all of this is very much more advanced, and we have cloud-based systems and cloud-based data storage, so the issue then is, how are we structuring the system, and where are the weak points? There, I always say, look to where there’s an interchange of information, when the information is coming from an outside source regarding a member into the system, and then when we transfer it as the pension system to a vendor, is it going to a vendor for printing checks or is it actually going to our pension administration system vendor into a cloud environment? Those are the points where we have to evaluate whether or not we should be responsible, and how, are there data transfer protocols that we want to keep in place? Some of you might be aware of the HIPAA data transfer protocols that are required.}

_{0:03:38.1 TD: It’s the same sort of evaluation, what kind of security do we want when information is, as they say, in transit, and then how are the developers or the pension system, if we post the information locally, how are we maintaining the security of our system? There the questions are, what are your firewalls, and how are they structured? Now, we’re lawyers. We shouldn’t have to get into the weeds of this, but now, not just lawyers, but even our pension administration systems need to be fluent in this conversation, we don’t need to necessarily understand or dive into the weeds of it, but we need to be able to understand what questions to ask. And so this has now become imperative for our administrators and our IT professionals, and I commonly will just sit down with the IT professional and just have an exchange of what their concerns are, and they can hear what my concerns are, and sometimes this really is captured in the agreements in terms of what our confidentiality expectations are.}

_{0:04:50.8 TD: The developer of a pension administration system, particularly those that are legacy, you’re aware of those boilerplate public records provisions that are in every agreement with a public entity, those have limited meaning when it comes to privacy obligations because we’re talking about what is... As a public entity, what we have to maintain as public, you know better than I, The Brown Act, Public Records Act. The other side of that equation is what is required for individual privacy, this might be members, this might actually be employees of a pension system, and what privacy expectations they are entitled to, and how we have to conform to those.}

_{0:05:39.2 AD: That’s interesting because I think in the public retirement sphere, there is certainly a lot of familiarity with Public Records Act, there’s also a familiarity with the concept of confidential member records being maintained confidentially, and yet it sounds like there is yet a further standard that requires certain data, even additional data to be maintained confidentially in the context of this personally protected information and data breaches that you’re referencing.}

_{0:06:10.5 TD: And what it is and what that importance is is to transfer the obligation that the pension system has additionally to each vendor, so to make sure that they have the same obligations to maintain the confidentiality of personal information that the pension system might have, if we use boilerplate public records provisions, that’s generally not captured. So we need to be aware of these issues.}

_{0:06:35.5 AD: Interesting and so complicated. One other thing or another aspect of this that is complicated now are the software and systems themselves and related contracting around them, I’m thinking specifically now about the licenses. What do pension systems need to include in their pension administration system licenses in order to sufficiently protect themselves?}

_{0:07:02.6 TD: Generally, in terms of the pension administration system structure, the structure that we are looking at to protect the data, the... And this comes back to the procurement approach, is this going to be a standard request for a proposal RFP approach, where there’s a draft contract that is being provided or is this going to be something where we are asking more generally for proposals that maybe we don’t anticipate, but then the drawback to that is, we may well get a developer software license that really doesn’t serve a public entity, so it means combining or somehow conforming the two to each other. Best practice, I still think, is to provide a draft contract. The responses that the systems might get might well include a software license that, again, I’ll use the term boilerplate, because even software developers like to go to a drawer and pull out a form from 10 years ago and still use it. None of those really include the kind of data security requirements that are commonplace nowadays and almost none of them will address the kinds of use and license that a pension administration system will need. So for example, we very often get into a procurement where we’re looking at best price versus what we’re getting, and very often we will say, "Okay, well, this is the best price without really looking... "}

_{0:08:36.2 TD: And I hesitate to say it again, you gotta dig into the details of it because the license grant that you’re getting might not actually be everything that the system needs, if you look at some of those terms, this is bedtime reading, but when you look at the license grant in some software development agreements, you’ll see the word "use," that you have the right to use the system, and it doesn’t include anything else. Well, case law in California specifically has addressed that and said that the right to use does not include the right to modify, make derivative works, to update. These are all critical things now, just consider data security alone or antivirus updates, well, you wouldn’t be able to do that if all you had was a right to use, so is this something where we anticipate, for example, a perpetual license and the developer is going to be there to maintain it for us for a while, and then they go away and maybe we get a new vendor, if you’re doing that, you still need all of these rights after the initial vendor goes away, that becomes a complicated process.}

_{0:09:43.1 AD: Yeah, that’s really interesting because, as you know, public retirement systems really are perpetual in the sense that they’re very long-term entities, they’re not going to be selling the data to anybody or transferring it to anybody, but they do need to be able to maintain the system and to upgrade it over time. Probably long after the entity that they first contracted with has gone out of business, and so as you’ve seen this develop over time, probably impresses upon all of us even more the incredible importance of these transition terms. Do you see contracts that are currently in existence, aren’t expected to expire any time soon be amended to deal with this just because people recognize that’s an issue?}

_{0:10:32.8 TD: Yes, and I think we should do more of that because you’re right, pension systems are perpetual. Some of the software license agreements that I’ve seen, even some that are old or legacy, also contemplate a perpetual license, unfortunately though, it doesn’t include the kind of consideration for what has to happen from a practical perspective. We know what we want the system to do, but we don’t really think through always at the initial stages, what we’re going to require of the developer for the license grant and for these transition services. And so I think, particularly for purposes of data security, these are things that change every day, you and I see notices every day about a new hacking technology, and our IT professionals have to get up to speed, so that often means an upgrade to the system, that’s the greatest explanation to a developer as to why some of these legacy contracts need to be amended, these are things that weren’t contemplated early on, we just simply didn’t think this could be an issue. I have drafted some of those legacy agreements, and we didn’t think it was important or as important, now of course, this is what we lose sleep over.}

_{0:11:50.0 TD: So going to your developer and having a rational conversation about the current needs of the system and attempting to amend the agreement to current standards I think makes sense, and if they’re unwilling to do that, that tells you quite a bit about the developer.}

_{0:12:05.6 AD: Well, that’s probably a good time to do it, when nothing’s going wrong. Speaking of risk management and crises, what are our current approaches to data breach issues and intellectual property infringement liability?}

_{0:12:21.5 TD: And isn’t that the reason that we’ve talked through everything regarding the pension administration structure and how we’re approaching the license grants, because all of this is now critical, we are intimately aware of data security liability and hacking events, so we don’t want to be on the hook for sometimes what is catastrophic in terms of potential damages, there are a lot of things to talk through for indemnification and limitations of liability. I’ll focus on just a few. The first as to... Let’s focus on data breaches, these are generally the acts of third parties, you don’t often have an insider that does these. If it’s a third party, the developer is going to come to you and say they can’t possibly be held responsible for this because this was out of their control. The argument back to them is, "Frankly, we’re paying you millions of dollars to provide the system and provide for the protection of the information that we are entrusting to you, you have some responsibility." Sometimes that will open the conversation to additional data security requirements, sometimes there are data security addendums that are included.}

_{0:13:38.9 TD: The issue with that, of course, is maintaining currency, you want to make sure that all those data security requirements are the then current requirements, unfortunately contracts are static in nature, generally, so how do we provide for that? Sometimes there are creative ways of approaching it, and sometimes you might come to a compromise in terms of the risk management, in some instances, they may not be responsible, but in certain instances, they would be.}

_{0:14:10.6 TD: Some developers are just simply not big enough from a financial perspective to be able to maintain the liability for a data breach. We have to talk about insurance, there has to be some backstop, particularly if they are not capitalized enough to maintain a liability judgment. Insurance, you’ve talked with Jim Vorhees, our partner on insurance, on related issues. I think cybersecurity insurance is the next critical thing that will develop within the insurance industry, it’ll increase in terms of what is excluded, but it may also increase in terms of the value to pension systems, and that also relates to consequential damages because again, the developer’s argument is going to be, "These are acts of third parties, they are not actual damages to the pension system," the reality is, of course, that if there is a data security event, they’re right, there is no actual damage to the pension system, but you’re going to have tens of thousands of consumers, sometimes not just members, but also employees that will be looking to the pension system to be compensated, and it is absolutely something that is predictable, but it is not by definition a direct damage. So we have to account for that, and it has to be an open conversation.}

_{0:15:40.9 TD: A related issue is IP infringement. As we have worked through this, you and I, Ashley, there are a lot of pension administration systems out there, some of which were maintained by small developers that were then swallowed up by others, there is a very finite group of pension administration systems developers that we have confidence in and that have proliferated throughout the industry. Those are the ones that we deal with, that also means that they’re highly competitive, and it wouldn’t be unreasonable to expect the pension systems to be swept up in IP infringement suits as these developers become more aggressive with their competitiveness.}

_{0:16:24.9 TD: That’s not something that the system should be involved with necessarily, but it is the nature of IP infringement and competition. The way to avoid that sometimes is to create some carve-outs in that IP infringement, to make sure that we are insulated some amount. We could talk about limitations of liability, they’ll want to cap their liability generally, I’m not a big fan of that, and if we do it, it has to be heavily researched, and risk management needs to take a huge look at that.}

_{0:17:02.8 AD: So that’s all very interesting, Thomas, and it highlights the fact that in the context of a dispute, you may well have a lot of different parties implicated, whether it’s one developer or two, potential cyber insurance carrier, certainly members if their data has been released, and then possibly the retirement system, so it’s a good idea to think about all of these things as much as possible in advance before there’s any problems that perhaps leads to litigation. On that point, thinking about best practices and lessons learned, Thomas, are there any final comments you could share with the audience, lessons learned that you would be able to impart to us?}

_{0:17:51.5 TD: Sure, and I echo your concern about the pension administration systems generally, I do think that it is worth diving into the weeds of some of this, and I think we are not doing ourselves a favor by expecting the developers to explain it to us. And that really goes into the first major concern for me, and that’s the nature of software licensing, this is not limited to pension administration systems, this is a broader concern. And some of these concerns, I would cut and paste into other industries because they are dealing with it in essentially the same way. So we have to ask ourselves these critical questions, what do we need the system to do, and what rights do we need from a legal licensing perspective to be able to have during the term of the agreement and then afterwards? And then what happens if something goes wrong? You become dissatisfied with the developer. These are things that we now have to ask ourselves in advance because if we get midstream and we go back and look at the contract, we’re going to be very disillusioned.}

_{0:19:01.4 TD: I think the other thing to keep in mind is really the dramatic importance of data security in this day and age, we have to maintain certain privacy obligations for our own members and employees, and at the same time, we need to understand and require our developers to maintain certain data security measures, whether that is at a local level or even in a cloud environment.}

_{0:19:33.7 AD: Well, that was a lot to absorb for the day and for the podcast. I want to thank all of our listeners for joining us for this episode of Public Pensions & Investments Briefings, for additional information on this topic and other public pension issues, please do visit our website at nossaman.com. Also, for those of you who are clients, you’ll be invited to our annual fiduciaries forum, which is scheduled for early December of this year, 2021, and Thomas will be presenting there on some of these very issues that he’s highlighted at a very high level today, he’ll be able to delve into them a little bit more there. Also, don’t forget to subscribe to Public Pensions & Investments Briefings wherever you listen to your podcast, so you don’t miss an episode. Until next time.}

_{0:20:26.4 Outro: Public Pensions & Investments Briefings is presented by Nossaman LLP, and cannot be copied or rebroadcast without consent. Content reflects the personal views and opinions of the participants. The information provided in this podcast is for informational purposes only, is not intended as legal advice, and does not create an attorney-client relationship. Listeners should not act solely upon the information without seeking professional legal counsel.}