The New Rules of Modern Incident Management

Most incident-management practices were built around a manageable sequence of events: something fails, monitoring detects it, responders establish scope, diagnose the cause, and recover the service.

That sequence still works for many incidents. The problem is what happens when the assumptions underneath it fail.

A configuration change can propagate across millions of endpoints before an operations team has established what happened. A cloud dependency can spread failure across services and regions that appear independent on an architecture diagram. Security and monitoring software can become part of the failure surface. AI agents can make production changes at a speed and scale that exceed the governance models designed for human operators.

Forrester’s new Best Practice Report, Incident Management Has Outgrown Its Playbook, argues that modern incident management has reached that point. Failure remains inevitable, while its nature, scale, and velocity have changed enough to expose the limits of conventional response practices.

The fundamentals still matter, of course. Ownership, structured response, retrospectives, and disciplined coordination remain valuable. Forrester’s argument is that those foundations now have to support systems that are larger, more interconnected, and increasingly automated.

The assumptions underneath incident response are changing

Traditional incident response works best when responders can establish a boundary around the problem.

There is a starting point. There is a recognizable set of affected systems. Telemetry helps narrow the search until the team can form a credible explanation and act.

Modern infrastructure makes that boundary harder to find. Software, cloud services, automation pipelines, endpoint tooling, and third-party platforms create dependencies that cross organizational and technical boundaries. A localized cause can produce effects across dozens of services, while the team responding to those effects may have little visibility into the originating system.

Forrester describes modern failure patterns as increasingly distributed and difficult to diagnose with manual or rule-based approaches because the volume of data and depth of dependencies have exceeded what those methods were designed to handle.

Four examples from the report show why.

1. Automation can spread failure before humans establish context

Automation changes the timing of an incident.

Forrester describes a “failure velocity gap” between automated systems that act in seconds or minutes and human recovery processes that can take hours. In 2024, a misconfigured network element disrupted AT&T’s wireless network within three minutes. In 2025, a race condition in Amazon DynamoDB DNS automation propagated across more than 100 dependent AWS services. Recovery took hours in both cases.

The important issue is the asymmetry. By the time responders determine what changed, which systems depend on it, and how far the impact has spread, automation may have already multiplied the consequences.

That puts more pressure on the investigative layer of incident response. Fast detection helps, but responders also need immediate access to topology, recent changes, dependencies, historical incidents, and service impact.

This is where Edwin AI becomes relevant. Its role is to correlate signals across infrastructure and services, combine those signals with topology and change context, and produce a clearer picture of likely cause, affected systems, and next actions. The objective is to reduce the time spent reconstructing an incident after propagation has already occurred.

2. Protective software can become part of the failure surface

Modern operations teams depend on software running deep inside the infrastructure they are trying to protect.

That creates concentration risk. Forrester points to the 2024 CrowdStrike incident, when a faulty update crashed millions of Windows hosts and disrupted organizations across healthcare, aviation, financial services, and government. The update propagated automatically into customer environments.

The operational lesson extends beyond security tooling. Monitoring systems, automation platforms, deployment infrastructure, and incident-response tools can all participate in an outage.

Forrester goes further, warning that response infrastructure itself may share the failure surface of the systems being managed. During a major outage, teams can lose the dashboards, collaboration systems, ticketing tools, or telemetry they depend on to coordinate recovery.

Resilience therefore depends partly on understanding dependencies before they become relevant during an incident. That requires more than collecting telemetry. Teams need a usable model of how systems relate, where impact can travel, and which services carry business consequences and operational waste.

3. Cloud failures make blast radius harder to establish

Cloud architecture distributes systems without necessarily distributing risk.

Forrester cites a 2025 Azure Front Door incident in which an incompatible configuration crashed a master process across Microsoft’s global edge fleet. The outage affected customer workloads and the Azure portal used by engineers coordinating the response.

The root cause may be localized while its consequences span regions, services, and organizations. For incident responders, that changes one of the first tasks in any major event: establishing scope.

A monitoring system can tell an engineer that multiple components are failing. An incident context system has to help explain how those failures relate.

That distinction matters for Edwin AI. Correlating related events into a common incident, applying dependency and topology context, and identifying likely causal relationships gives responders a way to reason about propagation rather than investigating every symptom separately. Connecting context and signals across infrastructure, cloud, applications, networks, and service dependencies while using topology and change history helps identify likely origin and impact.

4. Autonomous agents add a governance problem

Agentic AI adds another source of operational velocity.

Forrester documents a 2026 PocketOS incident in which a coding agent with production access issued a destructive API call that erased a production database and its backups within seconds. The report characterizes the resulting failure as a governance problem involving the policies that defined the agent’s autonomy.

That distinction matters because agentic systems can execute actions rather than simply recommend them. Permissions, approval requirements, auditability, and escalation thresholds become part of the incident-management architecture.

Forrester’s guidance is specific. Mature organizations define explicit permissions, require secondary approval for destructive actions, preserve audit trails, route higher-stakes decisions to humans, and evaluate agents according to outcome quality.

It makes the principle concrete: narrow, reversible tasks such as alert routing can carry greater autonomy, while irreversible actions with broad blast radius require review or should remain outside autonomous execution.

Edwin AI is being built around the same governance principles. Teams can use AI to investigate, correlate, recommend remediation, and execute defined playbooks while controlling which actions require human approval and which can run within established guardrails.

Incident management now depends on context and governance

Forrester summarizes mature incident management with three statements:

• Speed without context is dangerous.
• Automation without governance is risk.
• Resolution without learning is recurrence in disguise.

Those principles point to a more useful definition of maturity than faster ticket closure.

Responders need context at the point of triage. Automation needs permissions proportionate to consequence. Incident data needs to improve the next investigation rather than disappear when a ticket closes.

That is also where observability and AI start to converge. Forrester argues that mature organizations are turning observability into an incident context engine, bringing system health, recent changes, dependency status, and historical patterns directly into response workflows.

Edwin AI brings the signals together, establishes relationships, gives responders usable context, and automates only within a defined operating boundary.

The incident playbook still has value. The environment around it has expanded beyond many of the assumptions under which it was written. Modernizing incident management means accounting for propagation, dependency complexity, machine-speed actions, and the governance required when software can make operational decisions of its own.e prevalent, it’s increasingly important for network operators to verify not just whether their services are available, but whether their prefixes are being routed as intended.