SOC 2
Readiness: The MSP’s Guide to Trust and Verification
Published: 2026-02-27 Category: SOC
2 Compliance Tags: SOC 2, Type II, Trust Service
Criteria, AICPA, MSP compliance, vendor assessment Reading
Time: ~10 min Editorially Reviewed: Against
AICPA Trust Services Criteria (2017, updated 2022)
Why
Your Clients Are Asking for SOC 2 — and What They’re Actually
Evaluating
SOC 2 used to be a nice-to-have for technology service providers.
Over the past five years it has become a sales qualifier — not a
differentiator. Enterprise procurement teams, healthcare organizations,
financial institutions, and increasingly mid-market companies now
include “current SOC 2 Type II report” in their vendor requirements
before a contract conversation starts.
If you’re an MSP without a SOC 2 report, you’re either not selling to
organizations large enough to ask for it, or you’re losing deals to
competitors who have one and not knowing why. If you’re an organization
evaluating MSP partners, you should understand what a SOC 2 report
actually tells you — because a Type I report from 2023 isn’t the same
thing as a current Type II, and the nuance matters.
This guide covers what SOC 2 actually requires, how to evaluate
readiness (or a potential partner’s readiness), and what the path from
zero to Type II looks like in practice. It’s written for organizations
at the decision stage — comparing options, not learning
fundamentals.
SOC 2 Is Not a
Certification — It’s an Audit Report
This distinction matters. ISO 27001 is a certification — a third
party certifies that your organization’s ISMS meets the standard. SOC 2
is an attestation report — a licensed CPA firm (specifically, a firm
enrolled in the AICPA’s peer review program) audits your controls and
issues an opinion on whether they meet the Trust Services Criteria.
You cannot be “SOC 2 certified.” You can have a SOC 2 Type I or Type
II report.
SOC 2 Type I — A point-in-time assessment. The
auditor examines whether your controls are designed appropriately as of
a specific date. It does not test whether those controls operated
effectively over time. Type I is often used as a stepping stone when an
organization has recently implemented its control framework.
SOC 2 Type II — An assessment over a period of time
(typically 6–12 months). The auditor tests whether controls operated
effectively throughout the audit period. This is the report that
enterprise clients want, because it demonstrates that your controls
actually worked — not just that they existed on a specific day.
Practitioners who work through SOC 2 readiness engagements
consistently report that clients who receive a Type I report expecting
it to satisfy enterprise procurement requirements are frequently
disappointed. Enterprise procurement teams distinguish between Type I
and Type II, and increasingly specify Type II with audit periods of at
least 6 months.
The
Trust Services Criteria: What SOC 2 Actually Measures
SOC 2 is built on the AICPA’s Trust Services Criteria (TSC),
published in 2017 and updated in 2022. There are five Trust Service
Categories:
- Security — The system is protected against
unauthorized access (logical and physical) - Availability — The system is available for
operation and use as committed or agreed - Processing Integrity — System processing is
complete, valid, accurate, timely, and authorized - Confidentiality — Information designated as
confidential is protected as committed or agreed - Privacy — Personal information is collected, used,
retained, disclosed, and disposed of in conformity with commitments
Security is the only mandatory category. All SOC 2
reports must cover the Security criteria. The additional categories are
in scope only if they’re relevant to the services being audited and
included in the service description. An MSP’s SOC 2 report might cover
Security + Availability + Confidentiality without including Processing
Integrity or Privacy if those categories don’t apply to their service
model.
When evaluating a SOC 2 report from a potential partner, check which
categories are in scope. A report covering only Security tells you
nothing about the vendor’s availability commitments — if uptime is
critical to your use case, Availability needs to be in scope.
The Common
Criteria: The Foundation of Security
The Security category is organized into 9 “Common Criteria” (CC)
groupings. These map to the controls any MSP or technology service
provider needs to have in place:
CC1: Control Environment — Organizational commitment
to integrity and ethics, board oversight of internal controls,
organizational structure and reporting lines, commitment to
competence
CC2: Communication and Information — Internal and
external communication of security policies, third-party
communication
CC3: Risk Assessment — Risk identification, risk
analysis, and response to fraud risk
CC4: Monitoring Activities — Ongoing monitoring of
controls, evaluation of deficiencies
CC5: Control Activities — Policies and procedures
that address identified risks, including technology controls
CC6: Logical and Physical Access Controls — This is
the densest category for technology organizations. It covers: logical
access provisioning, role-based access, MFA, password management, access
reviews, physical access to facilities and data centers, and removal of
access upon termination.
CC7: System Operations — Vulnerability management,
monitoring for security events, incident identification and response,
recovery from security incidents
CC8: Change Management — Change control processes,
quality assurance, emergency changes, testing
CC9: Risk Mitigation — Third-party vendor
management, insurance coverage for risk transfer
The Common Criteria are detailed and prescriptive. CC6 alone
generates significant audit evidence requirements — user access reviews,
MFA enrollment records, access provisioning workflow documentation,
physical access logs, and termination checklists are all in scope.
The SOC 2
Readiness Gap: Where MSPs Most Commonly Fail
Based on what practitioners see when MSPs first engage for SOC 2
readiness assessments, the gaps cluster in predictable places:
1. No Formal Risk Assessment
Process
CC3 requires a documented, repeatable risk assessment process. “We
think about risks” isn’t the same as a documented framework for
identifying, scoring, and responding to risks. MSPs typically need to
implement a formal risk register with defined methodology before their
audit period starts.
2. Undocumented Change
Management
CC8 requires evidence that changes to systems go through a defined
change control process — review, approval, testing, documentation. MSPs
that deploy updates immediately from vendors without documented change
tickets fail this control. Even informal processes need documentation
trails that an auditor can examine.
3. Inadequate Vendor
Management
CC9 requires documented processes for assessing and monitoring
third-party vendors. For MSPs, this means maintaining a vendor
inventory, collecting SOC 2 reports or equivalent evidence from your own
vendors (backup, RMM, ticketing, email), and reviewing those reports
annually. If your RMM platform or cloud backup provider has a SOC 2
report and you haven’t read it, you’re not meeting CC9 requirements.
4. Access Reviews Not
Happening
CC6 requires periodic reviews of user access to confirm that access
remains appropriate. Many MSPs have access provisioning processes but no
deprovisioning discipline — former employees or contractors retain
access, and quarterly access reviews don’t happen. An auditor testing
this control will pull access review records; if they don’t exist, it’s
a finding.
5. Incident Response Plans
Not Tested
CC7 requires not just a documented incident response plan but
evidence that it’s been reviewed and tested. A plan that’s been written
and never exercised is a finding. Tabletop exercises with documented
outcomes are typically sufficient for smaller organizations, but they
need to be scheduled and documented.
6. Policies Not
Updated to Match Actual Practice
Perhaps the most frequent finding: policies written during an initial
SOC 2 effort that don’t reflect how the organization actually operates.
If your access policy says MFA is required for all remote access but
your audit evidence shows users accessing systems without MFA, you have
a control failure — not just a policy gap.
Type I to Type II: The
Practical Roadmap
The typical timeline for an MSP going from no SOC 2 program to a Type
II report:
Months 1–3: Readiness Assessment and Gap Remediation
– Select a SOC 2 auditor (AICPA-enrolled CPA firm with technology audit
experience) – Define the scope of services covered by the report and
which Trust Service Categories apply – Conduct a gap assessment against
the applicable Common Criteria – Prioritize and remediate gaps —
policies, procedures, technical controls – Implement evidence collection
processes for controls that need ongoing documentation
Months 3–6: Control Operation Period (Minimum for Type
II) – Controls must operate, and evidence must be collected,
throughout the audit period – This is where MSPs that rush to get Type
II reports fail — they remediate controls and immediately try to audit,
but AICPA guidance requires evidence of control operation over time, not
just at a point in time – Minimum audit period for Type II is typically
6 months; 12 months is the standard that enterprise clients expect
Month 6–9: Fieldwork and Report – Auditor conducts
fieldwork: interviews, evidence review, control testing – Auditor issues
draft report; management responds to findings – Final report issued with
auditor’s opinion
A SOC 2 Type II report with an unqualified opinion (no significant
findings) from a credible CPA firm is the goal. A report with multiple
qualified findings or exceptions signals to clients that the controls
described didn’t actually operate as designed — which is often worse
than not having a report at all.
Total realistic timeline: 9–15 months from zero to a
first Type II report with a standard 6–12 month audit period.
What
to Look for in a SOC 2 Report from a Potential Vendor
If you’re evaluating a vendor or MSP partner’s SOC 2 report, here’s
what to actually examine:
1. Type and Audit Period Type II, with audit period
ending within the last 12 months. A Type II report from 18 months ago is
describing controls from 18+ months ago — anything could have changed
since. Enterprise vendor management programs typically require annual
re-attestation.
2. Scope of Services Does the report cover the
specific services you’re purchasing? A SOC 2 report for a vendor’s cloud
hosting platform may not cover their managed security services — these
might require separate or expanded scope.
3. Trust Service Categories Are the categories that
matter for your use case in scope? If you’re relying on a vendor for
system uptime (SLA), Availability should be in scope. If you’re trusting
them with confidential data, Confidentiality should be in scope.
4. Complementary User Entity Controls (CUECs) Every
SOC 2 report includes a section listing controls that the service
organization (the vendor) cannot implement — these must be implemented
by the user entity (you). If a vendor’s system requires you to manage
your own user access appropriately, that’s a CUEC. Read the CUEC section
carefully: any failure to implement these controls on your side voids
the protection the vendor’s controls are designed to provide.
5. Auditor’s Opinion and Exceptions Look for the
auditor’s opinion paragraph. “Unqualified” (sometimes called “clean”)
means the auditor found controls operated as described. Qualified
opinions or exceptions in the report mean specific controls didn’t
operate effectively — understand what those are before relying on the
report.
SOC 2
vs. ISO 27001: Which Does Your Client Actually Need?
This is a common decision-stage question. The short answer:
- SOC 2 is the standard for North American technology
service providers, especially when clients are enterprise organizations
in the US. It’s an audit attestation, not a certification. - ISO 27001 is the international standard — more
common in European markets, required for global enterprise clients, and
increasingly requested as a credential alongside SOC 2 for organizations
operating internationally.
They’re not mutually exclusive — many organizations pursue both. The
controls overlap significantly (AICPA and ISO have published mapping
documentation), and building toward both simultaneously is more
efficient than treating them as sequential projects.
For MSPs primarily serving North American enterprise clients, SOC 2
Type II is the immediate priority. Organizations with international
operations or clients should include ISO 27001 in their compliance
roadmap planning.
FAQ Schema
Q: How much does a SOC 2 Type II audit cost? A:
Costs vary significantly based on organization size, scope complexity,
and auditor. For a small-to-mid-size MSP, expect $15,000–$50,000+ for
the audit itself (not including readiness assessment or remediation
costs). Auditors certified by the AICPA and with technology sector
experience typically charge at the higher end but produce more
defensible reports. Readiness assessments add $10,000–$30,000 for
organizations without existing compliance programs.
Q: Can we use a SOC 2 readiness platform (like Vanta, Drata,
or Secureframe) instead of hiring consultants? A: These
platforms automate evidence collection and control monitoring, which
reduces audit preparation burden significantly. They don’t replace a
qualified auditor, and they don’t replace the need for genuine control
implementation. MSPs with no existing compliance program typically still
benefit from a human-led readiness assessment before engaging these
platforms — otherwise the platform monitors controls that haven’t been
properly designed.
Q: What is a “bridging letter” in the context of SOC
2? A: When a SOC 2 report covers an audit period that ended
more than 6 months ago, some vendors provide a “bridging letter” — a
representation letter from management that no significant changes to the
control environment have occurred since the audit period ended. This is
not an auditor opinion and is not equivalent to a current report. Many
enterprise procurement teams will not accept bridging letters as
substitutes for current reports.
Q: Does our MSP need SOC 2 if we have cyber
insurance? A: These serve different purposes. Cyber insurance
provides financial protection against losses from security incidents.
SOC 2 provides evidence to clients and prospects that your security
controls operate effectively. They’re complementary, not
interchangeable. Many cyber insurance underwriters are beginning to ask
for SOC 2 reports or equivalent control evidence during underwriting —
having a Type II report can improve your insurability and premium.
Q: How long does a SOC 2 report remain valid? A: SOC
2 reports don’t technically “expire” — they report on a specific audit
period. However, enterprise vendor management programs typically require
reports with audit periods ending within the last 12 months. After 12
months, the report is considered stale for most practical purposes.
Annual re-attestation is the industry standard.
From
Readiness to Report: Start with an Honest Assessment
The gap between “we’re planning to get SOC 2” and “we have a clean
Type II report” is typically 9–15 months and requires genuine control
implementation, not just documentation. Starting with a readiness
assessment gives you a realistic picture of where your gaps are and what
the audit period needs to demonstrate.
Request a Free
SOC 2 Readiness Assessment →
CertifyDefense serves MSPs and technology service providers building
toward SOC 2 compliance. Our readiness assessments are built against the
AICPA Trust Services Criteria — the same framework your auditor will
use.
Sources: AICPA, Trust Services Criteria for Security,
Availability, Processing Integrity, Confidentiality, and Privacy (2017,
updated 2022); AICPA, SOC 2® — SOC for Service Organizations: Trust
Services Criteria; AICPA, Mapping of NIST Cybersecurity Framework to SOC
2 (aicpa.org). Last reviewed: February 2026.
References: NIST SP 800-171 | CMMC program | 32 CFR Part 170
This content is for informational purposes only and does not constitute legal, compliance, or cybersecurity advice. Consult qualified professionals for guidance specific to your organization.
References: NIST SP 800-171 | CMMC program | 32 CFR Part 170
This content is for informational purposes only and does not constitute legal, compliance, or cybersecurity advice. Consult qualified professionals for guidance specific to your organization.