By Samson Adekoya
In 2025, Nigeria’s National Data Protection Commission opened formal investigations into over 1,300 organisations across banking, insurance, and pension sectors. For enterprises that treated regulatory compliance as something to address after their technology systems were built, the reckoning arrived.
This is not a Nigerian story in isolation. It is a compressed version of a pattern I have watched play out across every regulated environment I have worked in over the past decade: the moment when a regulator starts enforcing a framework that previously existed only on paper. How an organisation responds depends almost entirely on whether it built compliance into its systems from the start — or planned to deal with it later.
I have spent the past decade implementing enterprise technology in industries where failure carries consequences well beyond a missed deadline. Banking. Aviation. Energy. Government. Legal. Public transport. The environments change, but one thing stays remarkably consistent: the ways these projects fail.
Not the technical failures — those are usually solvable. I mean the structural failures. The ones visible from week two but only acknowledged in month eight, when budgets are spent and executives want to know what went wrong. After leading implementations across Nigeria and now working in London on UK public infrastructure, I have watched the same patterns destroy projects that had perfectly sound technology at their centre.
My argument is simple: implementation failures in regulated industries are predictable and therefore preventable. They follow three identifiable patterns — compliance treated as a phase instead of a design constraint, downtime treated as an acceptable trade-off, and stakeholder readiness treated as a post-launch concern. Miss any one of these and the project is structurally compromised. Miss two and you are building something that will need to be rebuilt — either on your timeline or on a regulator’s.
When compliance enters too late
In unregulated industries, you can build first and figure out the rules later. In regulated ones, the rules are the architecture.
I learned this viscerally on a government-contracted technology project — a levy collection portal for civilian helicopter movements that had to satisfy compliance requirements from four separate regulatory agencies. Each agency had its own reporting standards, audit expectations, and approval workflows. The portal was a compliance instrument. Data structures, user permissions, audit trails — every design decision existed to satisfy a regulatory requirement, not a product requirement.
Had we treated compliance as a final review gate — something to bolt on after the core build — the project would have failed. Not because the technology could not handle it, but because the data structures, user permissions, and audit trails required by each agency shaped every design decision from the database schema upward. You cannot retrofit that kind of regulatory logic into a system designed without it. What you end up with is a fragile workaround masquerading as a solution, and regulators are exceptionally good at spotting those.
This is the first pattern: compliance treated as a phase rather than a design constraint. Teams build what they know how to build, then attempt to make it compliant afterward. In regulated industries, this sequence is backwards. When I scope a project in a regulated environment, the regulatory framework is the first document I read, not the technical specification. The technical spec serves the regulatory requirement. Reversing that order is how you end up rebuilding half a system three months before launch.
When the system cannot afford to blink
Still Earth Capital Finance Limited needed to migrate its core banking system from the legacy core banking platform to a modern replacement. In regulated financial services, a core system migration is roughly equivalent to performing open-heart surgery on a patient who needs to keep running a marathon. Every transaction, every balance, every regulatory report depends on that system. If it goes down, the institution does not just lose productivity — it loses the ability to operate, and the regulator notices.
The migration had to happen with zero downtime. Not minimal downtime. Not “we will schedule a maintenance window over the weekend.” Zero. Because in a regulated financial environment, even a brief outage creates cascading problems: failed transactions that trigger compliance flags, reporting gaps that attract regulatory scrutiny, and customer trust erosion that no amount of communication can fully repair.
Achieving this required a fundamentally different approach. It meant running parallel systems, validating every data migration in real time, and building rollback capabilities that could activate without human intervention. The go-live was not a single event but a graduated transition, tested and verified at each stage. From the customer’s perspective, the migration never happened. That was the point.
This is the second pattern: teams in regulated industries routinely underestimate the true cost of system unavailability. In an unregulated environment, downtime is an operational problem — costly, sometimes severely so, but ultimately an internal matter to resolve. In regulated industries, it becomes a compliance event with external consequences: in financial services, a regulatory flag; in aviation, a safety risk. The implementation methodology must account for this from day one — not as a resilience feature but as a hard constraint that shapes the project timeline, budget, and technical design. When project managers treat downtime as an acceptable trade-off to stay on schedule, they are making a risk calculation they are not qualified to make. The downside is not a delayed launch. It is a regulatory action.
When the people are not ready for the system
You can build a technically flawless system and still watch an implementation collapse if the people who need to use it cannot or will not.
When Still Earth Holdings needed to unify operations across departments — Accounting, Project Management, Procurement, CRM, Business Development, Administration, and Fleet Management — each had its own workflows, its own informal processes, and its own reasons to resist a centralised system. Leading the enterprise ERP deployment, the integration challenge split roughly in half. Half was technical. The other half was organisational: bringing each department through the transition without disrupting operations or losing the people who would use the system every day.
At Paul Usoro & Co, one of Nigeria’s leading commercial law firms, deploying a practice management system required mapping to how lawyers actually track billable time — not how a software vendor imagines they do. Legal professionals are, by training and temperament, precise about their workflows. Getting that right — not “close enough” right, but genuinely right — produced a 20% increase in billable hours. That gain came from an implementation that respected how the users worked and built the system around their reality rather than asking them to reshape their practice around the technology.
This is the third pattern: stakeholder readiness treated as optional. It shows up as insufficient training, as change management reduced to a single email, as go-live dates set without confirming that daily users are genuinely prepared. In regulated industries, this gap is especially dangerous because user errors do not just reduce efficiency — they create compliance risks.
On enforcement: until recently, the infrastructure for consequence management around data governance in Nigeria was limited. The result was that organisations could patch a breach and move on without formal consequence. That is changing. The NDPC’s enforcement action against over 1,300 organisations is the clearest signal yet that the gap between having a regulation and enforcing one is closing. Organisations that built consequence management into their processes before the regulator demanded it will navigate this period smoothly. Those that relied on the absence of enforcement will not. Without consequence management, even well-designed processes erode — because there is no structural reason to follow them when no one is checking.
Stakeholder readiness is not soft-skill territory. It belongs on the project risk register alongside server capacity and data migration integrity.
The common root — and why that is actually good news
These three patterns share a single origin: applying implementation methodologies designed for unregulated environments to industries where the operating constraints are fundamentally different. But predictable failures are preventable ones. Recognise the mismatch early enough and you can design it out. The diagnostic is simpler than most organisations expect. Before touching any technology, I check three things: do the people understand the process they are about to change? Does the data backing those processes actually exist and is it reliable? Are the processes themselves documented, or are they living in someone’s head? People, data, process. Get those three dimensions right and the technology project has a foundation. Skip any one of them and you are automating a mess.
When that foundation holds, the results are measurable. The core banking migration at Still Earth Capital Finance Limited completed with zero downtime. The aviation portal passed compliance across all four regulatory agencies. The ERP deployment unified departments across the group without disrupting operations. These outcomes are available to any organisation whose implementation approach matches the environment it operates in.
The NDPC investigations are a signal, not an anomaly. Every African market with a functioning digital economy is moving in this direction. Data protection, cybersecurity, financial reporting — the enforcement infrastructure is being built. The question for any organisation undertaking a technology transformation is whether its implementation approach was designed for the environment it actually operates in, or the one its methodology was originally built for.
Samson Adekoya designs and implements enterprise technology systems for regulated industries. Over the past decade, he has led implementations across banking, government, energy, aviation, legal, and public transport in Nigeria and the UK — delivering zero-downtime migrations and multi-agency compliance architectures in environments where failure carries regulatory consequences. Connect on [LinkedIn](https://www.linkedin.com/in/samsonadekoya/) or reach him at s.adekoya@bftnconcepts.com.
