IT Governance for Business Owners: Who Decides?

Why IT Governance Needs Clear Ownership

IT governance for business owners becomes a concern when nobody can clearly explain who approves technology spending, who owns important risks or who holds suppliers accountable.

Your business may have capable IT people, established suppliers and sensible technology plans. But if responsibilities are unclear, important decisions can still fall between the gaps. Good governance establishes who has authority, what information leaders need and when problems must be escalated.

Takeaways

What IT Governance Actually Controls

IT governance is the way a business directs, oversees and holds people accountable for its technology decisions, investments and risks.

It is not simply about IT policies, cybersecurity or compliance. It connects technology decisions with business objectives and makes responsibility clear.

For example, your IT manager may recommend replacing an ageing business system. Your CFO may assess the financial implications, while your operations manager considers the effect on customers and employees.

Someone still needs authority to make the investment decision.

Good governance establishes that authority before a disagreement or unexpected cost forces the issue.

The COBIT framework from ISACA provides guidance on governing and managing enterprise information and technology. Its principles can be useful, but an established Australian business does not necessarily need to implement an extensive governance framework.

I would start with four practical objectives:

• Clear decisions: Everyone understands who can approve spending, priorities and changes.
• Accountable risk ownership: Important technology risks belong to someone with the authority to address them.
• Reliable information: Leaders receive useful reporting on expenditure, performance, delivery and risk.
• Appropriate escalation: Problems reach the right decision-maker before they become harder to resolve.

The purpose is not to create more paperwork. It is to make better decisions while allowing capable people to get on with their jobs.

How Decision Rights Become Unclear

Technology responsibilities often become fragmented as businesses grow.

Finance introduces a new accounting platform. Operations selects a workflow system. Marketing purchases customer software. An external provider manages infrastructure, while a development company builds and maintains the business’s core application.

Each decision may be reasonable on its own.

The difficulty arises when nobody is responsible for understanding how those decisions affect the wider business.

A system purchased by one department may introduce security risks, additional costs, integration requirements or contractual obligations affecting several others.

An outsourced developer may make architectural decisions with long-term business consequences. An IT manager might approve expenditure without knowing that the change affects another department’s priorities.

These situations can create warning signs:

• Technology spending increases without a clear view of total commitments.
• Suppliers influence priorities without sufficient business oversight.
• Project delays are reported but rarely challenged.
• Important technology risks have no named business owner.
• Executives receive technical updates but cannot tell what decisions are required.
• Different managers give conflicting instructions to internal teams.
• Problems are discussed repeatedly without someone accepting responsibility for resolving them.

None of these automatically means the technology team is performing poorly.

The problem may be the way responsibility and authority have developed around them.

Who Should Approve Technology Decisions?

Technology decisions should be made by people with the appropriate authority, business knowledge and understanding of the consequences.

That does not mean your CEO needs to approve every software update or infrastructure change.

A useful distinction is between making a technical recommendation, approving expenditure and accepting business risk.

These responsibilities may involve different people.

A Practical Responsibility Model

The following example shows how responsibilities might be allocated within an established business. It is illustrative, not a universal organisational structure.

Decision or responsibility	Typical accountable role	Supporting roles
Technology strategy and major investment priorities	CEO or executive leadership	CTO, CFO, business leaders
Major technology spending	Authorised executive or budget owner	Finance, technology leadership
Routine technology expenditure	Delegated technology or budget manager	Procurement, finance
Technical architecture and standards	CTO or authorised technical leader	Architects, developers, suppliers
Project scope and business priorities	Business sponsor or authorised product owner	Project manager, technology team
Material operational risk acceptance	Authorised business risk owner	Technology, security, legal specialists
Supplier performance and contracts	Contract owner or authorised executive	Procurement, finance, technology leadership
Day-to-day technical implementation	Technology team or supplier	Technical lead, project manager

The precise structure depends on your business, legal obligations, existing delegations and level of technology complexity.

What matters is that the responsibilities are agreed and understood.

Separate Advice From Approval

Your developers and technology suppliers should be able to recommend technical solutions based on their expertise.

