How Schools Should Evaluate Education Technology in 2026

The central question around technology in education has changed. Schools no longer need to ask whether digital technology belongs in education. Laptops, cloud platforms, management systems, online assessment, digital resources and learning applications are already embedded across much of the sector. The harder question is whether each product improves teaching, learning or school operations enough to justify its cost, risk and complexity.

Artificial intelligence makes that question considerably more urgent.

Generating educational content is easier. Analysing responses is easier. Personalising activities is increasingly possible. Administrative work can be automated in ways that were unrealistic only a few years ago.

None of those capabilities automatically creates educational value.

A product can be technically impressive while solving a problem a school does not actually have. Another can save ten minutes in one process while creating thirty minutes of administration somewhere else. A platform may produce detailed dashboards without helping teachers make better decisions.

The strongest EdTech decisions therefore begin with the educational or operational problem, not the technology.

That principle is increasingly reflected in official guidance.

The Department for Education's digital and technology standards for schools and colleges treat technology as an interconnected environment covering infrastructure, cyber security, filtering and monitoring, accessibility, devices, governance and digital services.

The Education Endowment Foundation's guidance on using digital technology to improve learning similarly recommends considering how technology will improve teaching and learning before introducing it, rather than allowing technology to become a solution searching for a problem.

That is a useful starting point for almost every EdTech decision.

The EdTech Evaluation Problem

Schools are presented with technology making very different claims.

A product might promise to:

• improve attainment
• personalise learning
• reduce teacher workload
• improve homework completion
• support literacy
• increase engagement
• automate assessment
• identify misconceptions
• strengthen communication with parents
• improve attendance
• simplify school administration
• support pupils with additional needs
• improve access to learning
• provide AI tutoring
• reduce administrative duplication

Those claims cannot all be evaluated in the same way.

A management information system claiming to reduce administration needs different evidence from a learning platform claiming to improve mathematics attainment.

A resource library does not need to demonstrate the same type of outcome as an adaptive learning system making strong claims about pupil progress.

Schools therefore need to evaluate four separate questions:

1. Does the product solve a worthwhile problem?
2. Is there credible evidence that it can solve that problem?
3. Can it be implemented safely and effectively in our environment?
4. Will the benefit justify the total cost and complexity?

A product should ideally pass all four.

Start With the Problem, Not the Product

One of the easiest mistakes in technology procurement is beginning with a product demonstration.

A supplier demonstrates an attractive interface, an AI feature or an impressive dashboard.

The school then begins thinking about where the product might fit.

That reverses the process.

The starting point should be a clearly defined problem.

Instead of:

We need a new learning platform.

A useful statement might be:

Teachers currently spend approximately two hours per week manually setting and checking differentiated mathematics homework, while completion varies significantly between classes.

Instead of:

We need AI.

A better statement might be:

Teachers spend substantial time creating differentiated reading material for pupils working at different levels.

Instead of:

We need better data.

A better statement might be:

Trust leaders currently wait several days for attendance information to be compiled manually from six schools.

The more precisely the problem is defined, the easier it becomes to assess whether technology genuinely improves the situation.

Establish the Current Baseline

Schools should measure the existing process before trying to improve it.

Depending on the problem, that baseline might include:

• teacher time
• pupil attainment
• homework completion
• attendance
• administrative processing time
• number of systems involved
• number of logins required
• support tickets
• cost
• parent engagement
• accessibility problems
• system downtime
• duplicate data entry
• pupil usage

Without a baseline, almost any implementation can appear successful.

If a supplier says the platform saves teachers time, the school needs to know how much time the current process takes.

If a platform claims to improve completion, existing completion rates need to be understood.

If an MIS replacement is intended to improve reporting, the school needs to document how reporting currently works.

Define Success Before Procurement

Schools should decide what meaningful success looks like before purchasing a product.

This does not need to be excessively complicated.

A school might define success as:

• reducing manual homework administration by 30%
• increasing consistent mathematics homework completion
• enabling trust leaders to access attendance information without manual spreadsheets
• reducing the number of parent communication systems from three to one
• improving access to digital material for pupils using assistive technology
• reducing duplicate pupil-data entry
• improving teachers' ability to identify vocabulary gaps
• providing reliable single sign-on across core school applications

