IT Support Standards – what good looks like in practice.

In November 2025 the Department for Education added a new section on IT support to its Meeting digital and technology standards in schools and colleges guidance. It isn’t one of the six core standards to be met by 2030, but the expectation is clear: schools and colleges should already be meeting it or working towards it.

At first glance it might look like one of the less demanding standards. There are no technical specifications and no equipment to buy. In practice, though, it touches almost everything an IT service does. It also asks senior leaders to take a much closer interest in how IT support is planned, measured and reviewed than many do at the moment. Having carried out a number of IT support reviews for colleges and academy trusts, I’d suggest few organisations would meet every element of it today.

In this piece, we look at what the standard asks for, where support services commonly fall short and what good looks like in practice.

Who the standard applies to

The standard uses “IT support” to mean the person or team responsible for making sure digital technology works reliably, is secure and stays up to date. That could be an internal team, an external provider or a hybrid of the two, and the standard applies equally to all of them. This is an important context to internalise for those who outsource or are considering outsourcing some or all of the IT support function. Outsourcing does not outsource the responsibility and requirement to meet the DfE standards including IT Support.

This matters because it removes a common assumption, which is that an outsourced service is the supplier’s problem. If your IT support is delivered under contract, the standard still expects your SLT digital lead to set expectations, monitor performance and review it every year. Where there is no internal IT support at all, the digital lead is expected to coordinate the third parties directly. This should be part of the normal cycle of contract reviews but I have seen several cases where once established, the IT provider is left to their own devices until something goes wrong.

What the standard covers

The standard is split into five parts:

• Helping you meet the other standards. IT support should understand the digital and technology standards, and make sure day-to-day activity and planning decisions keep you compliant.
• Maintaining and improving your technology. Keeping systems patched, monitored, backed up and documented, and helping to plan upgrades in line with the digital strategy.
• Being responsive and meeting agreed expectations. Clear service levels, proper support channels, recording and tracking every request, and making good use of capacity.
• An annual review. A formal, written review of IT support, led by the digital lead and reported to governors or the trust board.
• Guidance and training. Induction and refresher training for staff, plain English self-help guidance and up-to-date technical documentation.

Rather than work through each part line by line, it’s more useful to look at where the gaps usually are.

Where services commonly fall short

Requests that never get logged. The standard is quite direct on this. Staff should avoid raising support requests through unofficial channels such as instant messages, and in-person requests should be recorded and tracked formally. In most colleges and trusts I’ve worked with, a significant share of the real workload arrives by other routes: Teams messages, a phone call to a favourite technician, or someone stopping a member of the team in the corridor. The work gets done, often quickly, but it never appears in the numbers. The result is a service desk report that understates demand, a team that feels stretched with no evidence to show why, and no way to spot the recurring problems that drive the work. Changing this is as much about culture as process, and it needs visible backing from senior leaders, not just the IT team asking nicely. Indeed in many cases it is the desire of the IT team to be helpful that allows these practices to persist, saying no isn’t something they feel comfortable with, either from a service point of view or because they feel they would not be supported by senior leaders who would see such responses as negative, rather than an attempt to change culture.

Ticket data that isn’t used. Even where everything is logged, the data often doesn’t tell you much. Categories are too broad or used inconsistently, priorities are left at the default, and tickets are closed without a meaningful resolution note. The standard lists what should be recorded for each request. It also expects the digital lead to use those records to monitor demand, identify recurring problems and highlight outdated technology. That only works if the data is good enough to trust. Tidying up categories and priorities is one of the simplest and most valuable things a team can do ahead of its first review.

Similarly, ticket data should be used as an aide for the IT team for future developments. This means tickets are closed with information as to what was done to resolve the issue, with a knowledge base entry where appropriate. Even in the absence of a full knowledge base entry, sufficiennt detail that should the ticket be reopened, any team member can see what has already been included in the fault-finding to avoid starting again from scratch.

Service levels that measure the wrong thing. Many service desks measure response times well and resolution times less so. Others have SLAs in a supplier contracts that nobody internally has read since it was signed. The standard asks for clear, recorded expectations for both response and resolution, with priorities that reflect the impact on teaching and learning and on core systems like the MIS. It also suggests a useful test: how long could the organisation keep running if a critical system, such as the MIS or the internet connection, was unavailable? The answer should shape the priority levels and the support hours you pay for, rather than the other way round.

Once established, these service levels and prioritisation metrics shouldn’t be some secret held only by the IT Team or senior leaders, they should be clearly identified and published for the whole organisation to see and understand. Alongside this should be the escalation process to follow if the service hasn’t met the users expectations. Here there does need to be some support from senior leaders for when escalation doesn’t alter the outcome – for example if someone is escalating because they feel their issue hasn’t been dealt with quickly enough but the call is still within the agreed SLA.

