Summary

• GDS updated the Technology Code of Practice on 29 October, improving its structure and clarifying requirements and recommendations.
• Its 13 principles continue covering accessibility, architecture, procurement, security, privacy, interoperability, and sustainability.
• Further renewal work will examine emerging technologies and make government guidance easier to navigate.

The Government Digital Service (GDS) has revised the Technology Code of Practice, clarifying how public sector teams should apply existing requirements when designing, purchasing, and operating technology.

The update, published on 29 October, gives greater prominence to the Code’s principles, improves the structure of sections covering user needs and architecture, and makes the distinction between requirements and recommendations clearer.

GDS has also begun removing material that no longer reflects current government technology arrangements. Its revision history confirms changes to organisational references and the removal of older references to spending controls, while a broader programme of improvement continues.

The Technology Code of Practice contains 13 principles used across government technology projects. Those principles remain in place following the latest update, which is intended to make the existing framework easier to understand rather than replace it with a new procurement regime.

Existing principles become easier to apply

Government technology projects involve decisions extending beyond the initial selection of software or equipment. Departments must consider how systems meet user requirements, operate securely, integrate with existing services, and remain maintainable as technology changes.

The Code provides a common set of expectations covering those decisions. Its principles address user needs, accessibility, open source software, open standards, cloud services, security, privacy, collaboration, integration, data, purchasing, sustainability, and the government’s wider Service Standard.

GDS has used research with public sector digital and data professionals to examine how the guidance is applied. Participants recognised the value of the principles but reported that navigation and the explanation of individual requirements could be clearer.

The first revisions respond to that feedback by improving the homepage and establishing more consistent layouts in sections dealing with user needs, technology architecture, and lifecycle management.

These areas influence decisions made early in a project. Establishing the intended users and service requirements affects which technical options are appropriate, while architecture decisions determine how a system will exchange information with other applications and remain operable over time.

Clearer guidance can help teams apply existing standards without repeatedly interpreting material distributed across several documents. It can also make the expectations placed on suppliers more apparent when a project enters procurement.

Procurement responsibilities depend on the project

The Technology Code of Practice is the agreed standard for cross-government projects and programmes. Its application depends partly on the procurement route and the assurance requirements relevant to the organisation undertaking the work.

Suppliers operating under the G-Cloud framework are contractually required to support government buyers in meeting the Code. Departments must also consult their assurance teams to establish which principles and requirements apply to their individual spending and approval processes.

For other projects, GDS encourages organisations to use the Code throughout the technology lifecycle and follow as many principles as practical. This approach recognises that different systems present different technical requirements and that assurance obligations may vary.

A department purchasing a common software service may face different integration and security considerations from one developing a specialist system to operate important public infrastructure.

The Code’s purchasing principle asks organisations to consider commercial and technical requirements alongside contractual limitations. Procurement decisions therefore need to account for how technology will operate after implementation, including support arrangements, data access, software licensing, and the ability to change suppliers.

The lowest initial purchase price may not reflect the full operating cost. A system requiring extensive custom integration or expensive maintenance can create financial obligations that continue throughout its working life.

Considering those costs before a contract is agreed can help organisations make more informed decisions about supplier arrangements and the long-term management of their technology.

Interoperability reduces repeated integration work

Several of the Code’s principles address the technical foundations used to connect services. Open standards, reuse, integration, and the effective management of data can influence whether departments can share information and adapt applications without rebuilding their infrastructure.

Government organisations often operate systems introduced at different times by different suppliers. Their ability to exchange information can depend on interfaces, data formats, permissions, and the technical choices made when the original applications were purchased.

Where those arrangements are incompatible, employees may need to transfer information manually or commission additional software to connect systems. The resulting work can increase costs and create additional opportunities for errors.

The Code encourages teams to consider compatibility and reuse when selecting technology. That does not mean every department should adopt identical software, but it supports decisions that allow systems to exchange information and remain adaptable as requirements change.

Its cloud-first principle asks organisations to consider public cloud services before alternative hosting approaches, while still assessing whether the selected option meets the service’s operational, security, and commercial requirements.

Accessibility and inclusion also form part of the framework because digital services must be usable by people with different needs and circumstances. These requirements influence application design as well as the technology infrastructure supporting a service.

Security and privacy remain continuing obligations

The Code treats security and privacy as considerations throughout a project’s lifecycle, not simply as checks performed before software is launched.

Systems can change through updates, integration with additional services, and alterations to the information they process. Those developments may affect access arrangements, operational risks, and the controls needed to protect data.

Government technology projects must therefore examine security and privacy during design, procurement, deployment, and ongoing operation. Suppliers may need to demonstrate how their services satisfy contractual requirements, while public bodies remain responsible for meeting their applicable obligations.

GDS directs users towards Secure by Design guidance for detailed security practices. The Service Standard and Service Manual provide additional expectations concerning the development and operation of public services.

These documents complement the Technology Code of Practice rather than duplicate every part of it. A department can use the Code to structure decisions while consulting specialist guidance for requirements applying to the system it is building.

AI creates questions for the next revision

The government’s technology environment has changed substantially since the Code was introduced in 2013. Artificial intelligence, modern cloud architectures, and changing cyber security practices are altering how applications are developed and operated.

GDS has identified these developments as areas to examine during the continuing renewal programme. The work is intended to ensure that guidance remains practical as departments introduce newer technologies and revise established services.

AI applications can involve external model providers, access to substantial datasets, automated generation of information, and workflows in which software performs several connected activities.

Those characteristics create procurement and operational decisions involving model access, data protection, reliability, and the responsibilities assigned to different suppliers.

The government’s AI Playbook already provides specialist guidance for public sector AI projects. GDS references it alongside the Code, allowing departments to apply the existing technology principles while considering additional requirements relevant to AI.

Further updates may improve the connections between these standards or clarify how they should be applied to emerging technical architectures. The work remains under development and should not be presented as a completed new set of AI procurement rules.

Sustainability extends across the technology lifecycle

The Code also requires consideration of sustainability and the long-term operation of technology. Systems consume electricity, use physical equipment, require specialist support, and eventually need replacement or substantial redevelopment.

These costs and environmental effects vary with the technology selected. Cloud services, local infrastructure, and managed software can involve different operating arrangements, making lifecycle assessment relevant to procurement decisions.

Organisations must also consider how existing technology can be reused or adapted. Replacing a functioning system may create additional cost and disruption, while maintaining outdated infrastructure can become expensive or insecure.

The Code’s lifecycle principles encourage teams to make these decisions with a view to the service’s continuing requirements rather than only the initial delivery milestone.

GDS is inviting further feedback from architects, engineers, digital workplace specialists, cloud professionals, and teams responsible for technology spending.

The department wants examples of criteria that are difficult to apply and practical case studies that could make the guidance more useful. Future work will also examine how navigation and discoverability can be improved across government standards.

The 29 October changes have already altered the presentation and wording of the existing Code, while the broader renewal remains an ongoing programme. Subsequent updates will determine how the framework develops in response to changing technology and the experiences of public sector teams using it.