IT Governance in Nigeria and Why It’s Different from IT Policy
Every organisation eventually reaches a point where informal IT decision-making stops working. Someone senior approves a vendor over email, IT manages the rest, and for years nothing breaks badly enough to force a change. Then decisions start getting made twice, or not at all, or by whoever happens to be in the room when something needs signing off.
This becomes especially visible once boards, executive leadership, and multiple departments all share responsibility for technology decisions, since there is no longer a single person whose judgement the rest of the organisation quietly defers to.
That point is a complexity threshold, not a headcount number. A fifty-person single-site business can reach it, while a two-hundred-person company with a simple, centralised IT setup might not. Complexity matters more than headcount. If a business is still at the stage where one clear IT policy document would solve most of its problems, IT policy for Nigerian businesses is the more useful starting point than this article.
Why Policy Alone Isn’t Governance
For organisations past that threshold, boards, regulated entities, and businesses with IT decisions spread across departments or locations, the real gap usually has less to do with a missing policy than with the absence of a clear answer to who has the authority to make an IT decision in the first place, and who is accountable when that decision turns out to be wrong.
That distinction matters more than it sounds. Policy is the rulebook: acceptable use, password requirements, data handling rules. Governance is a level above that: who has the authority to write the rulebook, who can change it, and who answers for the outcome when it is followed or ignored. An organisation can have excellent policy documents and still have no governance, because nobody has settled who actually owns the decisions the policy assumes someone is making.
This shows up most clearly at the exact moment when a policy needs updating or an exception needs to be granted. A well-written acceptable use policy says nothing about who approves a one-off exception for a senior executive who needs an unusual permission, or who decides the policy itself is outdated once a new category of tool becomes common. Without governance, those moments default to whoever is most senior or most persistent in the room, rather than whoever was actually meant to decide.
Where Governance Sits in an Organisation
Governance is not a department, and it does not need a dedicated committee to exist meaningfully. In practice, it is the set of agreements about who approves what, who gets consulted, and who is informed after the fact, made explicit enough that two different people would give the same answer if asked separately.
Most organisations already have an informal version of this. The problem is that it lives in people’s heads rather than anywhere written down, which means it changes depending on who is in the room and disappears entirely when someone leaves. Making it explicit is the actual work of IT governance, not building a framework from scratch.
The disappearing part is where organisations usually feel the pain first. An IT manager who has quietly held final say over vendor approvals for years leaves the company, and suddenly nobody can say with confidence who is supposed to make that call now. The org chart does not answer the question because the informal arrangement was never written into it in the first place.
Decision Rights: Who Approves What
The clearest sign of a governance gap is a decision made by whoever happens to be available, rather than by whoever is supposed to be accountable for it. A department head approves a new SaaS tool because IT was slow to respond. A regional office signs a vendor contract, which the head office learns about at renewal. Neither decision was necessarily wrong, but neither followed a path anyone could point to in advance.
Decision rights answer a recurring set of questions: who approves new vendors, who authorises security exceptions, who approves spending beyond agreed thresholds, and who reviews those decisions afterwards. Most organisations already have informal answers to these questions. Governance is the work of making those answers consistent and known, rather than rediscovered every time a decision comes up.
The cost of not doing this rarely shows up as one dramatic incident; instead, it shows up as inconsistency. One department gets a security exception approved within a day because the right person happened to be free, while another waits three weeks because nobody is sure who can sign off. Vendors get evaluated to different standards depending on who happened to be in the room. None of this looks like a crisis from the inside, but it compounds into exactly the kind of exposure a regulator or auditor eventually notices from the outside.
A Simple RACI View of IT Decisions
A RACI structure, which is Responsible, Accountable, Consulted, and Informed, is a useful device for making decision rights concrete rather than aspirational. Take a decision like approving a new SaaS vendor.
| Role | RACI Position |
|---|---|
| IT team | Responsible for evaluating the tool |
| Department head or finance lead | Accountable for the final decision |
| Security and finance teams | Consulted before the decision is made |
| Broader leadership | Informed once the decision is final |
The value of writing this out is not the document itself, but the fact that two people, asked separately, will give the same answer about who approves a new vendor. The same structure, once written for one decision, applies with minor changes to most others: security exceptions, budget overruns, and vendor contract renewals all follow a similar shape, usually with a different Accountable party depending on how much is at stake.
A security exception, for instance, might have IT as Responsible for assessing the risk, a chief information security officer or equivalent senior role as Accountable for approving it, legal or compliance as Consulted, and the rest of leadership Informed. The roles change depending on the decision, but the discipline of explicitly naming all four positions remains the same, and that consistency is what makes the structure useful rather than a one-off exercise.
Vendor Decisions Belong in the Same Structure
Vendor relationships are one of the most common places where decision rights quietly break down. Who approves outsourcing an IT function, who signs off on a cloud migration, who selects a managed service provider, and who reviews a vendor’s risk profile before a contract renews are all governance questions rather than purely procurement ones.
IT vendor selection in Nigeria covers how to evaluate a vendor properly, but that evaluation only means something if it is clear beforehand who has the authority to act on it, using the same RACI structure already established for any other decision type.
What Happens Without a Governance Structure
The absence of governance tends to accumulate rather than announce itself as a single failure. A department adopts a tool without informing IT, another does the same for a different need, and within a year, an organisation is running a dozen unmanaged subscriptions that nobody centrally approved. Our article on Shadow IT in Nigeria covers this pattern in detail: the tools, the reasons departments reach for them, and the risks that build up quietly underneath.
Why Departments Work Around IT
Shadow IT is the symptom. It happens because there was no clear, fast path for a department to get a tool approved through the proper channel, so people found a way around the channel instead. A governance structure that makes decision rights clear and responsive does not eliminate the temptation to work around IT, but it removes the excuse. If everyone knows who approves what and how quickly approval happens, going around the process becomes a deliberate choice rather than the default.
Speed matters more here than most governance discussions acknowledge. A department that waits two weeks for a straightforward tool approval will bypass the process long before it waits two months. Governance that only exists to slow things down invites exactly the workaround behaviour it is meant to prevent, which is why decision rights should specify both who is allowed to make a decision and roughly how quickly they are expected to make it.
The Regulatory Stakes
Regulated organisations carry a sharper version of this risk. A bank, an insurer, a telecoms operator, a healthcare provider, or an oil and gas company operating without clear IT decision rights risks more than an operational mess. It often carries compliance exposure it cannot demonstrate an answer to when a regulator or auditor asks who approved a given system or data flow. Government contractors face a similar version of this, since procurement processes increasingly expect a documented answer to exactly that question before a contract is even awarded.
Policy Frameworks vs Governance Structures
The distinction between policy and governance is worth returning to directly, since the two get treated as interchangeable more often than they should be. IT policy for Nigerian businesses covers the operational document a business needs from day one: acceptable use rules, password requirements, the practical guardrails that apply to everyone. That document answers what employees are allowed to do.
What Governance Answers That Policy Doesn’t
Governance answers a different question: who decided the policy should say that, who can change it, and who is accountable if the organisation ignores its own rules. A business can have a thorough, well-written IT policy and still lack governance behind it because nobody owns the decision to update it, enforce it, or grant exceptions to it.
The two should sit alongside each other rather than be merged into one document. Policy is what a new employee reads in their first week. Governance is the structure that determines what that document says and who is responsible for keeping it current.
Accountability and Review
Governance that is written once and never revisited stops being governance and becomes a document that was once accurate. Decision rights need periodic review for the same reason budgets do: the organisation changes, new tools get adopted, new risks appear, and a structure built for a fifty-person company does not automatically fit the same company at two hundred people.
A technology audit is usually the practical mechanism for this kind of review, since it surfaces the actual state of an organisation’s IT decisions rather than the assumed one. Our guide to technology audit in Nigeria covers what that process reveals and why it is often the point where governance gaps first become visible, alongside budget and vendor issues.
External Standards and Regulatory Expectations
For regulated organisations, this review also has an external dimension. NITDA maintains a set of published standards and guidelines that function as a minimum benchmark for IT practices in Nigeria, and its regulations page is a reasonable starting point for understanding which instruments might apply to a given sector.
Not every organisation will be directly bound by every guideline there, but boards in regulated industries are increasingly expected to demonstrate that IT decisions were made against a recognised standard, rather than invented internally with no external reference point at all.
Governance is not the same as compliance with the Nigeria Data Protection Act, sector-specific rules, or cybersecurity requirements, but it determines who within the organisation actually owns each of those obligations. A business can be fully aware of what NDPA compliance requires and still struggle to answer who is accountable for it internally, which is ultimately a governance problem rather than a compliance one.
Running the Annual Review
A review does not need to be elaborate to be effective. An annual check of who currently holds each decision right, whether that still matches who is actually making the decision in practice, and whether any new categories of decision have emerged since the last review covers most of what matters.
For a board, this is usually a short standing item rather than a dedicated meeting: a summary of which decision rights changed hands in the past year, any exceptions granted outside the normal process, and any gaps the technology audit or a similar review surfaced.
The review should also ask whether any emergency or one-off decisions made during the year exposed a weakness in the existing structure, since those moments are usually the clearest evidence of where a decision right was missing or unclear. The point is to confirm that the structure still matches how the organisation actually operates, rather than relitigating every decision made during the year.
Getting Started Without Overbuilding It
The temptation with governance is to reach for a full framework, COBIT, ISO 38500, ITIL, before establishing anything at all, and then stall because the framework feels too large for the organisation’s actual size. That is usually the wrong starting point. A framework is a reference to borrow structure from later, not something to implement wholesale on day one.
These frameworks exist for a reason and are worth knowing by name, even without adopting one in full. COBIT focuses on governance and control across IT processes. ISO 38500 sets out principles aimed specifically at boards and directors rather than IT teams. ITIL concentrates on IT service management rather than governance itself.
Most Nigerian organisations do not need to implement any of these formally. They borrow the specific practices that fit their size and regulatory environment, most often a decision rights structure and a review cadence, without adopting the full apparatus around it.
The more useful starting point is smaller: identify the handful of IT decisions that repeatedly create confusion or delay, usually five or six in most organisations, and write down who is Responsible and Accountable for each using the RACI approach above before considering a larger framework at all. That alone resolves most of the ambiguity that causes Shadow IT, inconsistent vendor approvals, and the awkward compliance conversations that surface during an audit.
What the First Session Looks Like
In practice, this usually takes one working session with IT leadership, finance, and whoever currently holds informal authority over these decisions, rather than a lengthy project. The output is a short, plain document, not a governance framework binder, listing each decision type and who sits in each RACI position. An annual review keeps it from going stale.
Organisations still working out whether this is a problem worth solving internally, or one that needs outside perspective to diagnose properly, may find when your company needs an IT consultant a useful starting point before committing to a governance review either way.
If your organisation is past the point where informal IT decisions still work, PlanetWeb can help map current decision rights, identify accountability gaps, and build a governance structure that matches your actual scale rather than a generic framework. Explore our IT consulting services or contact PlanetWeb to discuss a governance review for your organisation.
