What is the difference between third-party risk management and third-party due diligence?

Third-party due diligence is the point-in-time evaluation used to screen a vendor before or during onboarding. Third-party risk management is the broader lifecycle discipline that includes assessment, monitoring, issue management, and periodic review after the relationship begins. Teams need both: due diligence informs the entry decision, while risk management governs the relationship over time.

How the Two Concepts Differ in Practice

Third-party due diligence is the SOC 2 Trust Services Criteria (AICPA)-style point-in-time review of a vendor before onboarding or a major change. It is designed to answer, “Should we trust this party now?” Third-party risk management is the ongoing discipline that keeps asking that question over the full relationship, especially as access, services, and exposure change.

That difference matters because a vendor can look acceptable at intake and still become risky later through scope expansion, control drift, staff turnover, subcontracting, or weak offboarding. Due diligence is a gate; risk management is the operating model that keeps the gate relevant after the contract is signed.

Why Timing and Lifecycle Scope Matter

Due diligence is usually narrow in time and deep in evaluation. Teams collect evidence, review controls, and decide whether the relationship can begin or continue. Risk management is broader in time and more iterative. It covers the full lifecycle: onboarding, access changes, issue tracking, periodic reassessment, incident response coordination, and exit or termination.

That lifecycle distinction is important for security because third-party exposure is rarely static. A vendor may initially have limited access, then gain broader integrations, privileged API credentials, or operational dependency over time. In other words, the first review is only as good as the assumptions that remain true afterward.

This is why lifecycle controls matter in practice, including credential rotation, access review, and offboarding. NHIMG’s Ultimate Guide to NHIs is useful here because many vendor relationships now rely on service accounts, API keys, tokens, and other machine-access material that must be governed after onboarding, not just examined once.

What Strong Programs Actually Separate, and What They Keep Together

A good program separates the entry decision from the ongoing oversight model. Due diligence should be repeatable enough to compare vendors consistently, but risk management must also preserve operational context, such as business criticality, data sensitivity, and whether the vendor has privileged or persistent access. The same vendor can therefore score differently at onboarding than it does six months later.

The 2025 State of NHIs and Secrets in Cybersecurity reinforces why that matters: 91% of former employee tokens remain active after offboarding, showing how easily access can outlive the review that approved it. For third parties, the analogue is the same, if offboarding, recertification, and inventory are weak, the original assessment stops reflecting actual exposure.

At the same time, strong programs keep the concepts linked operationally. Due diligence should feed risk rating, contract terms, monitoring intensity, and required control uplift. Risk management should feed back lessons from incidents, audit findings, and control failures into the next due diligence cycle so the organization does not repeat the same mistakes with the next vendor.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the technical controls, while DORA define the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	15 — Service Provider Management	Covers third-party governance, assessment, monitoring, and exit controls.
Recommendation — Apply service provider management controls to track vendor risk, review access, and enforce offboarding.
NIST CSF 2.0	GV.SC — Cybersecurity Supply Chain Risk Management	Directly addresses third-party risk governance across supplier relationships.
	ID.SC — Supply Chain Risk Management	Supports identifying and managing supplier-related cybersecurity dependencies and exposure.
Recommendation — Use supply-chain risk governance to define vendor oversight, assurance, and periodic reassessment. Map supplier dependencies and update risk treatment as the relationship or exposure changes.
DORA	ICT third-party risk management — ICT Third-Party Risk Management	Material for regulated financial entities managing ongoing third-party ICT exposure.
Recommendation — Establish contractual, monitoring, and exit controls for ICT third parties.

Practitioner Guidance

What to prioritize: Treat due diligence as the evidence needed to justify the initial relationship, then use risk management to decide how much monitoring, access, and review frequency that relationship deserves. If the vendor will hold credentials, integrations, or production access, the ongoing controls matter more than the intake questionnaire.

What to verify: Confirm that onboarding decisions are tied to a current risk tier, a named owner, review cadence, and an offboarding path. If those elements are missing, the program is really performing screening, not managing third-party risk.

Practitioner takeaway: Due diligence is a snapshot, but risk management is the control loop; the safest programs do not confuse a clean vendor assessment with a durable vendor security posture.