SOC 2 for MSPs and MSSPs: what customers require

Does an MSP need SOC 2 for SOC 2 for MSPs requirements in customer contracts?

SOC 2 is not a legal requirement in itself. It is a customer assurance report, issued only by an independent CPA firm after an examination of the provider's controls. The managed service provider owns those controls, and an implementation partner can prepare systems and evidence, but only the CPA firm issues the report. What makes a customer ask for one is usually the contract, a tender question or a regulator's third-party expectations, so the first task is to read what the contract actually requires: a report type, a period, a set of criteria, or simply evidence of controls.

Three factors change how strongly the question applies. The first is privileged access: if your staff can reach customer environments through remote management tools, administrative consoles or service accounts, customers will expect the same scrutiny applied to your own administrators. The second is multi-tenancy: when many customers share one monitoring platform, ticketing system or remote management stack, a weakness in that shared layer affects every customer at once, and buyers will want to see it examined. The third is subservice providers: the cloud host, the SIEM vendor and any backup service beneath your platform will shape what your report must describe, and you should confirm with your CPA firm whether those providers are carved out or included. Ask each customer which of these three factors their contract relies on before you decide what a report needs to cover.

What customers expect from an MSP under the CISA advisory

CISA advisory AA22-131A was written for managed service providers and their customers, and buyers now use its recommendations as a checklist when they review an MSP's SOC 2 report. The cards below set out six expectations, the SOC 2 criterion each one touches and the evidence an auditor will ask to see.

MFA on every access account

The advisory recommends multi-factor authentication on every account that reaches customer environments, and treating those accounts as privileged. For SOC 2 this sits under CC6 logical access, where the auditor tests whether privileged access is granted, authenticated and reviewed. Check that MFA covers the provider's own staff, service accounts that can be used interactively, and remote tooling. Evidence usually means identity provider configuration exports, MFA enforcement reports and a list of accounts with customer access.

Retained logs and a segregated SIEM

The advisory recommends keeping the most important logs for at least six months in a segregated logging regime, such as a SIEM. This maps to CC7 system operations, where the auditor looks for event monitoring and evidence that security events are reviewed. Confirm that the logs cannot be altered by the administrators whose actions they record, and that retention is set in configuration rather than by habit. Evidence includes retention settings, log forwarding configurations and samples of reviewed alerts.

Written scope of included services

The advisory says an MSP should explain in writing which services are and are not included. This supports CC2 communication, because customers must understand what the provider does and does not control. Ambiguity here is the most common source of disputes after an incident, and it also shapes the system description an auditor reads. Check that the service catalog, the contract and the SOC 2 system description describe the same boundaries. Evidence includes signed service schedules and the customer-facing responsibility matrix.

Contract terms for hardening and response

Contracts should state which party owns hardening, detection and incident response for each system. Under CC9.2, the provider must assess and manage risks from business partners, and a customer's own controls depend on this split. The provider's controls should match the duties it accepts, and the complementary user entity controls in the report should name what the customer must still do. Evidence includes the signed contract, the responsibility matrix and the incident escalation terms.

Limited, audited and disabled MSP accounts

The advisory asks customers to limit MSP accounts to the systems the provider manages, audit their use, and disable them when idle or when the contract ends. For the provider, this is a CC6 control over access provisioning and removal. Auditors typically sample joiner, mover and leaver records and check that customer-side accounts were removed on termination. Confirm that the provider keeps its own register of customer accounts and reviews it on a set schedule. Evidence includes the account register, periodic access reviews and offboarding tickets.

Regularly tested isolated backups

The advisory recommends backups that are isolated from the systems they protect and tested on a regular basis. This falls under the availability criteria where in scope (A1 backup and recovery) and under CC7 recovery work. A backup nobody has restored is not evidence of recovery, so ask for restore test records along with backup job logs. Check that backup credentials are separate from production administration. Evidence includes backup schedules, isolation design, restore test results and the dates of the last test.

How SOC 2 for MSPs scopes a multi-customer service

An MSP's SOC 2 starts with the system description, and for a shared platform serving many customers the central decision is the boundary: which services, tenant environments, admin consoles, monitoring stacks and support teams sit inside the examined system, and which customer populations the report is written for. Define the boundary by service line, not by customer, and state which customer environments are managed through the platform and which are only reachable by ticket. The description is management's document, prepared against the AICPA's 2018 description criteria, so the provider owns every statement in it. Every SOC 2 still runs the common criteria CC1.1 to CC9.2 across the whole in-scope system, so the control environment, access, change management and vendor risk (CC9.2) must be shown to cover the shared tooling that all customers depend on, not only one flagship service.

