Managed IT & business technology support

The scope is the product, not the tooling

Two providers can run the same remote monitoring platform and deliver completely different services, because the platform is not what you are buying. What you are buying is a division of responsibility: which named tasks a provider performs, on which systems, during which hours, with what evidence, and which stay with your own staff. The service-management vocabulary for those tasks is public, and using it shortens the conversation. A service desk is the single point of contact where an issue, query or request is acknowledged, classified, owned and actioned. Incident management restores normal service as quickly as possible; problem management reduces how often incidents recur by finding their causes; change enablement assesses risk, authorises changes and manages the change schedule; and service request management handles the pre-defined, user-initiated requests that are not failures at all, such as onboarding an account. Fully managed places most recurring operating work with the provider. Co-managed splits it, usually keeping strategy, procurement and line-of-business applications internal. Project work is defined by a deliverable and an acceptance test. Break-fix is the narrowest of the four: work begins when something fails and nothing is watched in between. Naming which of those you are buying, in the first paragraph of a proposal, is the fastest way to tell whether it answers your question or restates the provider's product list.

• Fully managed: recurring operating work sits with the provider.
• Co-managed: an explicit split, written down and measured.
• Project services: a deliverable, an acceptance test and a handover.
• Break-fix: reactive only, with nothing monitored between failures.
• Use the practice names — incident, problem, change, request, service desk — in the contract.

Count what you own before you talk to anyone

Support is staffed and priced against counts, so the counts have to be yours rather than the provider's estimate from a walk-through. Collect users, endpoints by type, servers and network devices, sites, and the line-of-business applications that keep revenue moving. Record which systems are the source of record and who inside the business may approve a change to them. This is not only procurement preparation: the same inventory is what a security control baseline is built on, and the control catalogues say so. NIST's control set gives a baseline configuration its own control, CM-2, and a system component inventory its own, CM-8 — meaning that in an assessed environment an out-of-date asset list is a finding, not an untidiness. Where staff work away from a desk, separate them from desk users, because shared devices and shift patterns change the support model. The most useful internal exercise is to write down what consumes staff time now: hours a month spent on password resets, onboarding, printer and Wi-Fi complaints, and chasing vendors. That list is what you are buying back, and it is the same baseline you will measure the provider against ninety days in.

• Users by role, then endpoints by type, then servers and network equipment.
• Sites, including any premises with no staff permanently on site.
• The applications that cannot stop, and who approves changes to them.
• Hours a month currently lost to resets, onboarding and vendor chasing.
• Treat the asset list as a maintained control, not a one-off discovery exercise.

A standard to put in the contract, not just a promise

Most managed-service disputes are not about competence; they are about what was promised and never written down. There is a published standard for the provider side of that gap. ISO/IEC 20000-1:2018 sets out the requirements for an organisation to establish, implement, maintain and continually improve a service management system, covering the planning, design, transition, delivery and improvement of services. Its value to a buyer is not certification as a badge; it is that a service management system has to be defined, documented and maintained, which means the provider can produce the documents rather than describe them in a meeting. Ask for the service catalogue, the severity matrix, the change process and the last internal audit or improvement review. Pair that with the accountability question from the other direction: in NIST's Cybersecurity Framework the Govern function exists precisely to place risk-management expectations and policy with the organisation, which means the business keeps ownership of the decisions even where the operation is delegated.

• ISO/IEC 20000-1:2018: a service management system that must be maintained, not just declared.
• Ask for the service catalogue, severity matrix and change process as documents.
• Ask when the system was last internally audited and what changed as a result.
• Governance stays with the business even where operation is delegated.

Make response and resolution promises testable

Response time and resolution time are different promises and they are routinely conflated. Response is the clock from ticket creation to a human acknowledging and beginning work. Resolution is the clock to the service being usable again. A proposal should state both, define severity by impact rather than by the caller's mood, and say which hours the clock runs in. Business-hours coverage excludes evenings and weekends, so a four-hour response promise during business hours is four hours inside a window of roughly two to three thousand hours a year rather than all 8,760 of them. Ask what happens at the boundary: whether after-hours work is included, billed separately or simply not covered. Then ask for the previous quarter's measured performance against those promises, because a target nobody measures is marketing. Incident handling is a named control in its own right — IR-4 in NIST's control set — and the framework's incident practice is built around restoring service quickly, so the agreement should say which of those two promises each severity level carries.

