SOC 2 readiness vs. audit and why your MSP doesn't do audits

“Do you do SOC 2?” is one of the most common questions we hear from a growing software or services company. The answer is not a clean yes or no, and the fuzziness inside that answer is where most SOC 2 projects go sideways.

SOC 2 is not one thing. It is two distinct engagements, executed by two distinct firms, with different incentives and different deliverables. Understanding that split is the difference between a SOC 2 project that produces a clean report on schedule and one that wastes 6 months and comes back with a qualified opinion.

The two engagements

A SOC 2 project, done correctly, has two parts.

Readiness. The work of building, documenting and operating the control environment the audit will evaluate. Timeframe: 3 to 9 months. Done by the company’s internal team, a specialist consultancy or an MSP that handles the operational side.

Audit. The work of evaluating the control environment and issuing the attestation report. Timeframe: a few weeks of auditor fieldwork, plus a report-production cycle. Done by a licensed CPA firm.

These are separate contracts, separate firms, separate deliverables and, critically, separate professional responsibilities.

Why the firm that runs your program cannot audit it

AICPA independence standards prohibit the audit firm from having a material role in designing, operating or maintaining the control environment they are auditing. The rule exists because an audit that assesses your own work is not an independent assessment.

In practice this means:

• The firm that builds your SOC 2 program cannot issue the SOC 2 report.
• The firm that issues the SOC 2 report cannot have built your program, operated it on your behalf or provided material advisory services on the controls they are testing.

Some firms advertise “SOC 2 end to end” and then subcontract one side of the work to stay on the right side of the rule. Some firms blur the line intentionally and then hope the independence review does not surface it. Clean projects respect the split up front.

What a readiness engagement actually delivers

A real readiness engagement produces the material the audit will sample. That usually means:

• Scoping. What systems and data are in the audit boundary. What Trust Services Criteria apply. What is explicitly carved out.
• Gap assessment. A control-by-control inventory of the current state against the audit standard, with each gap flagged.
• Remediation. Building or hardening the controls that are missing or weak. Multi-factor authentication, logging, access reviews, change management, vendor risk, incident response.
• Documentation. Written policies, procedures and system descriptions. The auditor needs these to write the system-description section of the report.
• Evidence accumulation. Operating the controls for long enough to produce the artifacts the auditor will sample. For a Type II report, this is the observation period, usually 3 to 12 months.
• Pre-audit review. A mock audit against the audit standard to catch issues before the auditor does.

Skipping the readiness work and going straight to audit is a predictable way to burn audit fees. The auditor arrives, finds gaps, issues a qualified opinion or requests a remediation cycle that delays the report by several months.

What the audit firm actually does

The audit firm evaluates whether the control environment is designed appropriately (Type I) or operating effectively over a period (Type II). In practice:

• Reviews the system description the company provides.
• Tests the design of controls. “If this control were operating as described, would it address the relevant risk.”
• Tests the operation of controls, for Type II. Sampling evidence across the observation period.
• Documents findings, discusses with management and issues the opinion.

The audit firm does not build controls. Does not write policies. Does not operate the security program. Does not remediate gaps on the company’s behalf. Those are all readiness activities, and they are the reason the two roles are separate.

Where GRC tools fit

Vanta, Drata, Secureframe, Thoropass and similar GRC platforms have changed the SOC 2 market meaningfully in the last 5 years. Used well, they automate a significant portion of evidence collection once the control environment exists.

Used badly, they create a misleading sense of readiness. The platform marks controls as “passing” based on automated checks that prove the control exists in configuration. The auditor is evaluating whether the control is operating effectively against the criteria, which is a different question. A platform can show 94% passing controls while the audit produces 15 findings, because the platform is measuring configuration and the auditor is measuring operation.

The practical role of a GRC tool in a SOC 2 project:

• Excellent for continuous evidence collection once the program exists.
• Useful for policy template starting points, though templates often need substantial revision to reflect the actual environment.
• Not a substitute for a real readiness engagement.
• Not a substitute for an audit.

How to sequence a SOC 2 project

A defensible sequence for a company pursuing its first SOC 2 report:

1. Month 0. Named program owner internally. Decide Type I, Type II or Type I followed by Type II. Select a readiness partner.
2. Months 1 to 3. Scoping, gap assessment, initial remediation. GRC tool selected and configured if being used.
3. Months 3 to 6. Control operation, policy finalization, evidence accumulation.
4. Month 4 or 5. Select audit firm. (Timing matters. Selecting too early ties your readiness scope to that auditor’s preferences. Selecting too late delays the engagement.)
5. Months 6 to 9. Continued operation, pre-audit review, mock walkthrough.
6. Months 9 to 12. Audit fieldwork. Report issuance.

A shorter sequence is possible for a company that is already operating controls at audit-ready maturity. That is uncommon for a first-time SOC 2 project.

Where Atticus Rowan fits

We guide companies preparing for SOC 2 Type I and Type II audits, building the control environment, operating it long enough to produce the evidence the auditor needs and coordinating with the SOC 2 audit firm. We are not a SOC 2 audit firm ourselves; we are the MSP that makes the audit reach a clean opinion.

The practical shape of the engagement depends on the starting point. A company with no documented program and a 9-month runway to first audit needs a different engagement than a company with a mature but undocumented environment and a compressed 3-month runway. Both are workable. The scoping conversation at the beginning is where the shape of the project is decided.

What to ask before signing anything

Three questions that tend to expose where a proposed SOC 2 project will go sideways.

• Who is the audit firm, and are they independent of every firm involved in the readiness work. If the proposed audit firm is part of the same company as the readiness firm, the independence structure needs to be explicitly explained.
• What is the evidence accumulation period before the audit opens fieldwork. A Type II audit against a 3-month observation period is defensible. A Type II audit against a 30-day observation period will be weak.
• What happens if the audit produces a qualified opinion. A serious readiness partner will have a remediation-cycle answer. A weak readiness partner will have excuses.

If your company is pursuing SOC 2 for the first time and you want a clear read on how to sequence readiness and audit without burning budget or calendar, schedule a discovery call. We can scope the readiness work against your deal pressure and your runway.