They should not automatically have authority to approve material changes to business spending, commitments or risk.

For example, a developer might recommend replacing a database because the existing one has performance limitations.

That recommendation should include the technical reasoning, likely costs, alternatives and business consequences.

The appropriate business decision-maker can then consider whether the investment is justified.

Likewise, a CFO may have authority to approve expenditure but still need technical assurance before accepting the proposed approach.

The aim is to combine specialist advice with informed commercial decisions.

Keep Executive Oversight Proportionate

The board or executive team should focus on material investment decisions, business outcomes, important risks and strategic direction.

Routine implementation decisions should remain with the people qualified and authorised to make them.

Australian company directors have broader governance duties, including taking reasonable steps to guide and monitor company management, as outlined in ASIC’s guidance on directors’ responsibilities.

That does not mean directors should manage technology projects themselves.

They need appropriate oversight, reliable information and a clear understanding of material business exposure.

Who Owns the Technology Risk?

Technology risk should have a named owner who understands its business consequences and has the authority to decide how it will be managed.

An IT manager or supplier may identify a risk and recommend what should be done. But the responsibility for accepting a material business risk should sit with an appropriately authorised business leader.

Consider a customer-facing platform that occasionally becomes unavailable.

The technology team might identify the cause, estimate the cost of improving reliability and explain the possible consequences of doing nothing.

The operations executive responsible for the affected service may need to decide how much disruption is acceptable, subject to the company’s risk policies and approval arrangements.

This separates technical responsibility from business accountability.

Identify the Risks That Matter

Technology risks can affect the business in different ways:

• Operational continuity: A critical system fails and prevents employees or customers from completing essential work.
• Cybersecurity and privacy: Sensitive information is exposed, lost or accessed without authorisation.
• Supplier dependency: A provider becomes unavailable or the business cannot maintain an important system independently.
• Project delivery: A major technology initiative exceeds its budget, misses commitments or fails to deliver the intended business value.
• Key-person dependency: Essential technology knowledge or access is concentrated in one employee or contractor.
• Investment exposure: Technology expenditure continues even though the original commercial justification has changed.

Business Queensland’s guidance on managing information technology risk highlights the importance of understanding risks to systems and data, their business impact and the need for appropriate response plans.

The Australian Signals Directorate also identifies executive accountability, documented responsibilities and regular risk reporting in its cyber security governance principles. These are useful governance references, although their applicability and any mandatory requirements depend on the organisation’s circumstances.

Record the Owner and the Decision

I would expect material technology risks to be recorded in a form that business leaders can understand.

For each risk, identify:

• What could happen and which business activity would be affected.
• The potential consequences for customers, operations, finances or compliance.
• The named business risk owner.
• Existing controls and the actions being proposed.
• Who is responsible for carrying out those actions.
• The decision, target date and next review point.

A risk should not disappear simply because it has been entered into a spreadsheet.

Someone must be responsible for deciding what happens next.

Equally, accepting a risk does not remove legal obligations. Some risks must be addressed because of applicable laws, contracts or regulatory requirements, regardless of management’s preferred risk tolerance.

A Checklist for Your Next Leadership Meeting

You can begin improving IT governance without creating a new committee or purchasing specialist governance software.

Start with the decisions your leadership team already makes and the risks you already face.

Use the following checklist at your next executive or management meeting.

Technology Governance Checklist

1. Who can approve technology spending? Are expenditure limits defined? Who approves investments outside the existing budget?
2. Who can approve project scope changes? Can a project manager change delivery commitments? When must the business sponsor or executive team approve the change?
3. Who owns each significant technology risk? Is there a named business owner who understands the consequences and can authorise appropriate action?
4. What should developers and suppliers report each month? Do we receive reliable information about progress, actual costs, forecast expenditure, emerging risks and decisions required?
5. When must problems reach the executive team? Are there agreed triggers for delays, cost overruns, security concerns, operational incidents and unresolved risks?
6. Who is accountable for supplier performance? Do we know who monitors commitments, challenges estimates, reviews service performance and manages contractual concerns?
7. Who owns critical systems and accounts? Does the business understand who controls access, documentation, backups, intellectual property and recovery arrangements?
8. How are important decisions recorded? Can we identify what was approved, by whom, on what evidence and with which conditions?
9. When do we review previous decisions? Are outstanding actions, accepted risks and expected business benefits revisited rather than forgotten?

