Third-Party Risk Management: How to Assess Your Vendors Without Losing Your Mind

Your company uses dozens, maybe hundreds, of third-party vendors. SaaS platforms that store your customer data. Cloud providers that host your infrastructure. Payment processors that handle financial transactions. HR platforms that hold employee Social Security numbers. Marketing tools with access to your CRM. Every single one of them is an extension of your attack surface.

And most of them have security programs that would make you uncomfortable if you looked closely.

Third-party risk management (TPRM) is not a nice-to-have. It is the reason Target lost 40 million credit card numbers through an HVAC vendor. It is the reason the MOVEit breach cascaded through thousands of organizations in 2023. It is the reason Okta's breach in 2023 started with a compromised support case management system and expanded to affect every customer who had ever opened a support ticket. Your security is only as strong as your weakest vendor.

The problem is that most TPRM programs are either nonexistent or impossibly bureaucratic. You either have no vendor risk process at all, or you have a process that takes six months to onboard a $500/month SaaS tool. Neither extreme works. This guide is the practical middle ground: a framework for assessing vendor risk that actually scales without requiring a dedicated GRC team.

Why Third-Party Risk Matters More Than Ever

The shift to cloud-first, SaaS-everywhere infrastructure means your data lives in places you do not control. A decade ago, most of your sensitive data sat on servers in your own data center. Today, it is spread across dozens of vendor environments, each with their own security posture, their own vulnerabilities, and their own employees with access to your information.

The Breach Record Speaks for Itself

The case studies are not theoretical. They are a recurring pattern that shows no signs of slowing down.

Target (2013): Attackers compromised Fazio Mechanical Services, Target's HVAC vendor, through a phishing email. From there, they pivoted into Target's network using vendor VPN credentials and eventually accessed point-of-sale systems. The result: 40 million credit card numbers stolen, $18.5 million in settlement costs, and a CEO resignation. The HVAC company had network access that should never have existed.

SolarWinds (2020): Attackers compromised the build system for SolarWinds Orion, inserting a backdoor into a software update that was distributed to 18,000 customers, including multiple U.S. government agencies and Fortune 500 companies. This was not a vulnerability in the product. It was a compromise of the vendor's development pipeline.

Kaseya (2021): The REvil ransomware gang exploited vulnerabilities in Kaseya's VSA remote management software, which was used by managed service providers. The attack cascaded downstream, encrypting data at an estimated 1,500 businesses through a single vendor compromise.

MOVEit (2023): A zero-day SQL injection vulnerability in Progress Software's MOVEit Transfer file-sharing platform was exploited by the Cl0p ransomware gang. Because so many organizations used MOVEit for sensitive file transfers, the breach affected over 2,600 organizations and exposed data on more than 77 million individuals. Many of the affected organizations had no direct relationship with MOVEit. They were downstream victims, their data exposed because a vendor or a vendor's vendor used the platform.

Okta (2023): Attackers compromised Okta's support case management system using a stolen service account credential. They accessed HAR files that customers had uploaded during troubleshooting, which contained session tokens. The initial disclosure suggested limited impact. Weeks later, Okta revised the number to include every customer who had ever contacted support. The lesson: even your identity provider is a third-party risk.

The Vendor Risk Assessment Lifecycle

Effective TPRM is not a one-time activity. It is a lifecycle with four phases: identification, assessment, monitoring, and offboarding. Most organizations only do the first two, and they do those poorly. Here is what each phase looks like when done right.

Phase 1: Vendor Identification and Inventory

You cannot assess risk for vendors you do not know about. The first step is building a complete inventory of every third party that has access to your data, your systems, or your network. This is harder than it sounds.

Start with the obvious sources: procurement records, accounts payable, and IT asset inventories. Then go deeper. Check SSO and identity provider logs for all connected applications. Review DNS records for CNAME entries pointing to vendor platforms. Scan network traffic for connections to external services. Ask department heads what tools their teams use daily.

Shadow IT is the enemy of vendor identification. Marketing signed up for a data enrichment tool with a corporate credit card. Sales is using an AI transcription service for call recordings. Engineering spun up a third-party monitoring tool on a free trial that became permanent. Every one of these is a vendor with access to your data, and none of them went through procurement.

Your inventory should capture, at minimum: vendor name, what data they access, how they connect to your systems, who owns the relationship, contract expiration date, and when the last risk assessment was performed.

Phase 2: Risk Assessment

Once you know who your vendors are, you need to assess each one. The depth of assessment should be proportional to the risk the vendor represents. A vendor that processes credit card numbers gets a deeper review than a vendor that provides stock photography. We will cover tiering in the next section.

