The recent bank fraud incident in East Africa demonstrated something that security professionals already knew: the institutions that detect and respond fastest are the ones that limit damage. That bank contained the incident within hours and reversed most fraudulent transactions. Most 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. But a document on a shelf is not a capability. This guide covers what BNR expects, how to build an IRP that actually works, how to test it through tabletop exercises and simulations, and what reporting obligations you need to meet.
What BNR requires
The BNR Regulation on Cyber Security requires regulated financial institutions to have a documented incident response plan. The specific expectations include:
- A formal, board-approved incident response policy
- A designated incident response team with clearly defined roles and responsibilities
- Documented procedures covering detection, containment, eradication, recovery, and post-incident review
- Prompt reporting of significant cyber incidents to BNR
- Regular testing of the incident response plan
- Post-incident analysis and lessons learned to improve the programme
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.
The six phases of incident response
A BNR-compliant IRP should follow the established NIST incident response lifecycle, adapted for the East African banking context.
Phase 1: Preparation
This is everything you do before an incident occurs. It is the most important phase and the one most institutions underinvest in.
What to document:
- Incident response team composition and contact information (including after-hours contacts)
- Escalation matrix: who makes decisions at each severity level
- Communication templates for internal notification, BNR reporting, customer notification, and media statements
- Technical toolkit: forensic imaging tools, network isolation procedures, backup restoration processes
- Relationships with external parties: forensic investigators, legal counsel, law enforcement contacts, your penetration testing provider
- Insurance coverage and claims procedures
What to implement:
- Centralised log collection (SIEM) with sufficient retention for investigation
- Network monitoring capable of detecting anomalous activity
- Endpoint detection and response (EDR) on critical systems
- Backup systems tested and verified for integrity
- Network segmentation that allows isolation of compromised segments
Preparation is not just documentation. The institutions that respond well are the ones that invested in detection capabilities, practised their procedures, and built relationships with external support before the incident. If your first conversation with a forensics firm happens during an active breach, you have already lost valuable time.
Phase 2: Detection and analysis
The time between initial compromise and detection is the single most important metric in incident response. In East Africa, dwell times of weeks or months are common.
Detection sources:
- SIEM alerts on anomalous activity
- Intrusion detection system (IDS) alerts
- Anti-malware detections
- User reports of suspicious behaviour
- Transaction monitoring alerts (critical for banking)
- Third-party notifications (card brands, partner institutions, threat intelligence feeds)
- BNR or NCSA notifications
Analysis requirements:
- Determine the scope of the incident: which systems are affected, what data is at risk
- Classify severity based on a predefined scale (Critical, High, Medium, Low)
- Identify the attack vector: how did the attacker get in
- Assess whether the incident is ongoing or contained
- Preserve evidence for investigation and potential legal action
Phase 3: Containment
Containment aims to stop the incident from spreading while preserving evidence. There are two sub-phases:
Short-term containment (minutes to hours):
- Isolate affected systems from the network
- Block malicious IP addresses and domains at the firewall
- Disable compromised user accounts
- Redirect traffic away from compromised systems
- Preserve system images before any remediation
Long-term containment (hours to days):
- Deploy temporary fixes to prevent re-exploitation
- Increase monitoring on related systems
- Implement additional access restrictions
- Set up clean systems to replace compromised ones
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
- Reset all potentially compromised credentials
- Verify that the attacker has no remaining access through alternative channels
- Conduct thorough scanning of all systems that may have been touched
This phase is where many institutions fail. Incomplete eradication leads to re-compromise, sometimes within days. If you do not have internal forensic capability, engage an external specialist.
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
- Implement enhanced monitoring during the recovery period
- Conduct thorough testing before returning systems to production
- Gradually restore services, starting with the most critical
- Verify data integrity, especially for financial transaction data
Phase 6: Post-incident review
This phase is required by BNR and is where your institution actually improves:
- Conduct a formal post-incident review within two weeks of resolution
- Document what happened, when, how it was detected, and how it was handled
- Identify what worked well and what failed
- Update the IRP based on lessons learned
- Brief the board on the incident and the improvements being made
- File required reports with BNR
Building your incident response team
The IRT should include representatives from:
- Information security: leads the technical response
- IT operations: handles system isolation, restoration, and infrastructure changes
- Compliance/legal: manages regulatory reporting and legal obligations
- Communications: handles internal and external messaging
- Business leadership: makes decisions on service availability and customer impact
- HR: handles insider threat scenarios and employee-related incidents
Each role needs a primary and backup person. Contact information must be current and accessible outside of corporate email (which may be compromised during an incident). A printed contact list and a secondary communication channel (a secure messaging group) are essentials.
Designate decision-makers in advance. During an incident, the most common source of delay is waiting for someone to authorise a critical action like isolating a system or shutting down a service. Your IRP must specify who has authority to make these decisions at each severity level, including after hours and when the primary decision-maker is unavailable.
Tabletop exercises: testing the plan
A tabletop exercise is the most practical way to test your IRP without impacting live systems. Here is how to run one effectively.
Scenario design
Build scenarios that reflect realistic threats to your institution. Good scenarios for East African banks:
- Vendor platform compromise: a third-party core banking vendor is breached, and attackers are using the vendor’s access to initiate fraudulent transactions
- Ransomware on the corporate network: ransomware has encrypted file servers and is spreading to other systems. Core banking is on a separate network segment but connectivity exists
- Mobile money channel exploitation: anomalous transactions detected through the mobile money integration, with hundreds of small transfers to new SIM cards
- Insider data theft: a database administrator is exfiltrating customer data through encrypted channels
- Phishing compromise of executive email: the CEO’s email account has been compromised and is being used to send fraudulent payment instructions to the finance team
Exercise format
Duration: 2 to 3 hours
Participants: full incident response team plus relevant business stakeholders
Facilitation: an independent facilitator (internal or external) who presents the scenario in stages, introducing new information as the exercise progresses
Structure:
- Scenario introduction and initial detection alert (15 minutes)
- Initial response: who does what, first decisions (30 minutes)
- Escalation: new information reveals the incident is larger than initially thought (30 minutes)
- Containment decisions: trade-offs between service availability and security (30 minutes)
- Recovery and communication: how to restore services and what to tell stakeholders (20 minutes)
- Debrief and lessons learned (30 minutes)
What to evaluate
During the exercise, the facilitator should assess:
- Time to detect: how quickly does the team recognise the scenario as an incident
- Clarity of roles: does everyone know what they are supposed to do
- Escalation effectiveness: does information flow to decision-makers quickly
- Communication: are internal and external communications handled appropriately
- BNR reporting: does the team know when and how to report to the regulator
- Decision-making: are trade-off decisions (e.g., taking systems offline) made decisively
- Technical capability: does the team have the tools and access needed to respond
Common failures we observe
- Nobody knows who makes the call to isolate systems
- BNR reporting procedures are unknown or out of date
- 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
- Backup restoration has never been tested for the affected systems
Reporting to BNR
BNR expects prompt notification of significant cyber incidents. While the regulation does not specify an exact timeframe in hours, the expectation is clear: report as soon as practicable, and do not wait until the incident is fully resolved.
What to report
- Nature and classification of the incident
- Date and time of detection
- Systems and services affected
- Customer impact (data exposure, service disruption, financial loss)
- Containment actions taken
- Current status (ongoing, contained, resolved)
- Planned remediation steps
- Estimated timeline for full resolution
When to report
Report any incident that involves:
- Unauthorised access to customer data
- Service disruption affecting customers
- Financial loss through cyber means
- Compromise of critical banking infrastructure
- Incidents that could affect the stability of the financial system
- Ransomware or destructive malware
Follow-up reporting
After the initial notification, BNR will expect progress updates and a final post-incident report covering root cause analysis, full impact assessment, 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. This tests both your technical controls and your human response. See our comparison of red team vs penetration testing for how this fits into your testing programme.
- Backup restoration drills: actually restore critical systems from backup to verify recovery time objectives (RTOs) can be met
- Network isolation drills: practise isolating network segments to verify that segmentation controls work and that critical services remain available
- Communication drills: test the out-of-band communication channels you plan to use when corporate email and messaging may be compromised
How we can help
We are an OSCP-certified penetration testing firm based in Kigali. Beyond penetration testing, we help institutions test their incident response capabilities through scenario-based exercises that simulate the threats facing East African banks. Our tabletop exercises use scenarios drawn from real incidents in the region and are designed to surface the gaps that matter most.
For details on our testing methodology and deliverables, see our penetration testing service page. For broader security programme assessments, see our security assessments service page. Contact us to discuss incident response readiness for your institution.