Vendor risk operations playbook

This playbook is for the practitioner who’s been handed a vendor risk program and asked to make it work. We’ll cover the operational mechanics — not the theory of TPRM, which is well-trodden ground.

What you’ll find here: tiering criteria that actually filter vendors, an intake process that doesn’t bottleneck procurement, contract obligations that produce evidence, and ongoing monitoring that catches issues before they become incidents.

Tier vendors first, then assess

The single biggest TPRM mistake is treating every vendor the same. The intake form, due diligence questionnaire, and ongoing monitoring cadence should all vary based on inherent risk. Without tiering, your high-risk vendors get the same attention as your office snack delivery service.

Tiering criteria that work

Three factors capture most of inherent vendor risk:

Data sensitivity. Does the vendor store, process, or transmit your customer data? Regulated data (PII, PHI, cardholder data, controlled unclassified info)? Or none?

Operational dependency. If the vendor went offline tomorrow, would your business stop functioning? Some vendors are critical (payment processor, identity provider, primary cloud); some are convenient (analytics, monitoring tools).

Contract spend. Higher spend correlates with deeper integration and longer remediation paths.

The simple version: a vendor with high data sensitivity AND high operational dependency is Tier 1. A vendor with one of the two is Tier 2. A vendor with neither is Tier 3. Build out from there if you need more granularity.

Tier counts you should expect

For a typical mid-market company:

Tier 1: 5-15 vendors. AWS/Azure/GCP. Identity provider. Payment processor. Critical SaaS that handles customer data.
Tier 2: 30-60 vendors. Productivity tools that handle some sensitive data. Important-but-not-critical infrastructure.
Tier 3: 100+ vendors. Office tools, marketing, peripheral SaaS, hardware vendors.

If your tier-1 list has more than 25 vendors, the tiering criteria are probably too loose. If your tier-3 list has fewer than 50, you’re probably missing vendors entirely.

Vendor intake

The intake process is where TPRM either succeeds or starts failing.

What intake should accomplish

A good intake form does four things in 5 minutes or less:

Captures the proposed vendor name, the use case, the data they’ll touch, and the business owner.
Auto-assigns a preliminary tier from the inputs.
Routes to the right downstream process — light review for Tier 3, full due diligence for Tier 1.
Sets expectations on timeline (Tier 1 = 2-4 weeks; Tier 3 = same-week).

Anti-patterns

Long intake forms. When intake takes 30 minutes, business owners don’t fill it out. They sign the contract first and tell vendor risk later. This is the most common TPRM failure mode.

Manual tier assignment. “We’ll figure out the tier in the kickoff call.” This adds a week and removes accountability for the criteria.

Same SLA for every vendor. Tier 3 reviews shouldn’t take three weeks. If they do, business owners learn to route around the process.

Realistic SLAs by tier

Tier 1: 2-4 weeks (full due diligence, contract review, security exhibit negotiation)
Tier 2: 1-2 weeks (questionnaire response, contract review)
Tier 3: 2-3 days (basic checks, attestation)

These are realistic for a properly resourced team using modern tooling. Programs running spreadsheets and email will be 2-3x slower across all tiers.

Due diligence

Due diligence is the work of validating a vendor’s security posture before contract signature.

Tier 1 due diligence

The full package:

Security questionnaire response. SIG, CAIQ, or your custom questionnaire. Aim for ~150-300 questions; longer doesn’t add proportional signal.
Independent attestation review. SOC 2 Type II report (or ISO 27001 certificate, or HITRUST, etc.) — read it, not just collect it. Look for exceptions, scope gaps, and the auditor’s observations.
Pen-test summary. Most vendors won’t share full pen-test reports. Summary letters are acceptable; press for issuance dates and remediation status of high-severity findings.
Sub-processor review. Where does the vendor send your data? List sub-processors, their locations, and the legal mechanisms covering each transfer.
Reference check. Optional but valuable — talk to one or two of the vendor’s existing customers about real-world experience.
Contract security exhibit negotiation. Specific commitments — encryption standards, breach notification windows, audit rights, deletion requirements.

This typically runs 20-40 hours of staff time per Tier 1 vendor. Tooling cuts that significantly.

Tier 2 due diligence

The essentials:

Short security questionnaire (~50-100 questions).
SOC 2 Type II or equivalent attestation.
Standard contract security exhibit (templated).

10-15 hours of staff time. Most of it is questionnaire review.

Tier 3 due diligence

Light touch:

Basic intake form check (data they’ll touch confirms tier).
Vendor provides a current attestation (any will do — SOC 2, ISO, HITRUST).
Standard contract clauses; no negotiation.

2-4 hours of staff time. Often done by the business owner with vendor risk just signing off.

Contract obligations

Most security exhibits are written and then forgotten. Done correctly, the security exhibit is the single most important artifact in the vendor relationship — because it specifies what the vendor will be measured against.

What to include

Encryption. At rest, in transit, key management standards.
Access control. Who can access your data; how access is granted/revoked; audit logging requirements.
Breach notification. Timing (24 hours, 48 hours, 72 hours), required content, communication channels.
Audit rights. Right to audit (often via independent third-party); attestation report delivery cadence.
Sub-processor changes. Notification window before adding new sub-processors; right to object.
Data deletion. Timing and verification on contract termination; certification of deletion.
Business continuity. RTO/RPO commitments where relevant.

