Incident response plan framework for Nigerian fintechs

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs CEH (Certified Ethical Hacker)

Why Nigerian fintechs cannot afford to improvise

The regulatory environment for Nigerian financial technology companies has shifted decisively. The NDPA imposes a hard 72-hour breach notification deadline with fines of up to ₦10 million or 2% of annual gross revenue. The CBN's Risk-Based Cybersecurity Framework requires licensed institutions to maintain and regularly test incident response capabilities. In 2024, the CBN levied over ₦1 billion in cumulative cybersecurity-related fines, and several enforcement actions specifically cited the absence of documented incident response procedures.

NIBSS data from 2024 shows over ₦18 billion in fraud losses across Nigerian financial institutions. The median detection time for breaches in the sector is 120 days. Every additional day an attacker spends inside your network increases the scope of compromise, the volume of data exfiltrated, and the regulatory penalty you face. A tested incident response plan reduces detection-to-containment time from weeks to hours.

This framework follows the six-phase model established by NIST SP 800-61 (Computer Security Incident Handling Guide), adapted for Nigeria's regulatory requirements and the operational realities of fintech startups.

Phase 1: Preparation

Preparation is the only phase that happens before the breach. It is also the phase most Nigerian fintechs skip entirely, treating incident response as something they will figure out when it happens. That approach is how you end up paying ₦100 million in fines instead of ₦5 million.

Build your incident response team

Every person on this team must know their role before the incident occurs. During a breach, there is no time to figure out who does what.

Communication tree

Document the exact escalation path. When the on-call engineer detects anomalous activity at 2 AM, they must know exactly who to call, in what order, and through what channel. The communication tree should include primary and backup contacts for every role, personal mobile numbers (not just work email), and an out-of-band communication channel (Signal group, personal WhatsApp group) in case corporate Slack or email is compromised.

Tool inventory

Document every tool your team will need during an incident and verify access quarterly:

• Forensic imaging: dd, FTK Imager, or AWS EBS snapshot capabilities. Verify that engineers know how to create bit-for-bit disk images.
• Memory capture: LiME (Linux), WinPMEM (Windows). These must be pre-installed or available on a USB drive accessible to the team.
• Log aggregation: Your SIEM (Wazuh, Splunk, ELK) must be collecting logs from all production systems. Verify log retention is at least 90 days.
• Network monitoring: tcpdump, Wireshark, or cloud-native VPC Flow Logs. Ability to capture live network traffic during an incident.
• Secure communication: Out-of-band channel (Signal, secondary Slack workspace on clean devices) for IR team coordination.

Phase 2: Detection and analysis

Detection is where most Nigerian fintechs fail catastrophically. Without adequate monitoring, breaches go undetected for months. The Sterling Bank-Remita breach involved a 9-day persistence window. Many smaller fintechs have no detection capability at all.

Indicators of compromise (IOCs)

Your team must know what to look for. These are the most common IOCs in Nigerian fintech breaches:

• Unusual API traffic patterns: Spike in API calls to sensitive endpoints (user data export, transaction listings, BVN lookup) outside normal business hours or from unexpected IP ranges.
• New admin accounts: Any admin or superuser account created outside your normal onboarding process. Attackers frequently create persistence accounts with names that blend in ("svc-monitor", "backup-admin").
• Abnormal database queries: SELECT * queries on user tables, bulk data exports, or queries accessing columns not used by any application feature (e.g., direct BVN column access).
• Outbound data transfers: Large volumes of data leaving your network to unknown IP addresses, especially to regions where you have no customers or operations.
• Failed authentication spikes: Mass login failures followed by a successful login may indicate credential stuffing or brute-force attacks that eventually succeeded.
• Modified application code: Unexpected changes to production code, especially in payment processing, webhook handling, or authentication modules.

Severity classification

Not every alert is a critical incident. Your plan must define severity levels to prevent alert fatigue and ensure appropriate escalation:

• Critical (P0): Active data exfiltration, unauthorised fund transfers, compromised payment processing, ransomware deployment. Activate full IR team immediately. NDPC/CBN notification likely required.
• High (P1): Confirmed unauthorised access to production systems, compromised credentials with admin privileges, evidence of lateral movement. Activate IR team within 1 hour.
• Medium (P2): Suspicious activity that has not been confirmed as malicious: unusual login patterns, anomalous API usage, unrecognised processes. Investigate within 4 hours.
• Low (P3): Security policy violations, failed attack attempts blocked by controls, vulnerability scanner findings. Investigate within 24 hours.

Phase 3: Containment

Containment has two sub-phases: short-term containment to stop the immediate damage, and long-term containment to prepare for eradication without losing the evidence you need for forensics and regulatory reporting.

Short-term containment

Execute within the first 1-4 hours of confirmed compromise. The goal is to stop the attack from spreading without destroying evidence. See our detailed first 72 hours playbook for hour-by-hour containment steps.

