IT Support SLA Checklist: What SMBs Should Require

A service agreement can promise fast support while leaving the most important questions unanswered: Who takes ownership when payroll stops? Does an automated acknowledgment count as a response? What happens when the cloud vendor, not the MSP, controls the fix?

For an SMB, an effective IT support service level agreement, or SLA, turns those questions into operating rules. Before signing or renewing, require a written service scope, business-impact priorities, measurable milestones, named responsibilities, and evidence that both parties can review. Choose the targets only after those definitions are clear.

This checklist is ITECS’s buyer-oriented analysis, not a set of standard ITECS contract terms or legal advice. Use it with your business owners, internal IT team, provider, and legal adviser to develop commitments appropriate to your organization.

Start with risk and service management—not a response-time slogan

CISA’s September 2021 Risk Considerations for Managed Service Provider Customers explains why outsourcing does not remove an organization’s responsibility for managing risk. It encourages explicit provider/customer responsibilities and specific service expectations before contracting.

The joint May 2022 CISA and international-partner MSP advisory reinforces contractual clarity about included and excluded services, security responsibilities, incident notification, and tested response and recovery arrangements. These are security-risk recommendations, not universal response-time guarantees.

ISO/IEC 20000-1:2018 supplies a complementary service-management perspective: plan and manage services across their lifecycle, measure delivery, and improve it. ISO’s public catalogue identifies the standard as current, confirmed in 2023, with a 2024 amendment. This article uses that public scope; it is not a clause-by-clause interpretation of the paid standard or a claim of certification.

1. Name the business services and the boundaries

“All IT support” is not a usable scope. List the locations, users, devices, applications, cloud tenants, and business processes covered. Identify unsupported systems, project work, onsite travel, security incident work, and vendor services that require separate authorization.

Connect technology to its purpose: the warehouse’s order system, accounting’s payment run, or the phones used for customer bookings. For each service, identify the business owner, dependencies, supported operating conditions, and acceptable workaround. A contract for endpoint support does not automatically include recovery of every application running on those endpoints.

Compare the written scope with the selected managed IT plan and coverage, not just a marketing feature list. Record customer duties too: maintaining supported software, approving changes, supplying access through approved channels, and keeping an emergency decision-maker available.

2. Set priorities by impact and urgency

Do not let the loudest caller—or an unexplained “urgent” checkbox—determine the queue. Agree how lost business capability, affected users, security exposure, deadlines, and available workarounds influence priority. A single affected user can still represent a critical business function.

• Critical incident example: a core business process is unavailable with no acceptable workaround, or a suspected active compromise needs immediate security triage.
• Degraded service example: work continues, but a material function is impaired or the workaround is fragile.
• Routine request example: a planned access request or low-impact issue can be scheduled without interrupting essential operations.

These are illustrative categories, not prescribed priority definitions. Document who can assign or change priority, the evidence required, how disputes are escalated, and whether the original clock remains visible after reclassification. Give security incidents their own escalation path rather than relying solely on user-count thresholds.

3. Define response, restoration, and resolution separately

Three milestones answer different questions. Ask the provider to define each in the agreement and in its ticket reports:

• First response: a responsible person reviews the issue, makes meaningful contact, and establishes the next action. Specify whether automated acknowledgments are excluded.
• Service restoration: the agreed business capability becomes usable again, potentially through an approved workaround. Record any limitations and who validates usability.
• Resolution: the incident meets agreed completion criteria. Permanent root-cause work may remain in a separately owned problem record; ticket closure must not conceal that work.

These milestones are not interchangeable, and some incidents reach restoration and resolution together. A quick reply does not prove a recovered service. Likewise, restoring access does not prove that recurring faults or security risks have been eliminated.

4. Specify support hours and the clock rules

Write down the time zone, business days, holidays, after-hours contact method, covered priorities, and any callout charges or approval requirements. Distinguish monitoring availability from staffed response, remote assistance, onsite attendance, and project delivery. “24/7 monitoring” alone does not define all of them.

For each priority and milestone, complete this clock checklist:

• Start: which event starts measurement—an accepted monitoring alert, a call to the emergency number, or receipt through an approved ticket channel?
• Calendar: is elapsed time measured continuously or only during the purchased support window? What happens to a ticket received just before closing?
• Pause: which specific customer action or dependency justifies a pause, who approves it, and what timestamped evidence is required?
• Resume: how is the provider notified that the dependency is cleared, and when does measurement restart?
• Stop: what objective response, usability test, or completion evidence ends each clock?
• Reopen: how are renewed symptoms linked to the original incident and reflected in reporting?

Keep both total elapsed time and contract-counted time visible. A “waiting for customer” status should identify the missing decision and its owner, not silently hide an unattended ticket. Agree how periods of customer unavailability affect measurement without erasing business impact.

5. Make escalation and updates someone’s job

Define a technical escalation owner, a service-management escalation owner, and the customer’s business decision-maker. Use maintained role-based contacts with backups rather than depending on one named employee being available forever.

For each incident class, specify the update interval, communication channel, recipients, and minimum content: current impact, actions taken, next step, blockers, owner, and next update time. Require an update even when the underlying vendor has provided no new estimate. Escalation should also occur when the current approach is not working—not only after a target has already been missed.

6. Keep third-party outages inside the responsibility map

An MSP does not control when an internet carrier or SaaS provider will repair its platform. It can agree to diagnose the boundary, open and track the vendor case, preserve evidence, investigate safe workarounds, and keep the business informed.