Make it operational

The contract is signed. Six months later, what happens?

If the vendor’s annual SOC 2 isn’t delivered on time — does anyone notice? If a sub-processor changes — does anyone get notified? If the breach notification window passes during an actual incident — does anyone know?

Operational TPRM means tracking the obligations, not just signing them.

A workable approach: every vendor has a contract obligations record listing each commitment, the trigger that proves compliance (annual attestation delivery, sub-processor list update, etc.), and the next-due date. The system pings the vendor risk team when something is due. The team chases. The chase becomes evidence.

This is where most programs fail. They sign solid contracts and then don’t operate against them.

Ongoing monitoring

Tier 1 vendors require continuous attention; Tier 3 vendors don’t. Calibrate accordingly.

Tier 1 ongoing

Quarterly attestation freshness check (SOC 2 still current, no scope changes).
Monthly security alerts review (any public disclosures about the vendor’s security posture).
Annual full reassessment (refresh the questionnaire, re-validate the contract obligations, re-check sub-processor list).
Real-time monitoring of any direct feeds (SIEM integration, security ratings service if available).

Tier 2 ongoing

Annual reassessment (lighter than Tier 1).
Public-disclosure alerting (subscribe to news for these vendors).

Tier 3 ongoing

Annual attestation refresh.
Spot-check during the year if anything changes.

What to do when something breaks

Vendor incident? Vendor breach notification? Vendor SOC 2 with material exceptions?

A standard response template:

Triage. Internal severity rating based on data sensitivity and scope.
Vendor engagement. Specific questions tied to your data and use case.
Risk reassessment. Update the vendor’s risk rating; revisit tier if needed.
Remediation. Either the vendor remediates, or you do (find an alternative, increase compensating controls, terminate).
Documentation. All of this becomes evidence for your own compliance program.

This template doesn’t change much across incident types. What changes is the speed and rigor of each step.

Offboarding

The most-skipped part of TPRM. Vendors get added; vendors rarely get fully removed.

What proper offboarding looks like

When a vendor relationship ends:

Confirm contract end date.
Trigger data deletion per contract.
Verify deletion (the vendor’s certification of deletion is itself evidence).
Revoke access (deprovision SSO, remove from your IdP).
Remove from the vendor inventory; archive (don’t delete) the historical records.

Why it matters

Stale vendor relationships are a quiet liability. The vendor still has access to data they shouldn’t have. Future audits ask questions about vendors you no longer use. Your sub-processor list (for GDPR Article 28 purposes) becomes inaccurate.

Done right, offboarding takes 1-2 hours per vendor. Done wrong, it doesn’t happen, and the technical debt accumulates.

Tooling

Spreadsheets work for 20-30 vendors. Past that, the operational overhead exceeds what spreadsheets can handle.

What good tooling provides:

A single inventory with tier, owner, and status.
A self-service vendor portal so vendors fill out questionnaires once and reuse the answers.
Contract obligation tracking with due dates and reminders.
Attestation freshness monitoring.
Cross-mapping so vendor evidence (SOC 2 reports, security exhibits) becomes evidence in your own compliance program.
Integration with your IdP for access provisioning/deprovisioning.

What you don’t need:

A vendor risk tool that operates in a silo from your compliance program.
A tool whose questionnaire builder is so rigid you can’t customize it.
A “security ratings” service that scores vendors but doesn’t connect to your operational workflow.

Common questions

How do I get vendors to actually respond to questionnaires? The friction is usually format. Vendors that get the same SIG questions five times a year get tired. Use an industry-standard questionnaire (CAIQ is good). Accept their existing CAIQ response if they have one. Cross-walk to your custom questions only when necessary.

How do I handle vendors who refuse to share their pen-test reports? Most won’t share full reports. Accept summary letters (the “letter of attestation” pattern). What you want is: confirmation of test scope, dates, and whether high-severity findings remain open. Press for those specifically; let the rest go.

How do I prioritize when I have 200 vendors and 1.5 FTEs? Tier ruthlessly. Tier 1 gets full attention; Tier 3 gets a checkbox. The middle is where you’ll have the hardest time — that’s where to invest your most senior judgment. Don’t try to give everyone the same level of rigor.

What’s the minimum bar for a “secure” vendor? There isn’t one universally — it depends on what they do for you. For a vendor handling regulated data: recent independent attestation, current pen-test, signed security exhibit, named security contact. For a vendor handling no sensitive data: a current attestation and standard contract.

How do I know my program is working? Three signals: (1) average vendor review time has stabilized or decreased; (2) the percentage of vendors with current attestations is >90%; (3) you can produce a vendor inventory with tier, status, and last-reviewed date in under 5 minutes.

How Talarity helps

Talarity’s Vendor Management module ships every operational primitive in this playbook: tiered inventory with auto-tiering rules, self-service vendor portal, contract obligation tracking with reminders, attestation freshness monitoring, and cross-mapping so vendor evidence flows into your compliance program automatically.

If you’re rebuilding a TPRM program or scaling one beyond what spreadsheets can handle, we’re happy to walk through the operational workflow in a 30-minute session.