Vendor Risk Assessment: A Third-Party Security Framework

Vendor risk still shows up as a once-a-year spreadsheet at too many companies. That was already a bad idea at twenty vendors. Most enterprises now run on hundreds of SaaS providers, contractors, and downstream processors, and any one of them can be an entry point. A program that holds up does three jobs: tier new vendors in minutes, evaluate their controls with evidence, and keep watching them after the ink dries. You do not need a twelve-person GRC team. You need a framework you will actually use.

Start With Intake Tiering

Not every vendor deserves the same scrutiny. A stationery supplier and an identity provider are both "vendors" on paper. One of them holds the keys to your SSO. Tiering is how you stay proportional so assessment fatigue does not bury the signal.

The Four-Tier Model

Four tiers is enough. Call them whatever you want; the cut lines matter more than the labels.

1. Critical vendors: Direct access to production data, authentication, payment rails, or core infrastructure. Examples include your IdP, cloud hosting provider, payroll processor, and source code management platform.
2. High-risk vendors: Handle regulated data (PII, PHI, cardholder data) or integrate with customer-facing systems.
3. Medium-risk vendors: Limited access to internal data, indirect integrations, or non-sensitive business workflows.
4. Low-risk vendors: No access to corporate systems or data (office supplies, catering, most marketing swag).

The intake form should collect enough information to assign a tier in under ten minutes. Ask about data types, system integrations, user counts, geographic processing locations, and whether the vendor will be granted any level of network or identity access. A short, well-designed intake saves weeks of rework later.

Why Tiering Drives Everything Else

Tiering determines your assessment depth, reassessment cadence, required contractual clauses, and continuous monitoring investment. A critical vendor might warrant a full technical review plus quarterly check-ins; a low-risk vendor might only require an attestation and an annual refresh. Get the tiers wrong and everything downstream is wasted work.

Assessment Methodology

Once a vendor is tiered, you still have to evaluate them in a way you can repeat and defend. That means questionnaires plus evidence, not questionnaires instead of evidence.

SIG Lite vs SIG Core vs Custom

Shared Assessments' Standardized Information Gathering (SIG) questionnaire is the de facto industry standard. It maps to ISO 27001, NIST CSF, SOC 2 Trust Services Criteria, and most major privacy regimes.

• SIG Lite: Around 125 high-level questions. Appropriate for medium-risk vendors where you need coverage breadth but not forensic depth.
• SIG Core: Over 800 questions spanning 19 risk domains. Reserve this for critical and high-risk vendors where the stakes justify the effort on both sides.
• Custom supplemental questions: Every organization has niche concerns (Kubernetes hardening, specific data residency requirements, AI model governance) that generic questionnaires do not address. Maintain a short library of supplemental modules that you attach based on vendor type.

Avoid the trap of sending SIG Core to every vendor. Response quality plummets when vendors feel buried, and your analysts burn out reviewing irrelevant answers.

Evidence Over Attestation

Questionnaires are self-reported. Treat them as a starting point, not proof. For any answer that matters, request artifacts: SOC 2 Type II reports, ISO 27001 certificates, penetration test summaries, architecture diagrams, and incident response runbooks. A vendor that cannot produce evidence on request is telling you something important.

Reading SOC 2 Reports Like an Auditor

SOC 2 Type II reports are dense, and vendors know most reviewers skim them. The useful signal lives in a handful of specific places.

Red Flags to Hunt For

• Scope carve-outs: Look at which Trust Services Criteria are in scope. Many vendors only cover Security, omitting Availability, Confidentiality, Processing Integrity, or Privacy. If you need those, a Security-only report does not cover you.
• Subservice organizations: Check whether critical functions are delegated and whether the report uses the inclusive or carve-out method. Carved-out subservice organizations mean you still need separate assurance for them.
• Complementary User Entity Controls (CUECs): These are the controls the vendor assumes you will implement on your side. Read them carefully. If you are not meeting them, the vendor's controls may not protect you the way you think.
• Exceptions and deviations: The testing section is where auditors document failures. A few minor exceptions are normal; a pattern of failed access reviews, missing log retention, or uncorrected findings is not.
• Auditor reputation: Who signed the report matters. A Big Four firm and an obscure regional shop do not carry equal weight.
• Report period gaps: A Type II with a four-month observation window tells you far less than one covering twelve months.

The Cover-Letter Trick

Reputable vendors will share the full report under NDA. If a vendor only sends you the auditor's cover letter or a "SOC 2 bridge letter," push back. Bridge letters are appropriate between report periods, but they should supplement a real report, not replace one.

Continuous Monitoring Inputs

