Trust Your Vendors, Do You?

Key Takeaways

Morning, good afternoon, good evening for everybody and welcome to the webcast Trust your vendors do you. Now, before we jump into it, allow me to first do a small introduction about who I am and what we will be covering today. So, who am I? Well, I'm Jan. I'm Jan De Ridder, born and raised in Belgium, uh Europe, and I have worked for over 20 years in information / cybersecurity. I always refer to information security because when I started, uh there was no such thing as cybersecurity. Um it was it was just not a thing. Um and so we started in information security back then. Uh in the meantime, I have worked for several large uh companies in a variety of security roles ranging from security consultant to then uh cybersecurity manager to enterprise security or security architect, uh and then eventually ending up as a CISO. Uh currently, I'm working as a consultant and uh a management consultant and enterprise security architect focusing on uh transformation projects, helping increase maturity at organizations. What exactly that entails is for another time and another discussion, but feel free to reach out to me to talk about this. Uh you can find my contact details in the bottom or at the bottom of the slide. Uh so, please feel free to reach out to me if you have any questions as well later on so on. Um I believe I'm also a continuous learner. Uh I actually think this is mandatory for everybody working in cybersecurity or information security. So, I hope you're all will learn something today as well. Uh that's why we are here, of course. I'm also a certified instructor at SANS, and currently, I am teaching LDR 512 Security Leadership Essentials and also SEC 566, which is the CIS Controls. Um being from Belgium, I inherited or inherited, sorry, some Burgundian characteristics. In other words, I can appreciate a good drink and food, and I also like to travel. Um, still play basketball. I know it's March Madness in the US, so that's great. Sometimes, actually, I've been there two times already in March Madness. Um, I wish I could do go again, but unfortunately, I can't go this year. Um, also, I promised my wife it's my last year playing active basketball. Uh, so, um, yeah. Uh, that's also a good thing, I think, for myself and for my body. Um, on the other side, I also like Star Wars, um, which would probably explain the title I selected for this webcast. So, in my classes, I have a guarantee and a promise, that is, I always try to squeeze in few Star War references. Um, on the slide, I also mentioned that I have a special ability. Uh, to be more precise, my last name has a special ability, and it is my last name when entered in certain forms, websites, uh, can act as a SQL injection because I have a little apostrophe in my last name. I can tell you, this is the worst thing ever because I have broken so many, uh, let's say, registration sheets, uh, you cannot imagine. Um, if people print my names on badges in an automated fashion and so on, uh, sometimes you do not want to know what comes out of it. So, I'm basically an equal injection, at least my last name is. All right. So, what will we cover today? Um, presentation will set the stage for a discussion, I think, that we need to have on third-party risk management in cybersecurity. It will be a journey from, or I hope it will be a journey, that we uh, that I create some awareness, and that that eventually will result in some actions, uh, covering why vendor risks matter, and what are some of the current practices we do today, what some of the real world breaches, uh, that have be had that have been seen or have have experienced and then also some limitations of our current practices. So, what are some shortcomings of those? Uh eventually then we'll end up with some recommended improvements and some key takeaways. And something which I like to call the start to TPRM program. Um now, the goal is to emphasize the importance of rethinking how our organizations assess and manage vendor relationships in of course an increasingly interconnected digital landscape which we are in today. First things first. Why do we care about third-party risks? Well, we care because modern and uh let's say most of our enterprises rely on a vast network of third-party vendors. Uh with some organizations engaging even over 1,000 external partners if not more, right? So, we're all engaging with all external partners. This creates an extensive ecosystem that significantly expands our attack surface, making it imperative to understand and manage associated risks. According to data available on Gitlab, for example, and the TPRM impact report from Whistic, for the third straight year, security incidents are on the rise. In 2023, the number of organizations that reported a security breach during a 3-year period was 55%. If we do that same thing today, that number is already 70%. So, third-party vulnerabilities are a major culprit in security incidents. Over the past 3 years, 77% of those security breaches originated with a vendor or third party or was related to third party, in other words. Um so, a lot of our organizations have experienced a security incident involving third-party vendors, highlighting the prevalence and severity of these threats. Each vendor introduces potential vulnerabilities, and without proper oversight, these can be exploited by malicious actors to gain unauthorized access to sensitive systems and data. And it's not stopping. We are doing less ourselves and focusing more on our core business more mainly, but we're doing more with someone else. Vendor ecosystems also continue to grow. Uh, so in a nutshell, we have this expanding attack surface uh due to vendor growth, vendor sprawl, and also the vendor ecosystems, which just expand and grow. So, is it time to act? Well, I guess so, but are we really sure yet? Well, perhaps we're not fully convinced yet. Let's take a look at some real-world breaches. So, we might not be fully convinced yet. Um, so if there's one thing we should do, is that we should learn from others' mistakes. I worked in an organization where we had a saying, "Never waste a good incident." Learn from it, and let's pretend it from uh and let's prevent it from reoccurring. So, we know about some cases. Uh, well, why not learn from them, right? So, Armor Race, it's another company uh working in the third-party risk management space, they also did a research and uh and the link will be shared by Hayes uh in the chat. Um, this um company um has done this study and mentions that several high-profile breaches in 2026 underscore the dangers of inadequate third-party risk management. For example, UBS and China IQ Group AG suffered a breach exposing 130,000 employee records due to a compromised procurement vendor. Quanta was in the news. They experienced a breach in its offshore call center platform affecting over 6 million customer records. Kellogg's, Adidas were impacted by vulnerabilities in the Cleo file transfer platform, which then affected 66 companies as a result. Now, these incidents they demonstrate that even well-established organizations or were and and large organizations are because just the one that I named or very large organizations, they can and are vulnerable when vendor security is not let's say properly assessed potentially or monitored properly. Um the financial, operational, and reputational damage fallout that these breaches can can cause highlights the urgent need for, let's say, improving our vendor oversight and we'll do a better um management on top of this. Hm. Now, SecurityScorecard another vendor in the third-party security in the in the third-party uh security management space. Um They also have created a report. Again, H will share this report. Um in 2025, this report reveals that 35.5% of breaches they have analyzed are third-party related with an average remediation cost of 4.8 million per incident. Again, in the report itself, you can read all of the details which you want. Now, additionally, 41% of ransomware attacks now originate through third-party vectors, which is a bit scary, right? Because we trust our vendors and we give them access to a lot of our environment. And we give them access to data. We give them access to all kinds of things. Now, we also have something called regulatory frameworks. Um in Europe, uh I'm from Europe, so I know them quite well. We have GDPR, NIS 2, and Dora. I'll touch upon them later, but in an what you need to know is that, hey, it imposed strict requirements on organizations to manage manage vendor risks, uh including mandatory incident reporting and supply chain security evaluation. And the latter is what I want to highlight here. Non-compliance can then result in fines, potential fines even, and also reputational damage, of course. Um and then eventually that's also going to result in some financial impact. All of this is making, say, third-party risk management and a robust third uh robust third-party risk management not just best practice uh best practice, sorry, but a legal necessity going forward for our organizations. We need to do it because we want to stay in business. Right? We don't want to not be in business. We don't want to have those financials uh financial penalties and so on. Well, let's take a look at a notorious example, SolarWinds. SolarWinds 2020, um let's focus on the attack first. A nation-state hacker or nation-state hackers injected some malicious code into legitimate software and into a legitimate software update from SolarWinds Orion IT monitoring platform. The victim organizations, so the victims, hey, that use this software, they download this update because it's a legitimate update from SolarWinds. And as a result, they deployed this malicious code into their environment. That malicious code could potentially allow the attackers access to their I always say could potentially because could have been some other compensating controls in place, but nonetheless, malicious code was deployed on their system or is deployed by just updating the software to the latest version or with the latest patch. What you don't know is that inside that of course, there is a malicious code. Or eventually some some bad things going on. This is what we call a software supply chain attack. And because the malicious code was injected in the software from SolarWinds, um eventually this particular uh actually impacted a huge amount of customers of SolarWinds, of course. And because it's the SolarWinds update, so everybody's going to patch, right? Because that's what we as security people are telling everybody, "Update. Update. Patch. Make sure you're on the latest version. Apply this." So, we all downloaded these patches, and as a result, yeah, we were exposed. Um so, a lot of Fortune 500 companies were impacted. Some federal agencies, not only US agencies, but worldwide agencies, other country agencies were impacted, as well. So, what can we learn from this? Well, that no vendor is too big to fail, right? Every vendor can have an issue like this potentially. And perhaps we should look more into our updates and patches. Um and we should monitor the environment a little bit, perhaps, right? To see or to detect in case we see some abnormal behavior. Even though it might be an application where we have no control over, where we haven't written anything for, doesn't mean we don't need to monitor the application, right? It doesn't mean we need to not pay attention to what is going on. Let's take a look at another one. Kaseya, VSA. Tool used by uh MSPs, so managed service providers. And um again, let's start with the attack, and let's see what actually happened. Uh the REvil ransomware gang exploited a zero-day vulnerability in the Kaseya VSA. Uh Kaseya VSA is a tool used to remotely manage um client networks for from the MSP, so that's hundreds of potential clients. The tool is used by multiple MSPs and an MSP works has legitimate access to client networks because they need to manage network, they need to manage the environment, they need to manage the application, all this kind of right? And because they use this tool, that also means that the attackers of this tool had access to the uh environment of those customers. So, the attacker always focused on attacking one vendor and one specific tool. And the uh because they uh managed service providers have high-level permissions uh on multiple client environments, now the result the attackers only had to compromise this one item in the case because IFSA. As a result, now they have access to a whole lot of environments. Again, what can we learn from this? Well, vendors with high privileges and remote access to your network should probably be looked at as a critical vendor, right? Uh because they have access and we probably should maintain a high level of security uh which you as a company want to verify. So, we want to make sure that MSSP has a high standard when it comes to security. Um also, we probably want to look at the access controls and we want to limit the access that they have into our slash your environment. So, is it now time to act? I would say, yeah, probably yes. How can I convince you more? Well, regulatory alignment. We have regulations. We have a lot of regulations that are upcoming or that are already in place. So, this DORA and GDPR, I already mentioned it. Those three are the big ones, especially in Europe. Some of these frameworks uh require a robust third-party management practices. NIST 2, for example, NIST stands for network and information systems. Um, this uh regulation uh raises the European common level of ambition on cybersecurity to a wider scope, new rules, stronger supervision tools. It requires member states, so European countries, to enhance their cybersecurity capabilities by introducing them risk measures, reporting requirements to entities from all sectors, and setting up rules for cooperation, information sharing, so on and so on and so on. NIST 2 specifically emphasizes supply chain security, incident reporting, and vendor compliance across critical sectors. Critical sectors, think of finance, think of energy, something like this in the critical sector. Now, we also have DORA, DORA or the Digital Operational Resilience Act. It's a EU regulation establishing uniform digital operational resilience and cybersecurity requirements for financial entities and ICT third party providers. Effective, by the way, from January 17, 2025. It requires financial institutions to implement ICT, uh information communication technology, risk management frameworks, and conduct resilience testing, and maintain business continuity plans. And I will also have GDPR, or the General Data Protection Regulation. It's a comprehensive EU regulation that enhances uh data privacy rights for individuals, uh mainly in the EU, and imposes strict obligations on organizations handling personal data of citizens in the EU. Uh it holds data controllers accountability for breaches caused by vendors, necessi- necess- necessitated, sorry, uh thorough due diligence and contractual safeguards as a result. Organizations then must align their EPRM or third-party risk management programs with these regulations to avoid penalties and also to ensure operational resilience. Compliance, by the way, not just a legal obligation. It's a strategic imperative for protecting customer trust and business continuity. Can even be a differentiator for some organizations. Now, time to act. Think we can all agree that this is no longer a question. But, um you might go, "Aren't we doing this already with regards? Are we Are we doing already this all of stuff with third-party risk management?" Well, yes. Yes, we are. That's what we do today. We have been doing all of things. Um Now, more frequent, uh let's say, item that I see or that we have used is, uh questionnaires. Questionnaires are very static by nature. Um we often ask our suppliers, vendors, partners to provide feedback on questionnaires, and these are typically static questions we ask. Depending on the partners, we might ask different questions, or we might do the ping-pong game, right? We might get some reply, then we ask some more questions, and so on and so on and so on. But, in the end of the day, they're very static. They're also quite time-intensive. Um fortunately, these questionnaires often fail to reflect real-time security changes or implementations we have done in the meantime. And they are very generic by nature because you can't put nuance into it. Relying too much on these questionnaires can lead to, unfortunately, inaccurate risk assessments and a false sense of security. For example, vendor might claim in the questionnaire that they're patching on a monthly basis. While that's the case for the majority of the applications or of the systems, we might be able to see a system they are managing or that they are calling for us that has CVs open for already a certain amount of days and hasn't been. Now, again, in the questionnaire, you might not have a question, "Do you use MFA?" A vendor will reply, "Yes, we use MFA everywhere." Well, if you go and take a closer look at your environment that they are managing for you or that they have in setup for you, you might figure out that there's still some legacy admin accounts that cannot use MFA potentially. But, you didn't know about this, right? Because in the questionnaire, we say, "No, MFA is claimed everywhere." Data. Data could be encrypted at rest is what we request. Vendor might say, "Yes, perfect. We do this. No, don't worry about this." Well, that's true for the database, perhaps, but for the backup. Another issue I would be a bit worried about. Again, we won't All right. I had a glitch on the matrix, I think, but I'm back. Can you all hear me still? Hey, is it okay? Can you still hear me? Everything's good on our end. All right, perfect. Sorry. That was a glitch on the matrix, I guess. So, um where was I? Yes, encryption at rest. Also, that one not fully taken care of. SSO, single sign-on, claimed. Fine, great. What could be that we still have some local passwords. We still have some systems which are not, uh let's say, SSO'd for particular use case we have in our environment which a vendor providing for us. Um no subcontractors. They might say, "We don't use any subcontractor." But, when we do an incident, we find that for one specific item, they did use a So, again there, yeah, for the majority of cases they don't use subcontractor, but for the one specific case which we requested, ah yeah, they did use a subcontractor because it's not their core expertise, but we asked them to do it anyway. Now, the scope you purchase um might be subject to different security controls in 95% of the organization of the vendor of the third party. Now, we shouldn't share that code that we have covered by the security controls we are worried about. Also, these questionnaire processes are, like I said, time-consuming and often very burdensome. I'm not saying that they are bad. I'm just saying that they have limitation. They are often very static. Um or uh one point in time activity. Perhaps we even do a re-questionnaire every year. Even then, services that change, things change. Think about also companies providing us uh software process uh services or software as a service, platform as a service, things like this. Think about companies like potentially Amazon or Microsoft, something like this. They have constant new services being added to their catalog. You could decide to use them or not. But, will you do an assessment for every new feature or new product that you're going to use? Perhaps you will. Perhaps you won't. And what about services that change? Do you keep track of all of them? Do you know what changes are going on in the services? Some, perhaps yes, because they're big, they're huge, a new application or whatever could be. What about all the small ones? And those small ones, they might be also interesting from a security point of view. So, what I believe is that organizations must complement these questionnaires with a bit of more dynamic and real-time monitoring going forward. Again, I'm not saying these questionnaires are bad. I think we need to use them, but we need to add on top of it. Oh, but this is often where we then have issues. We often do not have the resources or means to monitor on a continuous basis. And as a result, we might be exposed to threats we were not aware of, or even worse, we might be delayed in detection. And if then actually an incident happens, um we might not be able to respond efficiently and effectively, and other damage might be done to our environment. Another issue that we often see with vendors and suppliers is especially in the BPO world, or in business process outsourcing or IT service relationships, is that these vendors have significant access to our environment. The partner could also be using a third-party supplier from them, making it a fourth-party relationship for you. And as a result, you're making a complex supply chain. And then you could also say they have a sub sub sub a sub a contractor and stuff like this, and then yeah, the ball starts rolling. So, it's making it a very complex supply chain. As a result, we have a need for integrating third-party risk management across all parts of the business. Think about items like procurement, legal, IT, compliance. All these people, that's where we want to integrate with. So, it needs to be a cross-functional uh thing function. Yeah. Um so, okay. Clearly, questionnaires alone are not enough. I hope that's clear. Um I hope I made my point already. But what else can or should we do? So, take a look at new recommendations. Um Now, by now, it should be clear that EPRM uh this is kind of a life cycle. Uh I already mentioned a few times, it's continuous. Vendors come, vendors go. Relationship with vendors change. You might take more services, less services, different services, I don't know, whatever. Um who knows what will happen in 1 year from now with a particular vendor? I don't. Um so, what do we need to do? We need to monitor them. Now, I create something called the TPRM life cycle. Um in this life cycle, we see five phases. First, we start with a planning and onboarding. In this phase, we can think of a prospect thinking of engaging with a new vendor or partner. We need to understand about how critical the service the partner will provide is for is for us. And we could argue one service is perhaps more critical compared to another service. I always use the comparison of the sandwich shop partner in the office to the payroll partner in the office. Who is more critical? I would typically argue the payroll partner, right? Unless I'm really, really hungry, especially even hangry, right? But most likely, 99% of people are going to say our payroll partner is more critical. So, in other words, what we're doing there is we're trying to differentiate our vendors. We're trying to start hearing for our vendors. The tier one being the more critical, for example, and then lower tiers being less critical for us. But this should be done based on the impact to the organization and business itself, not on the size or amount of money we are spending with a particular vendor. No, no, no, no, no, on the impact to the business. So, here you need to business sense and then business touch. Secondly, we now have the due diligence phase. This is where we typically will do our initial assessment. We will conduct questionnaire, review, and so on. Now, depending on the criticality defined in the previous step, we could argue that we need more on high tier vendors and less on lower tier vendors. Higher tier vendors might require audit or penetration testing reports or something like this, but there has to be differentiation, right? Thirdly, continuous monitoring. Our services that we are using from our vendors will change eventually. Now, servers they are the service they are providing today potentially not be done the same way in 1 year from now. Also, with the likes of AI, potentially this is the way that they are going to provide the service is going to change or will change. This means we need to look at automating monitoring of these vendors and of course also the environments that they are maintaining, managing, etc. for us. But, think about changing access management, uh lost or compromised accounts, all these kind Fourthly, remediation and reporting phase. We need to monitor issues we have found in phase two and phase three, so in the previous phases. Um and uh we need to track them. Um if we track them, we might require some corrective action plans or caps. Um this will allow us to create an overview of the residual risk, which we can then report to the business and also to senior leadership. Again, business is going to be involved in, right? Because they will be the owners of the risk. Lastly, we have the off-boarding or renewal phase. When we then decide and potentially to discontinue with a vendor or partner or when it uh or we want to continue, but let's say in the first case we want to discontinue, we need to verify that the data, for example, has been destructed, returned, etc. Um normally, this is requested by a contract or agreement. Um so, we need to conduct final check before closure of that agreement with partner, uh and all of those contractual items are delivered. That also means, of course, it needs to be part of your contractual agreements with the partners. Let's take a look at a quick example here. We have, let's say, HR software as a service that we want to purchase. We identify this as a tier one because it's critical for us, right? We need to We manage all of our human resource processes there, so it's probably a tier one or it's justified to be a very critical application for us. We plan accordingly and we know that we need to embed security as early as possible. Uh course, by the way, we always need to embed security as early as possible, but in this case, because it's a tier one, we want to pay some extra attention to it. So, we perform due diligence in the way of a questionnaire, for example, and let's say also a SOC 2 attestation. Uh we require also that, potentially even in the contract. Um that SOC 2 attestation, by the way, we want to focus that, of course, on the scope of service we are requesting. We also would like an architecture review, for example, to figure out how we are exchanging information, or what has been set up for us, uh or what what partner has set up in our environment for us specifically. Imagine that they're putting something in our cloud environment. Um we can, for example, then monitor and detect uh whole cloud storage buckets, AWS S3 buckets, for example, that are out there. Um if we then detect one, we raise uh an uh couple so and uh and uh action on them. And they then have to do fix this item. And then, hopefully, they fix it and let's say in within 20 uh 48 hours, they have fixed this issue. And then, when renewal is due, for example, we look at all the cup which were issued and raised, and we use this potentially as an input for the renewal with stronger clauses then, and we can actually embed some other security items which we have experienced before into that new contract with them. Just to avoid that we uh have the same issue again in going forward. Now, on this slide, we see an example of potential tearing of vendors and partners. Um, let's start at the bottom to begin with. Um, so let's start with tier three because tier two will build further on tier three. Uh, and so we'll build further upon the actions you can do in tier three. But, tier one then will also build further upon the actions of tier three and of tier two. So, tier three. No access to sensitive data and providing non-critical services to the organization. Here, we could say we perform a basic questionnaire and contract review to ensure our security requirements are included inside the contract. That's a very, very basic one. But again, that is for providers who not have access to sensitive data and do not provide any critical service whatsoever. Now, we have our second tier. This is where we have access to non-critical data uh or or they have access to, let's say, certain amount of data but uh they are important but also easily replaced. Here, we could perform a security questionnaire, bi-annual re-assessments, and also do security ratings and checks with popular tools that are out there to help you with these kind of functions. Now, we have the tier one. For example, it's a vendor who has access to PII or PHI or whatever, some very important data for us. For this tier, we perform full due diligence. We do a security audit on the request, security audit by a third party even. We do an on-site visit or even an interview or something like this. We do annual re-assessments. We do a security architecture review. Uh, we would like to know how we are working with them or anything like this. And we, of course, perform continuous monitoring of it. And we heavily do that. We want to know if the service changes, what changes, and what impact on our security controls are or will be with the change on my service. We know attackers no longer need to target final victim based on what we have seen in the past in the previous slide. They just target the weakest link I would say or a preem and abuse that going forward. So again, imagine a scenario where your contract or you contract with a particular vendor, let's say vendor A in our scenario, but vendor A has a security issue due to a failure provided by a sub provider of which is then vendor B. Now, these sub-providers of our providers is what we call the fourth parties. And we see this happen more and more and more. Um, but what can we do about? Well, one thing we could do is we could request third parties to disclose their key sub-contractors and also require a flow down flow down duty requirements inside contracts. So in other words, if I pose requirements to vendor A, that vendor will also pose same requirements to his or her sub-contractor going forward. That means you close the loop, right? Um, I've seen that before, I've done that before, and I would recommend to talk to your legal team. Uh, definitely they will know what to do. Also your procurement team and contract team, they will know what to do. Um, this is not normal I would say, but for security requirements, um, I have seen situations where we have not so fortunately. So I would definitely recommend to keep an eye on that. Now, what to address the limitations of our traditional approaches, um, organizations must adapt modern third-party risk management strategies. This is why we recommend the continuous monitoring of vendor security postures, vendor tiering based on criticality, and also integrating your TPRM into your procurement and legal workflows. Also embedding yourself into those workflows. I And with yourself, I'm in security, okay? Because we also want security requirements, for example, to be put inside procurement process, but also inside the contracts that we negotiate. Real-time alerts, automated risk scoring, and evidence-based assessments provide a more accurate and timely understanding of all vendor risks. Now, these strategies enable proactive remediation, ensure that security expectations clearly defined and enforced to them and contractual obligations. Now, by shifting from a reactive to a proactive risk management, organizations, hopefully, can reduce their exposure to third-party threats. I'm pretty sure we can if we do that monitoring and control on it. So, continuous monitoring in that cornerstone of that effective EPRM or third-party risk management program. And it is sitting right in the middle of the life cycle. When the risk monitoring tool provides some real-time visibility into vulnerabilities, such as open ports, leak credentials, misconfigured cloud assets, and so on. These platforms, they automate risk scoring, they help remediate or they have remediation workflows in place, but they help remediate issues. And you can also do compliance tracking, and they allow or enable organizations to respond swiftly to emerging threats that these tools can see. Um integrating them with internal systems, like for example, a Jira, ServiceNow ticketing systems, or something like this, ensures that you will have that incident management available to you. You have that full chain in case you have some audits and so on coming over, you have that full chain available to you. So, continuous monitoring also then has to extend third-party risks. Um uncovering hidden dependencies in your supply chain. By applying this approach, you will transform your TPRM from a periodic exercise into an ongoing dynamic process that enhances resilience and security overall. I hope that the items I mentioned previously sound a bit logical. Uh, and you might wonder, why are we talking about all of this? Well, fortunately, a lot of companies still make mistakes in all of this. All I can ask is that we learn from mistakes we have made in the past, and I have made in the past. So, what I've done is I've listed the the common mistakes on this slide with the goal to not make uh the same mistake again and again and again. One of the mistakes that we see is the perception that big vendors are more secure. Some people, uh mainly in finance, used to say a long time ago, you cannot get fired from buying IBM. Uh, I do not think it holds up anymore. Uh, not saying anything bad about IBM. I'm just trying to point out that what they used to say because IBM was a very well-known is still a very well-known vendor out there. And they said, well, you can't get fired from buying it so because you're going with a trusted vendor or let's say a respected vendor. Uh, this is where the catch is. You always need to assess and verify. Trust needs to be earned. In security, we talk about zero trust, right? We always speak about trust nothing, verify everything. Uh, third parties, we should apply the same methodology. We should apply the same logic. We have to verify them. And we often rely on vendors and partners, but the traditional self-attestation and compliance checklist can create false sense of security. Uh, so be careful with that. By verifying every third-party system through continuous testing and real-world validation, organizations like ourselves can uncover vulnerabilities might otherwise go unnoticed, mitigating the risk of breaches originating from trusted partners. Another mistake we sometimes make is that once we do the onboarding or once we have done the onboarding of a vendor, and we did our due diligence, so we have done all of that, uh we don't really monitor for changes within the vendor landscape anymore. We don't monitor changes with the vendors. We don't monitor changes that are is with the setup of the particular, you know, service we are getting, uh or that they are doing for us. We don't look at the architecture anymore. No, it's a one point activity. Um things change. Things change going forward. So, let's say we have a vendor today, right? They're doing infrastructure management. Tomorrow, they will be doing application development. Something like this. We have asked, right? But they're a typical infrastructure provider for us. They do mainly infrastructure, but there's something that that they go like, "Hey, we can also do that." And we tell them, "Hey, let's let's do that with you." Right? So, um when we are only involved in the initial, let's say, beginning or deal with this vendor at the beginning phase, we're going to be focused on the architecture and how they will connect to our system. Right? So, we saw that moment in time, but it evolved. Uh so because they now develop some application for us, we might have no control in place to cover that. So, we might not even require any application security inside the contract. Um we might not even have controls for it. As the original contract, of course, was focused on infrastructure management. So, what else do we have? Uh just have access. Vendors, that's a typical one. Uh we might not have as strict access controls and governance on the accounts from our vendors in our environment compared to our own internal users. Um seen this multiple times. Um vendors might use a generic account. They might have multiple my logins. accounts that are always on, always enabled because these are vendors that um need to help us. They have at least potentially, so they need these accounts. How are we managing them properly? Are we guarding, monitoring them properly? Right? So, that's one thing that I would definitely take away if you're not Sorry about that. Sorry. Sorry about that. Again, the same issue. Headset is disconnecting. Don't know why. But, um we might also have just too many vendors and we have no structured way of dealing with them. Now, we might not have insights in our vendor subcontractors, although they might be very important. And lastly, we should be involved in TPRM, but also others should be. Not only procurement should be owning this. It should be a shared responsibility. Um, by the way, pro tip, uh don't forget the business to be involved as well. At the end of the day, they're the ones who will drive the business decisions and the business is what the third party could support. Right? Um, so they are the ones that will definitely tell us this is a third party we want to work with because that service is what we need to be better in our business. And this actually brings me to the right side of the slide. And you can see the two arrows pointing each other. One arrow indicating the old style or the style that we used to do, and the other one is the new style. Um, we want to highlight again that we should focus on continuous monitoring, of course, and focus on evidence for your specific goal with insight in supplier suppliers and automated workflows to follow up and then trigger actions and then of course also, you know, follow up on those actions and make sure that those actions are performed and done. All right. That brings me a little bit to my conclusion for today and some key takeaways that I want you take with you. Effective third-party risk management requires a shift from those trust-based reactive practices to now evidence-based proactive strategy. Organizations must move beyond your typical questionnaires and embrace that continuous monitoring, automation, and cross-functional integration. Real-world breaches and regulatory mandates underscore the urgency of this transformation. Some key takeaways that I would like to give, let's say, to you that you need to verify vendor security postures. Um, you need to align TPRM with business objectives, of course, and you need to embed resilience into your supply chain. I would also recommend to start small. Of course, start now if you're not doing it yet, or as soon as possible. Um, implement modern TPRM practices, and if you do that, um, it will enhance security, it will ensure compliance, and it will protect organizational reputation in increasingly complex ecosystem that we have created, unfortunately, or more to the case, have created. I always say to execute it right, it will get you compliant. But being compliant doesn't mean you're going to be secure. And so, I would like that we do things purely and not because compliance reasons. This is why I want to leave you with this one, um, which is a start to a TPRM program. Where I live, we have something called a start to run program, which is a program to get you started running. But in line with that, I was thinking, okay, can't I make a start with TPRM project program? So, in case you have nothing yet, on this slide, I mention a few items which we can use to get started. First one being identify and inventory your vendors. Know your vendors. I think this is quite logical, but um you might be surprised on how many organizations do not know or do not have a list of all their vendors. Um it might be everywhere and nowhere at least. Uh on those vendors you can then apply some eating approach. Uh you could then identify some key stakeholders in your organization. Think about legal and procurement, but there might be others also. Um So, ensure you have uh standard security clauses in your contract clauses in case uh a vendor then disagrees and or requires changes to that standard contract clauses, make sure you know about. You're involved. And they ask your opinion about. Sometimes these changes are perfectly acceptable. No problem whatsoever. Or some of these things don't don't make sense at all for you not for the vendors. So, why not delete those things? That is perfect. But make sure you are involved because in some cases, right, might not make sense and you really want to have this. Now, I would also recommend to review your vendor activity of course and implementations that you have done. For example, how are they connecting to our environment? How are you connecting to their environment? Is this secure? What data exchanges going on? Is this data exchange secure and so on? By the way, these are questions which I asked all the time when I was doing security architecture reviews um several organizations because uh these are just very important questions. I want to know how this goes. I want to know what kind of encryption you use uh to exchange data with me or you that I have to or that I have to exchange with you because I want to make sure that this is done properly and securely, right? Um your questionnaire then um for your different tiers, make different questionnaire I would say for different tiers. Um standardize of course on the lower tiers. Um monitor and report on this as well, on a regular basis even. And last but not least, ensure you know who to contact from your vendors in case you have detected something strange. Or if you actually have a security incident that is linked to that particular vendor. But vice versa as well. Make sure that your vendor knows how to reach your security department and who to reach to. And then also who to make aware in case an incident with potential impact that will occur on their side. Unfortunately, that is often neglected or not up to date. They typically put like contact details in the contract, but that might be a person that has already left the organization, something like this. So, make sure you keep track of this. You know who to contact, who from your vendors you need to contact in case you have an issue like this. Um, by doing these things, uh, you will start to do meaningful third-party risk management. Later, you could then start investing in tools, products, and so on to get you to the next level of maturity. But I hope that you understand that just having a tool and running standard questionnaires is not going to be sufficient. And on that note, I have come to the end of my presentation for today. Um, but before I leave you with the for the remainder of the day, please allow me to share a few words on our leadership traits. We have three leadership traits at Sans. We have the operational transformation and cyber risk one. For each one of those, we have different trainings. You want to learn more about these spots, please check them out on our website, sans.org. And, um, thank you for your attention. I really hope that you enjoyed the session of today. I wish you all very pleasant rest of the day. Uh, thank you. Hopefully, see you soon in one of my classes. You can also see the list of the upcoming LDR 512 courses on the slide. You can see I'm going to be quite busy in June, July, and August. So, if you have time, if you want to join, perfect. See you there. Thank you very much.