Working with a managed service provider: scope, service levels, and oversight

Reference article · 5 min read

A managed service provider, or MSP, runs part of an agency's IT operations under contract: a help desk, servers and networks, endpoint management, backup, and sometimes security monitoring. For a department that cannot staff every specialty around the clock, that is often sensible. Whether it works depends less on the vendor's capability statement than on how precisely the contract names tasks, sets how fast work starts and service is restored, and says who inside the agency watches it.

The common failure is assumption. The agency believes someone is watching security alerts at two in the morning. The vendor believes it sold a business hours help desk and will read the alert queue when the next shift starts. Neither party is acting in bad faith. The scope never said, and nobody notices until an incident makes the gap visible.

Decide what moves and what stays

Outsourcing operations does not outsource accountability. Some responsibilities stay with the agency however much daily work the vendor performs, and the contract should say so.

• Decisions about risk and incidents. Accepting a vulnerability, approving an exception, taking a system offline, or declaring an incident is an agency call, as is notifying leadership, the insurer, and affected individuals. The vendor recommends and documents.
• Records and regulatory duties. The agency stays custodian of its records and remains subject to public records, retention, and sector rules such as criminal justice information, health information, or payment card requirements. A vendor supports those duties but cannot absorb them, and requirements change, so confirm current ones with counsel.

Write the scope as tasks, not categories

"Managed security" and "server management" are categories. They do not say what happens on a Tuesday. Turn each into tasks with a frequency, an owner, and evidence.

• Monitoring and response. State whether the vendor only alerts the agency or may act: isolate an endpoint, disable an account, block traffic. Give the hours for each; the two often differ.
• Patching. Name the systems in scope, the cadence for routine and emergency patches, who approves maintenance windows, how exceptions are recorded, and what monthly evidence of patch status arrives.
• Backup and restore. Jobs completing is not the service. Require periodic test restores, name who performs and witnesses them, define retention and where copies live, and get results in writing.
• After hours coverage. Define the window, whether it is a staffed console or on call staff, how a call reaches a human, who may trigger it, and how holidays work.
• Account work. Creation, changes, and removal on departure, with a target time for removal.
• Exclusions. A written list of what the vendor does not do, plus the rate card for doing it later.

Service levels that describe behavior

Priority definitions do most of the work. Tie them to impact on agency operations rather than the vendor's internal labels.

• Priority by impact. Define priorities by what is affected: a public safety workstation, a permit counter on a busy morning, one user's printer.
• Response and restoration separately. Acknowledgement is easy to meet and tells you little. Set one target for work beginning and another for service restored, and say whether the clock runs on calendar or coverage hours.
• Compliance measures, not only tickets. Patch currency, backup success, completed restore tests, and account removal timeliness are measurable monthly and belong in the table.
• A measurement source you can inspect. The numbers come from the vendor's ticketing system, so require read access, data export, and a rule for when a ticket may be paused or reclassified.
• Credits calculated, not requested. Say how a credit is computed, that it applies automatically, and that supporting detail arrives with the invoice. Think hard before making credits the exclusive remedy, especially for data loss or security failures.
• A chronic failure clause. Repeated misses across consecutive months should trigger a cure plan and, if the plan fails, a right to terminate without penalty.

Own the access and the oversight

Access is where a managed service becomes hard to unwind, so set these terms early: named vendor accounts rather than shared administrator logins, with multifactor authentication; a roster of vendor staff holding privileged access, reviewed on a schedule, with confirmed removal when someone leaves the account; agency ownership of tenants, subscriptions, domains, and licenses, with break glass credentials in an agency vault; log copies kept where the agency controls them; and approval of subcontractors and offshore work.

Name a contract administrator for invoices, credits, amendments, and out of scope charges, and a technical owner who reads the monthly report closely. Hold a service review on a set schedule with a fixed agenda: performance against each service level, aging tickets, changes to the environment, patch and backup evidence, access review results, and anything billed outside the base fee. Then verify rather than receive: trace a few closed tickets end to end each quarter, and ask for a restore of a system you pick. Settle transition assistance and data return at signing, not when the relationship is ending.

Questions to ask before award

1. Who is the named lead for this account, and what notice do we get when that changes?
2. Who performs the work: your employees, subcontractors, or both, and from where?
3. Walk us through what happens to a critical alert at nine on a Saturday night.
4. What does a standard monthly report contain, and may we see a redacted sample?
5. At the end of the term, what do we get back, in what form, and how quickly?

HQT provides technology and systems engineering services to state and local government, including managed service scope, service levels, and oversight.

Frequently asked questions