Defining success in advance prevents the implementation from being judged primarily by usage.

High usage does not necessarily mean the product is producing value.

A system may be used every day because staff are required to use it while still creating unnecessary work.

Infrastructure Comes Before Innovation

A sophisticated learning platform is of limited value when wireless coverage repeatedly fails.

A cloud-based assessment system becomes disruptive if pupils cannot reliably access it.

AI-supported learning cannot function effectively if devices are inconsistent, filtering blocks essential services or identity management is unreliable.

The Department for Education currently asks schools and colleges in England to work towards meeting six core digital and technology standards by 2030:

• broadband internet
• wireless networking
• network switching
• digital leadership and governance
• filtering and monitoring
• cyber security

Schools can review the complete standards through the Department for Education's digital and technology standards guidance.

The standards were updated again in September 2026, including amendments relating to cyber security and online safeguarding.

This is important because the visible EdTech application sits on top of several less visible dependencies:

• broadband
• Wi-Fi
• network infrastructure
• devices
• user accounts
• identity management
• filtering
• monitoring
• cyber security
• technical support
• governance

Weakness in any of those foundations can make otherwise useful software frustrating or unreliable.

Devices Are Infrastructure Too

Schools should establish whether the devices pupils and staff actually use are suitable for the proposed product.

Questions include:

• Does the product work reliably on existing hardware?
• Which operating systems are supported?
• Does it require a modern browser?
• Does it work on tablets?
• Is there a mobile application?
• Can pupils use it effectively on smaller screens?
• Does it require a microphone or camera?
• Does it need significant local storage?
• How much bandwidth does typical use require?
• Are older devices likely to struggle?

The DfE publishes specific guidance on laptops, desktops and tablets, helping schools assess devices as part of a wider technology strategy.

Purchasing software that technically works on existing hardware but performs poorly in practice can create substantial hidden costs.

Evidence Should Match the Claim

Not every EdTech product needs a randomised controlled trial.

But the strength of the evidence should broadly match the strength of the claim.

Consider three hypothetical products.

Product A

Claims to provide teachers with ready-made classroom resources.

The relevant questions concern:

• resource quality
• curriculum relevance
• teacher usability
• accessibility
• time saved

Product B

Claims to reduce school administration.

Relevant evidence might include:

• time studies
• workflow comparisons
• implementation case studies
• reduction in duplicate work

Product C

Claims that using its learning platform improves pupil attainment.

That is a considerably stronger claim.

Schools should therefore expect stronger evidence.

A Useful Evidence Hierarchy

Schools can examine evidence at several levels.

1. Plausible product logic

Does the proposed mechanism make educational sense?

A vocabulary product that gives pupils repeated meaningful exposure to vocabulary has a recognisable educational rationale.

A platform claiming attainment gains without explaining how learning is supposed to improve deserves more scrutiny.

2. Usability evidence

Can teachers and pupils actually use the product reliably?

An educational intervention that works only under ideal conditions may struggle when introduced across an entire school.

3. Adoption evidence

Do pupils and staff use the product as intended?

Low implementation fidelity can undermine otherwise promising technology.

4. Outcome evidence

Are relevant educational or operational outcomes improving?

5. Independent evaluation

Has research been conducted independently of the supplier?

6. Comparative evidence

Have users of the product been compared against an appropriate comparison group?

7. Experimental evidence

For strong causal claims, have sufficiently rigorous experimental approaches been used?

The important point is proportionality.

Evidence requirements should reflect the importance and strength of the claim being made.

The EdTech Evidence Board

On 24 September 2026, the Department for Education published findings from the EdTech Evidence Board pilot.

The project was funded by the DfE and carried out by the Chartered College of Teaching.

It tested an independent and transparent approach to evaluating evidence behind EdTech products.

The pilot concluded that:

• independent evaluation of EdTech evidence is feasible
• independent assessment is valued
• wider work is required to improve the quality of evidence
• evidence needs to become more visible and useful to buyers

This development is significant because schools have historically had to interpret supplier evidence themselves.

Supplier-produced research is not automatically unreliable, but buyers need to understand:

• who designed the study
• who collected the data
• who analysed it
• how participants were selected
• whether unsuccessful implementations were included
• what outcome was measured
• whether a comparison group existed

A headline statistic alone tells very little.

