Managing Third Party Vendor Risk

Managing Third-Party Vendor Risk

When to Use

• When assessing a new vendor before onboarding, especially one that will handle sensitive data, connect to your network, or be embedded in a critical process.
• When standing up or maturing a third-party risk management (TPRM) program and you need a repeatable tiering + assessment workflow.
• When tiering an existing vendor portfolio so effort matches risk.
• When reviewing vendor evidence — a SOC 2 Type II report, ISO 27001 certificate, CAIQ, or pen-test summary — and you need to know what to look for.
• When writing security and privacy requirements into a contract / DPA, including breach-notification SLAs and right-to-audit.
• When a vendor (or their subcontractor) suffers a breach and you must assess exposure.
• When managing software supply-chain and Nth-party (fourth-party and beyond) risk.

Prerequisites

• A vendor inventory (who you use, for what, and what data/access each has).
• A defined risk-tiering model (criteria and thresholds) agreed with the business.
• Access to standardized questionnaires (Shared Assessments SIG, CSA CAIQ) and a way to collect evidence.
• Clarity on your own regulatory obligations that flow down to vendors (e.g., HIPAA BAAs, CMMC flowdown, GDPR processor terms, PCI).
• Stakeholders identified: procurement, legal, security, data owner, and the business sponsor.

Workflow

1. Inventory and classify vendors

Catalog every third party and capture: data sensitivity handled, type of access (network, physical, none), business criticality, and regulatory scope. You cannot manage what you have not inventoried — shadow vendors are a common blind spot.

2. Tier by inherent risk

Score each vendor on inherent-risk factors (data sensitivity, access, criticality, regulatory scope, spend/concentration) and assign a tier (e.g., Critical / High / Moderate / Low). The tier drives how deep the assessment goes and how often you reassess. A payroll processor with PII and system access is not the same risk as a stock-photo subscription.

3. Run tier-appropriate due diligence

• Critical/High: full SIG (or SIG Core), request SOC 2 Type II and/or ISO 27001, recent pen-test summary, and evidence of an incident-response capability. Consider an assessor call.
• Moderate: SIG Lite or CAIQ, plus key attestations.
• Low: lightweight questionnaire / self-attestation.

4. Review evidence critically

Don't just collect — read:

• SOC 2 Type II: check scope, the Trust Services Criteria covered, the audit period (not just the date), and especially the exceptions/deviations and any qualified opinion. A clean cover page can hide noted exceptions.
• ISO 27001: confirm the scope statement and the Statement of Applicability actually cover the service you're buying.
• CAIQ: look for "no" answers and CCM domains left blank.
• Pen-test: age, scope, and whether highs/criticals were remediated.

5. Identify gaps and decide

Compare findings against your control requirements. For each gap: accept, require remediation (with a date), add a compensating control on your side, or walk away. Record the residual risk and a risk-owner decision.

6. Codify in the contract / DPA

Bake requirements into the agreement: security control obligations, breach-notification timeline, data-handling and return/destruction terms, right-to-audit / right to assessment evidence, subcontractor (Nth-party) flowdown, and liability/insurance. Contracts are where TPRM gets teeth.

7. Monitor continuously

Tiering is not a one-time gate. For higher tiers: periodic reassessment, security-ratings feeds, breach/news monitoring, certificate-expiry tracking, and watching for material changes (acquisition, region change, new subprocessors). Re-tier on change.

8. Manage Nth-party and concentration risk

Map critical fourth parties (your vendor's key subprocessors) and watch for concentration (many vendors riding on the same upstream provider) — a single upstream outage or breach can hit your whole portfolio at once.

9. Offboard securely

On termination: revoke access and credentials, confirm data return or certified destruction, remove integrations/API keys, and update the inventory. Un-offboarded vendors are standing risk.