If your team is getting different answers about who approves spending, owns technology risks or holds suppliers accountable, I can help you clarify those responsibilities and agree on what leadership needs to see. Explore Technology Leadership and IT governance support.

You do not need perfect answers to all nine questions immediately.

I would start by identifying the three questions creating the greatest uncertainty and assigning someone to resolve them.

That first step can expose more useful information than spending weeks designing a complicated governance framework.

What Suppliers Should Report Each Month

Your technology suppliers and development teams should report information that helps leadership understand progress, costs, risks and decisions requiring attention.

A report should not simply describe the work completed during the month.

For a business-critical technology initiative, I would expect a concise summary covering the following areas.

Delivery Progress and Commitments

What was expected to be completed? What was actually delivered?

Include important milestones, accepted deliverables and outstanding work.

A statement that development is progressing well is not enough if nobody can demonstrate whether the business is receiving the expected outcomes.

Actual Costs and Forecast Spending

How much has been spent, what commitments remain and what is the current estimated cost to complete?

The forecast matters as much as the expenditure already recorded.

A project may still appear within its approved budget while the remaining work is becoming more expensive than originally expected.

Risks, Issues and Dependencies

What is preventing progress or creating business exposure?

Reports should distinguish between risks that might occur and issues that are already affecting the business.

Important dependencies should be visible, particularly where another supplier, system or business decision is holding up delivery.

Quality and Operational Readiness

Is the work being tested appropriately, and is there evidence it can be supported once delivered?

Depending on the initiative, this may include defects, testing outcomes, release readiness, security concerns, recovery arrangements and unresolved operational problems.

A completed development task is not necessarily a business-ready capability.

Supplier Commitments and Decisions

Are contractual obligations, support commitments and agreed deliverables being met?

The report should make it clear when management needs to approve a change, resolve a disagreement or make a commercial decision.

Example Monthly Reporting Summary

Reporting area	What leadership should understand
Business outcome	Are expected benefits still realistic?
Delivery	What was completed, missed or changed?
Financial position	Actual spend, commitments and forecast to complete
Risks	Material exposure, named owners and actions
Supplier performance	Commitments met, missed and disputed
Quality and readiness	Testing, operational concerns and outstanding defects
Executive decisions	What needs approval, by whom and when?

A useful report can be brief. The important part is that the information is credible and leads to action.

If all indicators remain green while dates and budgets keep changing, the reporting process deserves closer examination.

When Should Problems Reach Executives?

Technology problems should reach the executive team when they exceed an agreed level of authority, threaten an important business outcome or require acceptance of material risk.

Waiting for the next monthly meeting may be inappropriate when an issue affects customers, critical operations or sensitive information.

The business should define escalation triggers before these situations arise.

Define Clear Escalation Triggers

Situation	Escalation trigger
Cost increase	Forecast exceeds approved budget or delegated authority
Delivery delay	A business-critical milestone or commitment is threatened
Scope change	Proposed change materially affects benefits, cost or obligations
Security incident	Impact requires executive, legal, regulatory or crisis-management decisions
Supplier failure	Repeated missed commitments threaten delivery or continuity
Operational risk	Potential consequence exceeds the authorised risk owner’s tolerance
Unresolved issue	Action remains blocked beyond the agreed decision deadline

These are examples of possible triggers. Each business needs to define suitable thresholds and response times.

A small scheduling adjustment may be handled by the project manager.

A delay affecting a contractual commitment, customer launch or critical operating system may require immediate management attention.

The same principle applies to expenditure.

A technology manager may have authority to approve an additional minor cost within an agreed budget.

That does not necessarily authorise a change that materially increases the business’s total investment.

Escalation Should Enable Action

Escalation is not about allocating blame.

It should provide decision-makers with enough information to understand the issue, consider options and authorise a response.

I would expect an escalation to explain the problem, business consequences, available options, recommendation and required decision date.