Two reporting concepts decide what customers must do themselves and what the provider can point to elsewhere. Complementary user entity controls (CUECs) are the controls the customer must operate for the service to be secure, such as reviewing its own MSP account list, approving privileged changes to its environment, or configuring its own retention where the contract leaves it to the customer. Complementary subservice organization controls (CSOCs) cover the cloud hosting, backup, identity and monitoring tools the provider relies on. Under an inclusive method the subservice organization's controls are described and tested within the report; under a carve-out method they are excluded and the subservice organization's own SOC report is referenced instead. The AICPA's SOC 2 Report Walkthrough course explains both. Confirm with your CPA firm which method fits each backup and tooling provider, and ask for the subservice reports and bridge letters early.

NIS2 changes the question a customer asks. Under Annex I, managed service providers and managed security service providers can be in scope when they meet the size-cap rule, and recital 86 calls for increased diligence when selecting managed security providers. A SOC 2 report is useful evidence for that diligence, but it is not a NIS2 certificate, and it does not by itself show the Article 21 risk-management measures or incident reporting duties. Check the report's in-scope system, carve-outs and CUECs against those obligations, and confirm your own size category and national transposition with counsel before quoting the directive to a customer. The Commission's implementing regulation, Regulation (EU) 2024/2690, sets the technical requirements that apply to in-scope providers, and it should be read alongside the report rather than in place of it.

What a SOC 2 for an MSP costs and who is paid for each part

This table separates the cost lines of an MSP or MSSP SOC 2 engagement by who is paid, whether the cost is one-time or recurring, and what pushes it up. Use it to build a request for quote that prices each line on its own, since a single lump sum hides the recurring Type 2 and tooling costs.

Cost component	Who is paid, and for what	One-time or recurring	What drives it up or down
CPA firm examination	The CPA firm performs the examination and issues the report, which the organization owns and cannot have prepared by the same firm if independence rules bar it	One-time per report; recurring each period for a Type 2	Number of customer-facing services in scope, number of subservice providers, and whether a SOC 1 or extra categories are added
Implementation partner	Prepares systems, access tooling and evidence collection; does not issue any report	Usually project-based, with optional recurring support	Number of customer tenants and environments to separate, current maturity of access and logging, and how many policies must be written
SIEM and log platform	Licensing or hosting for a segregated logging regime that retains the most important logs for at least six months	Recurring	Log volume across customer tenants, retention period, and whether the platform is self-hosted or licensed per data volume
Access and identity tooling	MFA, privileged access management and account review tools for accounts that reach customer environments	Recurring license plus one-time configuration	Number of MSP staff accounts, number of customer tenants accessed, and whether customers require separate identity providers
Internal staff time	Control owners, system administrators and managers who perform access reviews, change approvals and evidence requests	Recurring effort across the year	Number of control owners, how often reviews are run, and whether evidence is collected automatically or by hand
Penetration test requested by the examiner	A qualified tester engaged by the organization, scoped with the examiner and the customer contract	One-time per test, repeated when the environment changes	Size of customer-facing estate, number of tenants in scope, and whether testing covers customer management consoles
Subservice provider reviews	Staff time to collect and review vendor SOC reports, plus any bridge letters needed for periods the reports do not cover	Recurring	Number of cloud, remote management and security tool vendors, and whether they are carved out or included

Who does what: the MSP, the implementation partner and the CPA firm

The managed service provider owns the SOC 2 program. The organization decides which services fall inside the system boundary, writes the policies, runs the control activities day to day and accepts the risk of each control that fails. Management also prepares the description of the system, evaluated against the AICPA's 2018 SOC 2 description criteria (DC 200), and signs the written representations the examination requires under AT-C section 205. The MSP's team is also the party customers hold to the contract, so it decides who has access to which customer environment and how those accounts are approved and removed.

Controls and policies: Write and approve the information security policy, access standards, change and incident procedures, and the vendor management process that CC9.2 asks for.
Customer contracts: Define in writing which party owns hardening, detection and incident response, and which services are excluded, as the CISA advisory AA22-131A recommends.
Access decisions: Approve, review and remove staff access to customer environments, including MFA and privileged handling for every account that reaches a customer.
System description: Document the services, infrastructure, subservice organizations and complementary user entity controls that customers must maintain.
Evidence ownership: Keep the tickets, reviews, logs and approvals that prove each control operated during the observation period.

Before engaging anyone, confirm internally who will sign the management assertion and who answers auditor requests on each criterion.

