Half your response playbooks depend on connectors other teams own — who is accountable when a token rotation silently disarms containment?

## Why this is a structural problem, not an incident A modern response capability is a chain of integrations across organisational boundaries. The EDR connector belongs to the endpoint team, the account-disable connector to identity, the artifact-quarantine connector to the build platform team, the cloud isolation connector to the platform team, and several belong to vendors. Each of those teams rotates credentials, revokes grants, deprecates API versions, tightens scopes, and migrates tenants on their own schedule — all legitimate engineering work, none of it done with your containment playbook in mind, because they do not know it exists. The result is that your ability to contain an intrusion decays quietly and without notice, and the decay is only observed at the worst possible moment: mid-case, with an adversary active. That is what makes it a leadership question rather than a ticket. ## The options, and what each really costs **Demand ownership from the other teams.** Ask that every credential rotation or API change affecting a security connector be coordinated with the SOC. This works for a handful of high-consequence integrations with a cooperative, well-run team. It does not scale to twenty connectors and it does not survive reorganisations, holidays, or a vendor's unannounced change. Treat it as a bonus, never as the control. **Own the credentials yourself.** Sometimes possible — a dedicated service identity for the response platform whose lifecycle security controls end to end. Where you can get it, the dependency shortens considerably. Where the API only offers a delegated grant or a shared platform token, you cannot. **Shrink the surface.** Fewer connectors, each doing more, is a real strategic lever. Every integration you retire is a dependency that can no longer fail silently. **Detect the break instead of preventing it.** This is the one that always works, because it depends on nobody's cooperation. Assume every connector will fail without notice, and invest in finding out within hours. ## Exercising a containment path, properly A connector health check that only pings an endpoint proves the network path and nothing else. The exercise has to perform the real action, with the real credential, against the real API: - a parked, disposable host that the playbook isolates and then releases; - a disposable account it disables and re-enables; - a dummy artifact in a real repository that it quarantines and releases. This exercises authentication, authorisation scope, API version, and the platform's own logic together, which is precisely the set that a mocked test cannot cover. A failed exercise pages the SOC, because it is the SOC's capability that is broken — not the other team's system, which is working exactly as they intended. Cadence follows consequence: the paths you would reach for in the first fifteen minutes of a serious case — host isolation, account disable — deserve a daily exercise; rarer paths can run weekly or monthly. The rule of thumb is that the exercise interval must be shorter than the window of silent disarmament you are willing to accept. The cost is real and worth naming: decoy objects to maintain, noise generated in other teams' systems, and the risk that an exercise is mistaken for an intrusion by someone else's monitoring. Tell the affected teams what the exercise is and why, and make the decoy objects obviously named. ## When a path cannot be exercised Some actions have no safe rehearsal — an action that is destructive, irreversible, or visible to customers. Be honest about those: an unexercised path is a path you may not rely on as the primary plan. Either build a way to exercise a proxy for it, or write down a manual fallback with its realistic execution time, and let the incident plan use that number rather than an optimistic assumption. ## What leadership should be shown The common metric is an inventory: playbooks built, actions automated, hours saved. That number rises even while the capability rots, and it is the number that was true the morning the connector died. Replace it with capability measures: - share of containment paths successfully exercised in the last seven days; - for each connector, the date of its last verified successful action; - time to detect a disarmed path, measured from the last real exercise. When a path does break, the argument to escalate is not a principle about ownership; it is a duration. "This containment step was disarmed for thirty-one days, and in the case last week that cost us a window of four hours between believed-contained and actually-contained" is a sentence an executive can act on. An argument about whose job it should have been is one they cannot. ## Where accountability actually sits Other teams are accountable for their systems. The SOC is accountable for knowing whether its response capability works. Those two are compatible, and confusing them is how the capability ends up owned by nobody. The organisational ask is small and specific — notification for a short list of critical integrations — and everything else is engineered on the assumption that the ask will sometimes be missed.