Who is accountable when third-party cyber risk changes between reviews?

Why This Matters for Security Teams

Third-party cyber risk rarely stays static between formal reviews. A vendor may add cloud services, change subcontractors, expose new APIs, or suffer a compromise that alters the control picture overnight. That means accountability cannot sit with the supplier alone. The buying organisation remains responsible for deciding whether the relationship still fits its risk tolerance, because it is the party extending trust, connectivity, and often privileged access.

This is where governance fails in practice. Teams often assume a passed assessment is still valid until the next cycle, even when new intelligence or operational changes clearly indicate otherwise. Current guidance from the NIST Cybersecurity Framework 2.0 reinforces that risk management is continuous, not calendar-based, and that monitoring and response are part of the control obligation. In the same way, a vendor may be compliant on paper but still represent elevated exposure if its integration patterns, secrets handling, or incident response maturity have changed.

For NHI and agentic AI contexts, the issue is sharper because third parties often operate service accounts, API keys, tokens, or autonomous agents that can act with real authority. In practice, many security teams encounter the accountability gap only after a vendor change, incident, or access misuse has already occurred, rather than through intentional continuous reassessment.

How It Works in Practice

Accountability should be structured across three layers: the vendor owns its environment, the buying organisation owns its decision, and the business owner owns the risk acceptance. That split is important because it prevents “shared responsibility” from becoming no responsibility. A vendor can provide evidence, but it does not decide whether the relationship remains acceptable for the customer’s operating model, data sensitivity, or regulatory obligations.

In practice, this means the buying organisation needs triggers that force reassessment between scheduled reviews. Common triggers include a material incident, change in service scope, new subcontractors, newly exposed internet-facing assets, changes to authentication methods, or the introduction of privileged non-human identities. Security teams should also monitor threat intelligence and control drift so the review process reflects current conditions rather than stale attestations. Authoritative sources such as CISA cyber threat advisories are useful for understanding when external events should change internal risk posture.

• Define a named risk owner in the buying organisation for each critical supplier.
• Set explicit reassessment triggers tied to incidents, scope changes, and control failures.
• Require evidence refresh for access, logging, and incident response capabilities.
• Link vendor access to least privilege, time bounds, and rapid revocation paths.
• Track non-human identities separately, especially API keys, service principals, and agent credentials.

Where AI-enabled suppliers are involved, the control question becomes more dynamic. If a third party operates an AI service that can call tools, retrieve data, or generate actions, then model behaviour, prompt handling, and identity governance all affect the risk decision. Resources such as the OWASP Non-Human Identity Top 10 and the MITRE ATLAS adversarial AI threat matrix help teams connect supplier posture to the actual abuse paths that matter.

These controls tend to break down when a supplier’s access is deeply embedded in production workflows because revocation becomes operationally expensive and business teams delay action.

Common Variations and Edge Cases

Tighter review thresholds often increase operational overhead, requiring organisations to balance faster intervention against alert fatigue and commercial friction. That tradeoff is real, especially when procurement, legal, and security each believe the other function owns the call. Current guidance suggests the decision authority should still sit with the customer, but the evidence pipeline and escalation path can be delegated so long as responsibility is not diluted.

One common edge case is the “certified last quarter” vendor that now has materially different exposure due to a merger, hosting change, or compromised subcontractor. Another is the low-risk SaaS product that becomes high-risk once it receives privileged access, sensitive data, or automated credentials. In those cases, the contract language may not need to change immediately, but the security treatment should. That often means tightening access, increasing logging, rotating secrets, or pausing integrations until reassessment completes.

For AI-assisted suppliers, there is no universal standard yet for how much model-change evidence is enough to preserve trust. Best practice is evolving, but if an AI service gains new tool access or a new data source, the buyer should treat that as a material change in attack surface. This is also where human and machine accountability intersect: if the supplier manages autonomous agents, the customer still owns whether those agents are allowed to retain access. Operationally, the strongest answer is a written trigger matrix, a named risk owner, and a time-boxed escalation process rather than an assumption that the next annual review will catch everything.

Related resources from NHI Mgmt Group

• How should security teams handle third-party risk when vendor posture changes between reviews?
• Who is accountable when third-party risk reviews miss deadlines or findings?
• What is the difference between third-party risk management and NHI governance?
• How should security teams handle access decisions when cloud risk changes between reviews?