When the Dashboard Goes Red: What an MSP Actually Does, and Who Owns the Account

The 2 a.m. dashboard, and the question “who is responsible?”

A service has moved to the cloud, and one night the status page turns red. People on a group chat ask who restarts the box, who talks to the provider, and who tells the customer. That confusion is usually born in the contract, not in the console.

Teams look at a managed service provider — an MSP — when they do not have enough people to design, migrate and operate a cloud estate, or when they need after-hours coverage they cannot staff. An MSP is not the same thing as “the cloud brand on the invoice.” This page will not rank vendors, and

What the work usually includes — and what still stays yours

Typical MSP work, when it is in the statement of work, includes current-state review and architecture, migration of servers and data, building networks and databases and security controls, day-to-day monitoring and patching, access and vulnerability hygiene, and cost cleanup of idle resources. Some also resell and invoice the underlying cloud spend. None of that is automatic; it is only in scope if the paper says so.

A tiny brochure site may still be fine on ordinary web hosting or a single virtual server. An MSP starts to make sense when uptime, identity, backups and a changing bill have to be watched together. Many organisations keep product development in-house and hand infrastructure operations and monitoring to an MSP. Knowledge then lives in two places, so ask how runbooks and diagrams will be shared with your own staff.

If you work with public-sector or tightly regulated data, you can ask whether a candidate has experience with the assurance programme that actually applies — FedRAMP in the United States, ISMAP in Japan, CSAP in Korea, or the framework your own regulator names. That is a fitness question, not a leaderboard.

Choosing a partner without a popularity contest, then reading the SLA

Useful comparisons are unglamorous: skill on the cloud you already use, work with organisations of a similar size or industry, the shape of the support roster, container or Kubernetes support if you need it, a security operating model, and a clear incident path. Certificates held by engineers can be a signal; they are not a substitute for a reference you can actually call.

The service-level agreement is the document that names severity levels, response and restore targets, how and when you are told, and what sits outside the promise (a change you approved, a provider-wide incident, a system the MSP does not touch). “24/7” on a slide is not the same as a target in a signed schedule. Keep the cloud account’s owner or root privileges in your company, and grant the MSP only the roles it needs. Write down how access is returned, how long handover lasts, and how invoices and discounts work, before you start.

Start smaller than the slide deck, and keep one person who can still read the bill

A practical path is to write down the current estate, the pain and the goal; send the same request to more than one MSP; compare technical approach and price; begin with a narrow migration or a monitoring slice; then widen the scope only after a few review meetings. In the request, include server counts and shape, a sense of daily users, data size, a desired window, the incident level you need, and security constraints, so bids can be compared on similar terms. Have both a technical reader and a cost reader in the room.

After go-live, read the monthly report yourself: incidents, response times, and the cost trend. Even one internal person who understands the basic architecture makes the conversation cheaper, and makes a later exit or a partial insource possible. This is general information, not a vendor recommendation. Recheck the contract in front of you before you sign.

Sources

1. This page explains what a managed service provider (MSP) does in cloud operations: scope, service-level agreements, account ownership and a contract checklist. It does not rank vendors and it invents no market shares.
2. Cloud-account root or owner privileges should stay with the customer organisation. An MSP is typically granted only the access needed to operate the agreed scope. Official programme names such as FedRAMP (United States), ISMAP (Japan) or Korea’s CSAP are frameworks you can ask about; they are not a vendor ranking.
3. An SLA is a written promise about response and recovery targets, reporting and responsibilities — not a marketing slogan. Recheck the signed schedule, not a remembered number.
4. The Korean original is a first-look guide for teams considering an MSP. This localisation keeps that flow and adds questions a buyer in another country can take to a contract review.

Last checked: 14 November 2026