The executive team should not have to reconstruct the situation from technical emails and competing supplier explanations.

Before You Approve More Project Spending

One of the clearest tests of technology governance comes when a project is late and its supplier requests more money.

Consider this hypothetical situation.

An established business has approved $300,000 to develop a new software platform. The project is now six weeks behind schedule, and the supplier requests another $60,000 to complete the work.

The supplier explains that the original estimate was too low and additional functionality has increased the workload.

The business has already invested heavily, and management is concerned that refusing the additional funding will leave the project unfinished.

This is exactly where clear governance matters.

Ask Why the Estimate Changed

Before approving the additional expenditure, I would want to understand the original estimate, the assumptions behind it and what has changed.

Was the work genuinely more complex than expected?

Did the business request additional functionality? Were important requirements overlooked? Has the development approach created unexpected difficulties?

These are different problems requiring different responses.

A scope change initiated by the business may justify additional expenditure. A supplier repeatedly underestimating the remaining work may require a different approach.

Establish the Real Position

I would ask for evidence showing what has been completed, what remains and how the new estimate was prepared.

That includes:

• Deliverables completed and accepted against the original agreement.
• Work remaining, including integration, testing, deployment and documentation.
• Actual expenditure, outstanding commitments and the revised total forecast.
• Assumptions and dependencies behind the new completion date.
• Known technical problems, defects and delivery risks.
• Any changes to the original business case or expected benefits.

It is important to distinguish the supplier’s estimate from an independently supported delivery forecast.

A revised date is not necessarily more reliable simply because it is the latest date.

Consider the Available Options

The leadership team should consider whether to approve the full request, release funding in stages, reduce scope, obtain an independent assessment or pause the project.

In some situations, the additional expenditure may be justified.

In others, the best option may be to stop work temporarily and establish a more reliable view of the remaining effort.

The money already spent should not be the sole reason for continuing.

The decision should consider the remaining investment, likely benefits, business consequences and available alternatives.

Make the Approval Conditional

If the business decides to proceed, approval may reasonably be linked to revised milestones, acceptance criteria, testing evidence or agreed reporting.

The authorised decision-maker should record what has been approved and what must happen before any further funding is released.

This is not about creating an adversarial relationship with the supplier.

It is about making a commercial decision using enough reliable information.

For a deeper discussion of oversight during technology delivery, see my article on software project governance for CEOs.

How to Establish Practical IT Governance

You do not need to introduce an extensive governance framework overnight.

For most established businesses, I would recommend starting with existing responsibilities, decisions and reporting arrangements.

1. Identify Important Technology

Begin with the systems, suppliers, projects and technology investments that matter most to your operations.

You do not need an exhaustive technical inventory before making progress.

Start with business-critical systems, important supplier relationships, material projects and the areas where an outage or poor decision could have serious consequences.

2. Clarify Decision Authority

Document who can approve expenditure, project changes, supplier commitments and acceptance of material risk.

Use existing management and financial delegations wherever possible.

The aim is to resolve unclear responsibilities rather than create a separate approval process for every technology decision.

3. Assign Business Risk Owners

Identify the most important technology risks and allocate each to an appropriate business leader.

Make sure ownership includes the authority to act or escalate.

The technology team should remain involved in assessing risks and recommending treatments. Governance must connect those recommendations with the people responsible for business consequences.

4. Improve Executive Reporting

Agree on a manageable reporting format.

For material technology projects and services, focus on delivery, costs, risks, supplier performance and decisions required.

Use existing tools and information where possible.

Introducing another reporting system will not fix governance if the underlying information is unreliable.

5. Establish Escalation Rules

Agree on what needs executive attention and when.

Define thresholds for budget changes, delivery delays, operational incidents, supplier concerns and risks exceeding delegated authority.

People should understand both their responsibility to escalate and what information they must provide.

6. Review Decisions and Outcomes

Governance is not finished when a policy is approved.

Review whether spending decisions delivered the intended value, accepted risks remain within tolerance and agreed corrective actions have been completed.

Make changes when the arrangement no longer fits the business.

A simple decision log, risk register and concise monthly management report may provide a useful starting point.

