Vulnerability assessment for banking: what it covers, what CBN requires, and what most vendors skip

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs Comprehensive Security Partner (CSP)

The banking sector in Nigeria moves incredibly fast. Engineering teams push code multiple times a day. Infrastructure spins up and tears down automatically. In this environment, assuming your security posture remains static is a fatal mistake. You deploy a secure API on Monday. A developer changes a firewall rule on Tuesday. You get breached on Wednesday.

This is why continuous mapping of your attack surface is non-negotiable. A vulnerability assessment provides that map. But there is a massive difference between a generic IT assessment and a vulnerability assessment designed specifically for banking infrastructure.

Many vendors sell you automated scanner output. They run Nessus against your IP addresses, export a 400-page PDF, and charge you thousands of dollars. The CBN rejects these reports. They offer zero actual value. They miss the logic flaws that hackers actively use to steal money. Here is what a real, practitioner-led vulnerability assessment for a Nigerian bank looks like.

What a banking vulnerability assessment tests

A proper vulnerability assessment for a bank, neobank, or licensed fintech covers every single layer of your product that an attacker can reach. It does not stop at the firewall.

It covers the customer-facing mobile application. It covers the core API layer behind it. It heavily targets the internal admin tools your operations team uses. It scrutinizes your third-party integrations with NIBSS and payment gateways. Finally, it analyzes the underlying cloud infrastructure configuration. If an attacker can touch it, we map its weaknesses.

Application-layer vulnerabilities

We test for the full OWASP Top 10 and far beyond. We look for injection, broken access control, authentication failures, Server-Side Request Forgery (SSRF), and security misconfigurations.

For banking products, the highest-impact application-layer findings are always authorization failures. If your app allows one customer to access another customer's data, you have failed. If your app allows a user to initiate a transfer on behalf of another user, you have failed. We specifically hunt for Broken Object Level Authorization (BOLA).

# Common BOLA test in a banking API
# Logged in as Customer A, accessing Customer B's account statement
curl -X GET https://api.bank.com/v1/accounts/CUSTOMER_B_ACCT/statements \
  -H "Authorization: Bearer CUSTOMER_A_TOKEN"

# Expected: 403 Forbidden
# Finding: 200 OK with Customer B's complete statement
# Severity: Critical

We also look for business logic weaknesses. Scanners cannot understand that a user transferring a negative amount of money is a security risk. Scanners do not know what a transfer is. Human engineers do. We map every logical state transition in your application and test the boundaries of those states.

Configuration and infrastructure

Your application code might be perfect. But if your cloud configuration is weak, the code does not matter. We hunt for exposed debug endpoints. We hunt for default credentials left active on internal admin panels. We identify overly permissive Cross-Origin Resource Sharing (CORS) policies that allow external domains to read your API data.

We check for missing security headers, weak TLS configurations, and publicly accessible development environments. We map the entire infrastructure that supports your application.

# Check for exposed services that should not be public
nmap -sV --top-ports 1000 your-banking-domain.com

# Common findings in Nigerian banking infrastructure:
# - Swagger/OpenAPI docs exposed without authentication
# - Redis or MongoDB instances on public IPs without auth
# - Admin panels at predictable paths (/admin, /dashboard, /ops)
# - Development/staging environments on subdomains (dev.bank.com)

A very common finding in our assessments is discovering a staging server on a subdomain. The developers cloned the production database to the staging server for testing. They forgot to secure the staging server. The production application is perfectly secure, but the staging environment leaks the entire customer database. We find these shadow environments and shut them down.

Third-party integration risks

No bank operates in isolation. Every banking product in Nigeria integrates with NIBSS. You integrate with payment gateways like Paystack or Flutterwave. You integrate with BVN and NIN verification providers like SmileID or YouVerify. You integrate with card processors.

Every single integration is a trust boundary. An attacker will exploit the weakest link in that chain. We assess whether you actually verify cryptographic signatures on incoming webhooks. We check if your core API credentials are stored securely in a vault, or if they are hardcoded in plaintext. We verify that your system strictly validates the data types and bounds of responses from third parties before acting on them.

Data handling and storage

Where is your customer data actually stored? Is it encrypted at rest using industry-standard AES-256? Are sensitive data points like BVN numbers, account numbers, and transaction payloads carelessly logged in application logs?

