Three years ago, a file transfer tool called MOVEit quietly became the most expensive piece of software in corporate history. Cl0p, a ransomware group operating out of Eastern Europe, exploited a zero-day vulnerability — a previously unknown flaw with no patch available — in Progress Software's MOVEit Transfer product. The damage had nothing to do with whether the victim companies ran good IT departments. It had everything to do with a vendor they trusted to move sensitive data on their behalf. Over 2,700 organizations and 95 million individuals were affected. The estimated financial impact exceeded $12 billion.

That is third-party vendor risk. And for most small and mid-sized businesses, it is the largest unaddressed gap in their entire security program.

What the Breaches Are Really Telling You

MOVEit is not an isolated case. Look at SolarWinds in 2020. SolarWinds made network management software — the kind of tool that IT teams install on systems specifically because it needs broad access to monitor everything. Russian state-sponsored hackers (later attributed to SVR, Russia's Foreign Intelligence Service) inserted malicious code into a routine software update. Organizations that downloaded the update in good faith handed attackers a back door into their environments. The list of victims included the U.S. Treasury, the Department of Homeland Security, Microsoft, Intel, and thousands of private companies.

Then there was Kaseya in 2021. Kaseya makes VSA, a remote monitoring and management platform — the software used by managed service providers (MSPs, the IT companies that many small businesses outsource their technology to) to administer client systems. The REvil ransomware group exploited a zero-day in Kaseya VSA and used that single access point to push ransomware to approximately 1,500 downstream businesses. Most of those 1,500 companies had never heard of Kaseya. Their vendor's vendor was the attack surface.

The pattern is consistent across all three incidents. The attacker did not break through your firewall. They walked through a door your vendor left open, using credentials and access you legitimately granted.

Why the Vendor Questionnaire Is Security Theater

Most vendor risk programs — when they exist at all — consist of sending a PDF questionnaire to a new vendor before signing a contract. The vendor fills it out, checks a box that says "yes, we use encryption," and the file goes into a shared drive never to be opened again.

This approach has two fundamental problems.

First, questionnaires are self-reported. You are asking the vendor whether they are secure. A vendor with weak security has every incentive to answer optimistically. A vendor with genuinely good security may answer conservatively out of caution. The responses tell you very little about actual security posture.

Second, security is not static. A vendor who passed a questionnaire in January may have had a misconfigured cloud storage bucket exposed in February, laid off their entire security team in March, and suffered a credential breach in April. The questionnaire captures a snapshot of what a vendor was willing to claim on one day.

The SolarWinds attackers spent nearly nine months inside the build environment before anyone detected them. If SolarWinds had sent themselves a questionnaire asking "are your build systems secure?", they would have checked yes.

What a Real Vendor Assessment Looks Like

A meaningful third-party risk assessment (TPRA) has several components that go beyond paperwork.

Tiering your vendors by risk. Not every vendor deserves the same scrutiny. A vendor who has access to your customer data, your financial systems, or your internal network is tier one — they get a full assessment. A vendor who sells you office supplies through a web portal is not the same threat. Start by mapping which vendors have access to what, and prioritize accordingly.

Reviewing actual evidence, not claims. Ask for SOC 2 Type II reports, ISO 27001 certifications, or equivalent third-party audit documentation. A SOC 2 Type II report — issued by an independent auditor — documents whether a vendor's security controls were operating effectively over a six-to-twelve month period, not just on the day of an audit. If a vendor cannot produce this documentation, that absence is itself a data point.

Assessing the access the vendor actually has. Does your payroll platform have read access to your HR system, or does it have write access too? Can your IT management vendor remotely execute code on your workstations? The principle of least privilege — giving every system and user only the minimum access needed — applies to your vendors. If you have not audited what permissions your vendors hold in your environment, you cannot assess the risk they represent.

Testing through penetration testing. If a vendor is deeply embedded in your environment, consider whether the scope of your next penetration test should include the vendor integration points — the APIs, the network connections, the accounts used by the vendor's software. Attackers absolutely will test those paths, and you should too.

Ongoing monitoring instead of point-in-time reviews. A vendor's security posture changes continuously. Continuous monitoring means checking for new data breach disclosures involving the vendor, watching for changes to their public-facing security posture, and staying informed through threat intelligence feeds.

SaaS Risk Deserves Special Attention

Software-as-a-Service (SaaS) products — cloud-based software your teams access through a web browser — have become the dominant form of software acquisition for small and mid-sized businesses. The ease of adoption is the problem. Individual employees can sign up for a new SaaS platform with a company email address and a credit card, and the IT department may not know the tool exists for months.

This phenomenon is called shadow IT: unauthorized technology adopted outside of any procurement or security review process. Every shadow IT platform is a potential unauthorized access point. When that platform experiences a breach — and statistically, they will — your company data is exposed through a door no one knew was open.

A SaaS risk program starts with visibility. You need a current inventory of every SaaS platform in use across your organization, who authorized it, what data it stores, and what permissions your employees have granted it. Many SaaS platforms request access to email, calendar, contacts, and document storage as part of their standard setup — permissions that create meaningful exposure if the platform is ever compromised.

If you are subject to compliance frameworks such as HIPAA (Health Insurance Portability and Accountability Act), PCI-DSS (Payment Card Industry Data Security Standard), or SOC 2, your SaaS vendors may also be in scope for your compliance obligations. Our compliance services team regularly helps businesses understand which vendors trigger which compliance requirements and how to structure those vendor relationships properly.

Contractual Requirements That Actually Matter

The legal relationship with a vendor is a security control. Contracts that contain the right language create accountability that questionnaires never will.

Key provisions to negotiate into any vendor contract that involves access to sensitive data:

Right to audit. Your contract should give you the right to request audit reports, penetration test results, or conduct your own security review on reasonable notice. Vendors who refuse this provision are telling you something.

Breach notification timelines. Many state laws and federal regulations require breach notification within 72 hours of discovery. Your vendor contract should require the vendor to notify you of any incident affecting your data within the same or shorter window. A vendor who learns of a breach in January and notifies you in March causes you to miss your own legal disclosure obligations.

Data handling and retention requirements. Specify what data the vendor is permitted to store, for how long, and what format it must be returned or destroyed in at contract termination. This is particularly important for payroll processors, cloud storage providers, and CRM platforms.

Subprocessor restrictions. Your vendor's vendors are your risk too (see: Kaseya). Contracts should require vendors to disclose when they use subprocessors and should prohibit passing your data to fourth parties without your consent.

Incident response obligations. Define what the vendor is required to do in the event of a breach, including preserving forensic evidence, cooperating with your investigation, and covering costs attributable to their failure.

These terms require negotiation, and larger vendors with standard form contracts will push back. But for tier-one vendors — those with meaningful access to your most sensitive systems — these provisions are not optional extras. They are baseline expectations for a professional relationship.

The Dark Web Signal You Are Missing

Here is the practical problem with vendor risk management: you often do not know about a vendor breach until months after it happens. Breached data moves onto underground marketplaces and dark web forums long before any public disclosure. Credentials from a vendor's breach that includes your employee accounts will appear in those markets before the vendor issues a press release.

Dark web monitoring provides continuous scanning of these underground sources for your organization's data — email addresses, credentials, and sensitive documents that have leaked through any pathway, including vendor breaches. When a vendor suffers a compromise that exposes your employee credentials, you can know about it within hours rather than months.

This matters because the window between when data is compromised and when it is used is often narrow. Attackers who acquire credential sets act quickly. The sooner you can invalidate compromised credentials and investigate lateral exposure, the better your outcome.

A managed SOC (Security Operations Center) takes this a step further by correlating dark web signals with internal activity — flagging when a compromised credential set is actually being used against your systems and enabling rapid response before the intrusion escalates.

Building a Vendor Risk Program Without a Full-Time Security Team

You do not need a team of security analysts to build an effective vendor risk program. You need a structured process and the right partners.

Start by completing a vendor inventory: every third-party tool, platform, and service provider your organization uses, along with what access each one holds. Then tier those vendors by risk based on data access and system integration depth. Apply your heaviest scrutiny to the top tier and proportional scrutiny to the rest.

Establish an annual review cycle for tier-one vendors that includes requesting updated SOC 2 or equivalent documentation, reviewing any reported incidents, and confirming that contractual obligations remain current. For tier-two and tier-three vendors, a lighter annual review is sufficient.

When onboarding new vendors, the assessment should happen before access is granted — not after the contract is signed and the system is connected.

Third-Party Vendor Risk Is Your Biggest Blind Spot — A Practical Assessment Guide