Who is accountable when third-party software causes business disruption?

Accountability should sit with the business owner of the service, the security team that approved the risk, and the procurement or vendor management process that recorded the assurance. Under resilience and outsourcing regimes, the organisation remains responsible even when the failure originates in a supplier or sub-supplier.

Why This Matters for Security Teams

When third-party software disrupts a business service, the accountability question is usually misframed as a vendor failure. In practice, resilience obligations sit with the organisation that chose the supplier, approved the integration, and accepted the residual risk. That is why security, procurement, and the service owner all remain in scope, especially when secrets, service accounts, or delegated access are involved. NHI Mgmt Group notes that 92% of organisations expose NHIs to third parties, which makes supplier disruption a control issue as much as a commercial one.

The practical concern is not just downtime. Third-party incidents often expose the weakness of the entire trust chain, including credential handling, segregation, and offboarding. The patterns seen in the The 52 NHI breaches Report and the Reviewdog GitHub Action supply chain attack show how quickly a supplier issue becomes an enterprise issue when non-human identities are over-permissioned or poorly governed. Current guidance suggests organisations should treat vendor disruption as an accountability test, not an exception process.

Standards-based control design matters here because responsibility cannot be outsourced, even if the operational failure is. Controls in NIST SP 800-53 Rev 5 Security and Privacy Controls and the OWASP Non-Human Identity Top 10 reinforce that ownership, monitoring, and access review must be explicit, not implied. In practice, many security teams encounter accountability gaps only after a supplier outage has already exposed missing assurance, weak contract terms, or unmanaged credentials.

How It Works in Practice

Operational accountability should be mapped before the supplier is live. The business owner owns continuity impact, the security team owns the control decision, and procurement or vendor management owns the assurance record. That split is important because the person who buys the software is rarely the person who can recover it when it fails. A resilient operating model requires clear acceptance criteria, documented escalation paths, and evidence that the organisation can detect, isolate, and replace a failing supplier service.

In practice, the strongest programmes link vendor risk to identity and access controls. If a third-party tool uses API keys, OAuth grants, or service accounts, those NHIs should be scoped to the minimum viable function, monitored for unusual use, and revoked when the business purpose ends. The NHI Mgmt Group guide shows why this matters: only 20% of organisations have formal offboarding and revocation processes, while 97% of NHIs carry excessive privileges. That combination turns a supplier outage into a recovery problem and a security problem at the same time.

Effective teams also require contract language that supports action, not just assurance. Current best practice is evolving, but the baseline should include incident notification timelines, subcontractor disclosure, logging access rights, backup and recovery expectations, and auditability. Where possible, those requirements should be tied to control evidence from a vendor security review and refreshed periodically. The operational lesson from Klue OAuth Supply Chain Breach and Shai Hulud npm malware campaign is that a supplier compromise often spreads through delegated trust, not just direct service failure.

• Assign a named business owner for continuity and risk acceptance.
• Require security approval for access scope, secrets handling, and monitoring.
• Record vendor assurance, subcontractors, and renewal reviews in procurement.
• Use time-bound access, rapid revocation, and tested fallbacks for critical integrations.

These controls tend to break down when the supplier chain is opaque and the service depends on long-lived credentials that no one can rapidly revoke.

Common Variations and Edge Cases

Tighter supplier controls often increase onboarding time and contract overhead, requiring organisations to balance resilience against speed and commercial flexibility. That tradeoff becomes sharper when the software is embedded in a critical workflow or when replacement is operationally difficult.

One common edge case is sub-supplier failure. The direct vendor may be responsive, but its downstream provider may be the actual source of disruption. In that scenario, accountability still remains with the buying organisation, even if remediation is negotiated through the prime supplier. Another variation is “shadow procurement,” where teams adopt tools without formal review. In those cases, there may be no clear assurance record at all, which makes later accountability harder to prove and harder to enforce.

There is no universal standard for this yet, but resilience and outsourcing regimes increasingly expect organisations to demonstrate due diligence, not merely point to vendor contracts. For identity-heavy integrations, that means reviewing whether the supplier can expose, rotate, and revoke NHIs safely, and whether the organisation can do the same on its side. The supply chain cases documented by NHI Mgmt Group, including the Mastra npm Supply Chain Attack and JetBrains Marketplace AI Plugin Campaign, show how quickly trusted software can become an exposure path when access is not tightly bounded.

For organisations with high regulatory pressure, the safest interpretation is simple: the vendor may trigger the disruption, but the enterprise owns the response, the evidence, and the remediation path.

Related resources from NHI Mgmt Group

• Who is accountable when a third-party integration keeps an NHI active after the business need ends?
• Who is accountable when a third-party NHI causes PCI scope exposure?
• Who is accountable when a third-party OAuth app causes a breach?
• Who is accountable when a third-party SaaS app causes a compliance failure?