Assessment methods include security questionnaires, review of compliance certifications and SOC reports, technical security testing, on-site assessments for critical vendors, and automated risk rating services. The right combination depends on the vendor's tier and your organization's risk tolerance.

Phase 3: Ongoing Monitoring

An annual assessment is a snapshot. It tells you what a vendor's security posture looked like on the day they filled out the questionnaire. It tells you nothing about the other 364 days of the year. Continuous monitoring fills the gap between point-in-time assessments. This includes monitoring for data breaches and security incidents affecting your vendors, tracking changes to their compliance certifications, watching for negative press and regulatory actions, scanning their external attack surface for new vulnerabilities, and reviewing access logs for vendor accounts in your systems.

Phase 4: Vendor Offboarding

When a vendor relationship ends, the security work is not done. It is just beginning. Vendor offboarding is consistently the most neglected phase of TPRM, and it is where some of the worst exposures occur. If you have read our guide on employee offboarding and access reviews, you know that stale access is a systemic problem. Vendor offboarding is the same problem at a larger scale.

Offboarding should include: revoking all credentials and API keys, disabling SSO integrations and OAuth connections, confirming data deletion or return per contractual requirements, removing network access rules and firewall exceptions, updating your vendor inventory, and retaining assessment records for compliance purposes.

Tiering Vendors by Risk

Not every vendor deserves the same level of scrutiny. A vendor that hosts your production database is not the same risk as a vendor that provides your office snack subscription. Tiering allows you to focus your limited resources where they matter most.

Security Questionnaires: What to Ask and What the Answers Mean

Security questionnaires are the most common tool for vendor risk assessment. They are also one of the most misused. A 400-question spreadsheet that sits in a shared drive for three months and gets reviewed by someone who does not understand the answers is theater, not risk management. Here is how to do it properly.

Standard Questionnaire Frameworks

SIG (Standardized Information Gathering): Maintained by Shared Assessments, the SIG questionnaire comes in two versions. SIG Core is the comprehensive version with 800+ questions covering 19 risk domains. SIG Lite is the abbreviated version with around 200 questions for lower-risk vendors. SIG is the most widely used framework in financial services and healthcare. If you are building your own program, SIG Lite is a reasonable starting point for high-risk vendors, and it saves you from reinventing the wheel.

CAIQ (Consensus Assessments Initiative Questionnaire): Published by the Cloud Security Alliance, the CAIQ is specifically designed for cloud service providers. It maps directly to the CSA Cloud Controls Matrix and covers 261 questions across 17 domains. If you are assessing SaaS vendors and cloud infrastructure providers, the CAIQ is more relevant than a general-purpose questionnaire because it asks the right questions about multi-tenancy, data isolation, and shared responsibility models.

Custom questionnaires: Many organizations build their own questionnaires, either from scratch or by adapting SIG or CAIQ. The advantage is that you can focus on questions that matter most to your industry, your regulatory environment, and your specific risk concerns. The disadvantage is that vendors hate filling out custom questionnaires because they cannot reuse answers. A vendor that gets 50 unique questionnaires a year from 50 different customers is not going to give your custom form the same attention as a standard framework they have already completed.

Questions That Actually Matter

Regardless of which framework you use, these are the questions that separate vendors with real security programs from those with checkbox compliance:

• Do you encrypt data at rest and in transit? The right answer includes specific algorithms (AES-256, TLS 1.2+) and key management practices. "Yes" without details is a red flag.
• How do you manage access to customer data? Look for role-based access control, least privilege principles, regular access reviews, and MFA for all employees. If they say "admin access is restricted to senior engineers," ask how many senior engineers that includes.
• When was your last penetration test, and what were the results? A vendor that has never been penetration tested, or was tested more than 12 months ago, is behind. Ask for the executive summary. If they will not share it, that tells you something.
• What is your incident response process, and what is the notification timeline? You want a documented process, a named incident response team, and a commitment to notify affected customers within a defined period (72 hours or less for critical incidents).
• Do you have a vulnerability management program? Ask about scanning frequency, patching SLAs (critical vulnerabilities within 24-48 hours, high within 7 days), and how they handle zero-day disclosures.
• How is customer data segregated in your multi-tenant environment? Logical separation at the database level is minimum. Ask whether customer data can ever be accessed by other tenants' API calls. Ask about row-level security versus schema-level separation.
• What happens to our data when the contract ends? You want a defined data retention and deletion policy with a specific deletion timeline and certification of destruction.

Reading Between the Lines