Questions to Ask About Research

When a supplier presents evidence, ask:

• What exactly was measured?
• How was it measured?
• How many pupils or schools participated?
• What ages were included?
• When was the research conducted?
• Was there a control or comparison group?
• How were participating schools selected?
• What level of usage was required?
• Were all participating schools included in the final results?
• Who funded the research?
• Was analysis independent?
• Has the methodology been published?
• Does the research apply to pupils similar to ours?

A claim such as "schools using our platform achieved better results" means little without understanding how the comparison was made.

The Education Endowment Foundation's Position

The Education Endowment Foundation's Using Digital Technology to Improve Learning guidance makes a particularly important point:

technology is more likely to improve learning when it supports effective teaching and learning practices rather than when it is introduced simply because it is new.

The EEF's evidence review also emphasises that the conditions under which technology is used matter.

This aligns with a wider principle running throughout EdTech evaluation:

implementation is part of the intervention.

The same product can produce different outcomes in two schools because:

• training differs
• teacher engagement differs
• infrastructure differs
• pupil expectations differ
• curriculum integration differs
• leadership support differs

AI Changes Risk as Well as Opportunity

Generative AI introduces a different type of technology risk.

Traditional software usually produces outputs developers have directly designed.

Generative systems can create new responses dynamically.

That makes several issues more important:

• accuracy
• inappropriate content
• hallucinations
• bias
• manipulation
• age appropriateness
• privacy
• safeguarding
• transparency
• teacher oversight

Schools should therefore avoid treating "AI-powered" as a meaningful description.

Ask what the AI actually does.

What Does the AI Control?

AI might:

• recommend educational content
• generate lesson material
• generate questions
• mark pupil work
• provide feedback
• analyse written responses
• communicate directly with pupils
• summarise school information
• predict pupil needs
• determine learning pathways
• create reports

Those uses carry different risks.

A system that suggests worksheets to a teacher presents a different safeguarding profile from an open-ended chatbot communicating directly with a child.

DfE Generative AI Product Safety Standards

The Department for Education publishes generative AI product safety standards.

These standards are principally aimed at developers and suppliers, but schools can use them when assessing products.

They cover areas including:

• clearly stated purpose
• user safety
• privacy
• security
• transparency
• moderation
• product governance
• appropriate educational use

The standards were updated in January 2026.

Schools evaluating AI should ask suppliers to explain specifically how their product aligns with these expectations rather than accepting a general claim that the product is "safe for education".

AI Should Support Cognition Rather Than Replace It

One of the most important questions about AI in education is whether it supports the learning process or bypasses it.

Consider a pupil struggling with a mathematics problem.

An AI system could immediately provide the answer.

That may solve the immediate task while contributing very little to learning.

A better system might:

• identify the misconception
• provide a hint
• retrieve relevant prior knowledge
• show a worked example
• ask the pupil to explain a step
• reduce the complexity temporarily
• provide another similar problem

This distinction matters.

The goal of educational technology should not always be to make the task as easy as possible.

Sometimes productive difficulty is part of learning.

Teacher Oversight Must Remain Meaningful

Automated recommendations can be valuable.

They can also become opaque.

If software determines what a pupil should learn next, teachers should be able to understand enough about the recommendation to exercise professional judgement.

Ask:

• What inputs affect the recommendation?
• Can teachers see why the system made it?
• Can the teacher override it?
• Can pupils become trapped at an inappropriate level?
• How quickly does the model respond to improvement?
• Can teachers manually assign material?
• What happens when pupil data is incomplete?

Automation should extend professional capacity rather than remove appropriate oversight.

Data Protection Is Part of Product Quality

EdTech frequently processes information about children.

That makes privacy part of the product itself.

The Department for Education updated its guidance on procuring EdTech and data protection in July 2026.

The guidance stresses data protection by design and default and recommends involving the school's Data Protection Officer early in procurement.

Schools should understand:

• what personal information is collected
• why it is collected
• what lawful basis applies
• whether the supplier is a processor or controller
• where information is stored
• whether data leaves the UK
• which subprocessors receive it
• how information is secured
• how long it is retained
• what happens when the contract ends

For higher-risk processing, a Data Protection Impact Assessment may be required.

Controller and Processor Roles Matter

