A (3:13)

Yeah, so if you think about it, customers, at the end of the day, I work for a bank. Our customers don't care if information is taken or affected, whether it's us or whether it's a vendor. They just know that the relationship they have is with us. And so from a security lens, one of the important pieces is making sure that regardless if our organization has the right controls, we have to ensure that the controls and the risk being managed by our third parties is in alignment with our maturation. Again, that relationship was with us and our customer, not, not the vendor. And so, you know, really, I think that's one of the big pieces is just ensuring that those controls are appropriately assessed and managed to the best we can, given that we're not inside of those third parties. So we have the ongoing due diligence processes that we do.

B (4:09)

And let me ask you, because I think there's, there's several folks that will be tuning in that have gone through maybe a breach internally. But from your experience, how do third party breaches differ in impact compared to a direct attack on the organization?

A (4:28)

Some of the impact is similar. Right. So the data is taken, whether it's here, whether it's at a vendor, or if a system critical to operations is affected, whether it's here or the vendor, there's your similar impact. But you know, one of the challenges with a third party is that lack of visibility. If an incident occurs, whether data is taken or a system is affected, there's not much we can do to dig into that data. We can't hire necessarily or bring in a forensic team to look into that. We're reliant on the incident response of that organization. Another thing that gets interesting is around the regulatory side. If an organization is under specific regulatory requirements, partners should be aligned to that. But there may be some gaps there where as a regulated industry or regulated organization, in our case, we would have to engage with that third party and ensure that the things they're doing are also in alignment, given that our data has been provided to them.

B (5:29)

And it seems like a daunting challenge. There's so many third parties that any reasonably sized company relies on today. What methods do you recommend for identifying and classifying those critical third parties that might be in your supply chain?

A (5:50)

Yeah, So I, I think there are a number of different ways, but there are two or three that I really like to lean on. And consistency is key. Right. So once, I think the key is once you have that method of classifying it is to ensure that you're, you're consistent with that, that method. And so for one, what type of data, determining what type of data is being stored by that third party or you know, what type of data are they managing? Let's say that they access. You know, for us, if someone accesses data that we manage, but they're accessing that on a regular basis, we might factor that into our determination. Another aspect is how critical that third party is to operations. Maybe they don't manage number of sensitive records. However, if that vendor were to be disrupted or if the service they provide is disrupted, if that's going to cause downstream effect for our customers, that might fall into a higher classification. For example, in the banking world, online banking, you know, most folks want to log into their online banking account and perform transactions. If that system is down, you know that that's a pretty big deal for that, for that customer. That can affect reputation with us and the customer. And so it's important to make sure that those critical vendors are bumped up to the top. And I think another area that is important is thinking about the potentially fourth parties or organizations, third parties that leverage what I call the big three or the big four. So there are a number of very large companies everyone's familiar with, everyone uses that have data centers across the globe. And so it may be important to consider some of the geographic risk involved or to consider that if all of your third parties happen to leverage some of those same cloud providers, making sure that you have resiliency, you're factoring in resiliency when assessing them. And so I think whether it's, you know, any of those three or other items, the key is consistency. Not to be trivial, but maybe it's a simple math equation. If you have these two or three things, you hit a certain criteria, a certain threshold, and that's one way to stay at least consistent in the way that you're classifying them.

B (8:07)

You make such an important and timely point. Like just if I reflect over the last few months, how many of these pretty significant cloud outages by some of those very large providers that you mentioned have happened. And we've seen some of these ripple effects, some of which were unexpected. Right. As you said, it could be a fourth party provider, it could be a provider to that provider. It seems like if you wanted to, if you had infinite time, infinite resources, you could go all the way down the rabbit hole and you know, ask those third party providers about their providers. And even further, how, what advice would you give to security leaders to strike the right balance between a really in depth assessment, but then the practicality of dealing with maybe hundreds or thousands of these vendors.

A (9:07)

Yeah, so kind of back to the consistency you know, one thing that I like to think about is every partner that we have, every partner that any company has, there should be an expectation that it will experience a security incident or a material disruption. And so it's, on one hand it's less about assessing to ensure that that company or that third party isn't going to have an outage and more about the maturation. If that company has things like business continuity plans, if, if us as an organization in alignment with that third party's business continuity planning, if that helps manage the risk around those material disruptions, then that can be satisfactory. And so I think, I mean, I've gone down the path where I've tried to get much more in depth and it just takes a considerable amount of time versus here are the service level agreements that those organizations provide. And then we try and build again, consistency in our evaluation process. And then when a disruption happens like the ones we've seen even in mainstream media in recent weeks, then it's about how do you communicate that. So for organizations who are affected, making sure that your incident response plan internally incorporates some level of communication so that A, you're handling it from a business continuity standpoint, but then B, that you're communicating appropriately not just internally, but to your customers.

B (10:35)

And I've got to ask you this, and this is such a tough one. I know everybody struggles with this, but you've got this, this initial point of assessment, maybe when you're onboarding that company or maybe it's annually, but then you've got maybe continuous changes that that partner may have, maybe they're switching a provider themselves. What's some advice or what's some effective approaches that you've seen for ongoing monitoring of third party risks beyond the initial due diligence?

