What Third-Party Risk Management Actually Looks Like at 100 Employees

Most 100-employee companies could not produce a complete list of their vendors if asked this afternoon. Payroll knows the payroll processor. IT knows the cloud provider. Nobody owns the full picture: the marketing team's analytics tool, the HR platform's background-check integration, the billing system's payment processor, and the dozens of smaller tools that quietly picked up access to company data along the way. That gap usually stays invisible until a customer's security questionnaire asks for a vendor risk register that doesn't exist, or a vendor nobody was watching gets breached and the question becomes whether it had access to your systems.

Why Vendor Risk Became a Board-Level Question at This Size

A company crossing 100 employees typically runs on somewhere between 40 and 70 SaaS applications, according to SaaS management research tracking spend and app counts by company size. Each one is a relationship with its own login credentials, its own data access, and its own security posture that has nothing to do with yours. Ten years ago, most of those relationships would have gone unexamined, and for a while that was a manageable risk. It no longer is.

Verizon's 2025 Data Breach Investigations Report, based on more than 22,000 reviewed incidents, found that third-party involvement in confirmed breaches doubled year over year, from 15% to 30%. That is not a niche finding buried in an appendix. It means roughly one in three breaches now traces back to a vendor, a partner, or a piece of someone else's infrastructure rather than a direct attack on the company itself. IBM's Cost of a Data Breach research puts a number on what that costs: breaches that involve a compromised supply chain partner or vendor run well above the overall average, averaging close to $4.9 million once vendor remediation, downstream notification, and the extended time to detect and contain are factored in.

The mechanics of why this hits growth-stage companies specifically are straightforward. A 15-person company has one or two vendors that actually matter and can track them informally. A 100-person company has crossed into a different category of exposure: enough vendors that informal tracking breaks down, but usually not enough dedicated headcount to formalize it. That gap between exposure and capacity is exactly where third-party risk becomes a real, board-visible problem instead of a theoretical one.

In practice, the trigger is rarely a company deciding on its own that it's time to build a vendor risk program. It's a specific event that forces the question. A customer's procurement team sends a security questionnaire asking for the vendor risk register. A cyber insurance renewal application asks whether the company assesses third-party vendors before granting them system access, and answering honestly affects the premium. A vendor low on anyone's radar discloses a breach, and someone on the leadership team asks, reasonably, whether that vendor had access to anything sensitive. Any one of those moments turns a background risk into an urgent one, and companies that only start building the program in response to the trigger are almost always behind schedule from day one.

What "Managing" Vendor Risk Actually Means

Third-party risk management sounds like it requires an enterprise GRC platform and a team of analysts. At 100 employees, it doesn't. It requires four things done consistently, not four things done perfectly.

A real vendor inventory. Not a list someone remembers off the top of their head, but an actual accounting of every vendor with access to company systems or data, built from expense reports, SSO logs, contract records, and department-by-department interviews. Most companies attempting this for the first time are surprised by the count. It is almost always higher than anyone expected.

Risk tiering. Not every vendor deserves the same scrutiny. A payroll processor handling employee bank account numbers is a different category of risk than a scheduling tool with no sensitive data access. Grouping vendors into tiers, based on what data they can reach and how core they are to operations, is what makes the rest of the program sustainable instead of overwhelming.

Assessment proportional to risk. Higher-tier vendors get a real security review: a completed questionnaire, evidence of a current SOC 2 report or equivalent, and a look at how they'd notify you in a breach. Lower-tier vendors get a lighter check. Treating every vendor like a Tier 1 vendor is how well-intentioned programs collapse under their own weight within a year.

Ongoing monitoring, not a one-time gate. A vendor that passed review at onboarding two years ago may have changed ownership, had a breach, or quietly dropped a security control since then. A functioning program revisits Tier 1 vendors on a set schedule rather than treating the initial assessment as permanent.

The point-in-time approach is the most common failure mode in programs that do get built. A company runs a thorough assessment when a vendor is first onboarded, files the results, and never looks at that vendor again. Two years later, that vendor has been acquired by a company with a different security posture, or has quietly let its SOC 2 report lapse, or has expanded the scope of data it collects without anyone renegotiating the contract. None of that shows up unless someone is scheduled to check. A vendor risk program that only operates at onboarding is not managing risk. It's documenting a single day.

A Practical Framework for Building This at 100 Employees

Start with the inventory, and expect it to take longer than planned. Pull every vendor from finance's payment records, IT's SSO admin console, and a short survey to department heads asking what tools they use that finance doesn't already know about. Cross-reference all three. The overlap gaps are usually where the highest-risk shadow IT lives.

Tier by data sensitivity and operational criticality, not by contract size. A $200-a-month vendor with access to your customer database is a bigger risk than a $50,000-a-year vendor that only touches office supply ordering. Tier on what the vendor can reach, not on what you pay it.

