Which Instrument Applies to You
The governing document is the CBN Risk-Based Cybersecurity Framework and Guidelines for Deposit Money Banks and Payment Service Banks (2024), issued under circular BSD/DIR/PUB/LAB/017/008 on 31 May 2024, with an effective date for full compliance of 1 July 2024.
Its scope is stated precisely, and it is narrower than "Nigerian financial institutions". The framework "shall apply to the following financial institutions under the purview of Banking Supervision Department – Commercial banks, Merchant banks, Non-Interest banks and Payment Service banks, which are hereinafter jointly referred to as Supervised Financial Institutions (SFIs)" (Introduction). If your institution is not one of those four, this instrument is not the one that binds you: Other Financial Institutions are addressed by the separate CBN Risk-Based Cybersecurity Framework and Guidelines for Other Financial Institutions (2022). The 2024 framework states that it replaces the October 2018 Risk-Based Cybersecurity Framework and Guidelines for Deposit Money Banks and Payment Service Providers, and that it takes account of BOFIA 2020 and the NDPA 2023 (Introduction).
Everything below separates two things that are easy to blur. What the framework requires is cited to a section. What a bank has to build to satisfy it at branch level is our engineering view, and is labelled as such: the word "branch" does not appear anywhere in the framework, so any branch-specific design is an implementation choice, not a mandate.
What the Framework Actually Requires
The framework "comprises seven parts: Cybersecurity Governance and Oversight; Cybersecurity Risk Management System; Enhancing Cybersecurity Resilience; Emerging Technologies; Metrics, Monitoring and Reporting; Compliance with Statutory and Regulatory Requirements; and Enforcement" (Introduction), followed by seven appendices.
At the centre of it is section 1.1.2, which sets out the cybersecurity programme an SFI is required to implement, and which should "at a minimum" include:
- Risk assessment
- Security policy development
- Incident response planning
- Vulnerability management
- Log monitoring
- Data backup and recovery plan
- Security awareness and training
- Initiatives to attain target maturity level
- Metrics to assess the effectiveness of the programme
Several requirements carry explicit frequencies, and these are the ones most often missed:
- Annual vulnerability assessments and threat analysis; a third-party penetration test annually at a minimum; internal vulnerability scans quarterly (2.2, ii–iv).
- Risk assessment annually and whenever major changes occur, documented in a Cybersecurity Risk Control Self-Assessment (2.1.2).
- Annual maturity evaluation using the CBN Cybersecurity Self-Assessment Tool (CSAT) (2.4), with the self-assessment for the previous January–December "submitted to the Director, Banking Supervision Department of the Central Bank of Nigeria annually, not later than February 28", signed by the CISO after endorsement by Executive Management (2.5).
- Quarterly board reports on the cybersecurity programme, with contents specified at 1.1(viii), including cyber risk assessment updates, incidents and losses, vulnerability and penetration test reports, and status of compliance with Board-approved cyber risk thresholds (5.0, iv).
- Cyber incidents reported within 24 hours of detection to the Director of Banking Supervision, using the Appendix VII template (5.0, v). Appendix I defines a cyber-incident to include a financial loss exceeding 0.01% of shareholders' funds unimpaired by losses, data breach or destruction, unplanned Core Banking Application outage, and website defacement.
- Annual policy review: the cybersecurity policy is reviewed "annually at a minimum, or when there are significant changes to the SFI's cyber-risk exposure" (1.1.1, iv).
Governance is prescriptive in places. The Board must ensure at least two Non-Executive Directors, one of them independent, have relevant fintech, ICT or cybersecurity knowledge (1.1, i); a CISO is appointed subject to CBN approval (1.1, ix and 1.4); and a stand-alone cybersecurity budget, distinct from IT or Risk Management, is approved (1.1, xi). The CISO must "maintain the SFI's data privacy and ensure all employees undertake security awareness training periodically" (1.3, iii).
Enforcement is not left implicit. The CBN monitors compliance "through the annual Cybersecurity Supervisory Review and Evaluation exercise, Risk Based Examination, Annual Industry Standard Compliance audit and periodic spot check" (7.0, ii), and non-compliance "shall attract appropriate sanctions as defined in Section 68 of BOFIA, 2020 or subsequent regulations" (6.0, iii).
Where the Framework Is Silent, and Why That Matters
The framework does not prescribe branch controls. It does not mandate network segmentation, VLAN structure, or a branch endpoint baseline. Its one use of the word "segment" concerns vendor access: access granted to a vendor "shall be limited to the segment of the system required for a defined duration and monitored and revoked on completion of the task" (Appendix III, 1.3, b).
What it does require, and what branch estates most often fail, is inventory and topology. An SFI shall "maintain an up-to-date inventory of all authorised IT assets on-premises and in cloud infrastructure… such as workstations, laptops, ATMs, POS, network switches, routers, firewall, printers, scanners, photocopiers, IP Phones, Mobile devices, surveillance cameras" (Appendix II, 1.1, a), "maintain an approved up-to-date network topology diagram of wired and wireless networks irrespective of location" (Appendix II, 1.1, i), and "maintain a catalogue of all network connections to regulatory authorities, switches, third parties and wholesale customers" (Appendix II, 1.1, j).
That phrase, irrespective of location, is where a multi-site bank's obligation and its branch reality collide. The rest of this article is our answer to that collision. It is engineering guidance, not regulation.
Our View: Segmenting the Branch Network
Segmentation is the highest-leverage branch control we deploy, and flat-network legacy is where it hurts most. A workable minimum separates traffic into distinct VLANs: teller and core-banking traffic, back-office workstations, ATM and self-service devices, guest or staff Wi-Fi, and physical-security systems such as CCTV and access control. These populations have no business talking to each other, and collapsing them into one segment turns a single compromised device into a branch-wide incident.
The goal beyond separation is east-west containment. A workstation infected through a phishing payload should not be able to reach the core-banking segment, and it should not be able to traverse the WAN to another branch or to head office. Inter-VLAN traffic passes through a firewall or layer-3 policy that denies by default and permits only the specific flows each segment legitimately needs.
Two framework requirements pull in the same direction and are worth designing against explicitly: wireless networks must "use strong encryption and the frequency of encryption key change has been defined" (Appendix III, 1.5, f), and remote access must run over VPN or another encrypted solution with MFA, with unencrypted RDP over the internet prohibited outright (Appendix III, 1.7, a–b).
Segmentation is not a one-branch project. Standardise a reference design, push it through configuration management, and verify conformance centrally, so the topology diagram required at Appendix II 1.1(i) describes something real. One trade-off deserves honest attention: segmentation must degrade gracefully. When a leased line drops or the branch cycles onto generator power, essential operations should continue rather than fail closed in a way that halts the counter. For where branch controls sit in a full programme, see our guidance on banking and financial services security.
Endpoint Hardening: What Is Required, and What We Add
Here the framework is directive. Under Secure System Configuration Management (Appendix III, 1.5), SFIs shall "develop minimum security baseline configuration such as anti-malware, data loss prevention and systems security settings for IT assets, which should be governed by vendor recommendations, best practice and security standards" (a); "ensure that policies for security solutions are managed centrally and cannot be turned off locally by users" (b); "ensure hardening of new computer systems, Applications, or Databases prior to deployment" (c); and keep "hardening standards and configuration baselines… updated across servers, ATMs, workstations, databases, network devices" (d).
Read (b) again if you run a branch estate: security policy that a local user can switch off is a named non-compliance, not merely bad practice.
Our addition. A defensible branch baseline in Nigerian conditions specifies full-disk encryption, application allow-listing, removable media disabled where business policy permits, centrally managed EDR reporting to a console, removal of local administrator rights from standard users, and a hardened documented build image. Power realities shape how this holds: branch endpoints cycle through generator and UPS transitions, and a hardening regime that assumes always-on connectivity will drift. Build for intermittence, so policy reapplies and state reports on reconnection rather than a workstation silently falling out of band after a four-hour outage.
Vendor devices deserve a hard line, and here the framework backs you: vendors must not have "unfettered access to systems, databases, network and applications", access requires Senior Management approval, and it must be scoped, time-bound, monitored and revoked on completion (Appendix III, 1.3, a–b).
Logging, Patching, and the Evidence Trail
Monitoring requirements are specific. SFIs shall "establish a non-intrusive continuous (24x7) monitoring mechanism to collect, correlate and detect anomalous activities on critical systems, databases and networks"; "specify and document log retention period based on the criticality of data", with the retention period approved by the Board; "monitor the physical environment of assets – server room, network devices, data centre, disaster recovery site and off-site storage location"; ensure monitoring runs "through a Security Operation Centre (SOC)", in-house or outsourced, resourced with a SIEM; "enable logging capabilities on all systems and applications on-premises and in third-party locations"; and "ensure logging and monitoring of remote access activities" (Appendix III, 2.1, a–j).
Patch management is set out at Appendix III, 1.9: specify responsibilities and timelines for remediation by category (a); "scan patches for malware prior to application" (b); "deploy security updates promptly after thorough testing and in accordance with its Patch Management Policy" (c); confirm patches applied successfully after deployment (d); and ensure the process is "audited regularly and reports presented to Senior Management" (e).
Our addition. Set patch timelines by branch risk tier as well as vulnerability severity, run a test-then-deploy ring so updates are validated before they reach branch endpoints, and keep a written record of compensating controls for legacy systems that cannot be patched (tighter access scoping, enhanced monitoring) rather than leaving the gap undocumented. Synchronise time across all sites so logs correlate; skewed clocks make an incident timeline unprovable, which matters directly against the 24-hour reporting duty at 5.0(v).
Budget honesty belongs here too. FX pressure means premium tooling cannot be deployed uniformly across dozens of sites. Concentrate logging depth and patch automation where transaction risk is highest, and document that prioritisation as a deliberate risk-based choice. The framework's own logic supports this: the risk management system runs on identification, assessment, measurement, mitigation and monitoring (2.1.1–2.1.5), and mitigation measures are to be "consistent with the criticality of information assets" (2.1.4).
Operating the Controls
Controls decay without ownership. The workable split is that a central security team maintains the baselines, regional or branch IT executes and reports, and compliance holds the evidence, with an escalation path and a named owner for each deviation.
The artefact that makes an examination survivable is a control matrix mapping each framework requirement to its implementation and its evidence source. Build it against the seven parts and the appendices, not against a remembered summary, and populate the annual and quarterly obligations first: they have dates attached, and a missed 28 February CSAT submission or a late 24-hour incident report is a discrete, provable failure in a way that a thin baseline is not.
Keep adjacent obligations distinct. Customer personal data handled at the branch also falls under the Nigeria Data Protection Act 2023 and the oversight of the NDPC, and the framework itself directs SFIs to "ensure compliance with relevant data protection and privacy regulations such as NDPA, 2023" (Appendix III, 1.6, k) and lists the NDPA 2023 among the statutes the Board must ensure compliance with (6.0, i). Overlapping does not mean interchangeable: CBN examination evidence and NDPA compliance records answer to different regulators.
If you are scoping a branch baseline now, the practical next step is a gap assessment: map current controls against the framework's seven parts, and find the rows with no evidence behind them. That is exactly the work our banking and financial services advisory practice supports.
Frequently asked questions
Does the CBN 2024 framework apply to my institution?
It applies to commercial banks, merchant banks, non-interest banks and payment service banks under the purview of the Banking Supervision Department, jointly defined in the framework as Supervised Financial Institutions (Introduction). Other Financial Institutions fall under the separate 2022 CBN framework for OFIs. The 2024 framework was issued on 31 May 2024 under circular BSD/DIR/PUB/LAB/017/008, with full compliance required by 1 July 2024.
What does the framework require at branch level specifically?
Nothing branch-specific: the word does not appear in it. What binds a branch estate are requirements that apply irrespective of location: an up-to-date inventory of all authorised IT assets including workstations, ATMs, POS, switches, routers and surveillance cameras (Appendix II, 1.1, a); an approved current network topology diagram of wired and wireless networks "irrespective of location" (Appendix II, 1.1, i); centrally managed security policies that users cannot disable locally (Appendix III, 1.5, b); and hardening standards maintained across servers, ATMs, workstations and network devices (Appendix III, 1.5, d).
What are the reporting deadlines?
Two are hard dates. Cyber incidents as defined in Appendix I must be reported to the Director of Banking Supervision not later than 24 hours after detection, using the Appendix VII format (5.0, v). The annual CSAT self-assessment covering the previous January to December must be submitted to the Director, Banking Supervision Department not later than 28 February, signed by the CISO after Executive Management endorsement (2.5). Board reporting is quarterly, with contents specified at 1.1(viii).
What happens if we do not comply?
The CBN enforces through "the annual Cybersecurity Supervisory Review and Evaluation exercise, Risk Based Examination, Annual Industry Standard Compliance audit and periodic spot check" (7.0, ii). Non-compliance "shall attract appropriate sanctions as defined in Section 68 of BOFIA, 2020 or subsequent regulations" (6.0, iii).
