BSidesSF 2025 - Third-party Risk Management: SOC 2s, Security Questionnaires... (Eleanor Mount)

Good afternoon everyone. Thanks so much for being here. Uh we're excited to present a talk by Eleanor Mount third party risk management sock 2's security questionnaires and psychosis. For the slido, please reference either the QR code or besides.orgq&a org/q& selecting theater 9. All right. Can everyone hear me? All right. Welcome to thirdparty risk management sock 2 security questionnaires and psychosis. I'm Eleanor. Um, first time speaker. So excited to be here. Quick poll. How many people here support like a GRC function? Okay. Security engineering. any legal couple. Okay. Anyone else that's just like here for a good time? Okay, great. Uh well, yeah, just a little bit about me. Um I am a GRC professional. I'm based here in San

Francisco. Currently a security risk and compliance manager at ASA. Um obviously quick disclaimer that opinions are mine. This is not legal advice or anything. Um but happy to be representing GRC at Bides this year. So enough about me. Um, we are actually going to start by talking about Sonia Morgan. So, Sonia Morgan is most famously known for being a cast member of The Real Housewives of New York City. Um, her surname Morgan comes from her ex-husband who was in heir to the JP Morgan Chase throne. And there's kind of sort of this running joke on the show where Sonia has a lot of people that work for her. There's a lot of people that are on her payroll,

but like no one really knows who they are or what they do. Um, so for example, she has a facialist that she keeps on her payroll. Um, she has a lot of interns that kind of circle in and out very frequently. Um, here's some more interns. There's her psychic who is also on her payroll. Uh, Montgomery Frasier, her image guru. But like, what is Sonia? Why is she paying all of these people? She's an international fashion lifestyle brand. She's an artist. Like, what's going on? Um, unfortunately having this many people on her payroll does not end well for Sonia and she files bankruptcy chapter 11. Um, because she has so many interns. So kind of the lesson and the

takeaway here is that maybe if Sonia had some sort of thirdparty risk management, she would not have duplicative people that do the same thing. So with that, we're going to start by grounding in reality together. I'm going to talk about what thirdparty risk management is super briefly, why it's a good practice, and some industry drivers that keep it so ingrained in so many businesses today. Um, so quickly to define this, it is understanding and managing risks associated with vendors and other third parties with which a company does business or shares data. And you'll typically see people talk about thirdparty risk management as a cycle. So, it's not something that's a point in time assessment. It's not

something that ends. You start with procurement. You do a vendor assessment. There's a contract negotiation of some sort typically involved. And then there's ongoing continuous monitoring of all the third parties you work with. And effective thirdparty risk management programs do provide a lot of benefits. So the first one going back to Sonia Morgan would be cost savings. Um every company's trying to save money right now and third party risk management helps you reduce duplicative tools that might just do the same thing. The second thing is having a consistent approach. So if you have a consistent approach to contracting and vendor management, you treat all of your vendors the same. Um you then are more flexible as an organization. So let's

say you need to add new regulatory framework. I want to have a HIPPA compliant product. Um it's very easy then if you have standard contracts and have a list of vendors you work with to know who you're sharing data with, what I want to do, and how I'm going to do that. Um the other benefit of thirdparty risk management is operating efficiency. So, with every vendor you add, there's a trade-off between functionality and risk. And usually the benefits outweigh the potential negatives. So, one example is if you're collecting payment information, you probably don't want to do that yourself. You're going to add a vendor like Stripe to collect credit card information for you. Um, or if

you've seen Silicon Valley, there's a great example in there where they end up building their own data center. not something that everyone wants to do, but if you decide that's a core business function, you can keep that in-house or you can outsource it to a thirdparty vendor. All right. And I would be remiss not to talk about industry drivers of thirdparty risk management. Um, I talk about this last because I am of the belief that third-party risk management provides benefits besides just like legal requirements and something you have to do. Um, so the first one would be supply chain attacks. I apologize if you work at any of these companies, but these are examples of companies who had