How an MSP moves from scoping to a SOC 2 report

This sequence turns a managed service into a defined, testable system with evidence an independent CPA firm can examine. Each step produces a document or check that the next step depends on, so gaps surface before fieldwork rather than during it.

Define the service and customer population
Leadership, with the security and operations leads, decides which managed services fall inside the examination and which customer environments the provider touches to deliver them. The output is a written scope statement that lists services, customer types, the tooling used for remote access and monitoring, and the services explicitly excluded. Ask the CPA firm to review this statement before any system description work begins, because every later step inherits its boundaries.
Choose the report type and period with the CPA firm
The provider and its CPA firm agree whether the first report is a Type 1 or a Type 2, which trust services categories apply beyond security, and whether the period will follow the provider's own fiscal calendar. Security is always covered through the common criteria, so the decision concerns the additional categories. The output is an engagement letter and a written timeline tied to the agreed scope, which you should request from both the CPA firm and any implementation partner before committing.
Write the system description
The provider documents the infrastructure, software, people, procedures and data that support the managed service, including the administrative consoles, jump hosts, remediation tooling and logging stack used to reach customer environments. The description follows the AICPA description criteria, and it must state clearly which responsibilities belong to the provider and which belong to the customer. The output is a draft system description that engineering and the CPA firm both review until the boundaries match how the service actually runs.
Map controls to the criteria and CC9.2
The team builds a control matrix that links each in-scope control to the relevant common criteria, such as CC6 access controls, CC7 system operations and CC9 risk mitigation. CC9.2 requires the provider to assess and manage risks from vendors and business partners, so the matrix must include the tooling vendors, hosting providers and any subservice organizations, along with how each is reviewed. The output is a control matrix with a named owner, evidence source and test frequency for every control.
Implement access, logging and backup controls
Engineers put the controls the matrix describes into operation: multi-factor authentication for every account that reaches customer environments, accounts limited to the systems each customer contracts for, prompt disablement of unused or departed accounts, centralized logs retained for the period the provider sets, and isolated backups that are restored in tests. CISA advisory AA22-131A recommends several of these practices, and the provider should confirm each against its own risk assessment. The output is a working configuration baseline and a record of when each control went live.
Collect evidence into a library
Control owners gather the records an auditor will sample, including access reviews, MFA enrollment reports, account joiner and leaver tickets, log retention settings, backup restore results, change approvals and vendor reviews. Evidence is stored under the control ID it supports, with dates and the name of the reviewer. The output is an evidence library that a person outside the team can navigate without help. Ask your CPA firm which formats and sampling populations it expects before collection starts.
Run a readiness review
Before the examination, an internal reviewer or an independent advisor walks through the matrix and evidence library against the criteria and the customer-facing commitments in contracts. The reviewer records gaps such as missing evidence, controls that operate inconsistently across customers, or responsibilities written differently in the description and the contracts. The output is a set of readiness findings with owners and closure dates. Closing these findings is the provider's responsibility, and DeployOpen can support the remediation work if it is written into the agreed scope.
Complete fieldwork and receive the report
The CPA firm tests the controls, samples evidence, interviews staff and reviews the system description, and in a Type 2 examination it evaluates operating effectiveness across the observation period. The provider answers requests, explains exceptions and signs the written representations management must provide. The output is the SOC 2 report issued by the CPA firm, which only the auditor can issue. The provider then decides how it shares the report under the access restrictions that apply to a SOC 2.

What usually delays an MSP's SOC 2 and how to avoid it

Most delays in an MSP's SOC 2 trace back to a few structural gaps rather than missing tools. The six cards below cover access, logging, responsibility boundaries, subservice providers, contract language and evidence collection, which together decide whether the examination runs in one cycle or stalls in fieldwork.

Shared administrator accounts

Shared administrator accounts often predate the examination and were created for convenience across engineers and customer tenants. They make it impossible to attribute actions to a person, which weakens the access and logging criteria in CC6. The fix is named, individual privileged accounts with multi-factor authentication, limited to the systems each engineer manages, and a periodic review that removes accounts no longer needed. Evidence is the account inventory, the review sign-off and sample login records tied to named users. CISA's advisory AA22-131A treats accounts that access customer environments as privileged, so check that the list covers them all.

Log retention below policy

Logs are often kept for a shorter period than the provider's own security policy promises customers. When an assessor samples events from months earlier and finds nothing, the monitoring criterion in CC7 becomes an exception. Set retention for the most important logs at or above the period your policy states, and confirm the platform keeps them in a segregated store such as a SIEM so an attacker with tenant access cannot alter them. CISA advises keeping the most important logs for at least six months. Evidence is the retention configuration, a sample retrieval from the oldest retained date, and access records for the log store.