Identify who owns vendor contracts and support entitlements, who can authorize emergency spending, and who verifies recovery end to end. If a third-party outage excludes a restoration target, the exclusion should not also erase agreed communication and coordination duties. Separate the external dependency from the work your provider can control.

7. Join support, security, and continuity roles

The joint CISA advisory recommends contractual incident-response and recovery arrangements that fit customer resilience needs and are exercised. A support ticket alone is not a complete incident plan.

As a practical contract discussion, identify who may isolate a device, disable an account, disconnect a site, or approve a restore. Establish leadership, internal IT, provider, counsel, and insurer coordination as applicable. Agree an alternate communication method if business email is unavailable, and distinguish technical incident updates from legal notification decisions.

Keep recovery time and recovery point objectives separate from help-desk response targets. The former concern restoring a business service and acceptable data loss; they depend on architecture, backups, dependencies, and tested procedures. Review the actual backup and disaster recovery scope before attaching recovery promises to a support agreement.

8. Require usable records and security visibility

The joint advisory recommends appropriate logging and customer visibility where MSPs provide monitoring. Agree which relevant records you can obtain, how they are protected, and how long they remain available.

Our recommended evidence schedule includes ticket history, priority changes, clock pauses, approvals, service changes, incident records, and relevant security logs. Specify export formats, authorized requesters, delivery method, retention, and access during an incident or provider transition. Limit access appropriately so one customer cannot retrieve another customer’s information.

Do not place passwords or recovery secrets in ordinary ticket exports. A request for records is not a request for unrestricted access to the provider’s internal systems. Document the secure mechanism for transferring necessary customer-owned configurations and access information.

9. Review performance in a way that exposes exceptions

Require a report that states its reporting period, included population, measurement rules, and exclusions. Break results out by priority and service; a large volume of easy requests can obscure a small number of serious failures.

• Show the number of incidents, target attainment, and actual response and restoration times—not just an overall average.
• List missed targets, aged open work, reopened incidents, recurring faults, and total paused time with reasons.
• Track communication commitments and customer-impacting outages, including those attributed to third parties.
• Assign improvement actions, owners, and deadlines, then review whether the previous actions were completed.

Use a sample ticket to reconcile the dashboard with its underlying timestamps. With a small incident sample, examine the individual cases rather than treating a percentage as strong statistical evidence. Business owners should be able to understand the report without learning the provider’s ticket-system vocabulary.

10. Agree remedies, change notices, and an orderly exit

Ask what happens after repeated misses: a service review, corrective-action plan, additional oversight, agreed credits, or a defined termination right. Clarify eligibility, claim deadlines, caps, exclusions, and whether a credit is the sole contractual remedy. Have counsel review the actual language; this checklist does not establish an entitlement.

CISA’s 2021 customer-risk guidance also recommends notification concerning provider ownership or leadership changes and subcontracting that exposes customer data. Translate material changes into an agreed notice and review process rather than assuming the original delivery model will remain unchanged.

As an additional ITECS buyer recommendation, agree transition assistance before it is needed: notice periods, exit charges, support during handover, customer-owned documentation and configuration exports, access transfer, and removal of provider access after acceptance. Assign an owner and acceptance criteria for the handover. Record retention and deletion obligations must account for the applicable contract and legal requirements; do not assume all records can be deleted immediately.

Test the agreement with one business outage

Illustrative tabletop, not a client incident: the order-processing application fails near the end of the support window. The provider acknowledges the ticket, identifies a vendor dependency, and helps the business use an approved workaround. The vendor’s permanent correction comes later.

Walk that scenario through the draft agreement. Who sets priority? Does after-hours coverage apply? Which acknowledgment counts? Is the workaround sufficient to stop the restoration clock? Who tracks the vendor case and outstanding corrective work? Who tells the next shift what is safe to use?

Now change one condition: the workaround fails, or the symptoms suggest a security incident. If the agreement cannot explain who takes control and how the clocks change, fix the ambiguity before signing. Repeat the exercise for a remote worker and a site-wide connectivity failure when those dependencies matter to your business.

A short approval checklist for the business owner

• Every critical service has an owner, scope, dependencies, and exclusions.
• Priorities reflect impact and urgency, with a documented dispute path.
• Support windows and response, restoration, resolution, and clock rules are distinct.
• Provider and customer staffing, access, approvals, cost, and responsibilities can support the proposed targets.
• Escalation, communications, evidence access, and third-party duties are explicit.
• Reporting, repeated-failure action, change notification, and transition assistance are written down.
• Business and technical owners have walked through a realistic incident together.

Do not copy another organization’s target table and call the agreement complete. A credible commitment fits the business criticality, delivery resources, dependencies, and price behind it. If a tighter target requires different coverage or architecture, make that an explicit decision.

Want to turn a vague support proposal into a clearer operating agreement? Talk with ITECS about your managed or co-managed IT requirements. Bring your service inventory, current agreement, and the business processes that cannot wait; keep credentials and sensitive incident evidence out of the initial inquiry.

Research checked September 29, 2026. Prepared by ITECS Team with AI-assisted research and drafting. Source guidance is identified by publication date; the checklist and tabletop are editorial recommendations, not legal advice, certification criteria, or a promise of particular ITECS service levels. Revisit the agreement when services, owners, dependencies, or coverage change.