One issue identified repeatedly across EdTech is confusion around who controls personal data.

A supplier may initially appear to operate purely as a processor acting on school instructions.

But if that supplier uses pupil information for its own analytics, product development or AI-model improvement, its role may change.

Schools should ask directly:

• Do you use our data for any purpose beyond providing the contracted service?
• Is any data used for product development?
• Is any personal data used to train AI?
• Are analytics conducted for your own purposes?
• Are you a processor for every processing activity?

The answer should be reflected clearly in contractual documentation.

ICO's 2026 EdTech Findings

In June 2026, the Information Commissioner's Office published its EdTech examined findings.

The work followed audits conducted during 2024 and 2025 involving 28 EdTech providers whose products are widely used in UK primary and secondary schools.

The ICO reported positive practices, particularly around information security, but also identified recurring weaknesses.

These included issues around:

• suppliers incorrectly identifying whether they were processors or controllers
• insufficiently detailed contracts
• incomplete mapping of data flows
• weak data minimisation
• weak storage-limitation practices
• outdated or inaccessible privacy information
• gaps in Data Protection Impact Assessments

The ICO made 596 recommendations, with providers accepting and implementing 98% of them.

For schools, the practical lesson is straightforward:

do not assume that an established EdTech supplier has automatically resolved every data-protection issue.

Procurement still requires scrutiny.

AI and Personal Data Need Additional Attention

The DfE's procurement guidance specifically addresses artificial intelligence.

Schools should establish whether AI tools:

• generate content from pupil information
• personalise learning using personal data
• enable chatbot interaction
• conduct profiling
• make automated decisions
• use school information to improve AI functionality

Schools should also ask whether any information entered by pupils is used for model training.

That is particularly important with open-ended AI tools.

Pupils may enter sensitive information without recognising that it is sensitive.

A writing tool might receive information about:

• health
• religion
• family circumstances
• school incidents
• friendships
• behaviour

The school therefore needs to understand what happens to free-text input, not merely the basic account fields supplied when a pupil registers.

Safeguarding Cannot Be Separated From Technology Procurement

Schools have statutory safeguarding duties.

The DfE's current digital standards explicitly connect cyber security, filtering and monitoring with the responsibility to keep children safe online.

EdTech procurement should therefore involve safeguarding leads when pupil-facing functionality creates relevant risk.

Questions include:

• Can pupils communicate with unknown users?
• Can they communicate privately with one another?
• Can they upload images?
• Can they generate unrestricted content?
• Can administrators review activity?
• Are audit logs available?
• Can harmful interactions be reported?
• What moderation exists?
• How quickly can accounts be suspended?

Safeguarding controls should be demonstrated, not merely described.

Filtering and Monitoring

A school may already have filtering and monitoring technology at network level.

That does not necessarily mean every EdTech product automatically fits those controls.

Schools should determine:

• which domains the product requires
• whether encrypted traffic affects monitoring
• whether content is loaded from third parties
• whether pupils can follow external links
• whether AI functionality introduces new destinations
• whether filtering interferes with legitimate educational content

New applications should be tested inside the school's real filtering environment before full deployment.

Accessibility Is a Core Quality Requirement

Technology can significantly improve accessibility.

Digital systems can support:

• screen readers
• text enlargement
• text-to-speech
• speech-to-text
• captions
• keyboard navigation
• adjustable contrast
• alternative formats
• translation

Poorly designed digital technology can do the opposite.

A drag-and-drop activity may be impossible for a keyboard-only user.

A low-contrast dashboard may be difficult for visually impaired staff.

Uncaptioned video excludes some learners.

Timed activities can create unnecessary barriers.

The Department for Education's digital accessibility standard says digital products, content and services should be accessible and usable for everyone.

Accessibility should therefore be evaluated during procurement, not after complaints begin.

What to Ask About Accessibility

Ask suppliers:

• Do you publish an accessibility statement?
• Which accessibility standard do you test against?
• Has independent accessibility testing been completed?
• Does the interface support keyboard-only navigation?
• Is it compatible with common screen readers?
• Are videos captioned?
• Is audio transcribed?
• Can text size be increased?
• Are colour combinations accessible?
• Can timed activities be adjusted?
• Does the product support browser accessibility tools?
• How are accessibility defects prioritised?