• Response (acknowledged and started) versus resolution (usable again).
• Severity defined by impact, not by who is complaining loudest.
• Which hours the clock runs in, and what happens outside them.
• Last quarter's measured figures, not just the target.

Patching and vulnerability work is a cadence, not an event

Patching is the task most often described in a proposal as 'included' and least often described as a schedule. Ask for the cadence by system class — operating system, firmware, hypervisor, network device, line-of-business application — and for the exception process, because some patches cannot be applied inside the window and the question is what happens to those. NIST's enterprise patch management guidance, SP 800-40 Revision 4, treats patching as a repeatable process of identifying, prioritising and deploying rather than a monthly event, and the control set splits the work across two controls a provider should be able to evidence: SI-2 for flaw remediation and CA-7 for continuous monitoring. In practice the evidence is a report of what was deployed, what failed, what is still open and how long it has been open. An open item with a date attached is management; an open item with no owner is exposure nobody is tracking.

• A stated cadence per system class, not a single monthly window.
• A named exception route for patches that cannot be applied on schedule.
• SI-2 flaw remediation and CA-7 continuous monitoring as the evidence split.
• A monthly report of applied, failed and ageing open items, with owners.

Identity is where most incidents start

Across small and mid-sized businesses the recurring failure is rarely exotic malware; it is a credential. A reused password, an administrator account without a second factor, a departing employee whose access outlives their employment, a shared login nobody can attribute to a person. NIST's digital identity guidance treats authentication assurance as a design decision rather than a product, and its control set gives account management and personnel termination their own identifiers, AC-2 and PS-4, because offboarding is a control activity and not an administrative afterthought. The scoping questions are unglamorous: who holds administrative rights, whether every admin account is separated from day-to-day use, how a new starter's access is provisioned, how quickly a leaver's access is removed, whether service accounts are documented, and whether a break-glass account exists with its credentials stored somewhere you control. If your provider administers a Microsoft 365 tenant, ask how that access is held: the modern partner model, granular delegated admin privileges, grants least-privileged, granular and time-bound roles that the customer must explicitly consent to, with access measured in days, rather than the older delegated admin privileges model that handed over a broadly privileged role.

• Every administrator account separated from everyday use.
• A documented leaver process with a stated removal window.
• Break-glass credentials held by the business, not only by the provider.
• Tenant administration granted as time-bound, least-privileged delegated roles.
• A named owner for periodic access reviews.

Backup is a promise until something is restored from it

Backup is the responsibility most often assumed to be covered and least often tested. The two questions that decide whether a business survives an incident are recovery time objective, meaning how long the service can be down, and recovery point objective, meaning how much data can be lost measured in time. Both are business decisions rather than technical ones, and both should be written per system, because payroll and a print server do not warrant the same treatment. Ownership matters as much as technology: a provider may operate the backup platform while your business still owns the decision about what must be recoverable and the duty to prove that it is. Ask when the last restore test happened, what was restored, who performed it and what the result was. A backup that has never been restored is a hypothesis, not a control.

• RTO and RPO per system, agreed by the business rather than by the provider.
• Who operates the backup platform and who owns the recovery decision.
• Date, scope and outcome of the most recent restore test.
• A written restore procedure held where you can reach it without the provider.

Keep the accounts, the documentation and the exit

The most common regret after a support relationship sours is discovering that the provider holds the keys: the domain registration, the tenant administrator role, the DNS records, the only copy of the network diagram. Administrative ownership should sit with the business from day one, with the provider holding a delegated role that can be revoked as easily as it was granted. Documentation — asset list, network design, licence entitlements, circuit details, vendor contacts — belongs in the agreement as a deliverable rather than as a favour at the end, and it belongs in your own repository, not only in the provider's tooling. Agree the exit terms while the relationship is still good: a stated handover period, the format your data will be provided in, and what happens to monitoring agents and tooling installed on your equipment. Then test the arrangement once, by having your own staff member perform an administrative task the provider normally performs. Buyers who reach this point usually find the next decision is where the boundary of the managed service ends: identity and security tooling, backup and recovery, and the connectivity underneath are commonly priced as separate lines, so it is worth establishing which of them the agreement actually covers before assuming any of them is included.

• Domain, DNS and tenant administration held by the business.
• Provider access as a delegated role, revocable without negotiation.
• Documentation delivered as a deliverable and kept in your own repository.
• Exit terms at signature: handover period, data format, tooling removal.
• Check whether security, recovery and connectivity sit inside or outside the scope.

PUT THE OPTIONS SIDE BY SIDE

Your comparison checklist

Common questions