The right level of governance depends on your complexity, obligations and exposure. A business operating one straightforward system needs a different approach from an organisation running critical services across several locations.

Common Mistakes That Weaken Oversight

Even businesses with experienced technology teams can develop governance weaknesses.

One common mistake is allowing important decisions to remain informal because the people involved work well together.

That arrangement may function while everyone is available and priorities remain stable. It becomes harder when someone leaves, a supplier relationship deteriorates or the business grows.

Other mistakes include:

• Making executives approve everything. This creates delays and removes authority from capable managers.
• Confusing technical responsibility with business risk ownership. Technical specialists can manage controls without being authorised to accept the business consequences.
• Relying entirely on supplier reporting. Suppliers should report honestly, but important investment decisions may warrant independent scrutiny.
• Treating governance as documentation. A policy nobody follows provides little practical oversight.
• Measuring activity instead of outcomes. A high number of completed tasks does not demonstrate that the technology investment is delivering value.

My approach to technology leadership is based on people before technology.

That applies directly to governance.

Good processes should help people understand their responsibilities, raise concerns early and make informed decisions.

They should not discourage initiative or turn every disagreement into a management escalation.

When to Seek Independent Technology Advice

Some governance problems can be resolved internally.

If your organisation already has capable technology leadership, reliable reporting and clear executive authority, you may simply need to clarify a few responsibilities.

I would start internally when the leadership team agrees on the problems, understands the risks and has enough capacity to implement the necessary improvements.

Independent advice becomes more useful when the situation is harder to assess.

When an Independent Review Helps

An independent review can be valuable when you cannot establish whether the current technology arrangements are appropriate.

For example, your leadership team might be concerned about supplier dependence, weak reporting, unclear responsibilities or conflicting recommendations.

A broader Independent Technology Review can help assess technology, delivery, risks and proposed investment before management decides what needs to change.

A review should answer a specific business question. It does not automatically mean the organisation needs ongoing consulting support.

When Ongoing Leadership Makes Sense

Recurring governance problems may indicate that the business needs experienced technology leadership rather than another one-off assessment.

This is particularly relevant when:

• Technology investments and suppliers need continuing executive oversight.
• The CEO is regularly drawn into decisions that should have clearer ownership.
• Existing technology managers need support with governance, leadership or commercial decisions.
• Delivery and operational risks require regular independent attention.
• Business growth has increased technology complexity beyond the current leadership arrangements.

An ongoing Fractional CTO engagement may be appropriate where the organisation needs sustained executive-level technology direction and governance without appointing another full-time executive.

The decision should reflect what your existing leaders can manage, the complexity of the business and the outcomes you need.

The goal is to strengthen internal capability and accountability, not create unnecessary dependence on an external consultant.

Frequently Asked Questions

Who Is Responsible for IT Governance?

The board or executive leadership has overall governance responsibilities appropriate to the organisation, while specific technology decisions and risks can be delegated to authorised managers. Responsibilities should be documented and reviewed.

Does Every Business Need a CTO?

No. Effective IT governance requires clear accountability and appropriate expertise, not necessarily a full-time CTO. An existing leadership team may be able to manage it internally or with independent advice.

Who Should Own Technology Risks?

Material technology risks should have named business owners with authority appropriate to their consequences. Technology teams and suppliers can identify risks, manage controls and recommend actions, but should not independently accept business risks outside their authority.

What Should IT Suppliers Report?

For material services and projects, suppliers should report performance against commitments, delivery progress, actual and forecast costs, significant risks, outstanding issues and decisions requiring management attention. The level of detail should reflect the service’s importance.

What Is the Difference Between IT Governance and IT Management?

IT governance establishes direction, decision authority, accountability and oversight. IT management plans and carries out the work within that direction. Both are necessary, but they serve different purposes.

Make Ownership Clear Before You Spend

Good technology governance starts with clear decisions, named responsibilities and useful information. If your business is struggling with unclear approvals, supplier accountability or technology risk, book a free consultation to discuss your leadership needs and the options available. We can explore what practical IT governance for business owners should look like in your organisation.