A (11:13)

I think there are two pieces here. One is depending on classification, one thing I've seen very effective is to review those. Maybe that's annually, maybe that's every other year. But I think a company has to figure out for itself what, what frequency matches up with the, the tier or the classification of those third parties. You know, in our case, if we are assessing third parties and we're looking at pen test reports or SOC reports, things like that, that we're doing that on an ongoing basis because there's always a chance, you know, organization in which we partner with, they, maybe they decide and opt not to do some of these independent reviews, that could be a signal for us as an organization to say, wait a second, let's, let's put on the brakes and let's just make sure that the risk in the way that they manage security is still in alignment with us. And I also think another approach, there are software tools available that can do some of that monitoring. And even in cases where there's not one strategy I found fairly effective is to partner up with relationship owners of those third parties. So think about this. You have industry frameworks, whether it's cis, nist, cybersecurity framework, these frameworks cover areas of security awareness and if you look inside of those, it talks about ensuring that your employee base knows how to report events. So traditionally I think we think of security events, at least on the front lines with, with non technical folks and non security folks that an event would be, hey, I've got a pop up on my computer that doesn't look good. Let me call security or call it whatever the case is. But think about it from a third party perspective. If you can now build some rapport with those relationship owners and they now know, hey, a vendor I'm responsible for, they had this incident, it showed up in the news, now they know to report that. And that's one way to lean into some of the education and some of the relationship building that security leaders have to do inside the organization. And then the other item around tools to monitor is just enabling Google alerts for things that do hit the mainstream media.

B (13:31)

That's a great point. And I love the word that you used a little while ago, which is maturity, like assessing the maturity of those vendors because you know, if they're, if they're mature and another word you use, relationship and the relationship is strong that, that they're going to be working as hard as you would be inside of their organization. But I know, and I've got to ask you about this. Sometimes you have those vendors that might be critical to the business, but they're resistant to, to either stronger security requirements or to some of the questions that may come in from you as a customer. Any advice on how to handle those kinds of suppliers or those kinds of third parties?

A (14:22)

Yeah. So I think as security leaders part of our responsibility is to effectively communicate risk. So the way I look at it, as a security leader, I don't want to be the one responsible making that final decision that you know, this vendor is either appropriate or not for the organization. Therefore as a security leader, I would take the information I'm receiving or not receiving, bundle that up and either that goes to say a governing body within the organization, maybe for an organization that happens to be the board, whoever that governing body, or maybe it's a specific executive that's responsible for an area of third party. But security leaders should be communicating that risk effectively, making the decision in the right place, and then lastly, making sure that's documented. Because the reality is a year later, a decision could be made now to not partner with a vendor, or maybe it's okay to partner with a vendor, but a year later someone says, wait a second, why didn't we do this? Here's all this risk. Well, now the business can go back retroactively and say, well, look at those minutes from this particular meeting. Those minutes show why we made the decision and we accepted the risk and we move forward. Another possibility, and this is easier said than done, but there may be cases where you just don't partner with a vendor, or if it's an existing vendor and you're continuing to mature process, you may have to drop that vendor. And it's again, it's not about a third party being bad or not good per se. It's about ensuring that they're aligned with the organization's maturity level. And again, that decision really needs to be made by the appropriate governing body or resources in the organization. That also, as a security leader, helps build some credibility again about the relationships. It helps strengthen that relationship so that another year or two later when as a security leader we go back to those governing bodies, a, we're able to communicate effectively, but baby, we've got a little bit of rapport and it makes solving other security challenges better down the road.

B (16:27)

And let's say you've got this mix of third party providers, you've done your diligence. In some cases you've gotten a risk signed off where you need to. How do you think about the tools that are out there for things like continuous monitoring or processes like the attestations that they make and validating those attestations or audits, where do those things add the most value and where do you think that they fall short?

A (16:59)

Yeah, so I think when it comes to the tools specifically, I've seen some of the monitoring tools that will give ratings for organizations. In one instance, I saw a case where the area of system patching was rated poorly for an organization, but the surface that they were looking at was a very small picture to the overall patching of that organization. And so I think sometimes that data can be a little bit misleading. But on the other hand, you know, if a company wants to deliver a service to another company, they also know that company should recognize, all right, we need to make sure that these external tools they need to see us as being rated well so that, you know, potential customers will partner with this. So some of this is more business like. It's not about, you know, are we at A in patching or an F in patching? It's about that overall maturation. And a company downstream, you know, may say, hey, let me, let me pay for this assessment. And look at the external attack surface. And having those higher ratings can certainly help a business do more business. When it comes to the attestations, again, it's more about maturity, not each individual control. I've seen on social media, LinkedIn especially. I'll see folks have a lot of feedback surrounding some of the big names of audits that are done in organizations and their strong opinions where they're, they're not valuable or they are valuable. And I'll, I'll use SOC reports as an example. Soccer ports really do give a, an overall picture. They help show some of that maturity. And then as an organization, you know, if I'm a security leader in that organization, I can look at that and say, all right, these are the controls that, given the type of relationship we have with the vendor, we need to know that these controls are healthy. And if we suspect that, you know, maybe the audit isn't quite as strong as it, as it should be to align with our risk appetite, then maybe we need to ask further questions. But I think, you know, sometimes the tools and the attestations can be a little bit weak. Specific to attestations. I know a lot of times companies will say things like we have encryption at rest, or we have this list of controls, but if an independent party isn't validating that, you know, an organization really doesn't have a way to verify those controls exist. And so I think it's a, it's a, it's a bit of a balance and it's a bit of a, you know, organizations looking at the audit reports, the attestations available, and then determining does it align with the organization's risk, which if vendor tiers and requirements have all been built in a program or a policy and it's consistent, then you should be able to take whatever due diligence available from the vendor and line that up to determine whether or not they're an appropriate partner.