Schools should ideally test products with representative users rather than relying entirely on supplier statements.

Integration Is Part of Usability

An excellent standalone application can still be a poor addition to a school's technology estate.

Every additional system creates potential work around:

• accounts
• passwords
• pupil enrolment
• data imports
• data exports
• reporting
• permissions
• support

Integration therefore affects workload directly.

Schools should establish compatibility with systems such as:

• the MIS
• Microsoft 365
• Google Workspace
• single sign-on
• identity-management systems
• safeguarding tools
• assessment systems
• parent communication systems
• learning platforms

If pupil accounts need to be created manually every September, that administrative cost belongs in the evaluation.

Single Sign-On Matters More Than It Sounds

Login friction is easy to underestimate.

A pupil forgetting one password may appear trivial.

Across hundreds or thousands of pupils, repeated account problems can create substantial lost learning time and technical-support demand.

Single sign-on can therefore create operational value far beyond convenience.

Schools should ask:

• Which identity providers are supported?
• Can users be provisioned automatically?
• Are accounts removed automatically when pupils leave?
• Can staff roles control permissions?
• Does multi-factor authentication apply where appropriate?

Technology Should Reduce Fragmentation

Individually useful products can collectively create a poor digital environment.

A school might have separate tools for:

• homework
• assessment
• reading
• mathematics
• communication
• behaviour
• resources
• safeguarding
• attendance

Each may work perfectly well in isolation.

Together they may create:

• repeated logins
• duplicate information
• inconsistent interfaces
• overlapping costs
• fragmented reporting
• additional support
• more contracts
• more security dependencies

Schools should therefore ask a critical question before every major purchase:

What does this product replace?

If the answer is "nothing", that is not necessarily a problem.

But it means the product is increasing the overall technology estate and should provide enough value to justify that additional complexity.

Technology Should Reduce Net Workload

Time-saving claims should be assessed across the entire workflow.

Imagine a product that automatically marks homework.

That sounds like an obvious time saving.

But suppose teachers then need to:

• create pupil accounts
• resolve forgotten passwords
• manually import class lists
• investigate syncing errors
• interpret additional dashboards
• handle parent questions

The actual workload benefit may be much smaller.

Schools should map:

before implementation

versus

after implementation

for everyone affected.

That includes:

• teachers
• teaching assistants
• administrators
• IT staff
• senior leaders
• data teams
• pupils
• parents

A technology project can reduce workload for one group while increasing it for another.

Total Cost Means More Than the Licence

Schools should calculate the total cost of ownership.

This can include:

• subscription fees
• implementation
• migration
• training
• integration
• support
• additional devices
• infrastructure upgrades
• internal staff time
• consultancy
• data migration
• renewal increases

The cheapest licence may not represent the cheapest overall implementation.

Likewise, an expensive platform can sometimes create savings if it replaces several existing systems.

Cyber Security Is a Procurement Issue

Every cloud product connected to school systems becomes part of the institution's wider security environment.

Schools should understand:

• authentication controls
• encryption
• account permissions
• audit logs
• vulnerability management
• penetration testing
• incident response
• backup arrangements
• breach notification
• supplier access

The DfE's cyber-security standard forms one of the six core digital standards schools are expected to work towards by 2030.

Cyber security should therefore be treated as part of procurement rather than something considered only by the IT team after purchase.

Ask About Security Incidents

Schools should ask suppliers:

• Have you experienced a significant security incident?
• How are customers informed about breaches?
• What is your incident-response process?
• How quickly are critical vulnerabilities addressed?
• Do you conduct external penetration testing?
• Who can access customer data internally?
• Is privileged access logged?

A supplier unwilling to discuss security processes clearly deserves additional scrutiny.

Digital Leadership and Governance

Technology choices increasingly require organisation-wide governance.

The DfE's digital leadership and governance standard recommends establishing clear roles, responsibilities and processes around digital technology.

That matters because EdTech decisions can involve:

• curriculum
• finance
• safeguarding
• SEND
• IT
• data protection
• cyber security
• teaching
• administration

No single department necessarily sees the complete impact.

Maintain a Technology Register

Schools should maintain an up-to-date record of significant digital systems.

Useful fields include:

