Who should own third-party security due diligence in an organisation?

Who should own third-party security due diligence, and why?

Third-party security due diligence should be jointly owned, not left to procurement alone. The buying process can trigger the review, but security, identity, operations, and business leadership need to share accountability because vendor risk often spans access, availability, data exposure, and contractual control points. The owner should be the function that can coordinate decisions, not just collect questionnaires.

The practical test is whether the supplier can affect production access, sensitive data, service resilience, or privileged workflows. If yes, ownership has to extend beyond commercial onboarding into control validation, exception handling, and ongoing review. That is why due diligence is less a one-time vendor check and more a governance process around the risk created by the relationship.

In mature organisations, procurement typically owns the commercial workflow, security owns control assessment, IAM owns access-related requirements, and operations or service owners confirm dependency impact. That split avoids the common failure mode where a vendor is approved because the contract is signed, even though access paths, support accounts, or integration tokens were never properly reviewed. For access-driven supplier relationships, guidance on third-party, B2B and contractor access is useful because ownership becomes clearer when sponsorship, least privilege, time limits, and offboarding are defined up front.

How to draw the ownership boundary between procurement, security, and the business

Ownership should follow the control that is being exercised. Procurement should own process discipline, evidence collection, and contract gating, but it should not be the final risk authority for technical or identity-related exposure. Security should own the standards for what adequate due diligence looks like, while the business owner should own whether the service is important enough to accept residual risk.

That boundary matters because due diligence often includes questions procurement cannot answer well on its own, such as whether the supplier has excessive access, whether shared credentials exist, whether subcontractors are in scope, or whether termination will actually revoke access. Where supplier access is part of the relationship, the same logic applies to identity governance and entitlement review, which is why a general access model like IAM and IGA basics helps frame who should approve, review, and revoke access across people and machines.

For high-risk suppliers, the organisation should also decide whether procurement can approve only low-risk vendors by policy, while higher-risk vendors require a security sign-off or risk committee review. That creates a clean escalation path instead of letting every team assume someone else owns the decision.

What good ownership looks like in practice

Good ownership is visible in the workflow. There is a named business sponsor, a security reviewer, and a mechanism for escalating exceptions when the supplier’s controls do not meet baseline expectations. The organisation also keeps review ownership after onboarding, because vendor risk changes when access scopes expand, credentials rotate poorly, subcontractors change, or the supplier becomes embedded in a critical process.

A useful pattern is to separate three questions: who approves the vendor, who assesses the risk, and who accepts the residual exposure. Those are not always the same role. If they are collapsed into procurement, the result is usually checklist completion without meaningful challenge. If they are collapsed into security, commercial trade-offs and operational dependencies can get missed. The right model is shared ownership with a single accountable coordinator.

For external assurance and contract-facing control expectations, vendor questionnaires and attestations often map best to SOC 2 Trust Services Criteria, because they help structure what the supplier should evidence around security, availability, confidentiality, and privacy. That does not replace internal judgment, but it does help the organisation ask for the right proof rather than generic assurances.

Risk and Threat Considerations

Third-party due diligence fails when ownership is fragmented, because gaps appear between contract approval, access approval, and operational oversight. That creates exposure if a supplier becomes a single point of failure, if privileged integrations are never reviewed, or if offboarding is delayed after the relationship ends.

Failure mechanism: Procurement signs the relationship, but no function is clearly accountable for access review, control validation, or exception tracking, so weak supplier controls survive into production.

Impact: The organisation can inherit unauthorized access, data exposure, service interruption, or hard-to-revoke vendor access paths that widen blast radius during an incident.

Practitioner Guidance

What to prioritise: Define one accountable owner for the overall third-party risk process, then assign explicit sub-owners for commercial onboarding, technical control review, access governance, and residual-risk acceptance. That avoids both procurement-only and security-only failure modes.

Decision rule: If the supplier can access data, systems, credentials, or operational workflows, treat due diligence as a joint security and business decision, not a purchasing task. If the supplier is low-risk and non-integrated, procurement can lead the process with lighter security input.

What to verify: Confirm that the organisation can identify who approved the risk, who reviewed access or credentials, and who owns offboarding when the relationship ends. If those answers are unclear, the ownership model is not ready for audit or incident response.

Practitioner takeaway: The right owner is not the team that sends the questionnaire, but the team that can force a real risk decision, coordinate control validation, and close the loop when the supplier changes or exits.

Related resources from NHI Mgmt Group

• How should security teams structure vendor due diligence before signing a third-party relationship?
• Who should own third party risk management across security, legal, and procurement?
• Why do due diligence platforms matter for KYC and third-party onboarding?
• Who should own security oversight when customer support data is handled by a third-party provider?