We frequently find engineering teams caching entire JSON responses in Redis to improve speed. Those responses contain plaintext passwords and BVNs. Redis is rarely encrypted. If an attacker breaches the internal network, they dump Redis and walk away with the data. We trace sensitive data through your entire system architecture. We identify every point where it is stored, transmitted, or exposed unnecessarily.

What CBN expects from your vulnerability assessment

The Central Bank of Nigeria (CBN) Cybersecurity Framework mandates that licensed financial institutions conduct vulnerability assessments at least every six months. This is a strict regulatory requirement.

When the CBN IT examiners audit your institution, they do not just want to see a report. They want to see your remediation strategy. A raw scanner output PDF will immediately raise red flags. Here is exactly what the examiners expect:

• Contextual Severity: Findings must be ranked by severity, with business context specifically relevant to a financial institution. A missing security header is a low risk. A bypass in the transaction PIN flow is a critical risk.
• Manual Validation: Absolute proof that findings were manually validated by a human engineer, proving the report contains zero false positives.
• Remediation Tracking: A concrete remediation plan with specific delivery timelines, assigned engineering owners, and executive sign-off.
• Historical Progress: Clear evidence of remediation progress from previous assessments. If you had an SQL injection vulnerability in January, it must be gone in July.
• Comprehensive Scope: Coverage across all systems that process financial data, including internal back-office tools, not just the public marketing website.

Cybersecurity Governance for Cooperative Banks

While Tier-1 commercial banks have massive security teams, smaller financial institutions are frequently targeted because attackers perceive them as softer targets. A cyber risk assessment for cooperative banks and microfinance institutions is arguably even more critical. Attackers know that cooperative banks often rely on legacy core banking applications or off-the-shelf vendor software that has not been patched in years.

Cybersecurity governance for cooperative banks requires establishing a baseline that prevents catastrophic failure. We audit whether these institutions have segmented their internal networks, whether they enforce mandatory Multi-Factor Authentication for all tellers and branch managers, and whether their vendor contracts mandate regular security patching. A cooperative bank's vulnerability assessment maps the precise blast radius if a single branch manager's machine is compromised by ransomware.

Banking Network Security Compliance and Standards

Your infrastructure must adhere to strict banking cyber security standards (like PCI DSS and ISO 27001). A core component of our assessment is evaluating banking network security compliance. We do not just scan your external IP addresses. We perform internal network vulnerability assessments. We verify if your ATM network is cryptographically isolated from your corporate LAN. We check if your SWIFT messaging terminals are sitting on the same subnet as your employee Wi-Fi. A flat network architecture in a bank is a terminal compliance failure that guarantees a localized breach will escalate into a full-scale systemic compromise.

The Cybersecurity Checklist for Financial Institutions

If you are preparing for a regulatory audit or building a new digital banking product, your baseline cybersecurity checklist for financial institutions must include:

• Continuous Vulnerability Assessments: Biannual external and internal network scans, authenticated web application scanning, and mobile API assessments.
• Strict Network Segmentation: Cryptographic isolation between public DMZ, corporate LAN, ATM networks, and core banking databases.
• Endpoint Detection and Response (EDR): Deployment of active threat hunting agents on all employee workstations and teller machines.
• Identity and Access Management (IAM): Zero Trust architecture enforcing MFA and least-privilege access for all database administrators.
• Incident Response Plan: A documented, boardroom-approved protocol for reporting breaches to the CBN, NDPC, and affected customers within 72 hours.

What a vulnerability assessment does NOT cover

You must understand the difference between a vulnerability assessment and a penetration test. A vulnerability assessment identifies weaknesses. It builds the map. It does not prove exploitation.

An assessment will flag that your OTP endpoint lacks rate limiting. It identifies the vulnerability. It will not execute a brute-force attack to guess a 6-digit OTP and actually access a customer account. That aggressive exploitation is what a penetration test does.

The CBN requires both. Most banking products need both. A vulnerability assessment provides broad, continuous coverage. A penetration test provides deep, adversarial exploitation. A vulnerability assessment alone is legally necessary, but operationally insufficient to stop a dedicated attacker.

Related reading

Guides: CBN compliance security guide · Vulnerability assessment vs penetration test · PCI DSS for Nigerian fintech

Services: Vulnerability assessment · Penetration testing · API security testing