Most businesses invest serious money in firewalls, endpoint protection, security awareness training, and all the controls their IT teams recommend. And yet breaches still happen, often through systems you do not control. In a lot of the incidents I have reviewed over the years, the failure did not come from inside the perimeter. It came in through a vendor, a partner, or a SaaS tool that nobody was watching closely enough.

That is the uncomfortable reality of third-party risk. You can have your own house in order and still get exposed through someone else's front door. A vendor with a weak password policy, a forgotten API integration, an MSP that skipped a critical patch because they were stretched too thin: any of these can quietly undo months of internal security work. It happens more than most organizations want to admit.

Third-party risk management is not a new concept, but the urgency around it has grown significantly as businesses have become more reliant on external software, outsourced services, and deeply integrated supply chains. If this area has not had proper attention in your organization, it is worth examining sooner rather than later.

Why Third-Party Risk Is Now a Big Gap in Security

The way businesses use technology has shifted dramatically over the past decade. Most organizations today rely on a patchwork of SaaS platforms, external providers, and API-connected tools that span departments and use cases. Each of those connections represents a trust decision, and most of them are made without any formal security review.

Attackers understand this. They know that companies have put resources into hardening their own perimeters, so they look for the softer entry points. A vendor with admin-level access and no multi-factor authentication is a far easier target than a well-monitored internal network. Once a vendor is compromised, moving laterally into the connected client environment often requires very little effort.

I have seen this play out repeatedly. A manufacturing company with a solid internal security posture had a breach traced back to their HVAC monitoring vendor. A financial services firm was compromised through a marketing automation tool that had direct database access. Neither of those entry points would have shown up on a standard vulnerability scan of the client’s own systems. That is the nature of this problem.

Supply chain security is now front and center in frameworks like NIST and ISO 27001, and for good reason. The risk is real, it is growing, and it tends to be underestimated until something goes wrong.

What Counts as a Third Party in the IT Supply Chain

When I walk through a client's IT architecture for the first time, the full picture of third-party exposure almost always surprises them. Most organizations have a rough idea of their major vendors, but very few have a complete inventory of every external connection, tool, or party that touches their data or systems.

Third parties in an IT supply chain include more than the obvious names. Common categories include:

• SaaS platforms: CRMs, project management tools, file sharing services, accounting software, HR systems, and communication platforms
• Managed service providers (MSPs): Remote monitoring and management tools, helpdesk providers, patching services, and NOC operators
• External consultants and contractors: Developers, auditors, penetration testers, and agencies that are granted temporary or ongoing system access
• Payment platforms and e-commerce integrations: Payment gateways, fraud prevention tools, and third-party checkout plugins
• Cloud infrastructure providers: Hosting platforms, CDN services, and backup or disaster recovery vendors
• Data processors and analytics platforms: Tools that ingest, process, or store customer or business data

The category that causes the most problems in practice is often the one with the smallest footprint. A niche integration added by one team two years ago, a contractor who was given access for a short project and never fully offboarded, a free tool that someone connected to a shared drive. These are the gaps that rarely make it onto any formal risk register.

Shadow IT makes this worse. Employees connect tools to business accounts without going through any approval process, and IT teams often have no visibility into those connections until something breaks or gets flagged in an audit. A complete third-party inventory needs to account for the sanctioned and the unsanctioned alike.

That is the gap. And for most organizations, it is bigger than they think.

What Can Actually Go Wrong: Vendor Risk in Practice

Trusting a vendor without validating their security is one of the fastest ways to create a blind spot. The fact that a company is well-known, or was recommended by a trusted contact, tells you almost nothing about their actual security posture. I have encountered serious gaps at organizations with impressive client lists and polished sales decks.

Here are the failure patterns I see most often:

