Third Party Risk Management Basics

Third party risk management (TPRM) is how you reduce the security, privacy, and operational risk introduced by vendors—SaaS apps, MSPs, contractors, and partners—across the full lifecycle from onboarding to offboarding. This guide covers TPRM basics, including vendor tiering, evidence-based assessments (like SOC 2 reviews), contract security clauses, and continuous monitoring so vendor risk management stays scalable.

How it works

TPRM is a lifecycle program, not a one-time questionnaire. Mature programs are lightweight for low-risk vendors and rigorous for vendors that touch sensitive data or critical systems.

1) Build an inventory (what vendors exist and what they touch)

Start with a living list of third parties and fourth parties (key subcontractors). For each vendor, capture:

• Service provided (e.g., payroll, CRM, EDR, data warehouse, call center)
• Data types handled (PII, PHI, PCI, customer secrets, source code)
• Access level (none, SSO-only, API access, admin access, network connectivity)
• Business criticality (can you operate without them?)
• Geography / data residency (where data is stored/processed)
• Contract owner and renewal date

Practical sources for discovery - Accounts payable / expense systems (who gets paid) - SSO directory and OAuth app lists (who is connected) - DNS and proxy logs (who endpoints talk to) - Cloud marketplace purchases (AWS/Azure/GCP) - Procurement and legal repositories

2) Tier vendors by inherent risk (so you scale effort)

Risk tiering is how you avoid sending 200-question security forms to a low-impact vendor.

Common tier inputs: - Data sensitivity: Does the vendor store or process regulated or confidential data? - Privilege: Does it have admin access, production access, or write access via API? - Blast radius: Could compromise disrupt operations or customer trust? - Concentration risk: Is this a single point of failure (e.g., only payroll provider)? - Exposure: Is it internet-facing and integrated broadly?

A typical model: - Tier 1 (High): Processes sensitive data or has privileged access; critical to operations - Tier 2 (Medium): Limited sensitive data; limited access; important but not critical - Tier 3 (Low): No sensitive data; minimal access; easily replaceable

3) Perform due diligence (evidence-based assessment)

For each tier, define the minimum evidence you require.

Common assessment methods - Security questionnaire aligned to your control framework (NIST CSF, ISO 27001, CIS) - Independent assurance reports: SOC 2 Type II, ISO 27001 certificate, PCI AoC (when relevant) - Architecture and integration review: SSO/SAML/OIDC, SCIM, API scopes, network paths - Privacy review: DPA, subprocessor list, retention/deletion, data subject rights - Resilience review: BCP/DR, RTO/RPO, incident history, status page, redundancy

What “good” looks like (for higher-risk vendors) - Enforced MFA for administrative access and strong identity controls - Encryption in transit and at rest (and clear key management practices) - Logged and monitored privileged actions - Defined incident response with customer notification timelines - Documented vulnerability management and patch SLAs - Penetration testing (or equivalent) with remediation workflow - Clear subprocessor oversight and data flow transparency

Practical tip: If a vendor claims “we’re SOC 2 compliant,” ask for the actual SOC 2 Type II report, scope, and the audit period—then verify carve-outs and subservice organizations. This is also where supply-chain style issues can hide; if you need a quick primer on how suppliers can become an attack path, see our explainer on supply chain attacks.

4) Decide and document risk treatment

Assessment outputs should lead to a decision: - Accept (risk within tolerance) - Mitigate (require changes, compensating controls, or configuration hardening) - Transfer (contractual terms, cyber insurance where appropriate) - Avoid (don’t onboard / replace)

Track risks with owners and due dates. If you accept a risk, record the rationale—this is what auditors and incident responders will look for later.

5) Put security requirements in contracts (where leverage exists)

Security posture often improves fastest through contract language. Typical clauses include:

• Minimum security controls (MFA, encryption, logging)
• Breach notification timelines and cooperation requirements
• Right to audit / provide assurance artifacts (SOC 2, ISO cert, pen test attestation)
• Subprocessor disclosures and flow-down requirements
• Data retention and secure deletion on termination
• SLAs for availability and support
• Liability limits and indemnification (coordinate with legal)

