How to Prepare for Bank of Ghana CISD 2026: A Practical Checklist
CISD 2026 is in effect now. For IT directors and compliance teams at Ghanaian financial institutions, here is a practical, step-by-step checklist for assessing where you stand and what to do next.
Our previous article covered what the Bank of Ghana's Cyber and Information Security Directive (CISD 2026) requires and why it matters.
This article is the follow-up most IT directors and compliance officers actually need: a practical checklist for assessing where your institution stands and what to do about it.
This is not a substitute for legal or compliance advice — your compliance team and legal counsel should review the full directive against your specific institution's licence category and risk tier. What follows is an infrastructure-focused checklist for the technical and operational gaps that CISD 2026 introduces.
Step 1: Map Where Your Data Actually Lives
This sounds basic, but it is the step most institutions skip — and the one that surfaces the most surprises.
Inventory every system that touches customer data. Core banking platform, mobile app backend, payment processing, customer relationship management, document storage, backup systems, analytics and reporting tools, fraud detection systems. For each one, answer one question: where does the data physically reside?
Pay particular attention to "shadow" infrastructure. Many institutions discover during this exercise that a development team spun up a database on a public cloud platform for a project years ago, and it has quietly become part of production without anyone formally deciding that. These systems are often the highest-risk findings because nobody owns the decision to have put them there.
Document the data flow, not just the storage location. A system might store data in Ghana but route it through a foreign service for processing — analytics platforms, AI/ML services, third-party APIs. CISD 2026's cloud computing provisions concern themselves with processing as well as storage.
Output of this step: a single document listing every system, its data residency status, and a classification of whether it falls under "core systems and critical customer data" or "non-sensitive, front-end operations" as defined by the directive.
Step 2: Classify Against the Directive's Categories
CISD 2026 distinguishes between core systems and critical customer data — which must remain in Ghana — and non-sensitive, front-end operations, which may remain on external platforms.
Core systems typically include: core banking platforms, account management systems, transaction processing, customer identity and KYC data, credit and risk scoring systems, and any system that stores account balances, transaction history, or personally identifiable financial information.
Non-sensitive, front-end operations typically include: marketing websites, public-facing informational content, non-customer-data analytics, and internal tools that do not touch customer records.
The grey areas are where institutions need to be most careful. A customer support ticketing system might not seem like "core" infrastructure, but if support agents can see account numbers and balances within it, it likely falls under the stricter category. Err on the side of caution in classification — a system incorrectly classified as non-sensitive is a compliance gap waiting to be found during a BoG examination.
Output of this step: the same inventory from Step 1, now with each system classified, and a clear list of systems that are currently non-compliant — i.e., classified as core or critical, but located outside Ghana.
Step 3: Assess Your Operational Controls — Not Just Location
This is the step that catches institutions who assume "we're on-premise, so we're fine." CISD 2026 requires demonstrable operational controls regardless of where infrastructure is located. Being data-resident is necessary but not sufficient.
Work through this list honestly for your current infrastructure, wherever it is located:
Continuous monitoring — Do you have automated monitoring of infrastructure health, with alerting when something goes wrong? Or does your team find out about problems when users complain?
Documented incident response — If a server goes down at 2am, is there a written procedure for what happens, who is notified, and how the incident is documented? Or does it depend on whoever happens to be awake knowing what to do?
Patch management — Is there a defined, documented process and schedule for applying security patches? Can you demonstrate, for any given system, when it was last patched and what was applied?
Access logging and audit trails — Can you produce a record of who accessed what system, and when, for the past several months? Is this record tamper-evident?
Penetration testing on a schedule — CISD 2026 introduces requirements for quarterly and annual cyber exercises. Has your infrastructure been penetration tested in the last 12 months? Is there a schedule for the next one?
Board-level reporting — Can your IT team currently produce a report on infrastructure health, incidents, and security posture that is suitable for board-level review? Or would producing such a report require weeks of manual work pulling data from disparate systems?
Output of this step: a gap list — specific controls that are currently absent or undocumented, regardless of data location.
Step 4: Check Your SIEM Arrangements
CISD 2026 requires that any SIEM (Security Information and Event Management) system used by a regulated institution be operated by a CSA-accredited entity with Ghanaian majority shareholding.
If you use a SIEM provider — verify their accreditation status and ownership structure directly. Do not assume a well-known international vendor automatically meets this requirement; the requirement is specifically about the entity operating the SIEM for your institution, which may be a local partner or reseller rather than the underlying software vendor.
If you do not currently have a SIEM — this is now a requirement, not an option, and the provider selection needs to account for the accreditation and ownership criteria from the outset.
Output of this step: confirmation of compliant SIEM arrangements, or a gap to be addressed.
Step 5: Prioritise — Don't Try to Fix Everything at Once
With Steps 1-4 complete, you have a full picture: systems with data residency gaps, systems with operational control gaps, and SIEM arrangement status. The next step is prioritisation, not panic.
Prioritise by risk tier and exposure. A core banking system on foreign public cloud is a higher priority than an internal HR tool with a residency gap. CISD 2026's proportional implementation principle means the Bank of Ghana itself recognises that not everything can or should be fixed simultaneously — but it does expect a credible plan and demonstrable progress.
Separate "fix now" from "plan for." Some gaps — like implementing access logging on existing on-premise systems — can often be addressed quickly with configuration changes and monitoring tooling, without a full infrastructure migration. Other gaps — like a core system running on foreign public cloud — require a migration project with a realistic timeline.
Build the migration plan for genuine infrastructure moves. For systems that need to move to local infrastructure, the plan should include: an assessment of the target environment (new private cloud build, or existing on-premise infrastructure that needs operational controls added), a migration approach that minimises downtime for production systems, and a validation step before the source system is decommissioned.
Step 6: Build the Evidence Trail
Throughout this process — and ongoing afterward — document everything. CISD 2026 compliance is not a one-time project that concludes with a certificate. It is an ongoing operational posture that needs to be demonstrable at any point.
Keep the inventory from Step 1 current. New systems get added to institutions constantly. The inventory needs an owner and a process for keeping it accurate.
Retain evidence of operational controls in action — not just that a monitoring system exists, but logs showing it generated alerts and that those alerts were acted upon. Not just that a patch management process exists, but records of patches applied.
Prepare board reporting as a recurring artefact, not a one-time exercise for this compliance push.
The Honest Summary
CISD 2026 compliance is not primarily a technology purchase — it's an assessment and operational discipline exercise first, and an infrastructure project second (for institutions with genuine residency gaps). The institutions that will struggle most are not necessarily the ones with the biggest gaps — they're the ones who haven't done Steps 1-3 yet and therefore don't know the size of their gap at all.
If your institution hasn't completed this assessment, that is the place to start — today, not after a migration decision has been made.
What SwiftInfra Does
SwiftInfra helps Ghanaian financial institutions work through exactly this process — starting with an infrastructure assessment that produces the inventory and gap analysis described above, and continuing through to migration and managed operations for institutions that need to move systems to local, compliant infrastructure.
If you want help running this assessment for your institution, we are ready to start.
SwiftInfra is a private cloud engineering company based in Accra, Ghana. We deploy and manage private cloud infrastructure for financial institutions, fintechs, and enterprises across West Africa. This article is provided for general informational purposes and does not constitute legal or compliance advice. Institutions should consult their compliance and legal teams regarding their specific obligations under CISD 2026.