Managed IT & Buying Guidance
Updated
Do not buy an escalation promise by adjective. "Fast," "priority," and "24/7" are not operating instructions. A usable proposal defines which systems are covered, how urgency is assigned, who accepts the ticket, who can declare an incident, when specialists or vendors join, and who communicates until the situation is stable.
Turn proposal language into testable commitments
CISA's guidance for managed service provider customers recommends defining provider, customer, and shared responsibilities in the vendor agreement and requesting specific performance-related service levels before signing. NIST SP 800-161 Revision 1, Update 1 likewise addresses cybersecurity supply-chain risk across acquisition and the supplier lifecycle, supporting periodic review of provider responsibilities and escalation dependencies after contract signature. The practical implication is simple: every support claim should map to a written boundary and an accountable owner.
| Proposal phrase | What must be defined | Evidence to request |
|---|---|---|
| "24/7 monitoring" | Whether a human responds after hours, which alerts qualify, and whether remediation is included. | After-hours runbook, sample alert path, and written exclusions. |
| "Priority support" | Priority definitions, intake requirements, response target, escalation trigger, and update cadence. | Priority matrix and a sanitized incident timeline. |
| "Vendor management" | Which vendors are covered, who opens the case, who authorizes charges, and who owns client updates. | Responsibility matrix and examples of excluded project work. |
| "Unlimited support" | Covered users and systems, normal support hours, remote versus on-site work, and project boundaries. | Service Guide, Order Form, and out-of-scope approval process. |
Use a priority ladder that reflects business impact
The provider's contract controls its exact labels and targets. A buyer should still test whether the classification model distinguishes a critical outage or suspected security incident from serious degradation, routine user support, and planned requests. If every caller can mark every ticket critical, the queue cannot express real business impact.
| Priority type | Buyer question | Contract detail to locate |
|---|---|---|
| Critical | What business impact or security condition qualifies, and how is it reported after hours? | Covered emergency channel, response target, communication owner, and containment authority. |
| High | What distinguishes serious degradation from a complete outage? | Scope, business-hours treatment, escalation trigger, and workaround expectations. |
| Standard | How are normal incidents queued, updated, and closed? | Support window, intake methods, requester responsibilities, and closure process. |
| Request or planned work | When does a request become a separately approved change or project? | Approval path, scheduling rules, project boundary, and billing treatment. |
Demand one owner even when several teams are involved
Escalation often crosses the service desk, an engineer, a security partner, an internet carrier, a cloud vendor, and the client's own decision-maker. A good responsibility model does not pretend one provider controls every dependency. It identifies who coordinates the work and who gives the client the next meaningful update.
Walk through one realistic scenario before signing: the primary application is unavailable and the software vendor believes the network is at fault. Ask who opens each case, gathers logs, approves an emergency change, accepts third-party charges, and tells leadership what happens next. Compare that answer with the provider's onboarding plan, because missing access and undocumented vendors are common escalation blockers.
Treat security escalation as a separate operating path
A suspected compromise is not just a difficult helpdesk ticket. NIST SP 800-61 Revision 3 places incident response inside the full risk-management lifecycle, including preparation, detection, response, recovery, and improvement. Buyers should know whether the MSP performs initial triage or containment, when a specialist incident-response engagement begins, who preserves evidence, and who has authority to isolate an account or device.
Test those decisions before an emergency with an incident-response tabletop playbook. The exercise should expose missing phone numbers, ambiguous authority, inaccessible backups, and vendor handoff problems while there is time to fix them.
Run this checklist during proposal review
- Mark every covered user, device, server, tenant, site, and third-party system.
- Obtain the normal support window and exact after-hours channel.
- Ask what qualifies as critical and who may declare that priority.
- Locate response targets, update expectations, and stated limitations.
- Identify service, technical escalation, security escalation, and client decision owners.
- Separate remote support, on-site labor, project work, incident response, and vendor charges.
- Ask for a sample report showing aged tickets, escalations, owners, and unresolved risk.
- Confirm how lessons from serious incidents enter the next review cycle.
How Cloud Core MSP documents the boundary
Cloud Core MSP's public pages summarize capabilities; the signed agreement controls legal and business terms, the Quote, Order Form, or SOW controls selected services and commercial terms, and the current Service Guide controls priorities and operational boundaries. Compare those documents together, not a sales phrase alone. The broader MSP selection guide and guide to monthly reporting and quarterly reviews provide two other views of the operating model.
Sources and further reading
- CISA: Risk Considerations for Managed Service Provider Customers - customer due diligence, shared responsibilities, and contract considerations.
- NIST SP 800-161 Revision 1, Update 1 - supplier-risk governance across acquisition and the supplier lifecycle.
- NIST SP 800-61 Revision 3 - current incident-response recommendations aligned with Cybersecurity Framework 2.0.
- CISA and international partners: Protecting Against Cyber Threats to MSPs and Their Customers - provider-customer security practices.