Fund the Foundations First: A 2026 Board Case for Unfashionable IT Spend

Digital transformation budgets have a visibility problem. A pilot that produces a dashboard or a chatbot demonstration can be shown to a board in ten minutes. A tested restore procedure, a clean identity lifecycle or an integration layer that prevents duplicate records cannot. Yet the second category is what allows the first to survive contact with production. In 2026, UK transformation teams still face pressure to announce new AI initiatives while the foundations beneath them remain underfunded.

This is not an argument against experimentation. It is an argument for sequencing. Boards should approve visible pilots, but only after they have seen evidence that the boring technology underneath them is funded, owned and tested.

The pilot paradox

Pilots are usually designed to succeed in controlled conditions. They use a limited data set, a small group of enthusiastic users and a manual workaround when something breaks. Production is different. It involves joiners and leavers, multiple systems of record, audit requirements and the ordinary failures that occur when software meets real operations.

When identity controls are weak, a pilot becomes an access risk. When integration is unfunded, staff re-key data and trust in the result falls. When backup is untested, a corrupted data set can turn a promising initiative into a recovery exercise. The visible project absorbs the attention; the hidden dependency absorbs the risk.

What belongs in a boring technology line

A dedicated foundational budget should cover four areas. Backup and restore includes immutable copies, retention aligned to business and regulatory needs, and scheduled restore tests rather than merely a successful backup log. Identity and access covers single sign-on, multi-factor authentication, privileged access management and a reliable joiner-mover-leaver process. Integration covers the interfaces, middleware and data contracts that let systems exchange information without manual intervention. Monitoring covers service health, security alerts, log retention and clear escalation paths.

These are not glamorous purchases. They are the conditions that make digital services dependable. A separate budget line protects them from being raided whenever a more visible initiative needs contingency. It also gives the board a simple question to ask: what percentage of the transformation portfolio is committed to keeping the estate safe and connected?

Why AI procurement makes foundations urgent

AI tools intensify the foundational requirement. They often need access to documents, databases and workflow systems. They may create new categories of personal data or inference data. Their suppliers may rely on subprocessors and cross-border transfers. Procurement teams therefore need to know who can access the tool, what data it can reach, how that access is revoked and what happens if the service is withdrawn.

These questions are difficult to answer if the organisation cannot produce a reliable identity list, a data map or an integration inventory. AI due diligence becomes theatre when the underlying controls are unknown. The procurement question is not only whether the AI supplier is credible. It is whether the buyer can operate the tool safely once the pilot ends.

Six questions for the board

Before approving the next AI pilot, directors should ask for evidence on six points. First, when was the last successful restore test for the systems the pilot will depend on, and how long did it take? Second, can the organisation demonstrate that access to the pilot data is limited to named individuals and removed promptly when roles change? Third, how will data move between the pilot and systems of record, and who owns the integration work? Fourth, what monitoring will detect failure, misuse or unusual access, and who receives the alert? Fifth, what is the exit plan if the supplier changes terms, raises prices or ceases service? Sixth, what proportion of the total cost is being spent on these foundations rather than on the demonstration itself?

These questions are not designed to block innovation. They are designed to prevent a pilot from being approved on the strength of a demonstration while its operating costs are deferred to an unprepared team.

Defending the spend in financial terms

Unfashionable spend is easier to defend when it is expressed as avoided cost and reduced uncertainty. An untested backup is not a control; it is a hope with a retention policy. A weak identity process creates rework for every mover and leaver and exposes the organisation to avoidable access risk. Poor integration consumes staff time in reconciliation and delays every future change. Monitoring gaps turn minor incidents into extended outages.

The board does not need a dramatic forecast. It needs a credible statement of what the organisation is currently accepting. A short resilience review can show where single points of failure sit, which critical services lack tested recovery and which access reviews are overdue. That evidence makes the foundational line easier to approve than a vague request for more IT budget.

Guardrails that keep the line honest

A boring technology budget should not become a blank cheque. Set a small number of measurable outcomes: restore tests completed, privileged accounts reviewed, integration incidents reduced, critical alerts acknowledged within an agreed time. Report progress quarterly alongside the visible transformation portfolio. Protect the line from being raided, but require evidence that the money is buying tested capability rather than additional layers of tooling.

The constructive position for UK transformation leaders is straightforward. Fund the foundations, test them, and then approve the pilot. Visible innovation is valuable, but it is not a substitute for operational readiness. A board that asks for evidence of backup, identity, integration and monitoring before the next AI initiative is not slowing transformation. It is making transformation survivable.