a security incident that was caused through a third party. Um, and then you know having these regulators are now demanding an increased focus on how organizations are monitoring their third parties they work with. The second industry driver would be regulatory requirements. Um, there's a bunch here. Some are industry specific, some are self-imposed, some are regional, but these all have some sort of third-party risk management requirement. And the third one would be customer requirements. So, if you're a B2B organization, you might have a bank you work with or you might be trying to sell to the government. Again, HIPPA, if you're selling to a hospital or something or working with them or collecting PHI, you are required to meet

certain requirements. All right. So, now we're going to get into the fun part, which is the bad and the ugly. And there's a lot of self-imposed problems in the third party risk management space. The problems are related, but I think they're pretty distinct, and they make it difficult to actually realize the benefits of good third party risk management. So, time to kick off a third party vendor review. Um, you're going to have to get some documents from them. You're typically going to have to exchange that in some way. You kind of expect that to be straightforward, but what really ends up happening is it takes a lot of time and energy and you have this back and

forth with the vendor where you don't really know if you're getting what you need. So, you typically request documentation. There's some sort of NDA. You review it. Oh, it's not what I need. You gave me your sock 3, not my sock two. Um, everyone who's tried to onboard a vendor at their company probably can relate to procurement processes just being very lengthy and difficult to deal with. And this can end up causing reputational issues with stakeholders you work with because you're trying to get what you need, but it's just so slow because the vendor is not responding to you. You're not getting what you need. Um, and people don't necessarily agree in the industry on what documentation is

transparent or useful. So this information exchange just ends up taking way too long and then you don't even really feel like you have what you need to make a good decision on onboarding a vendor and an entire industry now exists based on all of our failures to share information. So security profiles and trust centers are one good example of where people are making their documentation more public more available. There's also things like compliance as a service. So like the Vantas, Dradas of the world where they are showing continuous monitoring of controls. Um fully outsourcing thirdparty risk management. So working with a company where they're just doing all of that for you. Um typically there's like no discernment and it's

very checkboxy. So it can take even more time, can be hard to get engagement from your suppliers, too. Um, and then also there's now tools like security scanners that scan a bunch of IP addresses that you might not even own and then give you a arbitrary score that's like A throughF and most of the time you're probably failing. So overall, these are not really getting people what they need. Um the second problem, so from the point of view of someone being assessed, you might get a security questionnaire and the questions you'll get on these really range highly, but they're kind of asking the same thing, just phrased a little bit differently, or they're asking like

absolutely nothing about your security posture. So these are some hypothetical questions that um I may have gotten working at a SAS company. Um, and if you kind of read them, you can probably guess this is not super useful for someone using a service that they access over the internet. So, you're answering these and you're like, "What is this telling you about my actual security posture? How are you going to sort through this mess?" Um, it's not really helpful and it's just a bunch of security theater where like people are pointing fingers at each other and not sure what to do. Um the second problem with information you're getting is that what you do finally get is sometimes not even

reliable. So a lot of people a hot talking point on social media I've seen recently is that audit reports are kind of playing grounds like the sock 2 is becoming commoditized and if you don't know much about the history of these reports um there are a lot of different assessors now that can issue sock twos people are giving ones for just a month so it's almost a point in time assessment instead of a full year. Um, so there's not much that they're actually telling you and it's hard to know what you can actually trust when you're getting these reports. And this means as a company being assessed, you're constantly asked for more. So people want to do on-site audits. People

want to go and get actual evidence that you're implementing controls because they don't even trust your auditor. So you're just ask for more with low return. It's very time inensive. Um, and overall you're just not even sure if you're getting reliable information. The third problem is that demonstrating trust is very misleading. Um, I think that trust has to be earned, but people are demonstrating it based on what they think is trustworthy, not what you need as an assessor. Um, so again, if you've worked in this for a while, you might have someone tell you, "Well, I used this at my last company, so we should just be able to use this now." Um, every single company's different.