Match the assessment to the tier. For Tier 1 vendors handling regulated or sensitive data, request a completed security questionnaire, a current SOC 2 Type II report or equivalent attestation, and documented incident notification commitments. The Shared Assessments Standard Information Gathering framework, used widely across the industry, offers a useful model here: a lighter-weight questionnaire for initial screening, with escalation to a deeper review only for vendors that are Tier 1, handle regulated data, or raise flags on the initial pass. Tier 2 and 3 vendors get a shorter version, or in the lowest tier, a documented but abbreviated check.

Put security terms in the contract, not just the sales conversation. A vendor that verbally agreed to notify you "quickly" after an incident has agreed to nothing enforceable. Breach notification timelines, data handling obligations, and audit rights belong in the master service agreement or a security addendum, reviewed before signature, not negotiated after something goes wrong.

Monitor on a schedule, and build in an offboarding step. Reassess Tier 1 vendors annually at minimum. When a vendor relationship ends, revoke access and confirm data deletion as a required step in the offboarding process, not an afterthought someone remembers three months later.

Report on it, briefly, at the leadership level. A one-page summary of vendor count, tier distribution, and any overdue reassessments, reviewed quarterly, is enough to keep the board and leadership informed without turning this into a full-time reporting function.

What This Actually Costs at 100 Employees

There is a wide range here, and the right answer depends on how much of this you build versus buy. A fully staffed, entirely manual program covering a portfolio of around 100 vendors typically runs in the range of $200,000 to $400,000 a year in loaded labor costs, per industry benchmarking on TPRM staffing, because reviewing questionnaires, chasing documentation, and tracking reassessment schedules by hand consumes real hours every week. Dedicated third-party risk management software aimed at mid-market organizations generally starts around $50,000 a year and climbs from there depending on vendor volume and feature depth.

Neither of those numbers fits most companies at 100 employees. A dedicated headcount for vendor risk alone rarely makes sense at this scale, and a full enterprise platform is usually oversized for the vendor count involved. That gap, between what the risk actually requires and what a full-time hire or an enterprise platform costs, is precisely why this function fits a fractional model well: senior oversight and a working process, sized to the actual vendor count, without the fixed cost of a role that doesn't need to be full-time yet.

There is a middle path worth naming directly, because it's where most companies in this range eventually land. A lightweight vendor risk tracker, built on a spreadsheet or a low-cost tool rather than an enterprise GRC suite, combined with a defined process and someone senior enough to actually enforce it, covers the vast majority of what a 100-employee company needs. The expensive mistake isn't underspending on software. It's having no defined process at all, which means the same gaps get rediscovered every time a customer questionnaire or insurance renewal forces the issue, instead of being closed once and maintained.

Where This Fits Alongside Your MSP

This is a common point of confusion, and it's worth being direct about it. Your managed service provider keeps your infrastructure running: patching, endpoint monitoring, help desk support, and day-to-day network operations. That is essential work, and a third-party risk program does not replace it or compete with it.

But most MSP contracts don't include ownership of vendor risk governance. Reviewing a new vendor's security posture before a contract is signed, tracking which of your 50-plus SaaS tools have current attestations, negotiating breach notification language into a contract, and reporting vendor risk status to the board are strategic and governance functions, not infrastructure functions. Fractional IT leadership is built to own exactly that layer, working alongside your existing MSP rather than duplicating what it already does well. The MSP keeps the lights on. Fractional leadership makes sure someone is actually watching which outside parties have a key to the building.

Frequently Asked Questions

How much does third-party risk management cost for a 100-person company?

It depends on how much is built in-house versus outsourced, but a fully staffed manual program can run $200,000 to $400,000 a year in labor alone, and dedicated software platforms typically start around $50,000 a year. Most companies at this size get more value from a fractional model that sizes the effort to the actual vendor count rather than committing to a full-time hire or an oversized platform.

How does this work alongside our existing MSP or IT team?

It works as a layer above day-to-day infrastructure work, not a replacement for it. Your MSP or internal IT team keeps systems running, patched, and supported. Vendor risk governance, tiering, contract review, and board reporting are separate functions that most MSP agreements don't cover, and fractional technology leadership is designed to own that layer without disrupting what your MSP already handles.

Do we need a dedicated GRC platform to do this properly?

Not at 100 employees, in most cases. A well-organized spreadsheet-based inventory, tiering structure, and reassessment calendar can run a sound program for a vendor count in the tens to low hundreds. A platform becomes worth the cost once vendor volume, questionnaire frequency, or audit requirements outgrow what a manual process can track reliably.

Which vendors should we assess first?

Start with the vendors that have access to your most sensitive data or are most critical to daily operations, regardless of contract size. Payroll processors, core business applications, and anything touching customer or employee personal data belong in the first assessment round. Low-cost tools with no meaningful data access can wait for a lighter-touch review later.

How do we get started if we've never done a vendor risk assessment before?

Begin with the inventory. You cannot tier, assess, or monitor vendors you haven't identified, and most companies find the actual count is higher than expected once they cross-reference finance records, SSO logs, and a quick survey of department heads. That inventory is the input every other step in the program depends on.