Accountability should sit with the business owner of the relationship, supported by security, IAM, and procurement. Security defines the control baseline, but the business function that depends on the supplier must own the risk decision, the access approval, and the offboarding outcome. Without that split, external access tends to persist by default.
Who owns third-party cyber risk when responsibility is shared?
Shared responsibility does not mean shared ambiguity. The accountable party should be the business owner that chose, funds, and depends on the supplier, because that function is the one that can accept, delay, or exit the relationship. Security, IAM, and procurement are essential controls and advisors, but they do not own the business consequence of the vendor relationship.
That split matters because third-party exposure is usually created by a business need, not by a security team decision. If the business owner cannot be held to the risk decision, access review, and offboarding outcome, external access becomes sticky and exceptions turn into standing entitlements.
What “accountable” means in practice
Accountability is not the same as doing all the work. In a third-party model, security defines the minimum control baseline, IAM enforces access paths and lifecycle controls, and procurement handles contractual guardrails, but the business owner signs up to the residual risk and accepts the operational impact if the supplier relationship is interrupted.
That ownership should include three decisions: whether the supplier is needed at all, what data or systems the supplier may touch, and when access must be removed. Third-Party, B2B and Contractor Access Guide is useful here because it frames sponsorship, least privilege, time limits, reviews, and offboarding as business-controlled outcomes, not just technical settings.
Where access is mediated by tokens, federated sessions, or vendor-managed integrations, the business owner still owns the exposure created by that trust relationship. A supplier may operate the mechanism, but the consuming business function owns the decision to keep the trust in place.
How to split responsibility without losing control
The cleanest model is to separate accountabilities by decision type. Security owns standards, exceptions review, and monitoring expectations; IAM owns provisioning, reviews, revocation, and identity evidence; procurement owns contractual clauses, due diligence requests, and commercial leverage; the business owner owns acceptance of the risk and the operational dependency on the vendor.
That model works best when one named business function is accountable for the full lifecycle of the third-party relationship. If no single business owner is assigned, teams tend to inherit access by default and offboarding becomes everyone’s problem, which usually means nobody moves first.
For practitioners, the practical test is simple: if the supplier were removed tomorrow, which function would feel the business pain first, and who has authority to say “stop,” “scope down,” or “terminate”? That function should be the accountable owner.
Where this model breaks down in real environments
Failure usually appears when accountability is treated as an IT issue rather than a business decision. The result is orphaned access, weak recertification, delayed offboarding, and exceptions that survive long after the original use case changed. IAM and IGA Basics helps anchor the control model because third-party ownership only works when entitlement reviews, joiner-mover-leaver discipline, and access certification are explicit.
It also breaks down when supplier access is inherited through shared accounts, broad SSO trust, or unmanaged integrations that no one inventories well. Top 10 NHI Issues is relevant here because many third-party relationships now depend on credentials, tokens, or service identities that outlive the original business approval unless someone is clearly on the hook for rotation and removal.
When incidents do occur, they often trace back to a business relationship that stayed open after the purpose had expired. That is why the accountable owner must be able to answer not only “why was access granted?” but also “why was it still active?”
Risk and Threat Considerations
Third-party risk becomes material when access, tokens, certificates, or federated trust remain active after the business need changes. At that point, a supplier compromise, token theft, or weak offboarding process can turn a normal integration into a standing path into your environment.
Failure mechanism: Ownership fragmentation lets each function assume someone else will approve, monitor, or revoke the access, so exceptions accumulate and dormant third-party access persists.
Impact: Attackers or negligent suppliers can retain access longer than intended, increasing the chance of data exposure, privilege misuse, and slow incident containment.
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 SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-6 — Access Control Management | Third-party access lives or dies on managed access paths and revocation discipline. |
| Recommendation — Centralise third-party access reviews and revoke unused paths quickly. | ||
| NIST SP 800-53 Rev 5 | AC-20 — Use of External Systems | Third-party cyber risk directly concerns authorised use of external systems and the conditions placed on it. |
| IA-5 — Authenticator Management | Supplier access often depends on tokens, secrets, or credentials that must be issued and removed safely. | |
| Recommendation — Restrict, approve, and document use of external systems before granting access. Track, rotate, and revoke third-party authenticators on a defined lifecycle. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Supplier relationships are the core governance object behind third-party cyber risk. |
| A.5.20 — Addressing information security within supplier agreements | Contract terms determine who must do what when third-party access, incidents, or exits occur. | |
| Recommendation — Define security requirements for suppliers and review them throughout the relationship. Put security duties, breach handling, and offboarding obligations into supplier contracts. | ||
Practitioner Guidance
What to prioritise: Assign one business owner per supplier relationship and make that owner accountable for risk acceptance, access scope, and offboarding completion. Security and IAM should challenge and evidence the decision, not inherit the decision itself.
What to verify: Confirm that every third-party access path has a named business owner, an approval record, an expiry or review point, and a documented revocation path. If any of those are missing, the relationship is already drifting toward unmanaged access.
Common mistake: Treating procurement closure, contract renewal, or technical deprovisioning as proof that the risk is closed. The real test is whether the business dependency and every associated access path have both been intentionally removed or re-approved.
Practitioner takeaway: Shared responsibility only works when the business function that benefits from the supplier is also the function that carries the residual risk and can force the access to end.
Related resources from NHI Mgmt Group
- Who is accountable when third-party cyber risk changes between reviews?
- Who should be accountable for building cyber resilience when regulation, funding, and third-party risk all intersect?
- Who is accountable for third-party compliance when children’s data is shared under COPPA?
- Who should be accountable for third-party cyber risk in hospital supply chains?