• Vendors as breach entry points: An attacker compromises a vendor's environment, then uses that foothold to pivot into connected client networks. This is not a theoretical risk. It is how a significant number of large-scale breaches have unfolded.
• Weak authentication and shared credentials: Password reuse, shared logins across teams, and no MFA are still extremely common, particularly among smaller vendors. When credentials leak, there is often no way to tell how long access has been exploited before someone notices.
• Excessive access permissions: Vendors accumulate permissions over time. What starts as a scoped engagement ends with broad access that nobody has reviewed in eighteen months. The original project is done, but the access remains.
• Poor patching and outdated infrastructure: Some vendors are running on legacy systems that have not been updated in years. They are aware of the gaps but lack the resources or internal pressure to fix them. Their clients assume someone is handling it.
• No visibility into vendor activity: Without proper logging and alerting, there is no way to know what a vendor is doing inside your systems. Misuse, accidental exposure, and outright theft can go undetected for months.

The following examples are composites based on real patterns seen in the field; details have been altered to avoid identifying specific organizations. One client discovered that a support consultant, originally brought in for a three-month engagement, still had active admin credentials eighteen months later, with no logging in place to show what had been accessed during that time. The contract had ended, the consultant had moved on, and nobody had flagged the account for review. In another case, a company's CRM integration had been quietly syncing customer records to a third-party analytics platform whose data retention policy turned out to be non-compliant with their industry regulations. The integration had been set up by a contractor, was not in any formal system inventory, and only came to light during an unrelated compliance audit.

None of these failures look dramatic on their own. That is exactly why they get missed.

These are not edge cases. They are the kinds of things that turn up regularly when someone actually looks.

Why Vendor Risk Management Fails in Practice

Most organizations do not have a deliberate vendor risk management failure. They have a gap that grew gradually, through competing priorities, unclear ownership, and processes that were set up once and never maintained. Understanding why it tends to break down is the first step toward building something that actually holds.

The most common root cause is that nobody owns it. Vendor relationships often span multiple teams: procurement handles contracts, IT manages access, compliance handles paperwork, and operations manages the day-to-day relationship. When responsibility is distributed that way, it is easy for everyone to assume someone else is monitoring security. In practice, nobody is.

The second issue is that assessments get treated as events rather than processes. A vendor gets assessed at onboarding, the checklist gets filed, and that is the last time anyone formally reviews their security posture. The vendor's circumstances change, new integrations get added, personnel turns over, but the risk profile in the organization's records stays frozen at the point of initial review.

Third, the tools most organizations use for vendor assessment are not fit for purpose. A questionnaire that asks a vendor to self-report their controls is not an assessment. It is an opportunity for the vendor to tell you what you want to hear. Without independent validation, those questionnaires produce a false sense of security that can be more dangerous than having nothing at all.

Vendor risk management fails because it is treated as a compliance exercise rather than an ongoing operational discipline. The organizations that do it well treat it the same way they treat patch management or access reviews: as something that runs continuously, with clear ownership and defined triggers for reassessment.

The ones that treat it as a once-a-year checkbox tend to find out about the gap the hard way.

Managing Third-Party Risk: A Practical Framework

When I build out a vendor risk management process for a client, I keep the structure straightforward. Complexity tends to be the enemy of consistency, and a process that is too burdensome will get abandoned. Here is the framework I recommend, along with the practical details that tend to get skipped:

Step 1: Build a Complete Vendor Inventory

This sounds obvious, but in practice, most organizations do not have one. And without it, everything else in the framework falls apart. A complete inventory means every SaaS subscription, every external API integration, every contractor with active system access, and every managed service provider, regardless of which team they support. If it touches data or systems, it goes on the list.

The practical challenge is that different teams buy and connect tools independently. Marketing has their automation platform. Finance has their analytics tool. Operations has their project management suite. None of these may have gone through a formal IT review. Shadow IT adds another layer: tools connected without any approval process at all. Getting to a real inventory requires active discovery. Asking department heads what they use is not enough.

Step 2: Classify Vendors by Risk Level

Not every vendor warrants the same level of scrutiny. A vendor with admin access to your core infrastructure is a fundamentally different risk profile from a company that handles your email newsletter. Classification should look at: what data the vendor can access, how deeply they are integrated into systems, whether they have privileged access, and how dependent the business is on their service.