Undefined provider and customer boundaries

When a contract does not say who owns hardening, detection and incident response, both parties assume the other is covering it. For an MSP, this shows up as gaps in CC2 communication and CC9 risk mitigation, and it often surfaces during fieldwork when a control appears in one party's description but not the other's. Write a responsibility matrix per service tier that lists each control, the owner and what is excluded. CISA recommends that MSPs state in writing what is and is not included. Evidence is the signed matrix, the contract clauses that reference it, and tickets showing each party acted within its stated role.

Subservice providers left out of the description

Hosting providers, backup vendors, remote monitoring tools and ticketing platforms are subservice organizations, and the system description must say how they are handled. Leaving them out, or describing them inconsistently, creates a mismatch between what the description claims and what the operating controls cover. Decide whether each provider is carved out or included, document the complementary subservice organization controls the MSP relies on, and collect the vendor's own SOC report or bridge letter. Evidence is the vendor register, the subservice reports on file with review notes and the description section that names each provider.

Contract language that conflicts with the report

Customer-facing contracts and sales material sometimes promise controls the examination does not test, such as continuous monitoring, specific response times or retention periods that differ from the report. An assessor reads those promises against the system description, and a conflict can turn into an exception or a question from every customer who reads the report. Review master service agreements, security addenda and marketing pages against the description before the observation period starts, and align the wording with what the controls actually do. Evidence is a clause-to-control mapping and a record of the legal review.

Manual evidence across customer environments

An MSP that gathers evidence by hand from each customer tenant repeats the same work for every client and multiplies the sample requests an assessor makes. The result is inconsistent screenshots, missed periods and long fieldwork. Centralize configuration and access data in one platform that reads all tenants, export it on a fixed schedule, and keep the scripts that produce it under version control. Confirm with your assessor which populations they will sample, since the population must be complete for each control. Evidence is the scheduled export log, the population list per control and a reproducible query that yields the same result on rerun.

Which report and boundary fits an MSP: Type 1 or Type 2, inclusive or carve-out

This table compares a SOC 2 Type 1 and Type 2 report, and inclusive versus carve-out treatment of the subservice providers an MSP relies on, such as its remote monitoring platform, cloud host and ticketing vendor. Read each row against your first customer tender or renewal request to see which combination matches the evidence buyers actually ask for.

Option	What it proves	When it fits an MSP	Question to ask the CPA firm
SOC 2 Type 1	System description and design of controls as of one date	A new MSP whose first customer tender asks for a SOC 2 and whose managed security service is recently launched	Will a Type 1 satisfy the tender wording, and what date will the report state?
SOC 2 Type 2	Design plus operating effectiveness of controls over an observation period	An established managed security service where customers request evidence that MFA, log retention and access reviews ran consistently	How long is the observation period, and which controls will you sample from it?
Type 1 then Type 2	Design first, then sustained operation across a period	An MSP that needs a report quickly but expects customers to ask for operating evidence in the following year	How do you carry the Type 1 findings into the Type 2 scope and timing?
Inclusive subservice treatment	Subservice provider controls are described and tested within your report	Smaller providers with a limited number of key vendors, where customers want one report covering the whole service	Which subservice controls will you test directly, and what evidence will you need from each vendor?
Carve-out subservice treatment	Your report excludes the subservice provider's controls, which are covered by that provider's own SOC report	Providers whose cloud host or monitoring platform already publishes a current SOC 2 that customers can review	Which vendor reports can we rely on, and which complementary subservice organization controls must we document?
Responsibility split in the contract	Who owns hardening, detection and incident response, as CISA AA22-131A advises contracts define	Any MSP, because the report boundary should match the written service description	How do the system description and the contract line up on hardening, monitoring and incident response?
Customer complementary user entity controls	Controls customers must run on their side, such as reviewing their own account access	MSPs that manage customer tenants or accounts, where customer actions affect the service	Which customer-side controls will you list, and how will we communicate them to customers?

Questions MSPs and MSSPs ask about SOC 2

Is SOC 2 legally required for managed service providers?

No general law requires a SOC 2 report from every managed service provider. In practice, SOC 2 is usually a contractual requirement from customers, their insurers or their auditors. NIS2 is a separate question: whether an MSP or MSSP is in scope depends on the size-cap rule and the sector it serves, not on whether it holds a SOC 2 report. Check with counsel whether your customers' contracts or your own sector rules apply to you, and confirm the size-cap test against the text of Directive (EU) 2022/2555 before deciding. A SOC 2 is a useful way to show customers controls, but it does not prove NIS2 compliance on its own.

