Compliance Incident Response Runbook

What is the Compliance Incident Response Runbook?

A compliance incident response runbook is a step-by-step operational document that tells your team exactly what to do when something goes wrong: a sanctions hit that wasn't escalated, a SAR filed 45 days late, a KYC gap discovered mid-audit, a monitoring alert closed without proper investigation.

The regulatory obligation is explicit. The FCA's PS21/3 on operational resilience requires firms to demonstrate they can respond to disruptions within defined impact tolerances, with documented procedures to show for it. FFIEC examiners treat written incident procedures as a core component of BSA/AML program adequacy reviews. The OCC's Heightened Standards framework expects the same discipline from large institutions.

Without a runbook, teams improvise. Improvisation means inconsistent decisions, incomplete evidence trails, and notifications that happen late or not at all. Examiners know it when they see it, and they treat it as a program deficiency.

This template gives compliance and AML teams a structured document they can fill in as an incident unfolds, store as a regulated record, and produce during an exam to demonstrate both preparedness and execution. It's built for the full incident lifecycle: detection and triage, containment, root-cause analysis, regulatory notification, remediation, and post-incident review.

The runbook connects naturally with Transaction Monitoring alert workflows and SAR Narrative Template filings. If your compliance function is working toward staying continuously exam-ready, this is the artifact that makes incident response auditable and defensible.

Who needs the Compliance Incident Response Runbook?

Primary users are MLROs, BSA officers, chief compliance officers, and fraud team leads at banks, credit unions, fintechs, money services businesses, and broker-dealers. Secondary users are operational resilience leads and risk managers who need documented evidence that the compliance function responds systematically to failures rather than reactively.

The trigger moments are specific:

• A transaction monitoring alert is found to have been incorrectly closed without investigation
• A sanctions hit surfaces on a customer who was onboarded months ago with no screening record
• A SAR deadline is missed, triggering a self-disclosure to FinCEN or the NCA
• An internal audit flags an AML control failure in a high-risk customer segment
• A regulator requests documentation of how a specific incident was handled
• A third-party or correspondent banking partner reports a potential compliance exposure

In each case, the team needs to act quickly and document everything. The runbook tells them what to do in what order, who to notify, what evidence to gather, and when to involve legal or senior management.

It's also the first artifact an examiner asks for in an operational resilience review. If your MLRO or BSA officer can produce completed runbooks for the last three incidents, that tells a regulator more about your program's maturity than a policy document ever will. A maintained runbook library is one of the clearest signals of a functioning compliance culture.

What's inside the Compliance Incident Response Runbook

The document follows a sequential incident lifecycle. Each section is designed to be filled in as the incident unfolds, not reconstructed afterward.

Section 1: Incident identification

• Date and time of detection
• Detection source: automated alert, employee report, customer complaint, regulator inquiry, internal audit finding, or third-party notification
• Name and role of the person completing the runbook
• System or control where the failure originated (transaction monitoring rule, sanctions screening batch, KYC process, model output)
• Initial classification: regulatory breach, AML/fraud control failure, data incident, operational failure, or third-party exposure

Section 2: Triage and severity rating

• Severity level with defined criteria: Level 1 is a material regulatory breach requiring immediate notification; Level 2 is a significant internal control failure with potential regulatory impact; Level 3 is a process gap with no immediate regulatory consequence
• Affected products, customer segments, or geographic markets
• Estimated number of customers or transactions in scope
• Initial regulatory notification decision: reportable? (Y/N with documented reasoning)

Section 3: Containment actions log

• Immediate steps taken to stop ongoing harm
• Internal notifications made: MLRO, General Counsel, CRO, Board Risk Committee
• Systems, accounts, or processes placed under hold or enhanced monitoring

Section 4: Regulatory notification log

• Regulator(s) notified, including jurisdiction
• Notification date, time, and method
• Reference number or case ID from the regulator
• Acknowledgment received (Y/N)

Section 5: Root-cause analysis

• Category: policy failure, process gap, technology failure, training deficiency, or third-party control weakness
• Contributing factors and timeline of how the failure developed
• Connection to any prior audit findings or model validations (link to your Model Risk Management Policy Template if relevant)

