The recent bank fraud incident in East Africa confirmed what practitioners already knew: the institutions that detect and respond fastest limit the damage. That bank contained the incident within hours and reversed most fraudulent transactions. Many institutions in the region would not perform as well, because their incident response plans have never been tested.
BNR requires all supervised institutions to maintain an incident response capability, and a document on a shelf is not a capability. This guide covers what BNR expects, how to build and test an IRP that actually works, and the reporting deadlines you must meet.
What BNR requires
BNR Regulation N°50/2022 on cyber security in regulated institutions requires every regulated financial institution to establish a written incident response management plan (Article 20). The specific expectations include:
- A formal, board-approved incident response policy
- A designated incident response team with clear roles and decision-making authority
- Documented procedures covering detection, containment, eradication, recovery, and post-incident review
- Effective escalation protocols linked to the organisation's decision levels
- Reporting on the clock: notification to BNR within two hours of a significant incident and a full incident report within 24 hours (Article 21)
- Regular testing of the incident response plan
- Post-incident evaluation and revision of the plan after every event
BNR examiners will ask to see your IRP, evidence that it has been tested, and records of how past incidents were handled. An untested plan is treated as a compliance gap. For the regulation's full scope, including the annual penetration test and bi-annual vulnerability assessments Article 10 mandates, see our BNR cybersecurity requirements guide.
The six phases of incident response
The six phases below expand the SANS model; NIST SP 800-61 groups the same activities into four. Either framing supplies the documented process a BNR examiner expects, as long as every phase is documented, tested, and adapted to the East African banking context.
Phase 1: Preparation
Everything you do before an incident occurs: the most important phase, and the one most institutions underinvest in.
What to document:
- Incident response team composition with after-hours contacts
- Escalation matrix: who decides at each severity level
- Communication templates for internal notification, BNR and NCSA reporting, customers, and media
- Technical toolkit: forensic imaging, network isolation procedures, backup restoration
- External relationships: forensic investigators, legal counsel, law enforcement, your penetration testing provider, your insurer
What to implement: centralised log collection (SIEM) with retention sufficient for investigation, endpoint detection and response (EDR) on critical systems, backups tested and verified for integrity, and network segmentation that allows isolation of compromised segments.
Preparation is not just documentation. If your first conversation with a forensics firm happens during an active breach, you have already lost valuable time. Build the relationships and practise the procedures before you need them.
Phase 2: Detection and analysis
The time between initial compromise and detection is the single most important metric in incident response. Mandiant's M-Trends 2026 report puts the global median dwell time at 14 days, and at 122 days for espionage intrusions. The previous edition recorded a 26-day median when an external party, not the victim, discovered the breach: by the time a card brand or correspondent bank calls, the attacker has had weeks. Under Regulation N°50/2022, detection speed is also a regulatory exposure, because the two-hour notification clock starts from the incident's occurrence or from the determination that one has occurred.
Once an alert fires, whether from the SIEM, transaction monitoring, a user report, or a third party, analysis must establish scope (which systems, what data is at risk), classify severity against a predefined scale, identify the attack vector, assess whether the attack is ongoing, and preserve evidence for investigation and legal use.
Phase 3: Containment
Containment aims to stop the incident from spreading while preserving evidence.
Short-term containment (minutes to hours): isolate affected systems from the network, block malicious IP addresses and domains at the firewall, disable compromised accounts, and preserve system images before any remediation.
Long-term containment (hours to days): deploy temporary fixes against re-exploitation, tighten access restrictions, increase monitoring on related systems, and stage clean replacements for compromised hosts.
For banking incidents specifically: freeze affected accounts, halt suspicious transaction batches, and engage your payment switch provider if card systems are involved.
Phase 4: Eradication
Remove the attacker's presence from your environment completely:
- Identify and remove all malware, backdoors, and persistence mechanisms
- Patch the vulnerability that enabled initial access and reset all potentially compromised credentials
- Verify the attacker has no remaining access through alternative channels, scanning every system that may have been touched
This phase is where many institutions fail. Incomplete eradication leads to re-compromise, sometimes within days.
Two regional realities complicate it. First, most East African banks run core banking platforms operated or supported by external vendors, so credential resets, patching, and rebuilds depend on a vendor's change process; write that coordination into the plan. Second, deep forensic capacity is scarce in the region: contract an external specialist before the incident, and know the national escalation path (in Rwanda, the NCSA's RW-CSIRT coordinates national-level response). Eradication also runs in parallel with the regulatory clock, not ahead of it: BNR's full incident report is due within 24 hours, long before most eradication work finishes, so report what you know and update as the picture changes.
Phase 5: Recovery
Restore systems to normal operations with confidence:
- Restore from known-clean backups where possible
- Rebuild compromised systems from scratch rather than attempting to clean them
- Run enhanced monitoring during the recovery period
- Test before returning systems to production
For a bank, recovery is channel by channel, not all at once. Restore and reconcile core banking first, then reopen channels in order of exposure: branch operations, ATM, internet banking, and mobile money last, the highest-volume channel and the one regional attackers favour for cash-out. Reconcile transaction data with your payment switch and telco partners before each channel reopens; a restored system with unverified transaction integrity is not recovered. The 24-hour BNR report will predate recovery, so progress updates to the regulator continue until services are fully restored.
Phase 6: Post-incident review
Regulation N°50/2022 requires incidents to be documented and the plan to be evaluated and revised after events. This phase is also where your institution actually improves. Conduct a formal review promptly (two weeks from resolution is a workable target): document what happened, when, and how it was detected and handled; identify what worked and what failed; update the IRP; brief the board; and file the final report with BNR.
Building your incident response team
The IRT needs information security (technical lead), IT operations (isolation, restoration, infrastructure changes), compliance and legal (regulatory reporting and legal obligations), communications (internal and external messaging), business leadership (decisions on service availability and customer impact), and HR (insider scenarios). Each role needs a primary and a backup. Keep contact details current and accessible outside corporate email, which may itself be compromised: a printed list plus a secure messaging group.
Designate decision-makers in advance. The most common source of delay is waiting for someone to authorise isolating a system or shutting down a service. The IRP must name who holds that authority at each severity level, after hours included.
Tabletop exercises: testing the plan
A tabletop exercise is the most practical way to test your IRP without touching live systems.
Scenario design
Build scenarios that reflect realistic threats to East African banks:
- Vendor platform compromise: attackers use a breached core banking vendor's access to initiate fraudulent transactions
- Ransomware on the corporate network: file servers encrypted and spreading; core banking is segmented but connected
- Mobile money channel exploitation: hundreds of small transfers to new SIM cards through the mobile money integration
- Insider data theft: a database administrator exfiltrating customer data over encrypted channels
- Executive email compromise: the CEO's account sending fraudulent payment instructions to the finance team
Exercise format
Plan 2 to 3 hours with the full incident response team plus relevant business stakeholders. An independent facilitator releases the scenario in stages: the initial detection alert, first response decisions, an escalation that widens the incident, containment trade-offs between availability and security, recovery and stakeholder communication, then a debrief.
What to evaluate
The facilitator should assess:
- Clarity of roles: does everyone know what they are supposed to do
- Escalation: does information reach decision-makers quickly, and are trade-off calls (such as taking systems offline) made decisively
- Communication: are internal and external communications handled appropriately
- BNR reporting: does the team know the two-hour notification and 24-hour report windows, and who drafts the submission
- Technical capability: does the team have the tools and access needed to respond
Common failures these exercises surface
- Nobody knows who makes the call to isolate systems
- BNR reporting procedures are out of date, or nobody can say when the two-hour clock started
- The SIEM is not configured to detect the scenario's attack pattern
- Communication breaks down between technical and business teams
- The IRP references people who have left the organisation
Reporting to BNR
Article 21 of Regulation N°50/2022 sets two hard deadlines for incidents that disrupt, or could materially harm, normal operations: notify BNR as promptly as possible, and in any case within two hours of the incident occurring or being determined, then submit the full incident report within 24 hours. That threshold covers unauthorised access to customer data, customer-affecting service disruption, financial loss through cyber means, ransomware, and compromise of critical banking infrastructure. Neither window waits for resolution. Report what you know, then update.
What to report
The notification and the 24-hour report should cover the nature and classification of the incident, when it was detected, the systems and services affected, customer impact (data exposure, service disruption, financial loss), containment actions taken, current status, planned remediation, and an estimated timeline to resolution.
Parallel duties under Law N°058/2021
If the incident involves personal data, Rwanda's data protection law adds a second reporting track with its own clock: the data controller must notify the NCSA within 48 hours of becoming aware of the breach (Article 43) and submit a report with all available facts within 72 hours (Article 44); a processor that discovers a breach has 48 hours to notify its controller. A bank breach that exposes customer data triggers both tracks at once, so your IRP templates should include a pre-drafted BNR notification and a pre-drafted NCSA breach notification. See our NCSA and data protection compliance service for how testing supports those obligations.
Follow-up reporting
After the initial notification, BNR expects progress updates and a final post-incident report covering root cause, full impact, remediation actions, and improvements to prevent recurrence.
Technical simulation exercises
Beyond tabletop exercises, mature institutions should conduct technical simulations:
- Purple team exercises: your penetration testing provider simulates an attack while your security team practises detection and response in real time, testing technical controls and human response together. See our comparison of red team vs penetration testing for how this fits your testing programme.
- Backup restoration drills: actually restore critical systems from backup to verify recovery time objectives can be met
- Communication drills: test the out-of-band channels you plan to use when corporate email may be compromised
How we can help
IMIZI Cyber is an offensive security firm based in Kigali, working with banks, fintechs, government bodies, and other regulated institutions across Africa. We approach incident response from the offensive side: a manual penetration test, run while your security team watches the wire, is the most honest test of whether detection fires and the escalation chain holds. Our testing is led by an OSCP-credentialled practitioner whose engagement history includes a Tier-1 Nordic bank red team.
See our penetration testing service page for methodology and deliverables, and our security assessments page for broader programme reviews. Book a Free Call to discuss incident response readiness for your institution.