Operational Ambiguity on Incident Response Scope

When several teams or organizations operate the same environment — internal operators, an outsourced operations provider, the security team, application vendors — how roles are divided operationally during an incident is defined nowhere: who isolates a machine, who preserves evidence, who decides to restore, who informs users, who coordinates the response overall.

Each party carries an implicit picture of how tasks are split — and these pictures don’t match, precisely on the heaviest actions. This is structural: the division of labor was built around routine operations (tickets, requests, maintenance), and a major incident was never mapped onto that structure. The ambiguity is painless as long as it isn’t tested — so it survives, invisible, until the day it costs something.

Two symmetrical failure modes, both observable within the first hours:

• the gap: each party believes an essential action belongs to the other. No one preserves the logs, no one cuts off the suspicious access — and the missing action is discovered hours later, once its absence has already produced effects;
• the overlap: two teams act on the same object without coordination. One reinstalls what the other was analyzing, destroying evidence; one restores while the other contains, reintroducing the compromise that had just been eradicated.

On top of this comes the negotiation cost: defining roles during the incident consumes the most expensive hours, under diverging interests that suddenly become visible — everyone measures what the incident will cost them, and the discussion of roles turns into a discussion of blame.

The pattern is hard to see from the inside: each party, questioned alone, describes a clear division of labor — its own. Identification therefore requires cross-checking each party’s version:

• submit the same list of about ten concrete actions separately to each stakeholder — “isolate a production server,” “copy the logs before reinstallation,” “decide to restore,” “inform users,” “keep the incident log” — and ask, for each: who executes it, who decides it?
• the discrepancies between the answers are the measure of the pattern — no interpretation needed, just counting;
• a joint exercise, even a short one, reveals it even faster: the hesitations show up at the first inject (“who does this?” followed by silence);
• a complementary signal in the documentation: if a security incident appears only as a ticket type within routine operations procedures, the mapping was never done.

Produce a responsibility matrix specific to incidents — not the one used for routine operations:

• for each family of actions — detection, qualification, isolation, evidence preservation, eradication, restoration, internal and external communication, coordination — define who executes, who decides, who is informed;
• attach the verified on-call contact details for each party;
• have it validated by all parties, not drafted by a single one: a matrix that no one has countersigned reproduces the ambiguity it claims to resolve, minus the authority;
• explicitly plan for coordination: who keeps the shared incident log, on which channel — a channel that remains reachable even if the environment is degraded;
• test it in an annual joint exercise (see MFL-011): it is the only mechanism that exposes residual discrepancies before an incident does.

Ambiguity is reduced during an incident through three simple moves:

• name a single coordinator within the first hour: the role can fall to any competent party — what matters is that there is only one, and that the others explicitly accept it, not the optimal choice;
• keep a shared list of actions underway and upcoming, with an owner for each: gaps and overlaps show up immediately on a list, never in parallel conversations;
• set a default preservation rule while roles remain unsettled: no reinstallation, no non-essential restart, no deletion — irreversible actions wait until they have a designated owner.

Substantive disagreements about the division of roles are dealt with after the incident, using the incident log as raw material: during the incident, the only question is who does what in the next hour.