• supplier
• product
• purpose
• system owner
• number of users
• annual cost
• contract start
• renewal date
• notice period
• personal data processed
• key integrations
• criticality
• accessibility information
• support contact

This makes it much easier to identify:

• duplicate products
• unused licences
• overlapping functions
• upcoming renewals
• unsupported systems

Pilot Before Scaling Where Appropriate

Not every product requires a pilot.

For significant or uncertain implementations, however, a structured pilot can be extremely valuable.

A useful pilot should answer specific questions.

For example:

• Can pupils use the platform independently?
• Does it integrate with the MIS?
• Does it reduce marking?
• Does the reporting help teachers?
• Are accessibility requirements met?
• How many support requests occur?

A pilot should not simply ask whether staff "liked" the product.

Avoid Pilot Bias

Pilots can produce misleading results when:

• only enthusiastic teachers participate
• unusually motivated pupils are selected
• supplier support during the pilot is far greater than normal
• implementation is too short
• success criteria are vague

Schools should design pilots around realistic conditions.

Measure Adoption Properly

After launch, schools should distinguish between:

• accounts created
• logins
• active usage
• meaningful educational use

A pupil logging in once is not adoption.

A teacher opening a dashboard is not necessarily meaningful use.

Where possible, measure usage related directly to the intended objective.

Implementation Requires Change Management

Technology implementation is partly a human process.

Staff need to understand:

• why the product is being introduced
• what problem it solves
• what will change
• what will stop
• what support is available
• what is expected from them

Simply sending login details rarely produces effective implementation.

Training Should Match Roles

Not everyone needs identical training.

A classroom teacher may need to understand:

• setting work
• viewing pupil progress
• handling common problems

An administrator may need:

• account management
• imports
• permissions

Senior leaders may mainly need:

• reporting
• strategic data
• evaluation

Role-specific training is generally more useful than a generic product tour.

Renewal Should Be an Evaluation Point

The easiest contract to renew is the one already in place.

That can allow technology estates to grow indefinitely.

Every significant renewal should prompt questions such as:

• Is the original problem still present?
• Has the product improved it?
• How many users are active?
• What does the product now cost?
• Has functionality changed?
• Is there overlap with another system?
• What happens if we cancel?
• Is the supplier still the right choice?

Renewal should not be automatic simply because implementation happened several years earlier.

Exit Planning Should Begin Before Purchase

Schools should understand how they can leave a service before entering it.

Ask:

• Can we export all information?
• In what format?
• How long will export access remain available?
• What assistance is available during migration?
• When will supplier copies be deleted?
• Which information must legally be retained?
• Can integrations be disconnected cleanly?

Vendor lock-in becomes most painful when exit planning was never considered.

A Practical EdTech Evaluation Framework

A useful school evaluation process can follow these stages.

1. Define the problem

Describe the educational or operational issue clearly.

2. Establish the baseline

Measure the current process, workload, outcome and cost.

3. Define success

Agree what meaningful improvement would look like.

4. Identify requirements

Separate essential requirements from desirable features.

5. Review infrastructure

Check devices, connectivity, wireless coverage and technical dependencies.

6. Examine evidence

Assess whether evidence supports the claims relevant to your problem.

7. Review data protection

Map personal-data flows and involve the DPO where appropriate.

8. Assess safeguarding

Review communication, content, monitoring and pupil-facing features.

9. Evaluate accessibility

Test the experience for users with different access needs.

10. Examine integration

Understand how the product connects with existing systems.

11. Assess security

Review authentication, permissions, incident response and supplier security.

12. Calculate total cost

Include implementation, training, integration and internal staff time.

13. Pilot where appropriate

Test under realistic conditions with clear success measures.

14. Plan implementation

Assign ownership, training, communications and support.

15. Measure adoption

Check whether the product is being used meaningfully.

16. Measure impact

Compare results with the original baseline.

17. Review regularly

Do not wait until renewal day to decide whether the product is working.

A Simple Decision Matrix

Schools can score potential products against criteria such as:

The purpose of scoring is not to create false precision.

It is to force decision-makers to consider areas that may otherwise be overshadowed by a compelling demonstration.

Questions Schools Should Ask EdTech Suppliers

Purpose and outcomes

• What specific problem is the product designed to solve?
• Which user groups is it designed for?
• What outcomes should reasonably improve?
• How should we measure success?