Every company's risk tolerance is different, and that's not really a good way to make a determination if you should share data with a vendor. Um, another way that people demonstrate trust is something I call information overload, where they share literally everything with you in attempts to be very transparent, but getting like 27 policies and trying to read through them is not necessarily going to be useful. Um, I have a quick story time about what I call vendor gaslighting, which is being told something's normal from a vendor when you know it's not. Um, we were onboarding a vendor. I asked for their sock 2 report. They told me that that was extremely abnormal. The sock 3

has always been fine. Um, no one's ever asked for it and it was really crazy. Um, after some back and forth, we did end up getting the report and it was indeed a qualified report and it disclosed a pretty serious security incident on the first page. So, that led me to believe that they did not actually want us to read this and after that I will never be gas lit again. Um, the fourth problem is all of these dirty contracting tricks. So sometimes a company will come to you and they'll be like, "Well, I've passed the security review at this bank, so you should just Why is it taking so long to get through your process?" Um, I

actually think this traces back to something called marketing rights, which if you're not familiar with these, it is where a company will um ask for the right to list you on their website. So, they'll say, "This company uses us and it's trusted by all of these people." Um, quick story time. I was working and my company was listed on a vendor's website showing that we endorse them. Someone else reached out to our CISO and said, "Hey, you're on this website endorsing this company, but we were doing a security review. We didn't really think they were trustworthy. Like, how did you handle this?" And we didn't even know we were using them. It was actually just a bunch

of people owing click-through agreements. We'd probably used it for years and had no idea. But because there were marketing rights and whatever click-through agreement someone agreed to years ago, we were listed on their website. So, we did get taken off. But overall, when you see logos, it's not necessarily something you should trust. Um, audit rights, too. So, you generally want to be able to audit a company once a year or after a security incident, but security incidents can have different definitions. So, that's not even something you're always prepared to defend against. Um, I've had a vendor once referenced terms in their standard contract, but our contract was different than their standard. So, it's always good to just check the contract because

there's a bunch of dirty tricks people can play. All right. So, that all being said, what can you actually do? So, we've talked about the ugly parts of this. How do you actually sort through this mess? How do you take ownership? Not just going to complain without giving you solutions. Um, the first thing I would recommend is embedding thirdparty risk management in other business processes and then making your assessment a starting point for other ones. So, typically you'll have some procurement thing that kicks off with budgeting. um thirdparty risk management should be deeply embedded in that and any risk space monitoring you're going to do and then you can also make it a jumping off point for other

internal processes. So if you're integrating things with octa, if you have a security design review, data mapping, this can solve the problem of thirdparty risk management being its own separate process where people get angry, they don't know they have to do an assessment. Just have it embedded in these and you'll be much more effective in the long term. The second thing you can do is track and share metrics to drive continuous improvement. So you can't manage what you're not measuring. And if you're able to build a good reputation internally, I found you can influence stakeholders to come to you early on in their evaluation process. So you can help set the direction they want to go

with a vendor. Um, a common issue I think we've all heard is that your security review is taking so long. Going back to the information exchange taking a long time. So what I found useful is track metrics about what exactly in the process is taking so long and be transparent. Regularly report on them. So it might be that you're waiting for information from a vendor for like 6 weeks every single time and it's not you ignoring it and not doing the work. Um but be transparent, track and share these metrics and you'll be able to continuously improve. Also holds everyone accountable and you can share what you're learning about the business. You can learn a lot about priorities

from vendor procurement too. The third thing I would recommend is determining your own risk tolerance and sticking with it. So, this is going to be different at every single company, every single business. It might even be different depending on the vendor you're working with. So, start with zero trust and really ask yourself, what do I absolutely need to know is in place to share data with this company or vendor. Um, I'd recommend having a set of defined requirements and then having some sort of exceptions or risk acceptance process when vendors may not meet these so you can follow that if things happen. And again, look out for red flags here. So, document overload. Are you being gaslit? Is someone saying,