B (19:55)

I also wanted to ask you about planning and the future. You know, often security professionals are put into this role of having to prepare for things that maybe aren't even happening yet, especially when it comes to regulation. I'll give you an example. We had a huge number of Submissions that came in for 2026 that were around Dora, and it was submissions from US cybersecurity professionals dealing with a European act. But they're already thinking about am I a service provider to a financial services company that may exist in Europe? So they're trying to sort of plan ahead. I'm just wondering what's on your mind, like what trends are emerging regulations around third party risks do you think CISO should be preparing for now, just in broad strokes, things you're thinking about in broad context?

A (20:56)

I think for us in the financial sector, there are specific regulations that may be different with financial here in the US versus those who may have customers over in the European side. And so I think it's important for security leaders to know where are their customer bases, where are they planning to be, and then really learning some of those regulations. I'll, I'll use the financial sector for us. I know that one of the things that seems to come up in a lot of conversations is, you know, fourth party. And I'm hearing more of that as I talk with folks who have been around who are in other financial institutions. And so one of the things in the back of my mind is, you know, at what point are we going to need to do further due diligence on those, those subservice organizations? Maybe that is the bigger partners, those cloud providers. I know AI is the word used in a lot of security conversations and has been for a while. And so another thing that I think may need to be considered is the usage of AI. If you have AI that processes data or manages data, it outputs information used in the business, are there models or are there any type of assessments that need to be done to show that that data is being transformed and outputted appropriately makes sense.

B (22:20)

And I think that's a great one actually for people to keep in their minds. Even if there's not something codified yet, it's likely at some point there will be. And this brings me to maybe a higher level question. How should security leaders engage boards and executives in understanding third party risk? And I ask you this because I've seen so many presentations to the board or to somebody that it could be the cfo, for example, that's on a risk committee and they're just loaded with technical details and, you know, it's almost like they're encrypted, right? The person can't relate to it or understand it. Any advice that you would give on communicating this third party risk topic without just overwhelming somebody that's non technical or not in security.

A (23:18)

Yeah. So one of the takeaways I had even from RSAC this year was to communicate really three things, financial, legal and time. How does it affect those three? And you know, I think it's important again as security leaders, it's important that we know how to communicate and translate effectively. And having sat in a number of boardrooms or different governing bodies, you know, I try and cascade things in a way that lines up with one of those three. Are there legal risks to the organization if we, you know, don't do certain things or if we do certain things under the third party umbrella? If there are, those are the things that in this case the board really cares about, you know. And so I think it's, it's mission critical to be able to translate, you know, what is the financial risk? Let's say a critical vendor, say a vendor that's critical to operations for your organization goes under or the service they deliver fails, what is the financial impact? And if you can find a way to quantify that, and you say that impact is going to cost us $100,000 if it's out for 24 hours and it's a little bit subjective, but if you can find a way to convey some of that, that goes a long way with groups like the board or governing bodies where they don't want in the weeds of all the day to

B (24:40)

day security speak in the language of finance basically, or along those three parameters that you mentioned because at least it translates and is universal to somebody in governance. Yeah, I love that. And a last question for you. If you had to give one piece of advice to CISOs that are either building or strengthening their third party risk programs, what would it be?

A (25:07)

I'll go back to that consistency and it seems very fundamental. But what I found personally is, you know, I've tried to mature different areas of third party risk and what I find is I start to bite off more than I can chew. But when I think about maturity, you know, maturing that third party risk when it comes to information security and I think about being consistent in the way I mature, I'm finding that, you know, it's being delivered upon a lot better. And you know, another piece to that consistency is building a framework. And I say build a framework leveraging an existing industry framework, whether that's, you know, NIST cybersecurity framework or CIS framework, leveraging one of those and maybe incorporating that into a due diligence document. So when it comes to consistency, maybe there are the same 10 to 15 key things that are being sought after during a review if you could find a way to incorporate those with whatever industry framework is being used for the organization now. Your third party risk is aligned with what the organization is already using, and it makes your own maturity a lot easier as you continue to grow as an organization.

B (26:17)

That's great advice. Tj. Thank you so much for being here today and listeners. Thank you for tuning in. Please keep the conversation going and our RSAC membership platform by visiting onersac.commembership and be sure to check onersac.com for new content posted year round. TJ, I can't tell you how much I appreciate it. Love this discussion.