Hour 0–4: Immediate containment
The attacker may still be active. Your first priority is to stop the bleeding without destroying evidence.
- Isolate the affected component: Disable the compromised feature, API endpoint, or service — don't shut down the entire platform if you can avoid it. Revoke the specific access vector.
- Force session invalidation: Rotate all session tokens, API keys, and secrets that may have been exposed. Force all users to re-authenticate.
- Preserve evidence: Do NOT wipe logs, redeploy code, or reset databases. You need the evidence for investigation. Take snapshots of current server state, database state, and all application logs.
- Freeze deployments: No code changes until you understand the root cause. A hasty "fix" can destroy the forensic trail or introduce new issues.
- Assemble your response team: Engineering lead, CTO, compliance officer, legal counsel. Establish a private communication channel (not the channel the attacker may be monitoring).
Hour 4–24: Investigation
Once the immediate attack vector is contained, determine what happened, what data was affected, and whether the attacker still has access.
Identify the root cause
Trace the attack from the earliest suspicious log entry. Was it an API authorization bypass? A compromised credential? A logic flaw in a payment flow? Understanding the mechanism determines how you seal it.
Determine the blast radius
What data was accessed? How many accounts were affected? Were funds moved? Was PII (BVNs, account numbers, personal details) exposed? The scope of data impact drives your notification obligations.
Check for persistence
Did the attacker create backdoor accounts, plant API keys, or modify configuration? Check for new admin users, unfamiliar SSH keys, modified webhook URLs, and unusual scheduled jobs.
Engage external expertise
If your engineering team doesn't have incident response experience, bring in external security professionals immediately. The cost of expert help during a breach is trivial compared to the cost of an incomplete remediation.
Hour 24–72: Notification and communication
Once you understand the breach scope, you have notification obligations — both regulatory and to your customers.
Regulatory notification
If you hold a CBN license (PSSP, MMO, MFB, or other OFI), report the incident to the CBN per their cybersecurity incident reporting guidelines. The NDPC (Nigeria Data Protection Commission) also requires notification if personal data was compromised. Document everything — regulators will ask for a timeline.
Customer notification
Be direct and factual. Tell affected users: what happened, what data was involved, what you've done to contain it, and what they should do (change passwords, monitor accounts, report suspicious activity). Do not minimize or obscure. Transparency preserves what trust remains.
Partner and payment processor notification
If the breach may have affected payment processing, settlement, or integration partners (Paystack, Flutterwave, bank partners), notify them immediately. They may need to take defensive actions on their side.
After containment: Preventing recurrence
A breach is a symptom. The underlying cause is a gap in your security posture. After the immediate crisis is resolved:
- Conduct a full penetration test: Not just on the breached component, but across your entire product surface. If one vulnerability existed, others likely do.
- Review your authentication and session management: Account takeover through broken auth is the #1 cause of fintech breaches. Ensure your auth chain is airtight.
- Audit API authorization: BOLA/IDOR flaws are the most common vulnerability class in fintech APIs. Verify that every endpoint enforces proper access control.
- Implement a continuous testing cadence: A single annual pentest isn't enough for a fast-shipping team. Establish quarterly assessments and on-demand reviews for major feature releases.
- Document and train: Write up the incident as a post-mortem. Share it with your engineering team. Build the lessons into your development process.
Dealing with a breach right now? We can help identify the root cause and seal the gap.
Contact Us ImmediatelyRelated services and resources
After a breach, most teams immediately engage us for a full penetration test and vulnerability assessment. For ongoing protection, see our startup engagement model — which includes quarterly testing and on-demand reviews. To understand the regulatory implications, read our CBN compliance guide. For self-assessment, start with our fintech security checklist.
Frequently asked questions
Should we shut down our platform immediately?
Not necessarily. Shutting down your entire platform is a drastic step that also halts legitimate business. The priority is containment — isolate the affected component (disable a specific API endpoint, invalidate compromised sessions, freeze a feature) rather than killing everything. You need to be surgical.
Do we have to notify the CBN?
If you are a licensed financial institution (PSSP, MMO, MFB), yes. CBN guidelines require timely notification of significant cybersecurity incidents. The specifics depend on your license type. Consult your compliance officer immediately, but don't wait for legal clarity before starting containment.
How fast should we tell our customers?
As soon as you have confirmed the breach and understand what data was affected. Delayed notification erodes trust more than the breach itself. Be factual: what happened, what data was involved, what you're doing about it, and what customers should do (e.g., change passwords, monitor accounts).
Can Simpa Labs help during an active breach?
Yes. We offer rapid-response assessments to help identify the root cause, contain the breach, and verify that the vulnerability is fully remediated. Contact security@simpalabs.com with the subject line 'Urgent: Active Breach' and we will respond immediately.