The way vendors respond is often as informative as what they say. Vendors that respond quickly and thoroughly have a mature security program with documentation ready to share. Vendors that take months to respond are either disorganized or building their answers in real time. Vendors that provide boilerplate marketing language instead of specific technical details are hiding gaps. Vendors that refuse to answer specific questions about encryption, access control, or incident response are telling you everything you need to know.

SOC 2 Reports: How to Actually Read One

Most companies treat SOC 2 reports like a diploma on the wall. The vendor has one, so they must be secure. Check the box and move on. That is not how SOC 2 works, and reading the report properly takes less time than you think.

Type I vs. Type II

A SOC 2 Type I report evaluates whether controls are designed properly at a specific point in time. A SOC 2 Type II report evaluates whether those controls operated effectively over a period of time, usually 6 to 12 months. Type II is significantly more valuable because it proves the vendor actually runs their security program consistently, not just that they had the right policies on audit day. If a vendor only has a Type I, ask when their Type II will be available. If they have no timeline, that is a concern.

What to Look for in Section IV: The Testing Results

Skip to Section IV first. This is where the auditor describes each control, the test they performed, and the result. You are looking for three things:

1. Exceptions. An exception means a control did not operate as described during the audit period. Some exceptions are minor (a quarterly review happened a week late). Others are critical (access reviews were not performed at all, or terminated employees retained access for months). Read every exception and evaluate its severity in context.
2. Qualified opinions. The auditor's opinion in Section I will say either "no exceptions noted" (clean opinion) or "except for the matters described" (qualified opinion). A qualified opinion means material control failures were identified. This does not automatically disqualify a vendor, but it means you need to understand what failed and what the vendor is doing about it.
3. Scope exclusions. SOC 2 audits are scoped to specific systems. If a vendor's SOC 2 only covers their marketing website and not the platform where your data actually lives, the report is irrelevant. Check the system description in Section III to confirm that the services you use are in scope.

The Trust Services Criteria That Matter

SOC 2 reports cover one or more Trust Services Criteria: Security (required), Availability, Processing Integrity, Confidentiality, and Privacy. Most vendors only include Security. If a vendor stores your data, you want Confidentiality included. If uptime matters to your business, check for Availability. If the vendor processes transactions, Processing Integrity is relevant. If they handle personal information, Privacy should be present.

Continuous Monitoring vs. Annual Assessment

The annual vendor assessment model is broken. A questionnaire filled out in January tells you nothing about a vendor that gets breached in July. Between assessments, vendors change their infrastructure, rotate staff, adopt new subprocessors, and experience incidents that they may or may not disclose to you.

Continuous monitoring does not mean real-time review of every vendor's security posture. That is unrealistic for any organization without a dedicated vendor risk team. It means implementing automated signals that alert you when something changes.

What Continuous Monitoring Looks Like in Practice

• Breach notification feeds: Subscribe to breach notification services that track disclosed incidents. When a vendor appears on a breach list, you get alerted immediately rather than finding out when reporters start calling.
• External attack surface scanning: Services like SecurityScorecard, BitSight, and UpGuard continuously scan your vendors' public-facing infrastructure and assign risk scores based on observable security indicators (open ports, expired certificates, unpatched systems, email security configuration).
• Compliance status tracking: Monitor whether vendors maintain their certifications. A SOC 2 report has a period. If a vendor's audit period ended eight months ago and there is no new report, their compliance status is stale.
• News and regulatory monitoring: Google Alerts are free. Set alerts for each critical vendor's name combined with terms like "breach," "vulnerability," "fine," or "investigation."
• Access log review: For vendors with direct access to your systems, review their access patterns monthly. Are they accessing data outside their scope? Are they logging in from unexpected locations? Are terminated vendor employees still showing up in your logs?

The right approach is both. Annual assessments provide depth. Continuous monitoring provides breadth. Use annual assessments as the baseline for critical and high-tier vendors, and layer continuous monitoring on top for vendors where a breach would directly affect your organization.

Contract Security Requirements

Your vendor contracts are the only enforceable mechanism you have for holding third parties accountable. A questionnaire answer is a claim. A contract clause is a legal obligation. If your contracts do not include security requirements, you have no recourse when something goes wrong.

Essential Contract Clauses

Data handling and classification: The contract should specify exactly what data the vendor will access, how it must be classified, where it can be stored (geographic restrictions matter for GDPR), and who can access it. Vague language like "vendor will implement appropriate security measures" is unenforceable. Specific language like "vendor will encrypt all customer data at rest using AES-256 and in transit using TLS 1.2 or higher" is enforceable.

