MSP–Client Responsibility Matrix: Who Does What

The client thought the MSP owned it.

The MSP was waiting for approval.

Nobody wrote it down.

And the ambiguity surfaced exactly when someone had to act.

> Download the MSP–client responsibility matrix in XLSX. It includes 30 controls, RACI roles, evidence, review frequencies, statuses, and tabs in English, Spanish, and Portuguese.

A managed service relationship doesn't fail only because a tool is missing. It can also fail when nobody can answer quickly: who executes, who decides, who accepts the risk, and what evidence must remain?

1) Remove “IT handles that” from the process

“IT” isn't an owner.

Neither are “the provider,” “the customer,” or “the appropriate team.” When something goes down, those labels force everyone to discover the process while the clock is already running.

NIST recommends that organizations document the service level, responsibilities, and expectations when engaging a managed service provider. It also makes an important point: outsourcing work doesn't eliminate the responsibility the business retains for protecting its systems and data.

That's why the matrix should sit next to the contract and the MSP SLA, while answering a different question:

• the contract defines the relationship;
• the SLA defines commitments and timing;
• the matrix identifies who participates in each activity;
• the runbook explains how the activity is performed;
• the ticket preserves evidence of what happened.

Don't force all of that into a fifty-page document. Give every artifact one clear job.

2) Use RACI without turning the meeting into an acronym class

RACI works because it separates four roles:

• R — Responsible: performs the work and records the result;
• A — Accountable: approves the decision, risk, or change;
• C — Consulted: provides context before action;
• I — Informed: needs the result but shouldn't stop the workflow.

One party can be R/A when it performs the work and has authority to decide within an agreed scope. For example, the MSP can review routine alerts, create a ticket, and close a low-risk action without asking permission for every click.

That doesn't mean it can decide everything. Isolating a server, shutting down an application, accepting a security exception, or increasing a cost usually requires someone at the client with actual authority.

The downloadable matrix has separate columns for the MSP role, the client role, and the approval or decision owner. That avoids a common trap: placing an A in a cell without naming the role that can provide approval.

3) Define scope and authorization before deploying agents

The first section of the matrix isn't technical. It's governance:

1. included and excluded services;
2. covered clients, locations, and assets;
3. authorized contacts;
4. escalation channels;
5. changes that affect scope or cost;
6. the next review date and owner.

This matters even more with an RMM. Having the technical ability to reach an endpoint isn't unlimited authorization to use it. Our guide to authorized use of Lunixar RMM explains why consent, scope, and traceability must accompany remote operations.

The same control applies during endpoint onboarding. If the client expected 42 devices and only 39 are visible, the matrix should say who reconciles the difference, who confirms the inventory, and who approves an expansion.

4) Divide daily operations and define minimum evidence

A useful matrix doesn't only say who does something. It also says how the result will be proven.

Notice the difference between sending an action and verifying the outcome. A patch isn't closed because a command was sent. An agent isn't installed because a file was downloaded. A backup isn't validated because the job is green.

Evidence should match the risk. A routine task may need only the console result. A restore, critical change, or exception needs a date, scope, owner, result, and next action.

5) Separate technical response from business decisions

Incidents expose weak ownership fast.

The joint CISA and international guidance for protecting MSPs and their customers calls for coordination around MFA, monitoring and logging, remote access, incident response, and recovery. None of that works well if both parties discover their responsibilities during the emergency.

Define in advance:

• who classifies the alert;
• who receives the first escalation;
• who can isolate a laptop;
• who authorizes interruption of a critical service;
• who contacts the insurer or legal counsel;
• who communicates with users, leadership, or third parties;
• who preserves the timeline and evidence;
• who declares the incident closed.

The MSP may contain a threat under a previously approved runbook. A business-impacting decision still needs a reachable client authority, including an after-hours backup.

Connect this section to a security alert response playbook and test it with a simple scenario: malware on a laptop, a server running out of space, or a locked administrative account.

6) Treat open items and exceptions as dated decisions

Not every row will end as “Agreed.” That's fine.

There may be a server that can't reboot, an unsupported application, a user who needs a temporary exception, or a service outside the agreement. The problem isn't having exceptions. The problem is not knowing who accepted them or when they expire.

Every exception should include:

• understood risk or impact;
• business reason;
• compensating control, if available;
• approval owner;
• follow-up owner;
• review or expiration date;
• closure evidence.

The template separates Not reviewed, Agreed, Pending, Approved exception, and Out of scope. It also calculates how many controls are agreed so the meeting doesn't end with a false sense of progress.

7) Review the matrix throughout the client lifecycle

The matrix isn't signed once and buried in a folder.

Use it at four moments:

1. Onboarding: confirm scope, access, contacts, assets, and initial policies.
2. Monthly operations: update changes, open items, vendors, and exceptions.
3. Client review: raise decisions that need budget, priority, or risk acceptance alongside RMM reports for clients and audits.
4. Offboarding: revoke access, transfer assets, and record acceptance with the MSP client offboarding checklist.

Review the matrix whenever the agreement, authorized staff, a critical platform, backup scope, or incident process changes.

A “last updated” date doesn't prove that the matrix is current. Useful evidence is a review where someone confirmed the owners are still correct.

8) Download the matrix and adapt it with the client

The workbook includes 30 controls across:

• governance and scope;
• identity and access;
• monitoring and inventory;
• patching and change;
• backup and recovery;
• incidents;
• data and third parties;
• reporting and review;
• service closeout.

It includes filters, dropdowns, RACI roles, minimum evidence, frequency, escalation, status, next review, and exception notes. English, Spanish, and Portuguese tabs let regional teams work from one file.

Download the MSP–client responsibility matrix (.xlsx)

Don't send it blank and expect the client to finish it alone. Pre-fill it with your proposed scope and use it to lead a decision-focused conversation.

Frequently asked questions

Does the matrix replace the contract or SLA?

No. It's an operational tool. The contract establishes obligations and the SLA defines service levels; the matrix translates them into owners, approvals, and evidence. Adapt it with professional advice when legal, tax, regulatory, or privacy requirements apply.

Should the MSP own every technical control?

Not necessarily. It depends on contracted scope, client capabilities, involved vendors, and delegated authority. Don't assign the MSP to an activity it can't execute or verify.

Can one party be R/A?

Yes, when it performs the work and has authority to approve within a defined scope. Use it carefully for actions that could interrupt the business, accept risk, or create cost.

How often should the matrix be updated?

Quarterly is a useful baseline, and every time scope, authorized staff, critical assets, vendors, policies, escalation channels, or the agreement changes.

What if the client won't approve a responsibility?

Leave it pending, record the impact, assign a follow-up owner, and set a date. Don't hide the missing decision by marking it out of scope without confirmation.

Less gray area. More verifiable operations.

A matrix won't prevent every incident.

It prevents something more basic and costly: wasting time discovering who was supposed to act.

Lunixar RMM can provide operational evidence across inventory, endpoint health, alerts, patching, and reports. The matrix connects that evidence to human owners, approvals, and decisions.

Explore Lunixar RMM for MSPs and try up to 5 devices for 14 days, with no credit card.