Public authorities often face a centralisation challenge when it comes to technology. This is because digital teams do not just manage technology for themselves, they also - to differing extents - have to do it for other teams, units, departments, and groups. This is true of all large organisations, but especially true of local public authorities.

Take the example of a local authority. The digital (sometimes called ‘tech’ or ‘ICT’) team of a local council does things on behalf of lots of other teams and departments: teams working on social care, children’s services, planning, local benefits, among others; and often, they might need to support an even wider set of organisations within their remit: such as delivering technology within local schools, arts centres, libraries and more.

This presents a big centralisation challenge. Authorities need to decide how much these central digital teams should do, and how much should be left to individual departments. 

In this article, we discuss how authorities can get the right balance when centralising processes, procurement and resourcing within their central digital team.

Why and when to centralise

There are benefits to ‘centralising’ and ‘decentralising’, and the debate should not frame them as competing options.  

Authorities will - rightly - adopt some level of technology decentralisation, because they want to empower their teams. These teams will be closest to the ground, to the user, or the policy area, and so the technology team should support, and not frustrate this. Done incorrectly, centralisation can become a bottleneck: standards can become compliance exercises, assurance can become slow approval, licensing can become a restriction on choice, and cyber oversight can become disconnected from how services actually operate. 

However, not having the right control from the centre can create other problems. We’ve worked with councils, regional authorities, departments and large organisations looking to set up such a function, usually because they want more control and the ‘let loose’ approach is no longer working. Or maybe they feel like that the devolved approach is creating security or data risks that the organisation can no longer manage. Or perhaps they think that centralisation can drive greater cost efficiency. Or, most likely, a combination of all of these factors.

Done well, smart centralisation can solve these challenges: standards make decisions more consistent and transparent, assurance reduces monetary risks, shared licensing improves value for money, cyber coordination controls risks of cross departmental boundaries breaks, and visibility helps optimise evidence-based decisions.

The best examples of centralisation come at the national government level, from central digital departments. In the UK, the Government Digital Service provides a central digital and (in some areas) data support function for the government, supported by standards such as the Technology Code of Practice. Singapore’s GovTech supports public agencies with digital transformation and builds technology for public good. Estonia’s Government CIO model is another useful reference: the CIO team leads horizontal digital strategy and policy, while individual ministries remain responsible for digital delivery in their own domains.

But, how can this model be replicated at a much smaller level - like a council or an NHS Trust? 

What a central tech function should do‍

1. Setting manageable and coherent standards

Setting standards is probably one of the most important responsibilities of a central tech function. But publishing them is not enough: making them usable, relevant, and adopted is the bigger challenge. 

A first step is to publish a short, binding set of technical standards covering delivery management and the software development lifecycle. This sets core expectations around how projects are delivered. Then, guidance can be scaled out to cover a wider set of technical standards, including data interoperability, hosting, identity and access management, and procurement requirements. 

For councils, the MHCLG Local Government Cyber Assessment Framework should be treated as the baseline for cyber. For accessibility, WCAG 2.2 AA should be the minimum. For API design, service design and technology assurance, GDS standards and the Technology Code of Practice provide a strong starting point. Digital teams in councils can use these standards to set key delivery processes and rhythms that are rolled out across all other teams. This does not mean they need to oversee or micromanage everything, but that they know other teams are following the right practices.

However, these external standards need to be translated into practical organisational rules that teams can understand and apply, and should apply to all new procurement and development. Exceptions can still be allowed, but they should require a written justification reviewed by the central team before contract signature. ‍

2. Creating a shared tech menu and central licences

Short of buying everything for everyone, central functions can set up some key common tools and licenses, established by a technology menu, covering the common needs of the teams. This should include five or six categories that appear repeatedly across the organisation: Productivity and collaboration; Devices and end-user computing; Case management; Workflow and automation; Analytics (including Power BI and Fabric where already in play); and LLMs or AI-enabled tools where appropriate.

The purpose of the menu is to help teams move faster, avoid duplicating procurement exercises, and use tools that are already known to meet the organisation’s standards.

Centralising licences also gives the organisation greater purchasing power. Negotiating enterprise licences through existing frameworks such as G-Cloud and CCS Technology Products and Services can reduce costs, improve commercial terms and simplify supplier management, while also making integration easier.‍

3. Assuring procurement outside the standard menu

For anything outside of this menu, central teams can run a lightweight assurance check before contract signature. The check should be lightweight, clear, fast, and act as a control layer that ensures quality, without being too frustrating to teams. 

In general, a central team might ask the following questions when assuring new tech: 

• Does the proposed tool and architecture meet our published standards?
• Has the appropriate security assessment been completed (including CAF, data classification, pen testing requirements)
• Is there already something on the menu (or, already deployed within the organisation) that does the same job?
• Are the commercial terms acceptable?

