The RACI Matrix between the business and the IT Helpdesk vendor
Outsourcing the IT Helpdesk does not mean the business transfers all technological responsibilities to the vendor.
The vendor can receive tickets, support users, troubleshoot endpoints, check the network, or coordinate with third parties. However, when it comes to granting administrative privileges, changing production configurations, handling security incidents, or prioritizing actions during a major incident, the critical question is no longer can the vendor do it? but rather who has the decision-making authority and who is ultimately responsible?
That is why the RACI Matrix should be defined alongside the service scope and Service Level Agreement (SLA) right from the start.
RACI helps businesses distinguish between four roles: Responsible – the person directly executing the task; Accountable – the person ultimately responsible; Consulted – the party that needs to be consulted; and Informed – the party that needs to be kept in the loop.
In the outsourced IT Helpdesk service model, this matrix is particularly useful when responsibilities are shared among users, internal IT, the Helpdesk vendor, the security team, Internet Service Providers (ISPs), and other application vendors.
What problems does the IT Helpdesk RACI Matrix solve that the SLA cannot?
Before creating a RACI matrix, the business needs to distinguish between three different management layers: scope, SLA, and responsibility.
Scope answers the question of what the vendor supports. For example, the Helpdesk might support laptops, Microsoft 365, user accounts, Wi-Fi, or coordinate with ISPs. If the business has not clearly defined this scope, they can refer to the task groups of IT Support and IT Helpdesk before designing the responsibility matrix.
The IT Helpdesk SLA, on the other hand, answers the question of under what conditions and how long the service must take to respond or resolve an issue. A Priority 1 (P1) ticket might need a faster response than a P3 ticket, but the SLA does not automatically determine who is authorized to change the firewall, who approves access rights, or who decides to shut down a critical system.
RACI fills in the missing piece: who executes, who is ultimately responsible, who must be consulted, and who must be informed.
The most important point is: Outsourcing execution is not synonymous with outsourcing the entire management responsibility.
For instance, the Helpdesk vendor might be the party directly creating accounts for new employees. However, the department manager or IT Manager may still be the one accountable for approving access rights. In this case, the vendor is Responsible, while the business holds the Accountable role.
5 Principles for creating a RACI Matrix between the business and the vendor
A RACI matrix is only useful when it accurately reflects actual authority. A beautifully crafted matrix that does not align with the contract, access rights, or approval processes will not solve operational issues.
1. Every critical task requires a clear Accountable party
An activity may involve multiple people in the handling process, but the situation where no one knows who is ultimately responsible must be avoided.
For example, when the entire office loses Internet connectivity, the Helpdesk might check the equipment, the ISP might check the connection, and internal IT coordinates with the office manager. However, there still needs to be an Accountable focal point responsible for coordination until the service is restored.
2. Responsible is not synonymous with approval authority
The vendor may have the technical capability to implement a change, but that does not mean they are permitted to make that decision independently.
A Helpdesk technician might know how to add a firewall rule, create an administrator account, or restart a server. However, if this is a production system, the execution authority must depend on the authority previously approved by the business.
3. Separate access rights from decision-making authority
This is particularly crucial regarding privileged accounts.
The vendor requires sufficient privileges to complete their tasks, but it should not be assumed that every Helpdesk technician has full administrator access across all systems.
The business should clearly define:
Who has access rights to which systems.
Whether access is persistent or granted on demand.
When approval is required.
Which activities must be logged.
Who can request privilege escalation.
Who has the authority to approve.
4. Escalation must be defined before an incident occurs
When an incident exceeds the Helpdesk's scope, the technician must know who to escalate it to.
For example:
Enterprise Resource Planning (ERP) application errors → application vendor.
Widespread Internet outage → ISP.
Endpoints showing signs of a cyberattack → security/Security Operations Center (SOC).
Core switch errors → network specialist.
Sensitive access rights → system owner or IT Manager.
Failing to pre-define the escalation path will cause tickets to bounce around between multiple parties, while users remain unable to work.
5. RACI must align with scope, SLA, and the contract
If the contract states the vendor manages endpoints but the RACI matrix requires all actions to await internal IT approval, the actual resolution time may not align with the SLA.
Conversely, if the SLA is very strict but the vendor is not granted sufficient permissions to handle issues, it will be difficult for the vendor to meet their commitments.
Therefore, RACI should not be a standalone document. It needs to be cross-referenced with the service scope, escalation matrix, access rights, and SLA.
Sample RACI Matrix by IT Helpdesk task groups
The table below is a reference sample, not a default matrix applicable to all businesses. Actual roles must be adjusted according to the systems, internal IT capabilities, the contract, and the level of authority the business wishes to delegate to the vendor.
Task Group | Internal IT / Business | IT Helpdesk Vendor | Business Owner / Manager | Security / Specialist |
Receiving and handling user tickets | A/C | R | I | – |
Password resets according to approved procedures | A | R | I | C if needed |
Installing approved software | A | R | I | C |
Endpoint setup and handover | A | R | I | C |
Monitoring endpoint patches/updates | A | R | I | C |
Troubleshooting LAN/Wi-Fi | A | R | I | C |
Modifying production network configurations | A | R/C | I | C/R |
Working with ISPs or third-party vendors | A | R/C | I | C |
Creating user accounts | A | R | C | C |
Granting access to sensitive systems | A | R/C | C | C/R |
Receiving security alerts from users | A | R | I | C/R |
Investigating security incidents | A/C | C | I | R |
Coordinating major incidents | A | R/C | C/I | C/R |
Executing approved changes | A | R | I | C |
Approving high-risk changes | A/R | C | C | C |
Review SLA, backlogs and recurring issue | A | R/C | I | C |
User support: Vendor hold the Responsible role, business is ultimately Accountable
Requests such as Outlook errors, inability to access the Virtual Private Network (VPN), non-functioning printers, or office software issues are generally suitable for the Helpdesk to handle directly.
In this case, the vendor can hold the Responsible role.
However, the business or IT Manager should still remain Accountable for the overall service quality: the support scope, the privileges technicians are allowed to use, ticket prioritization, and how recurring issues are addressed.
Endpoints: Distinguishing operations from device lifecycle decisions
The vendor can handle laptop setups, software installations, operating system updates, endpoint troubleshooting, or device retrieval.
However, decisions such as replacing new laptops, modifying security baselines, wiping data, or approving previously unapproved software should still have an owner on the business side.
In other words, the Helpdesk might be responsible for execution but not necessarily responsible for determining endpoint policies.
Network: Troubleshooting is different from system change control authority
The Helpdesk can check Wi-Fi, network cables, Internet Protocol (IP) addresses, Domain Name System (DNS), or determine whether an incident lies within the endpoint, Local Area Network (LAN), or ISP.
But when it comes to modifying Virtual Local Area Networks (VLANs), routing, firewall rules, or core network configurations, the business needs to clearly define whether the vendor has execution rights or only escalation rights.
This is an area very prone to misunderstandings if the contract generically states "network support."
Third-Party vendors: Clearly define who coordinates and who is ultimately Accountable
Many tickets cannot be resolved independently by a Helpdesk.
A Microsoft 365 error might require opening a case with Microsoft. Internet incidents require working with the ISP. Accounting application errors might fall under the responsibility of the software vendor.
The RACI matrix should clearly indicate:
Who opens tickets with third-party vendors.
Who provides logs or technical information.
Who tracks progress.
Who updates the users.
Who is ultimately accountable for the business outcome.
Without this assignment, the Helpdesk might complete its troubleshooting portion, but the ticket remains "hanging" with the third party.
Security and access rights: Helpdesk receives and escalates, not defaulted to investigating
The Helpdesk is often one of the first places to receive anomalous signals: users reporting suspicious emails, locked accounts, endpoints showing alerts, or computers exhibiting unusual behavior.
The appropriate role of the Helpdesk might be to receive, gather initial information, isolate according to approved playbooks, and escalate.
In-depth security incident investigations, on the other hand, might belong to IT Security, the SOC, or a specialized unit.
The National Institute of Standards and Technology (NIST) Special Publication (SP) 800-61 Revision 3, published in April 2025, also emphasizes that incident response involves multiple individuals, teams, and third parties; leadership, incident handlers, and other stakeholders have different roles in decision-making and incident handling.
RACI helps businesses avoid situations where a Helpdesk technician has to independently decide on issues exceeding their authority.
Major Incidents: When the handler is not the ultimately Accountable party
A major incident is the situation where a RACI matrix most clearly demonstrates its value.
Suppose the entire office loses Internet connectivity.
The Helpdesk can:
Receive multiple tickets.
Identify that this is no longer a single-user error.
Check the router, firewall, or network devices according to granted privileges.
Contact the ISP.
Update the incident status.
Escalate to a network specialist.
However, the person accountable for coordination on the business side might still be the IT Manager.
If the incident severely impacts business operations, the business owner or management board also needs to be brought into the information loop.
A RACI Matrix for a Major Incident could be designed as follows:
Activity | Helpdesk Vendor | IT Manager | Specialist/ Related Vendor | Business Owner
|
Identifying a major incident | R | A | C | I |
Initial triage | R | A | C | I |
Deciding on escalation | R | A | C | I |
Emergency production changes | R/C | A | R/C | I |
Updating users | R | A | C | I |
Deciding business priorities | C | C | C | A/R |
Post-incident review | R/C | A | C | I |
The goal is not to make the matrix more complex. The goal is to avoid arguing over “who gets to decide?” right in the middle of a system outage.
Change Management: To what extent is the vendor permitted to make changes?
An efficiently operating Helpdesk requires sufficient privileges for rapid resolution, but those privileges must have boundaries.
Changes can be categorized into three practical groups.
Standard change is a change previously approved by the business and has a clear procedure. For example, installing standard software or adding a printer according to an agreed configuration template. The vendor can execute this directly without seeking approval each time.
Normal change is a change requiring review prior to execution. For example, modifying firewall rules, changing network configurations, or altering policies on a large scale. The vendor can propose and execute this, but the business retains approval authority.
Emergency change occurs when rapid action is required to mitigate the impact of a severe incident. The process might be expedited, but it is still necessary to define who has the authority to permit the action and who must be informed.
A useful principle is: The vendor needs to know not only "what I can do," but also "when I am not allowed to do it myself."
RACI, therefore, should be directly linked to access levels and change authority.
Periodically review RACI to prevent scope creep and responsibility gaps
A RACI matrix should not be created once upon signing a contract and then left untouched for years.
IT systems are continuously changing. A business might open new offices, migrate to the cloud, deploy a new ERP, replace firewalls, hire a SOC, or change IT personnel.
Each such change can create a new responsibility boundary.
The business should review the RACI matrix when:
Starting or renewing a Helpdesk contract.
Changing the service scope.
Adding a new site or office.
Deploying a new critical system.
Changing a third-party vendor.
A major incident occurs.
Changing the IT Manager or key stakeholders.
The vendor is granted additional privileged access.
During each review period, at least five questions must be checked:
Is the current Accountable person still correct?
Are there any systems without a clear owner?
Does the vendor currently have privileges broader than their scope of responsibility?
Are there any tickets frequently bouncing around between multiple parties?
Does the current RACI matrix still align with the scope, SLA, and escalation procedures?
For businesses that already have their own IT team, the article Should you still outsource your IT Helpdesk? provides a deeper analysis of how to allocate resources among in-house, outsourced, and co-managed models. This RACI article does not replace that decision; it helps both parties operate with clear responsibilities once a model has been selected.
Prior to signing a contract, the business should also verify whether the proposed allocation truly exists in the vendor's operational processes or if it is merely on a proposal. The IT Helpdesk vendor due diligence: 12 evidence items to verify can be utilized to verify ticket workflows, escalation, personnel, access rights, and the ability to provide operational evidence.
Before signing an IT Helpdesk contract, finalize RACI alongside scope and SLA
A question like "does the vendor support the network?" is often insufficient.
The business should ask more specifically:
When a network error occurs, to what extent does the vendor handle it directly?
When a firewall change is needed, who approves it?
If the root cause lies with the ISP, who opens the case and tracks it?
If a ticket is security-related, does the Helpdesk handle it or escalate it to the SOC?
Who has the authority to create or escalate a privileged account?
When a major incident occurs, who is the Incident Owner?
Who is authorized to approve an emergency change?
Who notifies the leadership and the users?
Who is accountable for reviewing recurring issues post-incident?
When these questions are answered via a RACI matrix, the business will have a clearer responsibility boundary between internal staff and the vendor.
This helps mitigate three common risks: having no owner, the vendor acting beyond their authority, and tickets bouncing around between multiple parties.
In summary, the IT Helpdesk RACI matrix is not a substitute for the SLA or service contract. It resolves a different but highly critical question: who executes, who decides, who must be consulted, and who must be informed within each task group.
An appropriate RACI matrix should cover at least user support, endpoints, the network, third-party vendors, access rights, security incidents, major incidents, and change management.
More importantly, the RACI matrix must accurately reflect the actual operational model. The vendor might be responsible for handling the majority of tickets, but the business still needs to maintain accountability for decisions impacting access rights, risks, production systems, and business operations.
IT Helpdesk & IT Support from IPSIP Vietnam
If the business is preparing to outsource an IT Helpdesk or wishes to standardize its coordination with current vendors, IPSIP supports businesses in developing plans based on actual conditions before deploying IT Helpdesk & IT Support services.
References:
