What Is Third-Party Risk Management?

Why does third-party risk management matter?

Modern companies run on other companies. Payroll, identity, source control, customer support, observability, and hosting are commonly outsourced, and each of those providers holds data or access that could hurt you if their controls fail. When a vendor is breached, your customers, regulators, and auditors still look to you.

NIST treats this as cybersecurity supply chain risk management (C-SCRM). NIST SP 800-161 Rev. 1 addresses risks from products and services that may contain malicious functionality, be counterfeit, or be vulnerable due to poor supply chain practices. TPRM in most commercial programs is the operational side of the same idea: knowing which third parties you depend on, what they can reach, and whether their safeguards are adequate.

TPRM feeds directly into your risk register. A critical vendor without adequate assurance is a risk that needs an owner and a response, the same as any internal gap.

What are the stages of the TPRM lifecycle?

The lifecycle follows the relationship from first request to final offboarding. The effort at each stage scales with the vendor's risk tier.

Offboarding is the most commonly skipped stage. NIST CSF 2.0 calls it out explicitly in GV.SC-10, which expects supply chain risk plans to include activities that occur after a partnership or service agreement ends.

Which frameworks require third-party risk management?

Nearly every security framework includes supplier requirements. The table maps where they live, so one TPRM process can satisfy several audits.

For framework detail, see SOC 2, ISO 27001, NIST CSF, and CMMC.

How do you assess a vendor's security?

Match the depth of review to the tier. A low-risk tool with no sensitive data may need only a contract review. A tier 1 vendor holding customer data deserves a full assessment. The most useful evidence sources are:

• SOC 2 Type 2 report: Check the period covered, the system description scope, exceptions in the test results, carved-out subservice organizations, and complementary user entity controls (CUECs) that you are responsible for operating.
• ISO 27001 certificate: Confirm the certificate is current and that its scope covers the service you are buying, not just a different business unit.
• Standardized questionnaires: The Shared Assessments SIG and the Cloud Security Alliance CAIQ are widely used and often already completed by the vendor.
• Penetration test summaries and trust centers: Useful supporting evidence, especially for vendors without a formal attestation.

CUECs deserve special attention. A vendor's SOC 2 report often assumes you configure MFA, manage your own users, or review access logs. If you do not, the vendor's clean report does not protect you. Treat each relevant CUEC as a control in your own program and collect evidence for it.

How do GRC engineers automate third-party risk management?

The hardest TPRM problem is usually the inventory. Vendors arrive through expense reports, free trials, and OAuth grants long before anyone files an intake form. GRC engineers close that gap by building the inventory from systems of record: SSO app catalogs, OAuth grant listings from the identity provider, accounts payable data, and cloud marketplace subscriptions.

Once vendors are data, tiering and monitoring become code. This Python example flags tier 1 vendors whose most recent SOC 2 report period ended more than a year ago:

from datetime import date

SENSITIVE_DATA = {"customer_pii", "employee_pii", "payment"}

vendors = [
    {"name": "payroll-provider", "data": "employee_pii", "critical": True,
     "soc2_period_end": date(2025, 6, 30)},
    {"name": "design-tool", "data": "internal", "critical": False,
     "soc2_period_end": None},
]


def tier(vendor):
    if vendor["data"] in SENSITIVE_DATA or vendor["critical"]:
        return 1
    if vendor["data"] == "internal":
        return 2
    return 3


for vendor in vendors:
    end = vendor["soc2_period_end"]
    stale = end is None or (date.today() - end).days > 365
    if tier(vendor) == 1 and stale:
        print(f"{vendor['name']}: tier 1 without a SOC 2 period ending in the last 12 months")

Run on a schedule, the output becomes tickets for vendor owners and entries in the risk register. The same approach extends to software supply chain risk: generating SBOMs in CI and scanning dependencies addresses the product side of C-SCRM that NIST SP 800-161 describes. For the monitoring backbone, see continuous compliance monitoring and GRC automation.

Frequently Asked Questions