Evidence

• What independent evidence supports your principal claims?
• Can we review the methodology?
• Who funded the research?
• How many schools participated?
• What usage was required to produce the result?

Curriculum

• Which curricula are supported?
• How frequently is content reviewed?
• Who creates educational content?
• Can teachers modify or override recommendations?

Artificial intelligence

• Where is AI used?
• Which models power the system?
• What data enters those models?
• Is school data used for model training?
• How are hallucinations managed?
• How is harmful output filtered?
• Can teachers monitor AI interaction?
• Can automated decisions be overridden?

Data protection

• What personal information is collected?
• What is the lawful basis?
• Are you acting as processor or controller?
• Which subprocessors are used?
• Where is information stored?
• Is information transferred internationally?
• What is your retention policy?
• How is information deleted?

Safeguarding

• Can pupils communicate with other users?
• Can pupils interact with open-ended AI?
• What moderation exists?
• Are audit trails available?
• How are safeguarding incidents escalated?

Accessibility

• Do you publish an accessibility statement?
• What accessibility testing has been completed?
• Is keyboard navigation supported?
• Are screen readers supported?
• Are video captions available?
• Can timing requirements be adjusted?

Integration

• Which MIS platforms do you support?
• Do you integrate with Microsoft 365?
• Do you integrate with Google Workspace?
• Is single sign-on available?
• Can user provisioning be automated?
• Are APIs available?

Security

• Is multi-factor authentication available?
• Is customer information encrypted?
• Do you perform penetration testing?
• How quickly are vulnerabilities patched?
• What is your incident-notification process?

Implementation

• How long does implementation typically take?
• What work must our staff complete?
• What migration support is included?
• What training is provided?
• Who supports us after launch?

Commercial terms

• What is included in the licence?
• Are implementation charges separate?
• Are integrations charged separately?
• What is the contract term?
• Does it renew automatically?
• How are annual increases calculated?
• What is the notice period?

Exit

• Can all customer data be exported?
• Which format is used?
• How long does export access remain after cancellation?
• When is customer information permanently deleted?
• What migration support is available?

Common EdTech Procurement Mistakes

Several mistakes appear repeatedly.

Buying features instead of solving a problem

A long feature list is not a strategy.

Ignoring implementation

An excellent product with poor implementation can create little value.

Measuring logins rather than outcomes

Usage matters, but it is not the same as impact.

Underestimating data protection

Children's personal information deserves particularly careful scrutiny.

Treating accessibility as an afterthought

Accessibility problems discovered after purchase can exclude users and create expensive remedial work.

Assuming integration will be straightforward

Ask suppliers to demonstrate integrations that matter to your environment.

Ignoring exit arrangements

Data portability matters before the contract starts, not only when it ends.

Continually adding software

Technology estates should sometimes shrink.

Author's Take

Education technology is at its strongest when it becomes almost unremarkable.

The wireless network works.

The pupil can log in.

The resource is accessible.

The teacher can see the information that matters.

The system removes unnecessary work.

The technology helps a learner practise exactly what needs practising.

None of those outcomes requires the product to feel futuristic.

That is worth remembering during the current AI cycle.

Artificial intelligence is making educational software dramatically more capable, but capability and value are not the same thing.

A system capable of generating 10,000 questions does not mean a pupil needs 10,000 questions.

A dashboard containing hundreds of metrics does not necessarily help a teacher make better decisions.

A chatbot capable of answering almost any question does not mean providing the answer is educationally desirable.

The difficult questions in education remain surprisingly familiar.

What should pupils know?

What do they understand already?

Where is the misconception?

What should they practise?

What feedback will help?

When should the teacher intervene?

Technology becomes valuable when it helps schools answer those questions more effectively or removes unnecessary work around them.

The strongest EdTech purchase is therefore rarely the one with the most features.

It is the one where the school can clearly explain:

the problem we had, why this product was chosen, what changed after implementation and whether the improvement justified the cost and complexity.

That is also why evidence, infrastructure, data protection, accessibility, safeguarding, implementation and teacher workload should not be treated as separate procurement checkboxes.

Together, they determine whether technology actually works in the environment where education happens.

Schools comparing individual suppliers can also consult our guide to the best education technology companies in the UK.