Who should be accountable when a vendor or subcontractor causes a security issue?

Why This Matters for Security Teams

When a vendor or subcontractor triggers a security issue, the real problem is usually not the contract alone. It is the gap between paper accountability and operational control over non-human identities, secrets, and access paths. The business owner may own the risk, but procurement, the vendor manager, and the identity team each control a different part of the response. That is why third-party governance has to be treated as an identity problem, not just a legal one. NHI Mgmt Group research shows that 92% of organisations expose NHIs to third parties, which makes supply chain exposure routine rather than exceptional, and Ultimate Guide to NHIs — The NHI Market explains why visibility and lifecycle control are central to containment.

Security teams often assume vendor risk is managed through onboarding questionnaires, indemnity clauses, and periodic reviews. Those steps matter, but they do not revoke API keys, close OAuth grants, or remove stale service accounts. The control objective is shared accountability with enforced technical guardrails: least privilege, scoped secrets, and fast offboarding. That aligns with the NIST Cybersecurity Framework 2.0, which treats governance, access control, and continuous monitoring as connected duties rather than separate silos. In practice, many security teams encounter vendor-driven NHI exposure only after a token has already been reused or a subcontractor integration has already expanded access beyond the original business need.

How It Works in Practice

Accountability works best when it is split into clear decision rights. The business owner accepts the risk, procurement ensures the contract defines security obligations, the vendor relationship owner tracks performance, and the identity or platform team enforces the access model. That means every third-party connection should have a named owner, a defined purpose, an expiry date, and a revocation path. For NHIs, those controls must include secrets inventory, credential rotation, MFA where applicable, and removal of unused access.

Operationally, this is where NHI governance becomes measurable. The most important questions are: what non-human identities does the vendor use, what systems can they reach, which secrets are long-lived, and who can revoke them immediately? The Ultimate Guide to NHIs — The NHI Market is explicit that lifecycle control, visibility, and rotation are core requirements, not optional enhancements. Pair that with the NIST Cybersecurity Framework 2.0 functions for govern, protect, detect, and respond, and the accountability model becomes practical rather than theoretical.

• Assign one business owner for risk acceptance and one technical owner for access enforcement.
• Inventory vendor NHIs, including service accounts, tokens, certificates, and OAuth grants.
• Use least privilege and time-bound access so vendor access is removed when the task ends.
• Require secret rotation and immediate revocation paths for offboarding and incidents.
• Log third-party activity so the response team can tell normal integration traffic from abuse.

Current guidance suggests that third-party access reviews should be tied to live identity data, not annual paperwork, because hidden credentials and stale grants are what turn an external mistake into an internal breach. These controls tend to break down in environments with unmanaged SaaS integrations and shared API tokens because ownership and revocation authority are distributed across too many teams.

Common Variations and Edge Cases

Tighter third-party control often increases integration overhead, requiring organisations to balance speed of delivery against the cost of stronger oversight. That tradeoff becomes sharper when subcontractors operate inside shared platforms, where one supplier may create the secret while another maintains the workload that uses it. In those cases, no universal standard exists for how much delegated autonomy is acceptable, so policy has to define the minimum control set: owner, purpose, expiry, logging, and emergency revocation.

A useful distinction is between contractual accountability and technical accountability. The vendor may be contractually liable, but the enterprise still needs internal ownership for the controls that prevent recurrence. That is why the same issue can sit with procurement for supplier due diligence, the business owner for risk acceptance, and the identity team for access enforcement. Where services are automated, the Ultimate Guide to NHIs — The NHI Market remains the clearest reference for lifecycle discipline, while the NIST Cybersecurity Framework 2.0 is useful for mapping those duties into governance and response workflows.

Edge cases include reseller ecosystems, managed service providers, and subcontractors that inherit credentials from a prime vendor. Best practice is evolving here: organisations should not assume the prime vendor can fully account for downstream access. If the enterprise cannot see the subcontractor’s non-human identities, it cannot confidently say the risk is under control.

Related resources from NHI Mgmt Group

• Who is accountable when a privileged non-human identity causes a security incident?
• Who is accountable when a disconnected application causes a lockout or security gap?
• Who is accountable when a vendor causes a cyber incident?
• Who is accountable when AI output causes a compliance or legal issue?