Incident Management: Definition and Use in Compliance

What is Incident Management?

Incident Management is the structured process financial institutions use to detect, classify, contain, investigate, and resolve events that disrupt or threaten the delivery of critical services. The goal is two-part: restore normal operations as quickly as possible, and document everything for regulatory examination.

The scope is broad. An incident might be a core banking system outage, a fraud wave overwhelming the alerts queue, a cloud provider failure that takes down transaction monitoring, or a data breach affecting customer records. What these have in common is that they require a coordinated response across multiple teams, a documented timeline, and, in many cases, a notification to regulators or customers.

Incident Management sits within the broader discipline of operational resilience, which regulators in the UK, EU, and US now treat as a standalone obligation rather than a subset of IT risk. The FCA and PRA's PS21/3 requires firms to identify their critical business services and set impact tolerances, the thresholds beyond which disruption becomes unacceptable. Incident Management is how firms detect when they're approaching those tolerances and respond before they breach them.

A mature incident framework covers five phases: identification, classification (is this a minor disruption or a major incident?), containment, investigation (understand the root cause), and post-incident review (prevent recurrence). Each phase has documented evidence requirements. When an examiner asks "what did you know, and when did you know it?", the incident log answers that question.

One thing that trips firms up is conflating incident response with disaster recovery. Incident Management is operational; it handles events across the full severity spectrum. Disaster Recovery is a subset, triggered only by the most severe scenarios. They're related but not interchangeable.

How is Incident Management used in practice?

In practice, compliance teams interact with Incident Management constantly, though they don't always call it that.

When a transaction monitoring system goes offline at 2 AM, the on-call engineer logs an incident. But the compliance consequences unfold over the next 12 to 24 hours. The MLRO needs to know whether alert generation was interrupted, whether any pending Suspicious Activity Reports were affected, and whether the outage changed the risk profile of accounts that transacted during the window. A four-hour outage can produce a 2,000-alert backlog that takes a compliance team three days to clear.

A practical incident workflow looks like this. A first-line team member logs the event with a severity rating (P1 through P4 or equivalent). If compliance systems are affected, the MLRO gets notified within a defined SLA, typically 30 to 60 minutes for P1 events. A parallel regulatory notification track opens if the incident meets the major-incident threshold. The audit trail captures every action, every escalation, every decision with timestamps.

Post-incident, the root-cause analysis feeds into the risk register and the three lines of defense review. First line identifies the control failure. Second line assesses whether the incident exposed a gap in the risk framework. Third line determines whether the response itself met policy requirements.

Case management tools often track complex incidents that span multiple systems or business units. Where a fraud surge and a system outage happen simultaneously, case management provides the single thread of record across teams.

Teams that run tabletop exercises quarterly handle real incidents far better than those that don't. The difference isn't technical. It's knowing who calls whom, and in what order.

Incident Management in regulatory context

The regulatory baseline for Incident Management changed substantially after 2021.

In the UK, the FCA and PRA published PS21/3 in March 2021 (effective March 2022), requiring all in-scope firms to demonstrate operational resilience through impact tolerance testing. Incident Management is the live mechanism by which firms prove they can detect breaches of those tolerances. Examiners now ask for incident logs as a matter of course.

In the EU, the Digital Operational Resilience Act, Regulation (EU) 2022/2554, came into force in January 2025. DORA introduced a mandatory classification system for ICT-related incidents. Major incidents must be reported to the national competent authority within four hours of classification and 24 hours of initial detection. An intermediate report is due within 72 hours. DORA also requires annual summary reporting and post-incident reviews for major events. ICT third-party providers are included in scope, which is a meaningful expansion from prior practice.

In the US, the picture is more fragmented. The OCC, Federal Reserve, and FDIC published a final rule in November 2021 (effective May 2022) requiring banking organizations to notify their primary federal regulator within 36 hours of determining that a computer-security incident has materially disrupted, or is reasonably likely to materially disrupt, banking operations. The FFIEC IT Examination Handbook sets separate expectations for incident classification and response documentation.

For AML-specific teams, FinCEN guidance clarifies that a system failure affecting SAR filing capability is an incident requiring documented remediation. Filing delays attributable to system failure don't automatically result in enforcement action, but undocumented failures do.

The Basel Committee's Principles for Operational Resilience (BIS, 2021) provide the global baseline, adopted in various forms by national regulators across jurisdictions.

Common challenges and how to address them

The most common failure in incident response isn't technical. It's classification.

Teams default to the lowest severity that avoids escalation. A P3 incident that actually meets the definition of a major ICT incident under DORA gets logged as P3 because nobody wants to trigger the regulatory notification clock. This is a governance problem, and it surfaces during examinations when the regulator asks why a 12-hour transaction processing outage appears at minimum severity in the log.

The fix is a severity matrix that connects technical metrics directly to business impact and regulatory thresholds. If payment processing is down for more than two hours, it's a P1 regardless of what the engineering team prefers. If the transaction monitoring system is offline and alert generation has stopped, that triggers a compliance escalation path in parallel with the IT response. Remove subjective judgment from the classification decision.

Coordination is the second common failure. Incident response typically lives in technology or security. Compliance sits separately. When a cybersecurity incident affects the firm's ability to complete customer due diligence on new accounts or disrupts sanctions screening, compliance needs to be in the room from the start, not briefed 48 hours later.

Third-party risk management adds another dimension. When a cloud vendor or data provider has an outage, the incident belongs to them technically but to you contractually and regulatorily. DORA explicitly requires firms to include ICT third-party incidents in their incident management scope. Your vendor's SLA report is not a substitute for your own incident record.

Post-incident reviews get skipped when teams are under pressure. This is where the learning happens. A bank that experienced a SAR filing backlog of 6,000 reports after a system failure cut that to under 400 in the next comparable event, purely because the post-incident review identified a manual fallback process that worked and had been overlooked.

Related terms and concepts

Incident Management connects to a cluster of operational and compliance disciplines that financial institutions manage in parallel.

Operational Resilience is the parent framework. While operational resilience encompasses prevention, testing, and recovery planning, Incident Management is what happens when prevention fails. One without the other is incomplete.

Business Continuity Plan (BCP) defines what the firm does when an incident is severe enough to threaten ongoing operations. The BCP is the playbook; Incident Management is the real-time execution against it. Firms that confuse the two tend to activate BCPs too late, or not at all.

Impact Tolerance sets the limits. If a payment service can tolerate four hours of disruption before customer harm becomes unacceptable, Incident Management must detect and escalate any disruption approaching that threshold. The two concepts are interdependent.

Audit Trail is the evidence record. A well-run incident generates a tamper-proof log of every action, every notification, and every decision. This is the document an examiner reads when assessing whether the firm responded appropriately and within regulatory timelines.

Case Management tools are commonly used to manage complex multi-team incidents, particularly where fraud, compliance, and technology response tracks need to run in parallel under a single record.

AI Governance is increasingly relevant as firms deploy AI-powered compliance and fraud detection systems. When an AI model misbehaves (generating a surge of false positives, missing a class of alerts, or producing outputs that warrant review), that's an incident. The incident management framework must cover AI failures explicitly, including who has authority to activate the kill switch and what documentation the decision requires.

Tabletop exercises are the practice mechanism. DORA requires them for designated critical ICT systems. The quality of a firm's incident response in a real event is almost exactly correlated with how seriously it runs its exercises.