A supplier can sound capable in a sales meeting yet still be the wrong fit when an ERP server fails during a production run or a shop-floor PC cannot be patched without affecting machinery. An engineering IT supplier assessment should therefore test more than technical qualifications and monthly costs. It should establish whether a provider understands the operational consequences of an IT issue, can work safely around industrial systems, and will take clear responsibility when something goes wrong.
For engineering businesses, IT is rarely confined to office desktops. It connects planning, stock control, CAD files, ERP or MRP platforms, warehouse devices, production machinery and customer information. A weak provider relationship can create slow fixes, blurred responsibilities and avoidable downtime. A thorough assessment gives decision-makers evidence before those risks become operational problems.
Start the engineering IT supplier assessment with critical operations
The first question is not, “Which technology do they support?” It is, “What must keep working for us to produce, ship and invoice?” Map the systems and dependencies that affect output. This may include ERP and MRP software, file servers holding drawings, barcode scanners, remote access, plant Wi-Fi, label printers, finance systems and the network connections used by machinery suppliers.
Ask each prospective supplier to explain how they would discover and document these dependencies during onboarding. A capable partner will want to know which systems are time-critical, what happens when they fail, who owns each application and whether a workaround exists. They should not treat every device as having the same priority.
This exercise also exposes a common weakness in generic IT support: an assumption that restarting, updating or replacing a device is always low risk. On a production site, a change to a legacy workstation, driver, network address or firewall rule can interrupt a machine interface or cause a long troubleshooting cycle with an equipment vendor. Your assessment should test the supplier’s change-control approach, not simply its ability to close support tickets.
Look for manufacturing-specific technical judgement
Engineering environments often contain equipment that cannot be upgraded on the normal desktop lifecycle. A CNC controller may rely on an older operating system. A test station may use specialist software that only runs on a particular PC. An industrial device may have limited security controls but still need network access to exchange production data.
The right answer is not automatically to remove or replace every older system. That may be impractical, costly or disruptive. The right approach depends on the operational role, vendor support position and exposure to the wider network. A supplier should be able to explain practical compensating controls, such as network segregation, restricted access, jump machines, carefully managed backups and documented recovery procedures.
Ask for examples of how they protect legacy equipment without making production less reliable. Listen for specific questions about machine vendors, supported protocols, remote-access arrangements and recovery testing. Vague assurances about applying the latest updates are not enough where updates may not be validated for an industrial environment.
Test their understanding of network separation
Office systems and shop-floor systems do not always need the same access or carry the same risk. Separating networks can limit the spread of ransomware and reduce the chance that routine office changes affect production equipment. However, segregation has to be designed around how data actually moves between systems. Poorly planned separation can prevent ERP updates reaching terminals, disrupt scanning or create unmanageable workarounds.
A credible supplier will discuss segments, controlled traffic routes, secure remote support and visibility across the network in plain language. They should be able to identify where a firewall, managed Wi-Fi, separate credentials or a jump machine is appropriate, while recognising that each control must support the working process rather than obstruct it.
Assess response commitments, not just helpdesk claims
When production is delayed, the quality of the response matters as much as the eventual fix. Ask suppliers to define what counts as a critical incident and how an issue is escalated outside routine support. A promise to respond quickly is useful only if it is backed by named processes, monitoring, clear ownership and technicians who can make decisions.
Request detail on their service levels. How quickly will they acknowledge a production-stopping incident? What happens if the first technician cannot resolve it? Will they coordinate with your ERP provider, telecoms company or machinery vendor? Is there a single point of accountability, or will your operations team be left chasing several parties?
It is also worth asking how the supplier communicates during an incident. Operations leaders need concise updates: what has failed, what is being done, whether a workaround is available and when the next update will arrive. Technical language without a clear operational impact creates uncertainty at exactly the wrong moment.
Check how they prevent repeat failures
A supplier assessment should look beyond the emergency response. Recurring Wi-Fi dropouts, repeated user lockouts and ageing server warnings are signs that the provider may be treating symptoms rather than managing the environment.
Ask how they use monitoring, patch management, asset records and regular reviews to identify risks early. The best managed IT relationships include planned improvements with priorities agreed against production risk and budget, not a stream of surprise recommendations. You should see a clear process for root-cause analysis after serious incidents, including actions, owners and timescales.
Examine cyber security through the lens of continuity
Cyber security should not be assessed as a separate compliance exercise. In an engineering business, ransomware can stop access to orders, drawings, production schedules and shared data, even if machinery itself has not been directly affected. An IT supplier needs to protect both the office estate and the paths that connect it to operations.
Ask how they handle multi-factor authentication, endpoint protection, privileged accounts, email security, vulnerability management and staff awareness. Then take the discussion further. How are backups protected from the same attack that affects live systems? How often is restoration tested? Can the business recover an ERP database, critical file share or virtual server within an acceptable timeframe?
Backups are only reassuring when recovery has been tested. A provider should be able to help set recovery priorities and objectives that reflect the cost of disruption. It may be reasonable for an archive system to take longer to restore than an MRP platform, but that decision should be deliberate and documented.
If your customers, supply chain or certifications require Cyber Essentials, ISO-aligned controls or evidence of controlled access, ask how the supplier will support that work. Be cautious of anyone who promises compliance without first understanding the scope. Compliance evidence is built from everyday disciplines: asset control, access reviews, patch records, incident management and documented processes.
Clarify commercial accountability before you appoint
Technical capability is only part of the decision. The supplier should make responsibilities, service boundaries and costs understandable. Per-device managed service pricing can make budgeting more predictable, but you still need to know what is included, what counts as project work and how changes in device numbers are handled.
Discuss supplier management directly. Engineering firms commonly rely on several specialists for ERP, CAD, telecoms, machinery and line-of-business software. Your IT partner does not have to own every application to be useful. They do need to coordinate effectively, preserve evidence and avoid passing responsibility back to your team without a plan.
A practical assessment meeting should leave you with answers to four questions: who owns the incident, who approves changes, who maintains the documentation and who drives improvements? If those answers are unclear before the contract begins, they are unlikely to improve under pressure.
Use the first 90 days as a measure of fit
Switching providers is often delayed because the existing arrangement feels familiar, even when it is not working well. A good incoming supplier should make the transition controlled: gathering credentials securely, documenting assets, reviewing backups and monitoring, identifying urgent risks, and agreeing priorities with operational leaders.
Do not judge the first three months solely by the number of tickets closed. Look for better visibility of the estate, fewer recurring disruptions, clearer reporting and a plan for the risks that cannot be fixed immediately. Some improvements, such as replacing unsupported infrastructure or redesigning a network, require staged investment. What matters is that the supplier is honest about those trade-offs and manages them without losing sight of production.
The most useful assessment question is simple: would you trust this provider to make a careful decision at 2am when a production-critical system is unavailable? The answer should come from evidence, practical questions and clear accountability, not a polished presentation.