Usually, authorities might base their assurance process around the Technology Code of Practice as the backbone, building out their own bespoke process. Crucially these assurance processes need to be fast, not taking more than two weeks.‍

4. Identifying opportunities for consolidation and reuse

A central tech function needs to have a clear overview of the systems in place across the organisation, how they are being used, who owns them, and what contracts they are associated with. 

To do this, teams should run a software asset discovery across all departments and maintain a live tooling inventory. Amongst other things, this inventory will be useful at flagging where the same category of tool is being licensed separately by multiple teams, and identifying reuse opportunities. 

In addition to maintaining a live registry, teams can publish a quarterly consolidation report that will increase transparency by showing where savings are available and whether previous savings have been realised.

5. Providing shared environments for safe testing and delivery

Less common, but critical when done right: a central team can provide centralised and shared environments that allow the team to optimally and efficiently test and prototype new tools.

These environments should have role-based access, pre-configured to meet the published security standards. This removes one of the most common drivers of shadow IT and means teams can prototype safely without going off-piste.

6. Creating visibility over technical capacity and allocation

A key task of a central tech team is to maintain an organisation-wide view of current staffing and resource priorities. This should include the central digital team’s own staff, technical staff embedded in service departments, and external providers where they are critical to delivery. This allows organisations to understand where they are spending time, where their gaps are, and how they can balance BAU delivery with new projects and initiatives. 

To drive this, we recommend that central digital teams maintain a resource tracker showing where technical staff are allocated across major programmes and workstreams. 

This visibility helps identify gaps, flag programmes that are under-resourced, and feed workforce planning with actual data rather than estimates. This is especially useful if the central team is able to develop a view of their staff’s capability profile against their planned projects, including if they have any technical gaps. ‍

7. Coordinating cyber resilience and supply chain risk

Finally, the central tech has to own the organisation's cyber risk mitigation and response, including maintaining compliance with the LG CAF (or equivalent) framework. 

It has to also coordinate the self-assessment, manage the resulting action plan, and run incident response. Incident response and supply chain risk don't respect departmental boundaries, so this is the one area where centralisation tends to be genuinely necessary rather than just preferable.

But this is obviously a dynamic and evolving task, and is not about just completing a self-assessment once. Cyber resilience should be baked into all of the things above: in assurance processes, in organisation-wide standards, in building an organisation-wide tech menu.

Some tips when building or growing your central digital team

Now we have defined some of the broad functions and priorities of a central digital team, here are a few tips to help build a team from scratch, or grow one out from a smaller unit:

1. Map current spend and duplication

The best place to start is with a systems and contracts register. This should capture the organisation’s current technology systems and contracts across all departments, including the supplier, contract owner, service area, system or tool provided, annual cost, contract value, renewal date, data held, key integrations and whether the contract supports a critical service.

Once this is in place, a central team can conduct a spend analysis of IT procurement across all departments, which will show where the same types of tools are being bought separately, where contracts could be consolidated, and where the initial technology menu should begin. It also helps build the case for centralisation in financial terms.‍

2. Build the technology menu from existing tools and frameworks

The technology menu should be built from what already exists, not from a new procurement exercise. Central tech should use existing government framework agreements wherever possible. G-Cloud and CCS frameworks already have pre-vetted suppliers with agreed commercial terms. The central team's job is curation, negotiation, management and facilitation of technology, including building out agreements with existing suppliers.‍

3. Use existing assurance standards rather than inventing new ones

Assurance should also start from established standards. For example, the team should use the Technology Code of Practice’s 12 criteria as a ready-made assurance checklist rather than designing one from scratch - as well as the Service Manual when defining delivery rhythms - and WCAG for user experience and accessibility.

4. Ground cyber policy in the organisation’s actual risk posture

Cyber policy should be grounded in the organisation’s actual risk posture. Central tech teams should map the current cyber position against LG CAF before writing any new security policies. The assessment will show where the real gaps are, and clarify which risks sit with the centre, which remain with service teams, and how incident response, supplier risk and remediation will be coordinated across the organisation. Crucially, CAF mitigation steps should not just sit within the digital team - they should be understood and acted upon by any digital or system owner across the organisation. 

Final reflections

A central tech function is about creating the conditions for better decisions to be made consistently. When departments buy, build and manage technology in isolation, the result is often duplication, weaker interoperability, inconsistent standards and poorer visibility of risk and spend. 

A central function helps address this by setting common foundations: standards, assurance, shared licences, reusable environments, cyber coordination and visibility over technical capacity.

Central tech functions should focus on the areas where fragmentation creates the greatest cost or risk, while leaving service teams with the flexibility to deliver around user needs.

For organisations considering this model, the starting point should be practical rather than theoretical: map current spend, identify duplication, define the first version of the technology menu, and use existing government standards to shape assurance and cyber improvement. Centralisation should begin where it can quickly demonstrate value, then grow from there.

‍