"I've used this before. My company has millions of users. Why do you have to do this review?" Like, really stick to your own risk tolerance here because remember marketing rights, you can't always trust that companies are actually trusting people. Um, the fourth thing I would recommend is just being discerning with the information you receive. So you've established your risk tolerance, you have your requirements based on what you need to have. How does this third party meet these requirements? And it's 2025. I have to mention AI. I've actually found AI um a good way to use this process. So have it review documents, say, okay, does this meet my 10 criteria? What's your initial opinion? Um and don't send questionnaires if you

don't have to. Then you can look at their public resources. Again, be cautious of information overload. Um, the fifth thing I would recommend is creative contracting approaches. So, there's a bunch of different ways you can do this. Um, and this kind of lifts off some of the need to validate that a lot of controls are in place because a third party is able to contractually agree to the requirements you have. So the first one is just having a generic security addendum, having a list of broad requirements that can apply to most if not all third parties. And this should meet what you would yourself commit to as a company. Um, some examples of this, there's the MVSP, which is publicly

available. It's a list of very minimum viable secure product requirements. You can take that or put it into a contract of some kind. Um, and most SAS companies might have a like vendor security addendum online you can read for inspiration. The second one is situation specific security addendums. So maybe you have a different one for contractors, for contractors that are using a laptop, for AI services. This can be based on like access to data. You can make different ones for higher risk vendors um or even the services that they're providing. And the third one, which is a little bit more creative, is contract based risk transfer or reduction. So let's say a third party is responsible for enabling

a specific feature. you can actually work, you have to do a little bit of like wiggle room. So, this is very context specific, but if you have a customer take on some responsibility for enabling these features with the third party, um that can transfer some of the risk away from you as the organization. And if you're like, Eleanor, I work at a 10erson startup. I have no leverage at all. Like, I don't have a lawyer I can work with. Um, I would just identify what your ideal contractual requirements are and track them across vendors in some way. So again, you can use AI to try to read through these things, but that's a way you can transfer some risk

here. So that's pretty much it. In conclusion, don't let vendors pull your leg. Start with zero trust. Devel You can laugh. It's funny. Yeah. Develop your own risk tolerance. Don't fall for distasteful tactics. So information overload. Don't be gaslit. Um review contracts and terms of service. This is something you can apply in your everyday personal life too. Like I have friends that are planning weddings and they might want to read contracts to look for marketing rights so that their pictures aren't plastered everywhere. Um take ownership over your program and remember we're all responsible for making this space better. So don't send questionnaires if you don't have to. That's it. So thank you. Um you can connect with me on

LinkedIn. It's just my name. It's also linked in my speaker bio. Um, I'm accepting questions, comments, concerns, compliments, mostly compliments today. Okay. Okay. I will read some questions. Uh, what kind of metrics do you recommend to track? I recommend tracking time in certain phases if you can. Um, you can also track like number of high-risk vendors, what kind of requirements they're agreeing to, um, if they've agreed to your security agenda, if they've agreed to one with like edits. So, those kind of metrics I think are useful to track. Um, let's see what else. Do you feel that TPRM can and should make the go no decision for the business? ground your response using an example from

Vanderpump rules. Love that. Um I think you can serve as guardrails but not gatekeepers. So you can inform the business, okay, here's the decision that I would make. Here are the risks that you are taking on through onboarding this vendor. Um and sometimes that's going to be like a hard no, but sometimes it might be a business riskbased decision. So it depends. I do feel like TPRM should influence them strongly and they should trust you because that's your job. But sometimes you have to make trade-offs in a business. Um, let's see. Any tips on handling thirdparty incidents? We currently address those like we were breached in terms of time spent. This doesn't make much sense. Um, I think

