Skip to main content
Bank of Ghana

Third-Party Risk Management for BoG-Regulated Institutions

By Alfred Obeng, Founder, Goldline Consultancy

ISO 42001 Lead Implementer (PECB) · ISO 42001 Lead Auditor (PECB) · ISO 27001 Senior Lead Implementer (PECB) · ISO 27001 Lead Auditor (PECB) · CISSP · PMP

8 min read

Contents

    The pattern in BoG-regulated institutions on third-party risk is consistent across the reviews I have conducted. Onboarding due diligence is documented and signed off. The annual reassessment cycle exists in policy but not in practice. The supplier inventory is incomplete, with critical suppliers sometimes missing from the register entirely. The cyber posture of the largest correspondent banking partners is assumed rather than evidenced. Of the five CISD domains, third-party risk is the one where the gap between policy and operation is widest, the one where supervisory finding is most likely, and the one that takes the longest to remediate from a standing start.

    A CISO at a mid-tier Ghanaian universal bank put it concisely: "We have a third-party risk policy. We have a supplier inventory. The inventory is two years out of date and the policy has not been applied to half the suppliers we have onboarded since." That observation captures the typical state of the domain across the BoG-regulated population.

    This is a practitioner read on why third-party risk is the most exposed CISD domain, what the Bank of Ghana supervisory expectation actually looks like in this area, how the supplier inventory should be constructed and maintained, what cyber posture assessment of critical correspondent and technology suppliers should produce, how the annual reassessment cycle holds up to supervisory scrutiny, and where ISO 27001 Annex A.5.19 through A.5.22 supports the CISD obligation directly.

    Why third-party risk is the most exposed CISD domain

    Third-party risk is more exposed than the other four CISD domains for four structural reasons.

    The domain depends on continuous operating discipline. Information security governance can survive on documented architecture that meets occasionally. Risk management can survive on annual methodology review with periodic register updates. Incident management can survive on documented procedure that is exercised when an incident occurs. Business continuity can survive on annual planning with periodic testing. Third-party risk cannot survive on any of these patterns. The supplier population changes constantly, the supplier landscape shifts continuously, and the assessment of the supplier population needs to keep pace. A third-party risk programme that runs on annual cycles inherently lags the operating reality.

    The domain crosses organisational boundaries that are typically under-coordinated. Procurement makes the contracting decisions. The business function uses the supplier. Information security may or may not be consulted at onboarding, and often is not. Internal audit may review supplier relationships, but typically only the largest ones. The result is that supplier risk decisions are distributed across functions, with no single function holding accountability for the cyber posture of the full supplier population.

    The domain has a long tail problem. The institution's largest five suppliers receive disproportionate attention because their commercial significance is obvious. The next twenty receive moderate attention. The remaining hundred or more, individually low risk but collectively material, receive almost no attention. Supervisory findings tend to surface in the long tail, because the institution can describe its top-twenty supplier posture but cannot describe the rest.

    The domain is exposed to retrospective discovery. A supplier that was assessed adequately at onboarding can deteriorate in cyber posture over time without the institution noticing. The cyber attack surface of the supplier may grow, the supplier's own controls may weaken, the supplier's strategic direction may change. The institution discovers the deterioration either through ongoing assessment that it is not running or through an incident at the supplier that affects the institution. The retrospective discovery pattern is the supervisory finding pattern.

    The combined effect of these four factors is that third-party risk is the domain where good documentation and operational reality drift apart fastest, with the smallest signals that the drift is occurring.

    What the Bank of Ghana supervisory expectation actually looks like

    The supervisory expectation on third-party risk has three components.

    The institution can identify its full supplier population. The supervisor expects the institution to produce, on request, a supplier inventory that covers all suppliers with material cyber dependency, classified by risk, with current status indicated. The inventory should not require the institution to assemble information from multiple disconnected sources at the time of the request. It should exist as a single maintained artefact.

    The institution can evidence cyber assessment for its highest-risk suppliers. The supervisor expects, for the suppliers classified as highest risk, current evidence of cyber posture assessment. The evidence does not need to be a formal third-party audit, but it does need to be a structured assessment with documented findings, conducted within a reasonable timeframe, with management review of the findings.

    The institution can demonstrate operating discipline across the supplier population. The supervisor expects evidence that the institution is operating its third-party risk programme on the cadence the institution's own policy describes. Annual reassessment that is documented but not executed will surface in supervisory review. Onboarding diligence that is documented for some suppliers and absent for others will surface in supervisory review. Inconsistency between the documented programme and the operating reality is the central supervisory finding pattern.

    The practitioner observation is that the supervisor is not looking for the institution to operate a perfect third-party risk programme. The supervisor is looking for the institution to operate the programme it has documented. The gap that produces findings is the gap between the documented programme and the operating reality, not the gap between the documented programme and an aspirational ideal.

    The supplier inventory: scope, classification, and refresh cadence

    A credible supplier inventory has four characteristics.

    Comprehensive scope. The inventory covers all suppliers with material cyber dependency, not just the suppliers that procurement classifies as critical. A SaaS provider with limited commercial significance but access to sensitive data is a cyber-material supplier. An infrastructure provider with no commercial visibility but underlying technology dependency is a cyber-material supplier. The scope criterion is cyber dependency, not commercial materiality.

    Risk classification. The inventory classifies each supplier by risk, with the classification driven by the nature and extent of the cyber dependency. Suppliers with access to customer data sit at higher classification than suppliers with access only to administrative data. Suppliers operating critical operational systems sit at higher classification than suppliers operating peripheral systems. The classification framework should be documented and consistently applied.

    Current status. Each supplier in the inventory has a current cyber assessment status indicated. When was the supplier last assessed. What was the outcome. When is the next assessment due. The status fields make the inventory operationally useful rather than just informationally complete.

    Defined refresh cadence. The inventory itself has a refresh cadence, with periodic review of the inventory's completeness and accuracy. New suppliers are added at onboarding. Suppliers no longer in use are flagged as exited. Suppliers whose risk classification has changed are reclassified. The refresh cadence ensures the inventory does not drift from the operating reality.

    The practical implementation question for most institutions is who owns the inventory. A common pattern is for procurement to own the commercial relationship data, information security to own the cyber assessment data, and operations to own the operating relationship data, with no single function owning the integrated inventory. The remediation is to establish single ownership (typically information security with input from procurement and operations) and to operate the inventory as the system of record for the integrated supplier picture.

    Cyber posture assessment for critical correspondent and technology suppliers

    For BoG-regulated institutions, the critical supplier categories cluster in four areas.

    International correspondent banks. Where the institution holds US dollar correspondent banking, European correspondent banking, or other cross-border banking relationships, the correspondent is a critical supplier. The cyber dependency is bidirectional, the operational dependency is material, and the regulatory expectation on both sides is increasingly explicit.

    Core banking platform vendors. Where the institution operates its core banking on a vendor-provided platform, the vendor is a critical supplier. The technology dependency is concentrated, the supplier population is small, and the cyber attack surface includes the vendor's own infrastructure and update processes.

    Payment network connections. Where the institution participates in card scheme networks, mobile money interoperability schemes, or other payment networks, the network operator is a critical supplier. The operational dependency is real-time, the cyber attack surface is shared, and the cascading impact of a network incident on the institution is substantial.

    Cloud infrastructure providers. Where the institution operates production systems on public cloud infrastructure, the cloud provider is a critical supplier. The technology dependency is increasingly the dominant component of the institution's operational risk, and the cyber dependency is direct.

    For each of these critical supplier categories, the cyber posture assessment should produce four artefacts.

    Current attestation evidence. SOC 2 Type II, ISO 27001 certification, or equivalent third-party assurance covering the supplier's relevant operating environment. The evidence should be current (within the last twelve months) and should cover the scope of the institution's actual use of the supplier.

    Sector-specific assessment evidence. For correspondent banks, this includes any cyber posture self-assessments that the correspondent has provided through its periodic counterparty reviews. For core banking and payment network suppliers, this includes the supplier's own cyber risk reporting to its clients.

    Direct institution due diligence. The institution's own assessment of the supplier's cyber posture, conducted through structured questionnaire, evidence review, and where commercially feasible, on-site review or technical evaluation.

    Documented findings and management review. The cyber posture assessment produces findings, the findings are documented, and the findings are reviewed at appropriate management level. The supervisor expects to see the chain from assessment to finding to review.

    For non-critical suppliers, the assessment depth is calibrated downward, but the same artefact structure applies: attestation evidence where available, sector-specific evidence where available, direct due diligence at appropriate depth, and documented findings with management review.

    Annual reassessment that holds up to supervisory scrutiny

    The annual reassessment cycle is the operating discipline that the third-party risk policy describes. The supervisory expectation is that the cycle is operating, not just documented.

    A credible annual reassessment cycle has four characteristics.

    Defined trigger. The cycle is triggered by a known event (anniversary date, contract renewal, supplier-side change, periodic schedule). The trigger is documented and applied consistently.

    Defined scope. The reassessment covers the cyber posture areas that the institution has determined are material for the supplier. The scope should be calibrated to the supplier's risk classification, not applied uniformly across the supplier population.

    Defined outputs. The reassessment produces documented findings, comparing the current cyber posture to the posture at the prior assessment, identifying any deterioration, and recording any change in risk classification.

    Management review. The reassessment outputs are reviewed at management level, with documented decisions on any required action. Where the reassessment identifies deterioration, the management review establishes the remediation path and timeline.

    The pattern that surfaces in supervisory review as a finding is the reassessment that is documented but not executed. Policy says annual reassessment. The actual reassessment for many suppliers happened more than two years ago, or never. The supervisor identifies the gap and the institution faces a management letter finding.

    The remediation pattern is to establish a tracked reassessment programme, with the supplier inventory feeding the scheduling, the responsible function (typically information security) executing the assessments on schedule, and management review providing the visibility that confirms the programme is operating.

    Where ISO 27001 Annex A.5.19 to A.5.22 supports the CISD obligation

    The four ISO 27001 Annex A controls covering supplier relationships are structurally aligned to the CISD third-party risk expectation.

    A.5.19 covers information security in supplier relationships. The institution defines and applies its approach to managing information security risk in supplier relationships. The control produces the policy framework, the responsibilities, and the operating procedure that CISD's third-party risk domain expects.

    A.5.20 covers addressing information security within supplier agreements. The institution defines and includes information security requirements in supplier agreements based on the type of supplier relationship. The control produces the contractual flow-through of CISD-aligned obligations to suppliers, which the directive expects.

    A.5.21 covers managing information security in the information and communication technology supply chain. The institution defines and applies its approach to managing risk in the ICT supply chain. The control produces the structured supply chain risk assessment that the directive expects, with particular relevance for core banking, payment network, and cloud infrastructure dependencies.

    A.5.22 covers monitoring, review and change management of supplier services. The institution monitors and reviews supplier service delivery and manages changes to that delivery. The control produces the annual reassessment cycle, the change management discipline, and the ongoing assessment that the directive expects.

    For BoG-regulated institutions implementing ISO 27001 alongside CISD compliance, the Annex A.5.19 to A.5.22 control set provides the structured architecture through which the third-party risk programme is operationalised. The Statement of Applicability documents, for each control, how the institution implements it and what evidence demonstrates the implementation. The internal audit programme tests the controls. The management review surfaces the third-party risk position to the institution's governance structures.

    The result is that ISO 27001 implementation, properly delivered, closes the gap between the documented third-party risk programme and the operating reality. The control architecture, the evidence base, and the operating discipline are all produced by the same implementation effort that delivers the certificate.

    The most common practitioner mistakes and how to avoid them

    Across the third-party risk programmes I have reviewed, four practitioner mistakes recur.

    Treating the inventory as a procurement artefact. The supplier inventory should be the cyber-material inventory, owned by information security with input from procurement, not the procurement inventory with cyber data added as a secondary field. Treating it the other way produces an inventory that is comprehensive on commercial data and incomplete on cyber data.

    Calibrating the assessment depth to commercial significance rather than cyber dependency. The largest commercial supplier may not be the highest cyber risk. A small SaaS provider with access to sensitive data may be higher cyber risk than a large infrastructure provider with limited data access. Calibrating assessment depth to commercial significance produces blind spots in the long tail.

    Letting the annual reassessment cycle become an annual paper exercise. The cycle should produce genuine reassessment of the supplier's current cyber posture, not just a confirmation that the supplier is still listed in the inventory. The reassessment that becomes a paper exercise produces no early warning of supplier deterioration and offers no defence under supervisory review.

    Failing to integrate supplier risk findings into the institution's broader risk register. Supplier risk findings should feed into the institution's information security risk register, with the supplier-level risks contributing to the institution's risk picture. Without that integration, the supplier risk programme operates as a parallel process disconnected from the institution's broader risk management discipline.

    Avoiding these four mistakes requires the operating discipline that the third-party risk policy describes, applied consistently across the supplier population, with management review providing the visibility that confirms the discipline is operating. The remediation effort for an institution that has fallen behind is substantial but bounded. The starting point is a comprehensive supplier inventory. The operating discipline follows from there.

    If your third-party risk programme is one of the gaps in your CISD readiness, or if you are scoping the work required to close it ahead of your next supervisory walkthrough, book a strategy call to discuss the closure path.

    We use cookies and similar technologies to measure how this site is used, to see which organisations visit, and to measure our advertising. If you accept, we load Plausible, Google Analytics and Google Ads, Microsoft Clarity, which records session replays, and Apollo. Nothing loads until you accept. Read our Cookies policy.