• Network isolation: Remove affected systems from the network (revoke security groups, disconnect from VPC, disable network interfaces). Do NOT power off systems.
• Credential revocation: Rotate all credentials that may be compromised. This includes API keys, database passwords, secrets in environment variables, OAuth tokens, and SSH keys.
• Block attacker access: If you have identified the attacker's IP addresses, C2 domains, or compromised accounts, block them at the firewall, WAF, and IAM level immediately.

Long-term containment and evidence preservation

Once the immediate threat is stopped, preserve evidence for forensics, regulatory reporting, and potential legal proceedings.

• Forensic disk images: Create bit-for-bit copies of all affected system disks. Store originals untouched. All analysis happens on copies.
• Memory dumps: Capture RAM from affected systems before they are eventually powered down.
• Log preservation: Export all relevant logs to immutable storage. Ensure log retention covers at least 30 days before the detected compromise date.
• Chain of custody documentation: Document who captured each piece of evidence, when, using what tool, and where it is stored. This documentation is required if the case goes to law enforcement or court.

Phase 4: Eradication

Eradication eliminates the root cause. Containment stops the bleeding; eradication removes the knife.

• Root cause elimination: Patch the vulnerability that allowed initial access. If it was a BOLA vulnerability, fix the authorisation logic. If it was an unpatched server, update and harden it. If it was a broken access control, redesign the permission model.
• Malware removal: If the attacker deployed backdoors, web shells, or persistence mechanisms (cron jobs, scheduled tasks, modified SSH authorized_keys), remove them all. Use file integrity monitoring to verify no malicious modifications remain.
• Complete credential rotation: Rotate ALL credentials across the entire infrastructure, not just the ones you know were compromised. The attacker may have accessed credential stores you have not identified yet.
• Rebuild compromised systems: For severely compromised systems, rebuild from known-good images rather than attempting to clean them. You cannot be certain you have removed every backdoor from a system an attacker had root access to for days or weeks.

Phase 5: Recovery

Recovery brings systems back to normal operations with enhanced monitoring to detect any attacker re-entry.

• Staged restoration: Bring systems back online gradually, starting with the least sensitive. Monitor each system intensively for 48-72 hours before restoring the next. Do not rush to restore everything simultaneously.
• Enhanced monitoring: Deploy additional monitoring on recovered systems. Set SIEM alert thresholds lower than normal for at least 90 days. The attacker may attempt to re-enter through a backdoor you missed.
• Validation testing: Run a focused penetration test against the specific attack vector that was exploited, plus related attack surfaces. This validates that your eradication was effective and produces a report for regulators.
• Customer-facing service restoration: When restoring public-facing services, communicate the restoration timeline to customers. Provide clear guidance on any actions they need to take (password resets, monitoring their accounts).

Phase 6: Post-incident activities

This is the phase that separates companies that improve from companies that get breached twice.

Lessons learned retrospective

Conduct a blameless post-incident review within 5 business days of incident closure. The retrospective must answer:

• What happened? Complete timeline from initial compromise to full recovery.
• What worked? Which parts of the IR plan were effective? Which tools and processes functioned as intended?
• What failed? Where did detection fail? Where did communication break down? What tools were missing?
• What will we change? Specific, actionable improvements with owners and deadlines. "Improve monitoring" is not actionable. "Deploy Wazuh agents on all production nodes by August 15" is.

Regulatory reporting

Map your post-incident obligations to each regulator:

Process improvements

Update your IR plan based on the retrospective findings. Common improvements after a first incident include: deploying a SIEM or upgrading log retention, implementing zero-trust network segmentation, adding security awareness training for all staff, establishing a continuous pentest programme, and documenting communication templates for each stakeholder type.

Communication templates

Pre-draft these templates and have legal counsel approve them before an incident occurs. During a breach, you will not have time to write and review communications from scratch.

• Internal escalation alert: "[SEVERITY LEVEL] security incident detected at [TIMESTAMP]. Incident Commander: [NAME]. All IR team members report to [CHANNEL] immediately. Do not discuss on any other channel."
• Customer notification: "We are writing to inform you of a security incident affecting your account. On [DATE], we detected unauthorised access to [SPECIFIC SYSTEMS]. The following data may have been affected: [LIST]. We have taken the following actions: [LIST]. We recommend you: [ACTIONS]."
• Press holding statement: "[COMPANY] is aware of a cybersecurity incident and is actively investigating with the support of independent security experts. We are cooperating with relevant regulatory authorities. We will provide further updates as our investigation progresses."
• Partner notification: "We are notifying you of a security incident that may affect our shared integration. We recommend you review API activity from our systems for the period [DATE RANGE] and rotate shared credentials. Our technical team is available to coordinate at [CONTACT]."

Related reading

Blog: Hacked: First 72 Hours · Reporting to NDPC · Security Culture

Guides: After a Breach · CBN Compliance Guide

Services: Penetration Testing · Secure Architecture Review