IT Governance for a Small Business: What Matters

IT governance is not a pile of policies

IT governance sounds like something designed for large enterprises with a board, an internal audit department and several hundred pages of procedures.

For a 20 to 500 person company, that approach is usually wrong.

You still need governance, but you need it at the scale of the business. The basic question is simple: who decides what happens to technology, how is that decision controlled, and how do you know it was done properly?

That covers much more than cybersecurity. It includes access to systems, technology purchases, software changes, suppliers, data, backups, incidents, projects and the risks created by IT decisions.

A useful governance system creates accountability without making ordinary work painfully slow. Current IT governance guidance continues to emphasise alignment with business objectives, risk management, documentation, auditability and continuous improvement rather than treating governance as a one-off compliance exercise.

The mistake is copying an enterprise framework word for word. The better approach is to take the useful controls and make them workable for your team.

Start with ownership, not frameworks

Before choosing ISO 27001, COBIT, ITIL or another framework, answer a more basic question: who owns IT risk?

There should be someone who can answer:

• Which systems are critical to the business?
• Who approves access?
• Who approves major technology spending?
• Who can make production changes?
• Who owns cybersecurity decisions?
• Who checks backups?
• Who manages suppliers?
• Who decides when a risk is acceptable?
• Who reports important IT risks to management?

The answer does not have to be an IT manager. In a smaller company, it might be an operations director, CTO, finance leader or business owner working with an IT lead.

What matters is that the responsibility is explicit.

This becomes particularly important when IT is outsourced. A managed service provider can operate systems, but the business still needs to know who owns decisions and risk internally. Outsourcing the work does not automatically outsource accountability.

A simple responsibility matrix can help. For each important process, identify who is responsible for doing the work, who approves it and who needs to be informed.

Do not create a matrix for every printer change. Use it for things that can materially affect the business.

The six controls most small businesses actually need

You can build a useful governance baseline without creating dozens of policies.

1. Access control

Define how users get access, who approves it and what happens when they change roles or leave.

This should cover Microsoft 365, cloud platforms, business applications, network equipment and administrative accounts. Privileged access should receive more scrutiny than ordinary user access.

The important part is the lifecycle. An employee should not keep access simply because nobody remembered to remove it.

2. Change management

Not every IT change needs a committee.

But important changes should have an owner, a reason, an approval where appropriate, a planned implementation method and a rollback or recovery approach.

A recent 2026 change-management policy example defines controlled changes around approval, documentation, testing and implementation, while distinguishing normal changes from higher-risk changes.

For a small company, a lightweight change record may be enough. A firewall rule change, production database change or identity policy modification deserves more control than installing an approved application on one laptop.

3. Asset and configuration management

You need to know what you have before you can govern it.

Maintain an inventory of important devices, servers, cloud resources, applications and critical SaaS services. Record ownership and, where useful, lifecycle information.

This does not need to become a massive configuration-management database. Start with the assets that matter most to operations and security.

4. Backup and recovery

Governance is not simply deciding that backups are enabled.

Someone should own the backup policy. Someone should know what is protected, how long it is retained, where copies are stored and what the recovery priorities are.

The business should also distinguish between a successful backup job and a tested recovery. Those are different things.

A practical managed backup service can help operationally, but management still needs to define what data and recovery objectives matter to the business.

5. Security risk management

You do not need a 40-page risk register.

You do need a short list of significant technology risks, with an owner and a planned response.

For example:

Risk	Owner	Treatment
------------------------------	-----------	---------------------------
Unsupported server	IT	Replace or migrate
Excessive administrator access	IT/security	Reduce privileges
Single internet connection	Operations	Assess secondary connection
Unverified backups	IT	Schedule restore test
Critical supplier dependency	Management	Review contingency

The point is to make risk visible.

6. Supplier management

Your IT environment probably depends on more companies than you realise.

Cloud providers, software vendors, internet providers, security companies, payroll platforms and external IT support all create dependencies.

For important suppliers, record what they provide, what access they have, what data they handle and what happens if the service becomes unavailable.

The level of review should match the importance of the supplier. A company hosting your core financial system deserves more scrutiny than a minor software subscription.

What people get wrong about IT governance

The first mistake is thinking governance means more approvals.

Bad governance slows everything down. Good governance makes important decisions clearer.

If a technician has to obtain three signatures to install a routine security update, the process is probably too heavy. If nobody knows who can approve a change to the production firewall, the process is too weak.

The second mistake is choosing a framework before identifying the problem.

COBIT, ITIL and ISO/IEC 38500 have different purposes. Current guidance commonly positions ISO/IEC 38500 around governance principles, COBIT around broader IT governance and ITIL around service management.

You do not need to implement all three.

A company struggling with inconsistent support and change handling may need service-management processes. A board concerned about technology oversight may need a clearer governance layer. A company preparing for a formal security certification has a different problem again.

The third mistake is writing policies nobody follows.

A policy that says "all changes must be approved" is meaningless if urgent changes are routinely made without records and nobody reviews the exceptions.

A shorter policy that people actually follow is better than a perfect policy that sits in a document library.

The fourth mistake is treating compliance as the objective.

Compliance can be important. But passing an assessment while the underlying controls are weak is not good governance.

Governance should make the business more controlled, not simply more capable of producing documents for an auditor.

How to make governance fit a 20 to 500 person company

Start with a small operating rhythm.

Monthly: review important IT risks, major incidents, outstanding high-risk vulnerabilities, backup status and significant technology changes.

Quarterly: review administrator access, suppliers, technology roadmap, major licences and unresolved risks.

When someone joins or leaves: verify access is created or removed correctly.

Before a major change: document the reason, owner, risk, implementation plan and rollback approach.

After a major incident: record what happened, what was learned and which control needs to change.

At least annually: review the core policies and whether they still match the business.

The exact schedule can vary. The important thing is that governance becomes a routine rather than an annual scramble.

For organisations that need a more structured approach, IT governance and compliance consulting can be used to establish responsibilities, policies, controls and review processes. The sensible starting point is still proportionality. A 30-person company does not need the same governance machinery as a multinational bank.

Documentation also matters because memory is unreliable. If the person who normally manages the firewall leaves, another person should be able to understand the environment without reconstructing it from scratch.

What to actually do in order

First, list the systems that the business genuinely depends on. Include identity, email, finance, customer systems, file storage, networking, cloud services and critical applications.

Second, assign an owner to each important system. Ownership means someone is responsible for decisions and risk, not necessarily that they perform every technical task.

Third, write five basic rules: access management, change management, backup and recovery, security incident handling and supplier access.

Fourth, create a simple risk register. Keep it short enough that management will actually read it. Give every meaningful risk an owner and a next action.

Fifth, establish evidence. Keep records of access reviews, important changes, backup tests, security assessments, incidents and supplier reviews. Governance without evidence becomes difficult to demonstrate and difficult to audit.

Sixth, introduce a regular management review. Look for exceptions, overdue risks and recurring failures. Do not just review whether policies exist.

Seventh, only then decide whether you need a formal framework or certification. If the business needs ISO 27001, contractual assurance or a specific regulatory control set, map your existing processes to the relevant requirements instead of starting with a blank document.

A broader technology assessment can also help identify where ownership, documentation and control are missing across infrastructure and applications.

The goal is not to make IT bureaucratic. It is to make important technology decisions deliberate, repeatable and accountable.

If a business cannot answer who owns a critical system, who can change it, what happens when it fails and what evidence exists that its controls are working, that is a governance gap. It does not matter whether the company has ten policies or a hundred.