African banks can satisfy global security benchmarks and still miss regulator-specific obligations. A compliance-as-code model proposes testing Terraform and AWS CloudFormation changes against central-bank controls before deployment, while creating clause-level evidence for audit.
August 2024
Cloud infrastructure can satisfy common security benchmarks and still breach a regulator’s rules. Encryption may be enabled, network access restricted and identity permissions tightly controlled. The same deployment can still violate a data-residency requirement or fail to produce the evidence expected by a supervisor. For regulated banks, that gap can delay cloud onboarding and create exposure that technical baselines alone do not resolve.
A recent research paper on regulated African banking starts at the point where infrastructure is proposed. It translates supervisory obligations into machine-evaluable policies and places a Central Bank of Nigeria-anchored gate inside Terraform and AWS CloudFormation delivery pipelines. Databases, networks, identity roles and storage services are evaluated against the institution’s approved control envelope before they are created.
A failed check stops the deployment and identifies the clause, resource and remediation route. A successful check creates a structured record for audit and regulatory reporting. The approach addresses a practical problem across African financial institutions: global cloud frameworks provide strong technical baselines, while national supervisors impose additional requirements that are often interpreted manually during onboarding and reconstructed later for audit. [1]
When a secure deployment can still be non-compliant
Mainstream policy-as-code libraries usually test technical properties such as encryption, public exposure, logging and excessive access. Those checks remain useful, yet their control catalogues are generally derived from CIS, NIST, ISO or European data-protection frameworks. They do not automatically express the full set of obligations applied by an African central bank, including local accountability structures, approved data locations and regulator-specific evidence expectations.
The paper describes this missing-rule problem as an ‘adversary of omission’. A supervisory duty can remain unaddressed because no machine-readable policy represents it. A resource may pass every rule in the repository even when the repository itself is incomplete. The model therefore treats policy coverage as a control in its own right and requires every in-scope obligation to have a defined enforcement or evidence route.
The obligation model separates requirements into three operational categories. Plan-enforceable obligations, including approved-region placement, encryption attributes and prohibited wildcard permissions, become deployment-gate rules. Runtime-evidenced obligations, including recovery testing, are assigned continuous evidence collectors. Requirements involving professional judgement remain human attestations with accountable owners and review dates. The classification creates a visible register of what is enforced automatically, evidenced after deployment or reviewed by people. [1]
From regulatory clause to executable rule
Each control begins with a named supervisory expectation. The obligation receives a policy identifier, an enforcement point and an evidence source. A customer-data residency rule can reject a database or storage service tagged as customer data when its region falls outside the approved list. An encryption rule can require customer-managed keys on stateful services. An access rule can identify wildcard permissions on sensitive systems before the change is applied.
Figure 1. A Central Bank of Nigeria-anchored policy gate evaluates each Infrastructure-as-Code change before deployment and emits clause-level evidence. Source: Adesanya [1].
The paper includes executable examples for two widely used delivery environments. The Open Policy Agent example reads planned Terraform resources, checks the data-classification tag and region, and returns a denial message carrying the resource address and residency-clause identifier. The CloudFormation Guard example checks stateful resources for encryption and customer-managed-key attributes. Equivalent rules allow one supervisory intent to be applied across multiple infrastructure toolchains. [1]
The same clause-first structure produces a different form of audit evidence. Every evaluation can record the change identifier, timestamp, submitting author, policies assessed, affected resources, verdict, remediation guidance and exception approver. The evidence is created when the infrastructure decision is made. Audit and compliance teams can query the resulting record by workload, resource or supervisory clause. [1]
What happens before a cloud resource goes live
A Terraform plan or CloudFormation change set enters the policy gate before deployment. The gate evaluates the proposed configuration against a centrally governed repository. A failed rule returns the resource, clause and corrective action to the engineer. A passing plan continues into the landing zone, and its evaluation record is written to the evidence store. The exception register captures any approved deviation with its owner and approval trail. [1]
This central arrangement supports large banking estates with many workload accounts. Each account can retain its own delivery pipeline while calling the same policy service. The institution gains one governed version of each obligation and a consolidated view of compliance evidence. Jurisdiction-specific requirements can be added through approved parameters or local policy extensions without creating uncontrolled copies of the complete rule set.
Developer experience is treated as part of the control design. Denial messages include remediation guidance, and pre-approved Infrastructure-as-Code modules give engineers a compliant template for common services. Policy changes pass through version control, joint engineering-risk review and test fixtures containing known-good and known-bad plans. These practices reduce ambiguity around a failed deployment and make the policy repository itself auditable.
Audit evidence created at the point of deployment
Figure 2. Detective compliance identifies a violation after deployment; preventive compliance evaluates the proposed change before the resource exists. Source: Adesanya [1].
Many bank cloud controls are applied after infrastructure reaches a live environment. A posture-management scan or audit identifies the issue, and teams then change the running resource and assemble supporting evidence. The proposed model moves plan-enforceable checks into the change process. A non-compliant configuration is rejected before the resource is provisioned, and the decision record is created during the same pipeline run.
The earlier control point can support delivery, assurance and audit through one evaluation. A residency rule checks the proposed location, records the clause verdict and preserves the evidence for later review. Runtime monitoring remains part of the architecture for obligations that cannot be evaluated from the plan and for manual changes made outside Infrastructure-as-Code. The complete control environment therefore combines deployment-time gates, continuous evidence collection and detective scanning. [1]
Evidence from a production landing zone
The model is set out in a research paper by Oluwasile Adesanya and is grounded in a reusable production landing-zone product built with Terraform and AWS CloudFormation. The paper reports a 45 percent aggregate reduction in infrastructure provisioning time, elimination of configuration drift across managed environments and automated controls embedded into every deployment pipeline. These are presented as verified programme-level outcomes from the source product. [1]
Figure 3. Illustrative resource-class decomposition calibrated to the paper’s reported 45 percent aggregate provisioning-time reduction. The category values are not presented as separately audited series. Source: Adesanya [1].
The paper clearly separates those aggregate outcomes from its detailed analytical charts. Resource-level provisioning reductions, policy-coverage percentages and gate-latency curves are labelled illustrative and calibrated to the reported programme results or typical policy-engine performance. They provide a scenario view of how the architecture can operate; they are not presented as independently audited data series. [1]
The reported benefits depend on the type of obligation and the maturity of the implementation. Deployment-time checks create the strongest effect for controls that can be read directly from an infrastructure plan. Runtime obligations continue to rely on observation after deployment. Early-stage programmes can also experience more failed checks until pre-approved modules and remediation guidance are sufficiently developed. The continuing work shifts toward policy authoring, testing, module curation and exception governance.
Can the model travel across African regulatory regimes?
The architecture keeps the enforcement mechanism stable and allows the regulatory content to change. A bank in another African jurisdiction could retain the policy gate, evidence schema, testing lifecycle, obligation taxonomy and exception process. It would replace the CBN-specific clauses, approved locations and accountability requirements with those issued by its own supervisor. The paper presents this as a transferable design pattern; deployment across multiple regulators has not yet been demonstrated. [1]
The same gate-and-evidence structure may also be tested in other regulated sectors. Healthcare, telecommunications and public-sector cloud programmes often carry deployment-time requirements relating to location, encryption, access and network exposure. Banking provides a demanding use case because infrastructure decisions must connect with continuous evidence, formal accountability and supervisory scrutiny.
The paper states its evidence limitations directly. The evaluation draws on one production product. External institutional adoption has not been established. Several decompositions are illustrative. Policy completeness remains the principal design risk because the gate can only evaluate obligations represented in its repository. The proposed governance response includes measured clause coverage, joint risk-engineering ownership, version control and automated policy tests. [1]
What still needs to be tested
The research connects four activities that banks often manage through separate processes: regulatory interpretation, infrastructure engineering, software delivery and audit evidence. Its core chain links a supervisory clause to a machine-evaluable rule, a deployment verdict, a remediation path and an evidence record. The chain also shows where automation ends and accountable human judgement begins.
The paper identifies three areas for further research: a formal measure of clause-level policy coverage, assisted translation of new regulatory circulars into candidate rules, and multi-institution testing across African supervisory regimes. Those studies could provide stronger evidence on transferability, control completeness and operational performance. The current paper supplies a documented architecture, worked rules, an evidence schema, a clause-to-policy matrix and policy test fixtures for practitioner evaluation. [1]
The model treats compliance as a property of the cloud delivery process. Local supervisory obligations become visible when infrastructure is proposed, and each decision can be traced from regulation to code and evidence. The reported production outcomes provide an initial operational basis for the approach. Independent replication across institutions and jurisdictions remains the next test of its broader relevance.
Sources
[1] Adesanya, Oluwasile. “Compliance-as-Code for Regulated African Banking: Embedding Central Bank Controls into Infrastructure-as-Code Landing Zones to Enforce Audit Obligations at Deployment Time.” Author’s research paper.
[2] Central Bank of Nigeria. Risk-Based Cybersecurity Framework and Guidelines for Deposit Money Banks and Payment Service Providers. 2018.
[3] Central Bank of Nigeria. Guidelines on Outsourcing and Third-Party Risk Management for Banks and Other Financial Institutions. 2022.
[4] Open Policy Agent. Open Policy Agent documentation: policy-based control for cloud-native environments. 2023.
[5] Amazon Web Services. AWS CloudFormation Guard documentation. 2023.
[6] Joint Task Force. NIST Special Publication 800-53 Revision 5: Security and Privacy Controls for Information Systems and Organizations. 2020.
[7] Center for Internet Security. CIS Amazon Web Services Foundations Benchmark v3.0. 2023.
[8] International Organization for Standardization. ISO/IEC 27001:2022, Information security management systems. 2022.
[9] Vasarhelyi, M. A., Alles, M. G., and Kogan, A. “Principles of Analytic Monitoring for Continuous Assurance.” Journal of Emerging Technologies in Accounting, 1(1), 2004.