this is something you'd want to look at the contract with the third party to handle. Um, so it's going to again be really situation specific, but probably end up doing some sort of assessment with the vendor. the business might trust you a little bit more if you didn't like them in the first place and then they had an incident. Um, let's see. What are the differences between the default legal approach and the ideal legal road map for vendor risk mitigation? I have to read that question a couple times. Um, I would say this is probably a contract question. Go security theater thumbs up. What's your solution for understanding what's each vendor access to my systems? This is the biggest pain

point for us. Um, that's something you'll want to do in the initial assessment. So, the vendor might have like online documentation about how they're going to access your systems. Um, but that's something you'll want to get in the initial intake working with the business owner to determine how they're going to integrate with your systems. How can you track the business use of a vendor over time? During initial assessment, their scope was X. One year later, it's XYZ. Do you have to wait for the annual reassessment for figuring that out? Um, great question. And this happens a lot. So, I would work with your business stakeholders and make sure you have a process for scope increase,

um, reassessment, and make it very clear that if you're sharing new data or using a vendor in a different way, you do have to do a reassessment. Um, who's my favorite housewife? I love New York City. If y'all didn't notice the theme, that was my theme. Um, let's see. How do you manage ongoing vendor reassessments such as implementing new risky AI features? Um, again, I think we kind of touched on that a little bit, but just making it very clear with your business stakeholders that if there's changes to scope, um, we have some like checks and balances. So, for example, if folks want to add a new integration with a third party tool, there's like additional

verification with the security team that that integration's been reviewed. Um, what vendor do I hate the most is the most thumbmed up question.

You can talk to me after and I'll tell you. Um, how would you approach business units who want security analysts to assess the security risk of a supplier's contract language? Um, I think that's a great opportunity to work with a business unit if they're asking for your opinion of the supplers's contract language. Again, work with a lawyer or someone that can actually read the contract. Um, but it sounds like a good opportunity to work with them and give your opinion. How do you go about backdating vendors you've already been using and getting them to fill out third-party risk assessments after you have a contract in place? Great question. Um, I try to leverage like public facing

resources as much as possible because again, we don't want to be sending questionnaires if we don't need to. Um, but just trying to leverage public things as much as possible. And then if you can't, you can still do like a retroactive review. Um maybe there's a contract renewal coming up or some sort of like leverage you can take there. Um but that's a great question. Do you audit your vendors and third parties? If so, how? Yes, we do. Um what are your tools? Sorry, what are your thoughts on fully using AI to assess thirdparty vendors? for example, feeding all the reports into an AI system to generate a risk assessment and using AI to respond to security

questionnaires. I think this is kind of just the direction that the world is going. Um, so I've found it useful to have AI do like an initial assessment of documentation and then make sure there's a human in the loop to actually review all of that. Um, but just for like reading through all of the information overload, responding to security questionnaires, it's very useful. What's your opinion of using Genai for processing attachments for vital events? I feel like I just answered that. Um let's see. What tools do I recommend for security posture ratings of third parties? Um, I have used a sauna actually and it's worked great. It's not a plug I knew worked there, but we have

used that. Um, I've used Wistic before too and that was useful. Um, but really this is going to depend on the business. I think whatever will help you get the most engagement with your stakeholders is going to be the best answer. So if no one wants to log into this random new tool, it's probably not going to work. Try to leverage things that are already in place and then track them in a way that's useful for your team. My favorite LLM to help with reviews, um, I have used the LLM features in Auna. Again, this is just what I've used, not a plug. um but they are chatgpt and claude. How do you understand the

environments if you don't obtain questionnaires? You can read a system description in a sock 2 report or something like that. You can read public documentation from a vendor. Um if there's like an integration or some sort of setup, try to talk to the team that you're working with that's onboarding them and understand how they plan to use them. Um, a questioner is just like a different way to gather that information, right? So, whatever works for you best. Isn't using Genai a violation of vendor NDAs?

Depends. Any more questions?

All right. Thank you. Thank you so much, Ellanar.