6) Continuous monitoring and reassessment (because vendors change)

TPRM doesn’t stop at onboarding. Reassess: - Annually for Tier 1, every 1–2 years for Tier 2, and ad hoc for Tier 3 - After major product changes, acquisitions, or new integrations - After incidents (yours or theirs) - When new data types are added (e.g., you start sending customer PII)

Monitoring can be lightweight: - Track certificate/report renewals (SOC 2 period end dates) - Subscribe to vendor advisories and status pages - Review changes in subprocessor lists - Confirm critical controls (SSO enforced, least privilege) remain in place

7) Offboarding (reduce residual access and data exposure)

When a relationship ends: - Revoke SSO/OAuth tokens and API keys; remove SCIM provisioning - Confirm data deletion/return per contract; obtain written confirmation if needed - Remove network allowlists, VPN tunnels, and shared secrets - Archive evidence and assessment records for audit and legal hold requirements

Technical Notes: Practical checks you can run today

Below are actionable examples to reduce third-party exposure.

Identify third-party apps connected via OAuth (Google Workspace)

# In Admin Console: Security > Access and data control > API controls
# Export the list of app access, then review scopes and last used dates.

Look for: - High-privilege scopes (mail, drive, admin) - Apps with broad domain install but unknown owner - Apps unused for 90+ days

List SSO-integrated apps and enforce MFA (Azure AD / Entra ID)

Entra admin center:
- Enterprise applications > All applications
- Review: Users and groups, Permissions, Sign-in logs
- Conditional Access: require MFA, block legacy auth, restrict locations/devices for Tier 1 vendors

Log patterns to watch (sign-in logs): - New country/ASN for service principals - Consent grants to new apps - Unusual admin consent events

Validate least privilege for API integrations

# Example: Document required API scopes for a vendor integration
vendor: "ExampleCRM"
integration: "Data sync"
required_scopes:
  - read:contacts
  - read:accounts
prohibited_scopes:
  - write:users
  - admin:*
notes: "Scope changes require security review and re-approval."

This “scope manifest” prevents quiet privilege creep over time.

When you’ll encounter it

You’ll run into TPRM any time an outside entity can affect your confidentiality, integrity, availability, or compliance posture. Common triggers:

• Buying SaaS that stores customer data (support desk, marketing automation, CRM)
• Outsourcing IT to an MSP, MSSP, or helpdesk provider with admin access
• Integrations and automation (iPaaS tools, webhooks, data pipelines)
• Payment and financial workflows (billing, payroll, expense tools)
• Software development supply chain (code signing, CI/CD services, package repos)
• Regulated environments (HIPAA, PCI DSS, GLBA, GDPR/UK GDPR) where vendor oversight is mandatory or expected
• Customer security reviews where you must prove you manage your own vendors (especially for B2B/SaaS)

For SMBs, TPRM often starts when: - A key customer sends a vendor security questionnaire - Cyber insurance requires documented vendor controls - A breach occurs through a third party (credential reuse, compromised integration, MSP incident)

Tools that help reduce third-party exposure (practical, optional)

TPRM is a process first—but a few tools can reduce your real-world exposure while you operationalize vendor due diligence:

• Password managers: Use a shared vault model, enforce MFA, and rotate secrets when vendors change. If you’re standardizing, our picks for SMBs are here: password manager for small business 2026. One widely used option is 1Password.
• Endpoint security / EDR: If vendors connect to endpoints (especially MSP tooling), strong endpoint visibility helps limit blast radius. If you’re evaluating options, see best antivirus for windows business endpoints 2026. One common pick is Malwarebytes.
• Business VPN for travel/admin access (where appropriate): Helpful as a defense-in-depth layer for risky networks and admin travel, just don’t treat it as a substitute for identity controls and least privilege. Reputable options include NordVPN and Surfshark.