A managed IT service should make responsibility visible across everyday support and the technology risks behind it. Compare providers by asking who owns users, devices, Microsoft 365, security, backup, recovery, suppliers and future changes,not by relying only on a list of tools or a single monthly price.
Support, priorities and communication
Start with the experience of the people asking for help. A service description should make clear which channels are available, which services are eligible, how impact is assessed and how users receive updates. It should explain the distinction between a human acknowledgement, an engineer engaging with the issue and later progress communication. These definitions allow a business to understand what it is buying and allow a provider to operate the same way when pressure is high.
Ask what happens when an issue involves a third-party supplier, an application outside the provider’s direct control or a change that needs approval. A managed service does not remove every dependency, but it should establish who coordinates the next step and who communicates with the business. Review the proposed service levels with the agreement and service schedule; the applicable commitments are the written ones for eligible services, rather than generic wording on a website.
- Telephone, email, portal and secure remote support routes.
- Priority definitions based on impact, risk and available workarounds.
- Communication, escalation and supplier-coordination responsibility.
- Service reporting and a route for discussing recurring problems.
Users, devices and routine administration
People, accounts and equipment change constantly. Check how the provider handles joiners, leavers, role changes, laptop setup, shared devices, mobile access, licence records and asset information. The aim is not a complicated process for every small task; it is clear ownership so an account is not left with access it no longer needs and a device is not left unpatched or unsupported because nobody is responsible for it.
Ask whether the service includes monitoring, patching, device-health oversight and secure remote assistance for the agreed devices. Confirm the distinction between an included operational task and a separately scoped replacement, repair or project. NCSC guidance for small organisations supports practical measures such as keeping devices and software current, managing access and knowing who is responsible. Those controls work best when everyday administration is part of the service rather than an afterthought.
- Joiner, mover and leaver access processes.
- Asset, ownership and licence visibility for agreed equipment.
- Patching, monitoring and health oversight for supported devices.
- Clear approvals for replacement hardware and non-routine changes.
Microsoft 365, identity and collaboration
Microsoft 365 often carries email, files, identity and collaboration, so it needs accountable administration. Confirm who manages users, licences, shared mailboxes, groups, Teams, SharePoint, OneDrive and routine permission changes. Consider how external sharing, guest access and administrator roles are governed. The provider should be able to explain which tasks are included in normal administration and how larger configuration changes are assessed and approved.
Identity is the control that connects the service together. Ask how multi-factor authentication, recovery details, privileged roles and access reviews are handled. Record the owner of emergency accounts and the procedure for a change in staff or supplier. A useful service also considers the user experience: people need straightforward guidance for secure access and a known support route when a change is required, otherwise workarounds can undermine the intended controls.
- Microsoft 365 tenant, licence and user administration.
- Email, Teams, SharePoint and OneDrive ownership boundaries.
- Multi-factor authentication, recovery and privileged-role control.
- External sharing, guest access and periodic permission checks.
Security, recovery and incident readiness
Security should be visible in routine responsibilities, not presented as a separate product list with no operating owner. Compare the provider’s role in endpoint protection, alert handling, email security, access administration, patching and risk communication. Then ask what applies to backups: whether jobs are monitored, who owns the backup configuration, which data is covered, who receives failure alerts and how restores are requested or tested.
Recovery planning starts with business priorities. The business should identify the systems and information it cannot do without, while the provider should explain the technical dependencies and practical recovery steps. NCSC guidance encourages small organisations to prepare for response and recovery rather than assume preventative controls eliminate every incident. A service checklist should therefore include contacts, escalation, documented recovery information and a way to improve the plan after a disruption or restore exercise.
- Endpoint, email, identity and patching responsibilities.
- Security alert ownership, escalation and decision-making route.
- Backup scope, monitoring, failure notification and restore process.
- Incident contacts, recovery priorities and documented next steps.
Planning, documentation and commercial clarity
A managed service should give the business a route to improve technology without making every discussion a crisis. Ask how recurring issues become actions, how risks and lifecycle needs are recorded and how technology reviews or roadmap discussions are approached. The goal is a shared view of priorities, dependencies and investment decisions. It is also useful to understand how the provider coordinates other suppliers and where the customer needs to make decisions.
Finally, compare the commercial boundaries. Confirm what the recurring service includes, what is separately priced, how projects are scoped, who owns documentation and how exit support is handled. The best checklist is one you can use to test the written proposal line by line. It should leave both sides clear about the responsibilities that are included now and the process for agreeing work when the environment or business needs change.
- Regular technology discussion, risk visibility and action ownership.
- Documentation and supplier responsibility that remain accessible to the business.
- Project, onboarding and change-control process for separate work.
- Written inclusions, exclusions, assumptions and exit arrangements.
Use the checklist throughout the relationship
The checklist is most useful when it supports ongoing conversations, not only a provider selection exercise. Revisit it when the organisation adds people, opens a site, adopts a service, changes suppliers or experiences a material incident. This helps both parties identify whether the agreed scope still matches the environment and whether a responsibility or risk needs to be clarified before it becomes a support problem.
Keep the questions proportionate to the organisation. A smaller business may need one named owner and a concise action list, while a more complex environment may need clear service ownership across several teams and suppliers. In either case, the result should be understandable: the business knows who does what, what information is needed and how a gap becomes a decision or agreed action.
- Revisit after people, service, supplier or site changes.
- Keep ownership and actions understandable to the business.
- Use new risks to update scope or planned work.
- Record decisions before they become urgent support issues.
A checklist cannot replace a service schedule
This guide helps compare responsibilities, but it does not establish service commitments or technical suitability. Use it with a current inventory, risk priorities and the provider’s written agreement and service schedule.
How to compare two managed IT proposals
Give each provider the same requirements, then compare their written answers to the following practical questions.
- Who owns day-to-day support, administration and supplier coordination?
- Which users, devices, services and security activities are included?
- How are recovery responsibilities and backup boundaries documented?
- What is the approval route for changes, projects and charges outside scope?