A managed IT agreement SLA should explain exactly what happens when a system raises an alert or an employee needs help outside normal business hours. A promise of “24/7 monitoring” is not enough by itself: it may describe automated alerts, human review, or hands-on response, and those are different commitments.
Before signing or renewing an agreement, make sure it defines the coverage you are buying, how response times are measured, who gets notified, and what happens if the provider misses a commitment. Clear terms help your team act quickly when an issue occurs and make it easier to review the provider’s performance.
Separate monitoring from human response
Ask the provider to describe each part of its coverage separately. Do not assume that a monitoring commitment also means a technician is watching every alert or will begin remediation immediately.
- Monitoring and alert detection: Which systems, devices, services, and security events are monitored? Is coverage continuous, and what kinds of alerts are included?
- Human review: Are alerts reviewed by a person around the clock, or only during specified hours? What happens to alerts that arrive outside those hours?
- Help-desk availability: When can your employees contact support, and by which channels? State whether coverage includes nights, weekends, and holidays.
- Hands-on response: What does the provider do after an alert is reviewed? Clarify whether the commitment is to acknowledge, investigate, contain, or resolve the issue.
Also define what is in scope. For example, specify covered locations, devices, cloud services, and business applications, as well as any systems that are excluded or depend on another vendor. The UK National Cyber Security Centre’s guidance on choosing a managed service provider is a useful reference when assessing provider responsibilities and service arrangements.
Define what the response-time SLA measures
A response-time target can mean several things. It might measure how long it takes to acknowledge a ticket, notify a designated contact, or begin active investigation. Those are not interchangeable. The agreement should name the promised action, not just say that the provider will “respond.”
Define the clock in plain language. The agreement should state:
- What starts the clock: Is the start time when an alert is generated, when the provider receives it, or when a ticket is submitted through an approved channel?
- Which channels count: Explain whether a phone call, email, monitoring alert, or support portal submission starts the clock. Provide a fallback route if the usual portal or phone system is unavailable.
- How time is counted: Say whether the target uses business hours or calendar hours, identify the applicable time zone, and define holidays and after-hours periods.
- When the clock pauses: State whether it pauses while the provider is waiting for information or access from your team, and how that pause is recorded.
- What happens if priority changes: Explain whether a newly discovered impact changes the target and how the provider communicates that change.
Keep response time distinct from resolution time. Response time should specify when the provider will acknowledge or begin handling the issue. Resolution time concerns when the issue is fixed, and may depend on the cause, the availability of a vendor, or decisions that require your approval. If the provider cannot commit to a resolution deadline, ask what progress updates and interim actions it will commit to instead.
Set practical incident priorities
Ask the provider to define each severity level using business impact and urgency, not labels alone. A disruption affecting a critical business function or indicating a possible security incident may need a different path from a request affecting one user with a workaround available.
For each priority, document the applicable response commitment, notification route, update cadence, and escalation path. Include examples that fit your operations, then confirm who can raise or lower a priority. Your team should not have to guess which category applies during a stressful event.
Write down after-hours contacts and escalation
An after-hours promise is only useful if people know how to activate it and who will take responsibility. The agreement should identify the support route for employees, the contacts the provider will use for urgent incidents, and what happens if those contacts do not answer.
Specify an escalation path that covers:
- Provider escalation: When does the first responder bring in a senior technician, security specialist, or service manager?
- Customer escalation: Which business and technical contacts should be notified, in what order, and through which backup channel?
- Decision authority: Who may authorize actions such as isolating a device, disabling an account, or taking a system offline? Identify any actions the provider may take without waiting for approval.
- External parties: When will the provider involve a cloud, software, internet, or other service vendor, and who manages that coordination?
- Ongoing updates: How often will your designated contacts receive updates, and what information will those updates include?
Agree on an alternative contact method in case the main channel is unavailable. You should also confirm that contact details are kept current and that the escalation route is tested. For broader planning, see this guide to a business cyber incident response plan.
Make service levels reviewable
Require records that let both sides see what happened. Useful items include ticket timestamps, alert and notification records, incident summaries, monitoring reports, and notes showing when a priority changed or a case was escalated. Agree on how often the provider will share reports and review performance with your team.
Finally, put the consequences of missed service levels in writing. Define how a miss is reported, how the provider explains it, and what corrective action or other remedy applies if commitments are repeatedly missed. Make sure the agreement states who reviews unresolved concerns and how they are escalated.
For a broader provider review, Stop Hackers Now also has a guide on choosing a managed cybersecurity service provider. The service-level terms should match your actual operational needs, not just sound reassuring in a proposal.
Managed IT agreement SLA review checklist
- Does the contract distinguish automated monitoring, human review, help-desk coverage, and active response?
- Are covered systems, hours, holidays, time zone, and contact channels explicit?
- Does each response target define the exact action and the clock’s start, pause, and restart rules?
- Are priorities tied to impact, with clear notification and update expectations?
- Are after-hours contacts, fallback routes, escalation steps, and decision authority documented?
- Can you verify service performance through timestamps and reports, and are remedies for missed commitments clear?
Clear agreement language cannot prevent every disruption, but it can reduce uncertainty when your business needs support. Review the terms with the people who will use them, and ask Stop Hackers Now about a free cybersecurity assessment if you want to discuss your organization’s needs.