Can a SOC 2 report cover only one service line?

Yes, the report can be scoped to a defined service, provided the system description states clearly which services, infrastructure, people, procedures and data are included. A managed monitoring service, a backup service and a help desk may each sit inside different boundaries. The practical question is whether shared identity systems, consoles, ticketing and logging platforms serve several lines, because those shared components usually have to be inside the boundary wherever they are used. Expect the auditor to test that the scope matches what customers actually buy. Ask the auditor to confirm the boundary in the engagement letter before fieldwork starts.

How much internal effort does a SOC 2 take, and what must the provider supply?

Effort depends mostly on how many systems are in scope, how well existing controls are documented, and how many people run the consoles that reach customer environments. The provider owns its controls and must supply the system description, policies, a control matrix, access reviews, change records, vendor reviews, incident records and evidence that controls operated throughout a Type 2 observation period. Some organizations also hire outside help to prepare systems and evidence, while the CPA firm alone issues the report. Ask any consultant for a written scope, a list of deliverables and a list of tasks that remain with your staff before you sign.

Can the firm that implements our controls also be our SOC 2 auditor?

No. The auditor must be independent of the organization it examines, so the firm that designs, builds or prepares your controls cannot issue your SOC 2 report. An implementation partner can prepare systems, configuration evidence and documentation, but only an independent CPA firm performs the examination and issues the report. Independence rules also limit what the auditor may build for you. Buyers should keep the preparation work and the examination in separate engagements and confirm the auditor's independence position in writing before work begins.

Can customers rely on our report if we use a cloud or backup vendor?

Often yes, but only if the vendor's role is handled correctly in the report. A subservice organization can be included in your report with its controls tested, or carved out, in which case its own SOC report is referenced and you must show how you monitor it. Your report also depends on complementary user entity controls, which are controls customers must run themselves. CC9.2 requires you to assess and manage risks from vendors and business partners, so collect each critical vendor's current report, review its exceptions and document the review. Confirm with your auditor whether each cloud, backup and tooling vendor is inclusive or carved out, and whether a bridge letter is needed for any gap.

How often does a SOC 2 report need to be renewed?

A SOC 2 report has no legal expiry date, but customers usually treat a report as current for about twelve months after the end of its examination period. A Type 2 report covers an observation period, often several months, and most providers renew on an annual cycle so that the new period starts before the old report goes stale. Customers may ask for a bridge letter to cover any gap between periods. Plan the observation window around your customers' contract dates, and ask your auditor for a renewal timeline when you sign the engagement letter.

What do CISA's MSP recommendations expect that a SOC 2 report may not show?

CISA advisory AA22-131A recommends MFA on every account that reaches customer environments, treating those accounts as privileged, and retaining the most important logs for at least six months in a segregated logging regime. It also asks contracts to state who owns hardening, detection and incident response, and to limit customer-side accounts to the systems you manage. A SOC 2 tests whether your controls operated against your own criteria, so the report will only reflect these practices if they appear in your control set. Map the advisory's points to your control matrix and confirm the mapping with your auditor before the observation period starts.

How DeployOpen prepares an MSP's systems and evidence for a SOC 2

DeployOpen plans, implements and hardens self-hosted open-source platforms inside your own infrastructure, then prepares the systems, controls and evidence a SOC 2 examination will test. The CPA firm performs the examination and issues the report; DeployOpen does not issue audit reports or attestations.

How we scope

Engagements are fixed-scope, with systems, customer boundaries and deliverables agreed in writing before work starts
We map which customer-access accounts, logging sources and vendor relationships fall inside the described service
The written scope states which responsibilities sit with your organization and which sit with each customer

How we build

We configure MFA on every account that reaches customer environments and restrict MSP accounts to the systems each customer contracts
We set up centralized, segregated log collection with retention periods agreed against your contracts and the advisory guidance
We document hardening baselines, backup and restore tests, and change records as infrastructure code where the platform supports it

How we hand over

You receive a documented control set with the evidence each control produces and the owner responsible for it
Runbooks cover account onboarding, offboarding, access reviews and incident escalation for customer environments
We walk your team and your CPA firm through the evidence locations so the examination can sample them directly

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover
Retainers can cover recurring access reviews, log checks and backup restore tests between examination periods
Changes to customer scope or platforms can be re-documented so the system description stays accurate for the next period

SOC 2 for MSPs and MSSPs