The mistake I see most often here is risk misclassification in the other direction, where a vendor that looks small gets a light-touch review, but they actually have write access to a production database or an integration that touches customer financial records. Classification should be driven by access level and data sensitivity, not just by the size or prominence of the vendor.

Step 3: Run a Real Partner Security Assessment

A meaningful partner security assessment goes well beyond sending a questionnaire and filing the response. I will cover this in more detail in the next section, but the short version is: ask for evidence, not statements. If a vendor says they have MFA enabled, ask for a demonstration. If they say they conduct annual security training, ask for documentation. Claims without evidence are not controls.

Step 4: Define and Enforce Minimum Security Standards

Set clear requirements that all vendors must meet to maintain the relationship. These should cover authentication requirements, encryption standards, data handling and retention practices, breach notification timelines, and access review schedules. Put them in contracts. A vendor security standard that exists only as an internal document has no leverage.

Step 5: Monitor Continuously and Reassess Regularly

Vendor risk is not static. Vendors get acquired, their infrastructure changes, their security teams turn over, and new integrations get added without formal review. A minimum annual reassessment is the baseline, with immediate reassessment triggered by material changes: a vendor acquisition, a reported security incident in their environment, significant changes to their product or integration, or concerns raised during routine monitoring.

Ongoing monitoring should include regular permission audits, watching for changes in vendor access behavior, and tracking vendor-reported incidents. Some organizations use automated tooling for this. Others manage it through scheduled internal reviews. Either way, the process needs to be running continuously, not just at onboarding.

What a Partner Security Assessment Should Really Cover

Checkbox assessments are one of the more persistent problems in vendor risk management. They create documentation without creating insight. I have reviewed hundreds of vendor questionnaires that were filled out thoughtfully, filed correctly, and provided almost no useful information about the vendor's actual security posture.

The problem is that self-reported assessments measure a vendor's willingness to say the right things, not their actual controls. A vendor that knows what answers you want to see will give you those answers. Without validation, you have no way to distinguish between a vendor with mature security practices and one who has learned how to fill in the form.

Here is what a thorough assessment should actually include:

Access Controls and Authentication

Ask the vendor to walk you through who has access to systems that touch your environment, what their roles are, and how they authenticate. Check whether former employees are removed promptly. Check whether shared credentials are in use. If they claim MFA is enforced, ask to see it in action. This takes fifteen minutes and tells you far more than a yes/no question on a form.

Data Handling and Storage Practices

Where does your data actually go? Is it encrypted at rest and in transit? Who within the vendor's organization can access it? How is it wiped when the engagement ends or the contract is terminated? For any vendor touching regulated data, these answers need to be specific and verifiable, not generic assurances about their security culture.

Security Policies in Practice

Most vendors have an information security policy. That tells you very little. What matters is whether the policy is actually implemented. Ask for evidence of security awareness training completion. Ask for sample audit logs. Ask about their vulnerability management cycle and how quickly they patch critical vulnerabilities. The gap between what a policy says and what actually happens is often significant.

Compliance Evidence

Certifications like SOC 2 Type II, ISO 27001, and PCI DSS carry real weight, but only when they are current and scope-appropriate. An expired certificate, a report from three years ago, or a certification that covers a different part of the business than the part you are working with: none of these provide meaningful assurance. Ask for the actual report, check the audit date, and verify that the scope covers the services you are using.

Incident Response Readiness

If a vendor has a breach that affects your data, how quickly will you know? Who contacts whom, through what channel, and within what timeframe? Ask the vendor how they define a reportable incident, what their internal escalation process looks like, and whether they have tested their incident response plan in the past twelve months. Organizations that have never run a tabletop exercise on this scenario are often unprepared for how slow and disorganized the actual response turns out to be.

I have started asking vendors a simple question at the end of assessments: 'Can you show me the last time you ran an incident response drill?' The ones with strong practices can answer immediately. The ones who struggle with the question usually tell you everything you need to know about their real-world readiness.