Breach notification requirements: Specify the notification timeline. 72 hours is the GDPR standard and a reasonable baseline. Require that the notification include what data was affected, how the breach occurred, what remediation steps are being taken, and a point of contact for your incident response team. Without this clause, a vendor can delay notification indefinitely while they "investigate."

Right to audit: This clause gives you the right to assess the vendor's security controls, either through your own team, a third-party auditor, or by reviewing the vendor's SOC 2 and penetration test reports. Many vendors will push back on on-site audits but will agree to share their most recent SOC 2 Type II report and penetration test executive summary. That is usually sufficient for all but the most critical vendors.

Subprocessor disclosure: Your vendor almost certainly uses other vendors. If your data flows to those subprocessors, you need to know. Require disclosure of all subprocessors that handle your data, along with notification when subprocessors change. This is how MOVEit-type cascading breaches happen: you assessed your vendor, but not your vendor's vendor.

Data retention and deletion: Specify how long the vendor can retain your data and what happens when the contract ends. Require a certification of data destruction, including backup deletion, within a defined period (30 days is standard). "We will delete your data upon request" is not the same as "we will certify deletion of all copies within 30 days of contract termination."

Security standards compliance: Require the vendor to maintain specific certifications (SOC 2 Type II, ISO 27001) throughout the contract period, not just at the time of signing. Include a clause that allows you to terminate the contract if the vendor loses certification or experiences a material security incident that is not remediated within a defined period.

Vendor Access Management

When you give a vendor access to your systems, you are extending your trust boundary. Every vendor account is an attack vector. The Target breach started with compromised vendor credentials. The principle is simple: give vendors only the access they need, monitor that access continuously, and revoke it the moment it is no longer required.

Least Privilege

Vendor accounts should have the minimum permissions necessary to perform their contracted function. If a vendor needs read access to a specific database table, do not give them admin access to the entire database server. If they need to push code to a staging environment, do not give them access to production. If they need access for two weeks during an implementation, set an automatic expiration date.

Most organizations get this wrong by defaulting to broad access because it is easier. Setting up granular permissions takes more time upfront. But the cost of a vendor account with excessive privileges being compromised is orders of magnitude higher than the cost of configuring least-privilege access correctly.

Dedicated Accounts

Vendor personnel should always use dedicated, named accounts, never shared credentials. Every action taken by a vendor should be attributable to a specific person. Shared accounts like "vendor-support" or "contractor-admin" make it impossible to trace activity to an individual, which means you cannot detect malicious behavior until the damage is done.

Require multi-factor authentication on all vendor accounts with no exceptions. If a vendor tells you their employees cannot use MFA, that vendor has a security program you cannot trust.

Monitoring Vendor Access

Log everything. Vendor account activity should be monitored with the same rigor as privileged employee accounts, arguably more. Set alerts for after-hours access, bulk data downloads, access to systems outside the vendor's scope, and any administrative actions. Review vendor access logs at least monthly for critical vendors. Feed vendor account activity into your SIEM if you have one.

SaaS Security Posture Management (SSPM)

As your SaaS vendor count grows, managing configurations across all of them becomes a security problem in itself. SSPM tools address this by continuously monitoring the security configuration of your SaaS applications and alerting you when something drifts from your baseline.

The core functions of SSPM include:

• Configuration monitoring: Detecting when a SaaS application's security settings change. Did someone disable MFA enforcement in your Salesforce org? Did a new OAuth integration get approved? Did file sharing permissions change from "company only" to "anyone with the link"?
• Privilege analysis: Mapping who has access to what across all your SaaS platforms. Identifying users with excessive privileges, dormant accounts, and external users with persistent access.
• Compliance mapping: Checking SaaS configurations against frameworks like SOC 2, ISO 27001, and CIS benchmarks. This helps you demonstrate that your vendor configurations meet your compliance obligations.
• Shadow SaaS detection: Identifying SaaS applications that are being used without IT or security approval by analyzing OAuth tokens, browser extensions, and network traffic.

SSPM is particularly valuable for companies with 50+ SaaS applications where manual configuration reviews are not feasible. If your organization is at the stage described in our guide on security after Series B, SSPM is worth evaluating as part of your vendor risk program.

Building a Lightweight TPRM Program Without a GRC Team

You do not need a dedicated governance, risk, and compliance team to run an effective third-party risk program. You need a process that scales with your vendor count and a person who owns it. Here is how to build one from scratch.

Step 1: Assign Ownership

