SOC 2 by industry
SOC 2 for MSPs: the keys you hold to other people's systems.
A managed service provider is trusted with administrator access to dozens of client environments at once. One stolen technician account can reach all of them. That is why clients, and their insurers and auditors, want independent evidence of how an MSP controls that access. This guide covers how an MSP scopes a SOC 2, which tools count, and how responsibilities are split with clients.
Back to SOC 2 services01 · Who asks
Who asks MSP companies for a SOC 2 report
The buyer decides the scope and the weight of the report, so start with who is asking.
| Asked by | What they want to see |
|---|---|
| Mid-sized clients outsourcing IT | How technician access to their systems is granted, recorded and removed, and how quickly they are told about incidents. |
| Clients in regulated sectors | A report they can place in their own vendor file for their regulator or examiner. |
| Clients' cyber insurers | Sometimes evidence that the MSP uses multi-factor authentication and secures its remote management tools. |
| Clients' financial auditors | Occasionally a SOC 1 if the MSP runs systems that affect the client's financial reporting. |
02 · What is in scope
What sits inside the system boundary
The report covers one system. In this sector the boundary usually takes in:
- Remote monitoring and management (RMM) platform
- The tool that can run scripts on every managed device. The single most sensitive system an MSP has.
- Privileged access and password vault
- Where client admin credentials are stored, checked out and rotated.
- Professional services automation and ticketing
- Where client requests are logged, approved and linked to changes made on their systems.
- Backup service
- Client backups the MSP runs, monitors and restores on request.
- Technicians and the service desk
- The people with access, their onboarding, training and offboarding.
03 · Categories
Which Trust Services Categories matter here
Security is always in. The rest depend on what you promise customers.
| Category | Weight in this sector | Why |
|---|---|---|
| Security | Core | Always included. Privileged access into client environments is the whole risk. |
| Availability | Common | Clients pay for monitoring and response. Backup and restore commitments are tested here. |
| Confidentiality | Common | Technicians see client documents, mailboxes and configurations. Disposal when a client leaves matters. |
| Processing Integrity | Rare | Seldom a fit for IT services, unless the MSP runs a defined processing service such as patch compliance reporting clients rely on. |
| Privacy | Rare | MSPs act for clients and rarely hold their own relationship with individuals. |
04 · Vendors in the report
The vendors that appear in your report
Each one is a subservice organization or a carve-out, and the report has to say which.
- RMM and PSA vendors
- Usually hosted by the vendor, so carved out. Their security is your clients' exposure; review their reports closely.
- Backup storage provider
- Carved out, with CSOCs for storage durability and encryption.
- Security tooling vendors (endpoint detection, email security)
- Subservice organizations if your monitoring controls rely on their detection.
- Subcontracted technicians or offshore desks
- Inside your controls if they use your accounts. Otherwise a vendor whose access you must oversee.
05 · Sector controls
Controls that this sector makes necessary
Examples only. Your own wording is what the auditor tests.
- S.1Phishing-resistant MFA on the RMM and vaultTechnicians sign in to remote tools with phishing-resistant authentication. Shared logins are not allowed.
- S.2Credentials checked out, not knownClient admin passwords live in the vault, are checked out per ticket and rotated after use where the client's system allows.
- S.3Every client action traces to a ticketRemote sessions and scripts run on client systems link to a ticket that records the request.
- S.4Script library under change controlScripts that can run across many clients at once are reviewed and approved before they are added.
- S.5Technician offboarding same dayWhen a technician leaves, access to the RMM, vault and all client tenants is removed the same day and confirmed.
- S.6Client offboarding removes all accessWhen a client leaves, agents are removed, stored credentials are deleted and the client receives confirmation.
- S.7Restore tests per client tierRestores are tested on a schedule agreed by service tier, and results are shared with the client.
06 · Traps
Where companies in this sector slip
Predictable, and cheaper to fix before fieldwork.
- Scoping the office, not the tools. The MSP's own laptops and email matter, but the RMM, vault and backup console are what reach clients. They must be inside.
- Accounts that live in client tenants. Technician accounts created inside each client's directory are easy to forget at offboarding. Keep a register by client.
- One-off scripts pushed fleet-wide. A quick fix sent to every client without review is a change-management exception and a real risk.
- Unclear duty split with clients. Who approves a firewall change, who reviews user lists? Without written CUECs, gaps fall between you.
- Backup monitoring with no restore evidence. Green job statuses prove the job ran, not that data comes back. Keep restore test records.
07 · Access into clients
Controlling privileged access into client environments
The access lifecycle for one technician and one client, with what to keep at each stage.
Grant
A technician is assigned to a client.
- What happens
- Request raised and approved by a service lead
- Least-privilege role chosen in the RMM and vault
- You get
- Approval record
- Role assignment log
- Good practice
- Access tied to named clients, not 'all clients'
- Watch for
- Copying a senior technician's permissions
Use
Work happens on client systems.
- What happens
- Sessions launched from the RMM against a ticket
- Credentials checked out from the vault
- You get
- Session logs linked to tickets
- Vault checkout history
- Good practice
- Session recording for high-privilege work
- Watch for
- Saved passwords in browsers or notes
Review
Access is checked on a schedule.
- What happens
- Periodic review of who can reach each client
- Clients receive their technician list
- You get
- Signed review records
- Client acknowledgements
- Good practice
- Unused access removed at review
- Watch for
- Reviews that only cover your own directory
Remove
A technician moves off the client or leaves.
- What happens
- RMM, vault and in-tenant accounts disabled
- Shared credentials they used are rotated
- You get
- Offboarding checklist with timestamps
- Good practice
- Removal confirmed in each client tenant
- Watch for
- Leaving client-side accounts for the client to find
08 · Evidence
Evidence to have ready
What an auditor will ask for, in the order they usually ask.
- The register of technicians and which clients each can access
- RMM and vault sign-in configuration showing enforced MFA
- Tickets sampled against remote session logs
- Script library change approvals
- Technician offboarding records, including client-tenant accounts
- Restore test results by client tier
- Your review of RMM, PSA and backup vendors' reports
When a client's auditor asks for SOC 1
If you host or operate systems that feed a client's financial statements, such as an accounting platform or payroll server, their financial auditor may need a SOC 1 report under AT-C section 320 rather than a SOC 2. The two can share many IT general controls, but they answer different readers and use different criteria.
Sources: AICPA Trust Services Criteria (TSP section 100), common criteria CC6 (logical access) and CC8 (change management); AICPA Description Criteria (DC section 200) on complementary user entity controls; AICPA SSAE 18, AT-C section 320.
More about SOC 2 for MSP
Our clients' environments are all different. Can one report cover them?
Yes. The report covers your service, not their estates.
The system is the managed service you deliver: your tools, people and procedures. Client environments sit outside the boundary. What you do inside them is described through your controls, and what clients must do is described as CUECs.
Do co-managed clients with their own IT team change our scope?
They change the CUECs.
Where a client's team shares admin duties, write down who approves changes, who reviews accounts and who responds to alerts. Those become complementary controls specific to the co-managed service line.
Our RMM vendor had a serious incident during our period. What now?
Describe it, and show your response.
An incident at a vendor is not automatically an exception in your report. The auditor will look at how you monitored the vendor, how you responded and what you told clients. Keep that record as it happens.
Should our small offshore support desk be in scope?
If they touch client systems, yes.
Anyone using your remote tools against client environments is part of the system. Whether employed or contracted, they need the same onboarding, access review and offboarding evidence.
Scope your MSP SOC 2 around what buyers ask.
A readiness assessment turns this into your boundary, your categories and your gaps.