Point-in-time assessments expire the moment they are signed. Continuous monitoring closes the gap between annual reviews by watching vendors for signs of trouble in real time.

Signals That Actually Predict Risk

• Breach feeds and attribution data: Public breach disclosures are the most obvious signal, but breach attribution often lags by weeks or months. Subscribe to primary sources, not just news aggregators.
• Credential exposures for vendor domains: Infostealer logs containing vendor employee or customer credentials are a leading indicator of unresolved endpoint compromise. Revealer.US can surface this for third parties: run vendor-associated emails through a data breach lookup or check stealer log collections for credentials tied to the vendors you track.
• Dark web chatter: Mentions of vendor names on initial access broker forums or ransomware leak sites are a near-certain prelude to incident disclosure.
• TLS and DNS hygiene: Certificates about to expire, misconfigured DMARC, and exposed admin panels all speak to operational discipline.
• Code repository leaks: Public GitHub commits containing vendor API keys or internal hostnames.

Skip the wall of dashboards. Raise a prioritized alert the moment a vendor crosses a threshold that would change your risk decision. To automate these checks in your own pipeline, the Revealer.US API docs cover programmatic access.

Contractual Security Requirements

Contracts turn expectations into obligations. Weak contract language makes enforcement impossible after something goes wrong.

Clauses Worth Negotiating

• Incident notification windows: Specify hours, not days. Twenty-four to forty-eight hours is reasonable for critical vendors.
• Right to audit: Reserve the right to perform or commission an audit, subject to reasonable scheduling and confidentiality.
• Subprocessor disclosure: Require advance notice of new subprocessors with a right to object.
• Data location and residency: Pin down where data is stored, processed, and backed up.
• Security control floors: Reference SOC 2, ISO 27001, or an equivalent framework as a baseline, not just a marketing claim.
• Deletion and return obligations: At termination, what happens to your data and on what timeline.
• Liability carve-outs for security incidents: Negotiate carve-outs from general liability caps for breaches of confidentiality and security obligations.

Legal and security teams need to co-own these clauses. Security writes what is needed; legal writes what is enforceable.

When to Offboard a Vendor

Sometimes the right answer is exit, and good programs know when to pull the trigger without drama.

Triggers That Justify Termination

1. Repeat incidents involving the same root cause with no evidence of remediation
2. Material misrepresentation in questionnaires or SOC 2 scopes
3. Failure to notify within contractually required windows
4. Subprocessor changes that violate data residency or sovereignty requirements
5. Sustained credential exposure indicating uncontrolled endpoint compromise
6. Loss of key certifications without a remediation plan

Offboarding is painful and expensive, which is why it gets deferred. Build the muscle before you need it: document exit criteria in advance, keep data export tooling current, and run at least one tabletop exercise per year on a simulated vendor failure.

Frequently asked questions

What is a vendor risk assessment?

The process of evaluating a third party's security posture before and during the relationship: what data and access they hold, what controls they operate, and what evidence backs their claims. Done well, it runs continuously, not just at contract signing.

How often should vendors be reassessed?

Let the tier drive the cadence. Critical vendors warrant a full technical review plus quarterly check-ins. High and medium risk vendors typically get annual reassessment. Low-risk vendors can often run on attestation with an annual refresh.

What is the difference between SIG Lite and SIG Core?

SIG Lite is around 125 high-level questions, suited to medium-risk vendors where breadth matters more than depth. SIG Core is over 800 questions across 19 risk domains and is reserved for critical and high-risk vendors where the stakes justify the effort on both sides.

Is a SOC 2 report enough evidence on its own?

No. Read the scope (which Trust Services Criteria are covered), the subservice organization method, the CUECs, and the exceptions section. Pair the report with other artifacts like penetration test summaries and incident response runbooks before you rely on it.

What is the best early-warning signal for vendor risk?

Credential exposure tied to the vendor's domain. Vendor employee credentials appearing in stealer logs or breach datasets usually precede public incident disclosure, along with ransomware leak-site mentions and initial access broker chatter.

When should a company offboard a vendor?

When the relationship shows repeat incidents with the same root cause, material misrepresentation in assessments, missed incident notification windows, subprocessor changes that break residency requirements, sustained credential exposure, or lost certifications with no remediation plan.

Conclusion

A vendor risk framework that lives in a binder is already dead. The version that works tiers vendors, demands evidence, and keeps watching for trouble after the contract is signed. Treat third-party risk as part of your own perimeter, because that is what it is.

If you are starting from scratch, start with tiering and continuous monitoring. Those two catch most of the supply-chain risk that questionnaire-first programs miss.

Want to add supply chain risk signals to your vendor program? Start a free trial of Revealer.US and watch your third parties the same way you watch your own domains.