Who should be accountable for detecting and containing state-sponsored activity that moves through third-party relationships?

Accountability should sit jointly with security, third-party risk, and the teams that own the business relationship, but one function must coordinate the response. Security needs detection and containment authority, vendor risk teams need relationship visibility, and system owners need the technical context. Without a clear owner, attacker activity can fall between operational and governance boundaries.

How Accountability Should Be Split Across Security, Third-Party Risk, and System Owners

When state-sponsored activity arrives through a supplier, partner, SaaS integration, or other external relationship, accountability cannot sit in a single team. Security owns detection logic and containment execution, third-party risk owns the relationship and control expectations, and the business or system owner owns the operational context that determines what can be safely cut off, degraded, or preserved.

The key decision is not who gets blamed after the fact, but who can act fastest with the right authority. A clear incident owner should coordinate across functions so the response does not stall between governance review, vendor contact, and technical containment.

That is why third-party access and delegated trust need explicit ownership boundaries, especially when the relationship itself is the access path. Internal guidance on Third-Party, B2B and Contractor Access Guide is useful here because it frames sponsorship, least privilege, time limits, and review as shared controls rather than one team’s problem.

Why Third-Party Paths Create a Different Accountability Problem

Third-party relationships blur the line between security operations and vendor governance. The attacker may be using a legitimate integration, token, contractor account, or trusted workflow, so the first sign of compromise often looks like normal partner activity until someone correlates it across identity, network, and business telemetry.

That makes ownership harder than in a direct intrusion. If no one is accountable for the relationship, the organisation can see the malicious activity but fail to decide whether to rotate credentials, suspend access, notify the vendor, or keep the service running under tighter containment.

Practically, this is the same ownership gap that appears in OAuth and SaaS-to-SaaS abuse. NHIMG’s SaaS-to-SaaS and OAuth App Governance Guide is a strong companion because it ties consent, scopes, token risk, and revocation to an explicit operational runbook.

What “Good” Accountability Looks Like in a Cross-Company Incident

Good accountability has one coordinator, but not one owner for everything. Security should lead containment decisions, including detection coverage, token revocation, isolation, and threat hunting. Third-party risk should confirm relationship ownership, contractual escalation, and whether the supplier’s obligations are being met. The system or service owner should decide what business processes can be paused, what data exposure matters most, and what downstream dependencies would be damaged by a blunt shutdown.

The best operational model is a named incident commander with a pre-approved escalation path into procurement, legal, and the vendor relationship owner. That prevents the common failure where teams wait for each other to declare the incident “theirs” while the adversary continues moving through trusted channels.

For organisations with many external identities and integrations, foundational identity governance matters because accountability depends on knowing what exists, who sponsors it, and how it is revoked. The IAM and IGA Basics guide is relevant because it connects access reviews, entitlement ownership, and lifecycle control to third-party and machine access.

Risk and Threat Considerations

Third-party routes are attractive to state-sponsored actors because they convert trust into reach. A compromised supplier account, integration token, or partner workflow can give the attacker valid access paths that blend into routine business traffic, which slows detection and makes containment decisions harder.

Failure mechanism: accountability breaks when security sees the malicious behavior, vendor management owns the relationship, and the system owner controls the operational dependency, but no one has authority to make the final containment call. That gap lets the attacker persist inside a trusted channel long enough to expand access, exfiltrate data, or move laterally.

Impact: delayed containment increases blast radius, especially when third-party access is shared across systems, environments, or business units. The organisation may also mis-handle the incident by revoking the wrong access, damaging operations without removing the attacker’s real path.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IR-4 — Incident Handling	Defines coordinated containment for incidents across teams and suppliers.
	CA-3 — System Interconnections	Third-party relationships are trust boundaries that need explicit oversight.
Recommendation — Assign a single incident coordinator with authority to contain third-party-linked activity. Document and review external interconnections before granting or retaining access.
NIST CSF 2.0	GV.RR-02 — Roles, Responsibilities and Authorities	Accountability depends on clear authority across security and business owners.
	ID.RA-03 — Cybersecurity Risk Information Is Used to Inform Prioritization	Third-party compromise risk should drive containment priority and escalation.
	DE.CM-08 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software	Detection through partner and vendor paths requires monitoring of external connections.
Recommendation — Define who can detect, contain, and approve exceptions for third-party incidents. Use third-party risk signals to prioritize containment of trusted-relationship abuse. Monitor supplier and partner connections for suspicious activity and unexpected access.

Practitioner Guidance

What to prioritise: assign one incident coordinator before an event happens, and make sure that role can compel action across security, vendor management, and the business owner. If that authority is unclear during a live incident, the containment decision is already too slow.

What to verify: every external relationship should have a named business owner, a technical owner, a revocation path, and an escalation contact that security can reach without waiting for procurement or legal approval. In practice, the missing owner is usually the real control failure.

Practitioner takeaway: accountability should be shared for visibility, judgment, and business impact, but incident coordination must be singular, because state-sponsored activity through trusted relationships exploits ambiguity faster than it exploits technology.