Who fixes an application incident after you appoint an MSP?

The problem and decision criteria

Imagine reviewing a managed cloud operations contract. The proposal says “monitoring and incident response included.” If orders stop, does that include checking the server, correcting defective code and repairing missing orders?

The label MSP does not determine who will resolve an application incident. Confirm which diagnostic and repair tasks are delegated, and who may approve and execute changes. Outsourcing infrastructure operations still requires a separate owner for code fixes. Application maintenance can also be outsourced, but decisions involving the business, such as the scope of data restoration or resuming service, still need a designated approver.

Before signing, answer two questions: “Who coordinates the incident through to completion?” and “Who actually repairs each system?” Establishing one contact point and assigning every repair to one provider are different choices.

In this article, “responsibility” means the roles that decide, approve and perform work. It is not a standard for determining legal fault or liability for damages in a particular incident.

A CSP shared responsibility model does not define managed operations scope

First distinguish the cloud service provider (CSP), managed service provider (MSP), and application development and maintenance team. Also identify the service owner who decides when business operations stop or resume, the data owner who approves the correct data state and restoration scope, and external SaaS providers such as payment or authentication services. One person can hold several roles in a small organization.

The AWS Shared Responsibility Model distinguishes security responsibilities for underlying EC2 infrastructure from the customer's guest operating system, applications and other components. Google Cloud also explains that responsibility boundaries depend on the service type. These documents are a starting point for understanding security responsibilities. They are not statements of work specifying which code an individual MSP will fix at night.

Review support products separately. The AWS Support FAQ describes its scope and excludes custom code development and software debugging. This does not mean no assistance is available, but a technical support subscription should not be treated as an application maintenance contract.

Availability commitments are covered by yet another document. The AWS Compute SLA and Google Compute Engine SLA define availability, applicability, service-credit claim conditions and exclusions for the relevant services. Those figures cannot simply be transferred to the availability of an entire customer website or an MSP's recovery time. Check the provider's service commitment, its technical support and the MSP's actual operating work separately.

Split “24-hour response” into seven activities

The following are design criteria for comparing proposals. They separate activities so that the presence of one is not mistaken for a guarantee of the next.

An automatically generated ticket is not evidence of human acknowledgment. A responding server does not prove that missing orders have been repaired. Conversely, mitigation need not wait for all diagnostic work to finish. The Google SRE incident response guidance emphasizes mitigation alongside organized role assignment.

When reading a response target, the conditions around “how many minutes” matter more than the number alone. The Google Cloud Technical Support Services Guidelines distinguish initial response targets by support tier and priority from support hours. An initial response target is not a deadline for resolving the problem.

Specify whether timing begins at detection, reporting, notification or acknowledgment, and how waiting for customer approval or an external provider will be reported. It is also useful to prevent the total user-visible interruption clock from restarting when an incident is handed to another provider. If acceptable downtime and data loss must be defined first, consult how RTO and RPO determine recovery objectives.

Assign responsibility by task, not by the label “DB incident”

The following is a design example for a hypothetical web application operations contract. It is not a provider's default service scope or IXC's contractual terms.

The application uses VMs and a managed database. The MSP operates VMs and networking and executes approved deployment procedures. The development and maintenance team owns code, queries and DB connection configuration. Assume that the service owner has delegated actions within predefined budget and change limits.

Final decision and approval identifies one party that decides whether a task may proceed. Execution identifies who investigates or makes the change. Cooperation cells are left empty where none is needed. The table does not imply that customers gain approval authority over a provider's internal work.

Capacity changes exceeding preapproved limits belong in an additional-cost approval process rather than being treated as the same delegated task. Restoration with potential data loss should not share the same authority as an ordinary server restart.

This task-level view breaks “Who owns a DB incident?” into smaller questions. The required executor and approver depend on whether the issue concerns DB engine internals, application connection management, queries or business data. A self-installed database also needs an assigned engine operations owner. Check the service policy for the provider's scope in a managed product.

The same principle means high CPU alone does not establish an infrastructure root cause. The following example assumes an application change caused connection problems. Being able to add resources is different from being able to fix the cause.

Use one contact point and place change authority where it belongs

Google SRE distinguishes incident command, communications and technical operations. One person may hold several roles in a small incident, but command and technical action should remain distinguishable.

For operations involving multiple providers, designate someone who owns the whole incident even while its cause is unclear. That can be the MSP or an internal customer representative. Whichever is chosen, an “outside our scope” notice must not leave the incident without an owner.

In particular, require acknowledgment by the receiving owner when handing work from the MSP to developers. Include symptoms, impact, actions taken, required permissions and the next update time. When requesting CSP or SaaS support, confirm the account and support agreement that permit a case to be opened on the customer's behalf, and attach the external ticket number and acknowledgment state to the incident record. Opening an external ticket does not close the internal incident.

Design example 1: DB connections are exhausted immediately after deployment