Common Mistakes Companies Make with Vendor Risk Management

After working through vendor risk reviews with clients across a range of industries and sizes, the same mistakes come up with frustrating regularity. Most of them are not the result of negligence. They are the result of competing priorities, unclear ownership, and processes that were set up with good intentions but never maintained.

Trusting Vendors Based on Reputation

A well-known brand name or a warm referral from a business contact does not mean strong security. I understand the logic: if they are serving large enterprise clients, surely they have their controls in order. This assumption is wrong often enough that it should not be relied upon. Some of the weakest vendor security postures I have encountered belonged to companies with impressive client logos on their website. Validate every vendor on the merits of their actual controls, regardless of their market position.

Treating Assessments as One-Time Events

Doing a thorough onboarding assessment and then never circling back is a common pattern. Vendor environments change. Security teams turn over. New integrations get added. A vendor that passed an assessment eighteen months ago may have experienced significant changes since then, and there is no way to know unless you look again. This is not about distrust. It is about recognizing that security posture is not static.

No Clear Internal Ownership

Vendor risk often sits in the space between departments, which means in practice that nobody owns it. Legal owns the contract. IT owns the access. Compliance owns the documentation. Operations owns the relationship. When a vendor changes ownership or has an incident, who is responsible for initiating a reassessment? If the answer is not immediately clear, that is the gap that needs to be fixed first. I recommend assigning a named internal owner for each significant vendor relationship, with clear responsibility for ongoing monitoring and periodic review.

Permissions That Outlast Their Purpose

Access permissions accumulate over time. A developer is given staging environment access for a project. The project ends, the developer moves on, but the access is never revoked. A support consultant is given read access to a database for a specific troubleshooting session. Six months later, the access is still active. This is not a vendor problem. It is an internal process problem that creates vendor risk. Vendor access reviews need to be calendared the same way employee access reviews are, and they need to actually happen.

Failing to Account for the Vendor's Vendors

Fourth-party risk is the category that most vendor risk programs ignore entirely. Your vendor uses their own set of sub-processors, cloud providers, and third-party tools. A breach at one of those sub-processors can propagate through your vendor into your environment. Most vendor questionnaires do not ask about this. Most vendors have not fully mapped it themselves. It is worth at least asking the question and understanding where significant sub-processor dependencies exist.

IT Supply Chain Security Is Not Just Compliance

There is a tendency to frame third-party risk management as a compliance requirement: something you do because your auditors need to see it, or because a framework checkbox requires it. That framing understates the real business risk significantly.

A breach that enters through a vendor counts the same as any other breach when it comes to customer impact, regulatory consequences, and reputational damage. Your customers do not care that the attacker came in through a supply chain partner rather than through your own systems. Your regulatory obligations do not change because the data was exposed by a third party you trusted. The downstream consequences are identical.

Beyond breach scenarios, IT supply chain security affects business continuity in ways that are often overlooked. A critical vendor going offline, getting acquired and shuttering their product, or having their systems seized in a regulatory action can create operational disruptions that are just as damaging as a security incident. Vendor dependency mapping, which identifies where single points of failure exist in the supply chain, is a natural extension of vendor risk management and an underused tool in most organizations.

The organizations that manage this well tend to have one thing in common: they treat vendor risk as an operational discipline with real ownership and ongoing attention, rather than as a compliance exercise that runs once a year. The difference in outcomes is significant.

Vendor risk done well is not more work. It is less exposure.

How FunctionEight Approaches Vendor Risk Management

Most clients come to us knowing something is off. They have added tools, vendors, and integrations over time, but no one has stepped back to map the full picture. They know their own systems reasonably well. What they have lost track of is everything connected to those systems from the outside.

The starting point is usually an IT security audit that goes beyond internal systems. We look at the full vendor landscape: what tools are connected, what access levels have been granted, whether integration configurations match current business needs, and whether any vendor relationships have drifted significantly from their original scope. In many engagements, we find vendors with more access than anyone internally realized, integrations that are no longer actively used but are still connected, and at least one account that should have been revoked months or years earlier.