Planning for the peaks. The standard calls out the start of the academic year and exam periods as times of high demand. For colleges, enrolment and induction add thousands of new accounts, devices and questions in the same few weeks, often alongside apprenticeship starts and staff changes. Most teams know this is coming. Fewer plan for it formally with extra staffing, change freezes on critical systems and self-help guidance prepared in advance. The previous year’s ticket history is the best planning tool you have here. This doesn’t mean extra people, it means forward planning and expectation setting alongside removal of non-essential workloads.

Knowledge held in people’s heads. IT support is expected to keep user and technical documentation up to date, including system configurations for business continuity. In smaller teams especially, much of this knowledge sits with one or two long-serving people. That’s a real risk, and it becomes very visible during a cyber incident or when a key member of staff leaves.

Lack of documentation is a recurring theme with clients that we have worked with and it is rarely an intentional act. More common it simply didn’t get written at the time a change was made or a new system was introduced and before anyone had a chance to do it the next big thing had made an entrance. This can be equally true with systems that are implemented by a 3rd-party. Unless time is allocated to document new developments and ongoing changes it won’t happen for either internal or external project.

Third parties that nobody coordinates. The MIS, the MFD fleet, the finance system, telephony and the wireless network may each have their own supplier and support arrangements. The standard expects internal IT support to coordinate that activity. It also expects a record of every IT support service in use, who provides it and what it covers. In practice, contracts are often held in different departments, and renewal dates are tracked in someone’s calendar, if at all. Bringing this together links naturally to the contracts and asset registers in the digital leadership and governance standard.

Not only does this leave gaps in support, it also leads to cliff-edge procurement where a system “suddenly” comes to end of contract without enough time to run a meaningful procurement. Again, centrally held contracts and asset registers can help develop a longer term view on what needs procuring when and based on likely value, time to procure can be built in.

Capacity that is assumed rather than tested. The standard deliberately avoids setting staffing ratios, and I think that’s the right call. A headline number of technicians per device or per user says little on its own. Demand depends heavily on the age of the estate, how well it’s managed and how many requests could be avoided. The standard asks instead whether capacity matches demand, and whether that demand can be reduced. It gives some sensible examples:

• letting staff reset their own passwords
• automating repetitive tasks
• replacing technology that generates repeated requests
• targeting training where problems come from user error.

It also suggests a hybrid approach, supplementing the in-house team with specialist providers for complex or occasional needs such as cybersecurity or network upgrades. The internal team can own the activity without having to do the work.

Getting ready for the annual review

The annual review is the part of the standard that will feel newest for many organisations. It should be led by the SLT digital lead and carried out alongside the wider digital strategy review. The findings should then be written up and shared with SLT and with other stakeholders dependent on context.

The standard sets out what the review should cover. In my experience, these are the building blocks worth putting in place well before the review is due:

• Twelve months of reliable ticket data, broken down by month, category and priority, with performance against the agreed service levels. Personally I feel this should be published monthly by default anyway.
• A list of the top recurring issues and the systems or devices behind them.
• User feedback, whether from ticket surveys or a short annual questionnaire for staff and, where relevant, students.
• An up-to-date record of IT support services and contracts, including informal arrangements that may never have been properly contracted.
• A skills and capacity view of the team, covering current training, gaps and single points of knowledge.
• A value for money check on external support. The standard is clear that value for money doesn’t necessarily mean the lowest cost, but it does expect you to check whether other suppliers could offer better value or services in an alternative and more effective format.

A good review doesn’t need to be long, as long as it is honest and well evidenced. Two or three pages with a handful of charts and clear recommendations will usually serve governors far better than a lengthy report. The key is that the findings lead to decisions, whether that’s additional investment, a change of approach at contract renewal or a targeted training plan.

A quick self-check

If you want a quick sense of where you stand, these questions are a good place to start:

• Do we have agreed, written expectations for how quickly issues are responded to and resolved?
• Are all support requests logged, including those made in person or by message? Do we push back where requests are not through the desired route?
• Could we produce a report on last term’s demand and performance without a lot of manual work?
• Do we know every IT support arrangement we rely on, who provides it and when it renews?
• Is our technical documentation good enough for someone else to rebuild a critical system?
• Did we plan specifically for the start of this academic year, and do we know how it went?
• Has IT support been formally reviewed in the last year, and did governors see the findings?

If the answer to several of these is “no” or “not sure”, the standard is a useful prompt to put things right.

Final thoughts

The IT support standard doesn’t ask for anything unreasonable. Most of it is what a well-run service desk has always aimed to do. What changes is the level of senior oversight expected, and the need to evidence it each year. For IT teams, that is a real opportunity. Good data and a clear annual review are the best way to show the value of the service and to make the case for the resources it needs.

---

If you’d like an independent review of your IT support against the DfE standard, or help putting the building blocks in place ahead of your first annual review, please get in touch.