Most companies rebuild wrong
The most common post-breach mistake is treating remediation as a single action: patch the vulnerability, restore from backup, move on. This approach fails because it addresses the symptom (the specific vulnerability) without addressing the disease (the systemic security gaps that allowed the breach to happen and go undetected).
The Sterling Bank-Remita breach was not caused by a single unpatched server. It was caused by an unpatched server PLUS flat network architecture PLUS inadequate monitoring PLUS a 9-day detection gap. Patching the server alone would not have prevented a different attack vector from producing the same result.
Rebuilding your security posture requires three parallel workstreams: root cause analysis (understanding the systemic failures), prioritised remediation (fixing what matters most, first), and stakeholder communication (demonstrating to regulators, customers, and investors that you are taking this seriously).
Post-incident assessment methodology
Before you fix anything, you need to understand what actually failed. A post-incident assessment goes deeper than the forensic investigation that identified the attack vector. It examines why your security programme did not prevent, detect, or contain the breach effectively.
Root cause analysis: The three failure modes
Every breach results from one or more of three failure types. Your remediation strategy must address the actual failure mode, not just the technical exploit.
Technical failure
A specific security control was absent, misconfigured, or insufficient. Examples: an API endpoint lacked proper authorisation checks, database encryption was not enabled at rest, .env files were committed to a public repository, or TLS was not enforced on internal API calls. Technical failures are the most straightforward to remediate but are rarely the only contributing factor.
Process failure
The organisation lacked procedures to prevent or detect the issue. Examples: no vulnerability management process (so critical patches were never applied), no code review requirements for security-sensitive changes, no access review process (so a terminated contractor still had admin access), or no incident response plan (so the team improvised during the breach).
People failure
Staff lacked the knowledge, training, or accountability to maintain security. Examples: an engineer deployed API keys directly in source code because nobody taught them about secrets management, a support agent fell for a social engineering attack because the team had no security awareness training, or leadership deprioritised security because there was no accountability framework.
Most breaches involve all three failure modes. An attacker exploits a technical vulnerability (missing input validation) that exists because the development process lacked security review (process failure) and the engineering team had no secure coding training (people failure). Your remediation must address all contributing layers.
The prioritised remediation roadmap
You cannot fix everything simultaneously. Attempting to overhaul your entire security programme in one sprint leads to paralysis, half-implemented controls, and engineer burnout. Instead, use a phased roadmap that addresses the highest-risk items first.
Days 1-7: Stop the immediate risk
These are actions that must be completed within the first week after the incident is contained. Every item here directly reduces the probability of a second breach through the same or similar attack vector.
- Patch the exploited vulnerability: The specific vulnerability that allowed the initial compromise must be fixed immediately. If it was a broken access control issue, redesign the authorisation logic. If it was an unpatched CVE, apply the patch and verify.
- Complete credential rotation: Every credential in the environment must be rotated: API keys, database passwords, encryption keys, OAuth client secrets, SSH keys, service account tokens. The attacker may have harvested credentials beyond what your forensic investigation identified.
- Remove persistence mechanisms: Verify that all attacker-installed backdoors, web shells, cron jobs, scheduled tasks, and modified configuration files have been removed. Use file integrity monitoring to verify the integrity of critical system files.
- Commission a verification pentest: Engage a penetration testing firm to validate that the exploited vulnerability is actually fixed and to test for related weaknesses. This report becomes critical evidence for regulators.
- Enable enhanced monitoring: Deploy or configure alerting on the specific indicators of compromise (IOCs) associated with the breach. Set SIEM alert thresholds lower than normal. Monitor for attacker re-entry attempts for at least 90 days.
Days 8-30: Fix systemic gaps
These actions address the process and architectural failures that allowed the breach to succeed and go undetected.
- Implement network segmentation: If the breach involved lateral movement (the attacker pivoted from one system to access others), implement zero-trust network segmentation. Payment systems, customer databases, and corporate IT should exist in isolated network zones with strict firewall rules governing inter-zone traffic.
- Deploy or upgrade SIEM/EDR: If you had no centralised logging and monitoring, deploy a SIEM (Wazuh is a capable open-source option). If you had monitoring that failed to detect the breach, review and tune your detection rules. The goal: reduce your detection time from days to hours.
- Establish vulnerability management: Implement automated vulnerability scanning (at least monthly) with defined SLAs for patching: 72 hours for critical, 30 days for high, 90 days for medium. Track compliance against these SLAs.
- Review and harden API security: Audit all API endpoints for authentication, authorisation, rate limiting, and input validation. Nigerian fintech breaches disproportionately originate from API vulnerabilities because APIs are the largest attack surface.
- Update the incident response plan: Incorporate lessons learned from the breach. Update the IR plan with new team roles, improved communication procedures, and updated tool inventory. Schedule a tabletop exercise to test the updated plan.
Rebuilding after a breach requires expert guidance. We structure post-breach engagements to close gaps systematically.
Get Post-Breach SupportDays 31-90: Build the programme
These actions transform your security from a reactive patchwork into a sustainable programme.
- Security awareness training: Roll out training for all staff, with specialised modules for engineering teams (secure coding, JWT security, secrets management) and customer-facing teams (social engineering defence, phishing identification). This addresses the people failure mode.
- Secure development lifecycle: Integrate security into your development process: mandatory code reviews for security-sensitive code, automated SAST/DAST scanning in CI/CD, threat modelling for new features, and a security checklist for every deployment.
- Third-party risk assessment: Audit the security posture of every third-party service that processes your data. Review contracts for security requirements. Monitor third-party SDK security. If a vendor's compromise would compromise your customers, that vendor needs to demonstrate adequate controls.
- Data protection compliance: Ensure full compliance with the NDPA: data classification policy, encryption at rest and in transit, data processing records, DPO appointment, and data subject rights procedures. The NDPC will scrutinise your data protection posture closely during post-breach follow-up.
- 90-day follow-up pentest: Commission a comprehensive penetration test covering your full attack surface (external network, APIs, mobile apps, internal network). This validates that your 30-90 day remediation has been effective and produces a clean report for regulators and investors.
Communicating recovery to stakeholders
A breach damages relationships with three critical stakeholder groups. Each requires a different communication strategy.
Customers: The transparency framework
Customer communication after a breach must balance transparency with responsibility. The worst approach is silence. The second worst is vague corporate statements that say nothing.
- Initial notification: Clearly state what data was compromised, what you have done about it, and what customers should do to protect themselves. If BVNs were exposed, recommend they contact NIBSS for fraud monitoring. If passwords were compromised, force a password reset.
- Ongoing updates: Provide regular updates as your investigation progresses and remediation advances. Customers need to see that you are actively addressing the issue, not just issuing a one-time apology.
- Demonstrate improvement: When your verification pentest confirms remediation, communicate this. "We engaged an independent security firm to verify that the vulnerability has been fixed and to conduct a comprehensive security assessment of our platform" carries weight.
- Offer tangible protection: Where possible, offer affected customers concrete protective measures: free credit monitoring, identity theft protection services, or enhanced account security features (hardware MFA tokens). The cost is a fraction of the customer acquisition cost to replace churned users.
Investors: The security posture improvement plan
Investors are primarily concerned with two questions: "How bad is the financial exposure?" and "How do we prevent this from destroying our investment?" Your communication should address both with data.
- Financial impact assessment: Quantify the total breach cost: direct losses, regulatory fines (actual or estimated), legal fees, DFIR costs, customer compensation, and projected revenue impact from churn. Be realistic. Investors respect accuracy more than optimism.
- Remediation investment plan: Present a budgeted security improvement plan with specific line items: pentest programme cost, SIEM deployment, additional security headcount, training programmes. Tie each investment to a specific risk reduction.
- Third-party validation: Provide investors with independent pentest reports, architecture review findings, and compliance certifications. Third-party validation carries more weight than internal assurances.
- Milestones and metrics: Define measurable security metrics: mean time to detect (MTTD), mean time to respond (MTTR), patching SLA compliance, percentage of critical findings remediated. Report progress against these metrics quarterly.
Regulators: Compliance evidence
The NDPC and CBN will follow up on your breach notification. They want to see evidence that you have taken the breach seriously and implemented appropriate measures to prevent recurrence.
- Remediation evidence: Submit the verification pentest report showing the exploited vulnerability has been fixed. Provide documentation of additional security controls implemented.
- Process improvements: Demonstrate new or updated policies: incident response plan, vulnerability management process, access control procedures, data classification policy.
- Ongoing compliance: Show evidence of sustained improvement: quarterly pentest reports, training completion records, vulnerability scan results, incident response exercise reports.
The cost of getting it wrong
Nigerian fintechs that fail to demonstrate adequate post-breach remediation face compounding consequences. The total cost of a data breach for a mid-sized fintech can exceed ₦100 million when you factor in NDPA fines (up to 2% of gross revenue), CBN penalties (up to ₦1 billion for severe failures), legal defence costs, customer churn, and the operational cost of emergency remediation.
Re-testing cadence
Post-breach testing is not a one-time event. Your re-testing schedule should be aggressive in the first year and normalise over time.
- Immediate (Week 1): Verification pentest targeting the specific exploited vulnerability and related attack surface. Confirms the fix is effective.
- 90-day follow-up: Comprehensive penetration test covering external network, APIs, mobile applications, and internal network. Validates the broader remediation programme.
- Quarterly (Year 1): Quarterly pentests for the first year post-breach. Each test should cover the full scope and specifically re-test previously identified findings to confirm they remain remediated.
- Semi-annual or continuous (Year 2+): Move to a semi-annual or continuous testing programme based on your risk profile and the maturity of your security programme.
Rebuilding security culture
A breach either destroys your security culture or catalyses it. The difference is leadership response.
If leadership treats the breach as someone's fault, engineers learn to hide security issues. If the post-breach response is punitive, the next vulnerability will go unreported until an attacker finds it. If security is treated as an obstacle to shipping, engineers will route around it.
The correct response is to treat the breach as a systemic failure and invest in systemic fixes. Allocate engineering time for security improvements. Celebrate security findings (internally) instead of punishing them. Make security a promotion criterion, not just a compliance checkbox. Fund the tools, training, and headcount that your security programme needs.
Companies that emerge stronger from a breach are the ones that use it as the catalyst to build a real security programme. Companies that treat it as a one-time cleanup get breached again.
How Simpa Labs structures post-breach engagements
We have helped Nigerian fintechs recover from breaches and rebuild their security posture. Our post-breach engagement follows a structured three-phase approach:
Phase 1: Gap assessment
We conduct a comprehensive security assessment that goes beyond the exploited vulnerability. We examine your entire attack surface, security architecture, access controls, API security, mobile app security, and infrastructure configuration to identify all systemic gaps.
Phase 2: Remediation support
We provide a prioritised remediation roadmap with specific, actionable findings. For each finding, we include the risk rating, technical description, proof of exploitability, and step-by-step remediation guidance your engineers can implement. We are available for follow-up consultations as your team works through the fixes.
Phase 3: Verification pentest
After remediation, we conduct a verification penetration test that specifically re-tests all previously identified findings and explores the broader attack surface. The resulting report provides documented evidence of your improved security posture for submission to the NDPC, CBN, investors, and enterprise clients.
Whether you are in the middle of a breach recovery or proactively strengthening your security, we can help.
Discuss Post-Breach RecoveryFrequently asked questions
How long does it take to fully recover from a data breach?
A meaningful recovery, where the root cause is eliminated, systems are hardened, and regulatory obligations are satisfied, typically takes 90 to 180 days for a mid-sized Nigerian fintech. The initial remediation of the exploited vulnerability should happen within days, but building a comprehensive security programme that prevents recurrence takes months of sustained effort.
Should we hire a new CISO or security team after a breach?
Not necessarily. If the breach resulted from systemic underinvestment in security rather than individual incompetence, replacing people without fixing the system just resets the clock. However, if the breach revealed a fundamental lack of security leadership capability, bringing in experienced security leadership is appropriate. Many Nigerian fintechs had no security function before their first breach.
How do we communicate recovery to investors?
Investors need to see a concrete, time-bound security improvement plan with measurable milestones. Present: root cause analysis, specific remediation actions taken, third-party verification (pentest reports), ongoing monitoring improvements, and the investment required. Frame security spending as risk reduction that protects their investment, not as a cost centre.
How often should we conduct penetration tests after a breach?
Immediately after remediation (verification pentest), again at 90 days to confirm ongoing effectiveness, then quarterly for at least the first year. After the first year, you can move to a semi-annual or continuous testing programme depending on your risk profile and regulatory requirements.
Related reading
Blog: Hacked: First 72 Hours · Reporting to NDPC · What Happens After a Pentest
Guides: After a Breach · Fintech Security Checklist
Services: Penetration Testing · Secure Architecture Review