Someone needs to own TPRM. In smaller organizations, this often falls to the head of IT, the security lead, or the operations manager. In larger organizations without a GRC team, it might be a shared responsibility between security and procurement. What matters is that one person is accountable for ensuring vendors are assessed before onboarding and monitored after.

Step 2: Build Your Vendor Inventory

Use a spreadsheet. Seriously. Do not buy a vendor risk platform until you have outgrown a spreadsheet. Your inventory should list every vendor, what data they access, their risk tier, the date of their last assessment, and who owns the relationship internally. Review and update this quarterly.

Step 3: Create Tiered Assessment Templates

Build three questionnaire templates: comprehensive (for critical vendors), standard (for high-risk vendors), and abbreviated (for medium-risk vendors). Low-risk vendors do not need a formal questionnaire. Base your templates on SIG Lite or CAIQ, then customize for your industry and regulatory requirements. A 50-question abbreviated questionnaire is more effective than a 400-question comprehensive one that nobody reviews.

Step 4: Integrate with Procurement

The single most important process change is making vendor risk assessment a prerequisite for vendor onboarding. No contract gets signed without a risk assessment appropriate to the vendor's tier. This means security has to be involved in procurement early enough that the assessment does not block the deal. Set SLAs: low-risk assessments in 2 business days, medium in 5, high in 10, critical in 15.

Step 5: Automate What You Can

Use free tools first. Google Alerts for breach monitoring. Have I Been Pwned for email domain monitoring. Qualys SSL Labs for checking vendor TLS configuration. Browser-based port scanning tools for quick external checks. As your program matures, consider investing in a vendor risk management platform that automates questionnaire distribution, tracks responses, and maintains your vendor inventory.

Step 6: Review and Improve Quarterly

Every quarter, review your vendor inventory for completeness, check that assessments are up to date, discuss any vendor incidents or concerns, and update tiering for vendors whose scope has changed. This should take two to four hours per quarter for a company with 50-100 vendors. That is manageable without a dedicated team.

Tools for Vendor Risk Management

The TPRM tooling market ranges from spreadsheets to enterprise platforms. Here is what is available at each level.

Start with what you have. A well-maintained spreadsheet with quarterly reviews is better than an expensive platform that nobody updates. Buy tooling when the manual process becomes a bottleneck, not before.

When to Walk Away: Vendor Security Red Flags

Not every vendor relationship is worth the risk. Some vendors have security postures so poor that no amount of contractual protection or monitoring will mitigate the exposure. Here are the red flags that should make you reconsider the relationship.

• No SOC 2 report and no timeline to get one. For any vendor handling sensitive data, the absence of a SOC 2 or ISO 27001 certification, combined with no plan to achieve one, means security is not a priority. If they are unwilling to invest in an audit, they are unlikely to invest in the controls an audit would evaluate.
• Refusal to complete a security questionnaire. Vendors that refuse to answer basic security questions are either hiding something or do not have the answers. Either way, you cannot assess what you cannot see.
• No penetration testing history. A vendor that has never been penetration tested has unknown vulnerabilities. They may have good security. They may not. Without testing, neither you nor they know the answer.
• Shared credentials or no MFA. If a vendor admits to using shared accounts or does not enforce multi-factor authentication for their employees, their identity and access management is fundamentally broken.
• Vague or nonexistent incident response plan. Ask what happens when they get breached. If the answer is vague ("we will investigate and notify affected parties"), they do not have a real plan. Real plans have named roles, runbooks, communication templates, and defined timelines.
• Undisclosed subprocessors. If a vendor will not tell you which third parties have access to your data, you cannot assess the full chain of risk. This is non-negotiable for any vendor handling regulated data.
• History of breaches with no evidence of improvement. A single breach is not necessarily disqualifying. Breaches happen. But a vendor that has been breached and cannot demonstrate what they changed afterward will be breached again.
• Unwillingness to include security terms in the contract. If a vendor will not agree to breach notification timelines, data deletion requirements, or right-to-audit clauses, they are telling you that they do not want to be held accountable. Believe them.

Putting It All Together

Third-party risk management is not a project. It is an ongoing discipline. The organizations that get it right treat vendor risk with the same seriousness as their own internal security program, because a vendor breach is your breach as far as your customers and regulators are concerned.

Start small. Build a vendor inventory. Tier your vendors by risk. Assess critical vendors first. Add contract security clauses to new agreements. Set up basic continuous monitoring. Review quarterly. Expand the program as your vendor count and regulatory obligations grow.

The goal is not perfection. The goal is a defensible program that demonstrates reasonable due diligence, catches the most dangerous risks, and gives you the information you need to make informed decisions about who gets access to your data.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.