Section 6: Remediation plan

• Specific corrective actions, each with a named owner and a completion date
• Whether the fix requires a policy update, a control change, technology remediation, or retraining
• Sign-off milestone and confirmation date

Section 7: Post-incident review

• Lessons learned and whether the incident reveals a systemic weakness
• Changes made to prevent recurrence, with evidence
• Final sign-off by MLRO or CCO

FATF Recommendation 11 requires institutions to maintain records of compliance activity, including failures and corrective actions, for a minimum of five years. This structure meets that standard.

How to use the Compliance Incident Response Runbook

Using the runbook correctly is as important as having it. Here's how to work through it in a real incident.

1. Make it accessible before anything happens. Add the runbook to your compliance shared drive alongside your AML program and operational policies. Brief your MLRO, BSA officer, and fraud lead on where it is and how to open a new instance. The worst time to explain the workflow is during an active incident.

2. Open a new instance the moment an incident is detected. Don't wait until containment is complete or the facts are clear. The timestamp in Section 1 is evidence. Examiners look at the gap between when you knew and when you acted. A runbook dated three days after detection tells its own story.

3. Complete Sections 1 and 2 within the first two hours. Severity classification drives the entire response: who gets notified, how fast, and whether you're on a regulatory clock. In the US, FinCEN's SAR rules require filing within 30 days of when you know or have reason to suspect reportable activity. The UK's Proceeds of Crime Act 2002 consent regime has tighter windows for certain authorized disclosures. Get the classification right early.

4. Write containment actions as you take them, not after. An after-the-fact reconstruction looks like one. Use Section 3 to create a contemporaneous record. If you place an account on hold at 14:32, log it at 14:32.

5. Run the regulatory notification decision with legal, not after. If the incident involves a potential SAR filing, your MLRO should review open cases and the SAR Narrative Template to understand the full picture. Teams working through a SAR filing backlog should check whether the incident creates new filings or modifies existing ones.

6. Complete root-cause analysis before closing the record. Examiners treat an incomplete runbook as evidence the incident wasn't properly resolved. "Under review" is not an answer.

7. Store the completed runbook with your AML records. Under FATF Rec 11, the runbook is a regulated record. Retain it for the period your regulator specifies, typically five years from the date the incident was closed.

Common mistakes to avoid

Starting the runbook after the fact. Teams often wait until an incident is "under control" before opening the template. That turns a real-time record into a reconstruction, and examiners can tell the difference. Open the runbook within the first two hours of detection, even if your facts are incomplete. You can add detail as the picture clears.

Under-classifying severity to avoid escalation. A Level 3 classification gets reviewed quarterly. A Level 1 triggers a regulator call today. Some teams default to Level 3 to avoid the escalation chain. That decision looks far worse during an exam than the original incident would have. Apply your defined severity criteria honestly.

Listing remediation actions without owners or deadlines. "Review KYC procedures" is not a remediation plan. Every action in Section 6 needs a named person and a specific completion date. Examiners follow up on prior findings. If you can't show who fixed what and when, the finding survives to the next exam.

Ignoring transaction scope. If a transaction monitoring control failed for a segment of accounts, the runbook should identify the scope clearly: how many accounts, what time window, what transaction types. A vague description signals you still don't know what happened, which is a worse finding than the control failure itself.

Skipping the post-incident review. Closing out the remediation plan is not the same as completing the runbook. The post-incident review is what turns a record of a failure into evidence of a learning program. Leave it blank and you'll see the same finding in the next exam cycle.

Keeping it inside the compliance function. Operational resilience failures often cross compliance, IT, and operations. If the root cause sits in a system or third-party process outside your team, the remediation needs owners outside your team too. A runbook that names only compliance staff for every action is probably incomplete.

How FluxForce automates this

FluxForce's AI agents monitor for the conditions that trigger a runbook: transaction monitoring anomalies, sanctions screening hits, and adverse media signals that cross your defined severity thresholds. When an alert qualifies, the platform generates a structured evidence package with timestamps, transaction records, and screening results that map directly to the runbook's containment and root-cause sections. That cuts manual assembly from hours to minutes and removes the reconstruction problem entirely. To see how it works against your own incident types, book a demo.