Identity determines how systems behave.

Architecture determines what happens when something goes wrong.

Incidents are often treated as events.

They are responded to through:

  • plans

  • processes

  • coordination

This assumes outcomes are shaped during the incident.

They are not.

The misconception

Incident response is treated as a capability.

Organisations assume:

  • preparation improves outcome

  • coordination determines containment

  • execution limits impact

This places emphasis on response.

What actually determines the outcome

Outcomes are constrained before the incident begins.

They are shaped by:

  • how systems are structured

  • how access is configured

  • how components interact

These are architectural conditions.

How systems behave under pressure

When something goes wrong, systems do not become different.

They behave as they were designed to behave.

  • access paths are followed

  • dependencies are exercised

  • trust relationships are applied

The conditions that enable normal operation also enable failure.

Where identity reappears

Identity defines:

  • who can act

  • what they can access

  • how far those actions can propagate

Under normal conditions, this enables operation.

Under failure conditions, it defines spread.

What determines survivability

Survivability depends on whether the system:

  • constrains access or allows it to expand

  • isolates components or links them implicitly

  • limits propagation or enables it

These are not response capabilities.

They are design decisions.

Why response is not enough

When systems allow:

  • broad, persistent access

  • implicit trust across components

  • loosely defined boundaries

No response process can fully compensate.

The system permits more than response can contain.

The consequence

Organisations often experience:

  • rapid escalation of incidents

  • unclear containment boundaries

  • difficulty explaining impact

This is not a failure of execution.

It is the expression of architecture.

A useful reframing

Instead of asking:

“Can we respond effectively?”

Ask:

“What does the system allow when something goes wrong?”

Closing thought

Systems do not fail at the point of incident.

“They fail at the point of design.”

Keep Reading