Assumption: Order errors rise after an application deployment because changed connection-management code causes a problem. The MSP can run the deployment pipeline but cannot arbitrarily change code. The following sequence is not an actual incident record.

Follow detection and acknowledgment → joint diagnosis → rollback approval → execution and verification → business confirmation and handoff of follow-up repairs.

The MSP acknowledges the incident and identifies a commander. It checks resources, networking and DB connection metrics while developers investigate recent changes and application errors. Do not immediately classify it as a “server problem” or “development problem” and send it to only one side.

If returning to a previous version is appropriate, the application technical lead checks compatibility with the current DB schema and configuration and approves rollback. The MSP executes only the agreed deployment procedure. Approval to roll back code must not include permission to overwrite the entire DB with a past state.

Plan for an unreachable approver. Without an alternate approver or explicit emergency delegation, the MSP should use preapproved mitigation and continue escalation, rather than expanding its application or data modification authority on its own.

After recovery, developers and the MSP verify critical functions; the service owner checks actual order processing and backlogs. If missing data is found, the data owner approves the correction scope. Root-cause code changes and regression testing remain developer follow-up work. Record the deployed version, approval and execution times, verification results and the person who accepted the follow-up tasks.

Design example 2: an external payment API stops responding

Assumption: A customer's web application stops receiving responses to payment requests. Whether the external provider processed them is not yet known. This is another design example, not a real customer case.

Distinguish not receiving a response from a payment not being executed. Stripe's error handling documentation describes network errors where the client cannot know whether the server received a request. This is Stripe-specific technical guidance; it does not imply that every payment provider has the same query and retry rules.

Assign roles along impact assessment → correlation with the external incident → business mitigation decision → transaction outcome confirmation → reprocessing and business resumption approval.

The MSP checks the customer's network and servers, while developers inspect request identifiers and application records. If there is evidence suggesting an external service issue, the designated owner opens a support case. A public status page is supporting information, not proof of success or failure for an individual transaction.

The service owner decides whether to pause new orders or use another payment path that has already been validated. Do not assume the MSP can repair the external platform internally. Request external recovery while reducing the impact on the customer's web application.

Even after connectivity returns, do not resend every request. Developers confirm outcomes according to that payment provider's query and retry rules, and the data owner approves how order/payment discrepancies will be reconciled. After approved reprocessing and business checks, the service owner decides whether to resume. The closure record includes not only the external incident number but also transactions with unresolved outcomes and owners for outstanding work.

Record decision conditions alongside the work list

When connecting the responsibility matrix to a contract or operating agreement, review the following items beside “incident response included.” These are questions for clarifying scope, not standard contractual clauses.

When comparing proposals, use the managed cloud provider selection guide and map each proposal's scope to the incident executors and approvers defined above. After assigning roles, incident response runbook design can help document the actual response procedure.

Treat access permissions as a separate handover condition. Instead of a line saying “administrator access,” specify accounts, resources, actions, duration and revocation. For example, AWS Support Authorization describes permits limited by resource, action and duration for support cases. The suggestion is to use comparable specificity in MSP access agreements, not that the feature is included in every MSP contract.

Define provider-exit conditions before starting. Identify who controls accounts and domains; which source code, configurations, operating documents, monitoring settings and backups are handed over; how restoration keys are transferred securely; and what license or reseller agreements restrict migration. Also specify handover format, deadline, cost and owners for open incidents. Agree to revoke old permissions only after the incoming owner verifies the required access and restoration mechanisms.

Which operating model fits your team?

If internal staff can handle both infrastructure and applications and cover the required hours, organizing their roles and permissions may be sufficient without an additional MSP. Filling out this matrix also does not require a new management tool. Existing documents and incident tools are enough if they can track ownership, approvals and handoffs.

If developers are available but server operations are burdensome, separate infrastructure-focused managed services from application maintenance. Include a common reporting channel, joint diagnosis, developer availability and acknowledgment of handoffs in the operating agreement. The purchasing decision should expose that someone may acknowledge a nighttime incident while the person able to fix the code is available only on the next business day.

If nobody owns application maintenance, do not assume an infrastructure contract fills that gap. First determine whether maintenance takeover, repair of code and deployment paths, or outsourcing that includes application operations is needed. If a system can remain unavailable until the next business day, consider whether business-hours support is more appropriate than continuous human response.

Under any model, the customer retains roles deciding service suspension and resumption, data corrections and acceptable loss, additional spending and priorities. Decisions may be delegated, but the delegate, limits and alternate approver for absences must be explicit.

Before contracting, choose one critical business operation and ask what happens if it stops now. Can you identify who acknowledges the incident, who repairs it, who approves action and who confirms the business is running again? Resolving an unassigned task comes before comparing provider names or availability percentages.

To review operational responsibility and support scope with an external team, send IXC an inquiry describing the systems, work to delegate and approval authority you intend to retain.