From there, we help clients build vendor risk management frameworks that are practical enough to actually be maintained. A framework that is too complex or too time-consuming will be abandoned under operational pressure. The goal is something structured, clearly owned, and repeatable, with defined criteria for assessing new vendors at onboarding, triggers for immediate reassessment, and a manageable schedule for routine reviews.

We also provide ongoing vendor oversight support for clients who want external help maintaining the process. This includes scheduled permission audits, structured reassessments for high-risk vendor relationships, and monitoring support for clients who lack internal bandwidth. For many organizations, the challenge is not understanding what needs to be done. It is finding the capacity to do it consistently.

The underlying goal is the same across all of these engagements: making sure that no vendor relationship becomes an unmonitored blind spot. In IT supply chain security, it is usually the things nobody is watching that create the biggest problems.

FAQ: Third-Party Risk and Vendor Management

What is third-party risk, exactly?

Third-party risk is the exposure your organization takes on when vendors, partners, or suppliers have access to your systems or data but operate outside your direct control. Even strong internal security can be undermined by a vendor with weak controls, which is why the relationship needs to be actively managed rather than assumed to be safe.

How often should vendors be assessed?

Every vendor should go through a full assessment at onboarding and at least once per year after that. For vendors with admin access or handling particularly sensitive data, more frequent reviews are warranted. Reassessment should also happen immediately following any material change: a vendor acquisition, a reported incident in their environment, or a significant expansion of their access or integration scope.

Are small vendors a bigger risk than large ones?

Often, yes. Large vendors are not automatically safe, but they typically have more dedicated security resources and external scrutiny. Smaller vendors frequently lack formal security teams, run on legacy infrastructure, and have not gone through independent audits. The fact that a vendor is small or familiar does not reduce the risk they introduce. If anything, it is a reason for additional scrutiny during the assessment process.

What should a vendor security check actually cover?

A meaningful vendor security review covers authentication controls and access management, data handling and encryption practices, evidence of compliance certifications (not just claims), incident response plans and testing history, and patch and vulnerability management processes. The key word is evidence. Asking for proof rather than accepting self-reported answers is what separates a useful assessment from a checkbox exercise.

How do you manage vendor risk on an ongoing basis?

Ongoing vendor risk management involves regular permission audits, scheduled reassessments based on risk classification, monitoring for changes in vendor behavior or environment, and clear internal ownership for each significant vendor relationship. It also means building vendor requirements into contracts so there is a formal mechanism for enforcing standards, not just relying on goodwill. The organizations that manage this well tend to treat it as a continuous process rather than an annual event.

What is fourth-party risk and should we care about it?

Fourth-party risk refers to the exposure that comes from your vendors' own vendors and sub-processors. A breach at a company your vendor relies on can propagate through that vendor into your environment. Most organizations do not explicitly manage this, but it is worth understanding where your critical vendors have significant sub-processor dependencies, particularly in areas like cloud hosting, data storage, and identity management.

If you are unsure how exposed your business is to third-party risk, the fastest way to find out is to map it properly.

At FunctionEight, we help businesses identify vendor-related risks that are often missed internally, from excessive permissions to forgotten integrations and weak access controls. This often starts with a structured IT security audit, where we review vendor access, hidden dependencies, and third-party exposure across your environment. You can learn more about our services on the FunctionEight website.

We also support businesses that need a more practical and ongoing approach to vendor oversight, including reassessments, access reviews, and stronger third-party risk processes that can actually be maintained over time. For companies in Hong Kong, more information is available through the FunctionEight Hong Kong team.

If you would like a clearer view of your vendor exposure or want to strengthen how your business manages third-party risk, our team is available to help.

Third-party risk management is not a one-time project. It is an ongoing commitment to understanding who has access to your environment and whether that access is warranted and secure. The cost of getting it wrong tends to be much higher than the cost of building the process correctly in the first place.