Passing SOC 2 Type II without a dedicated compliance manager

Most SaaS companies hitting the point where a customer demands a SOC 2 report do not have a dedicated compliance manager. What they have is an engineer who cares about security, a CTO who says "yes, let's do this," and a shared understanding that nobody has done this before.

This guide is for that person. It is not a comprehensive overview of SOC 2 theory. It is the practical playbook for getting through Type II without losing your mind or your existing job responsibilities.

Stage 1 vs Stage 2: what you are actually signing up for

SOC 2 is issued as two report types. Type I is a point-in-time assessment — the auditor looks at your controls on a specific date and opines that they are suitably designed. Type II adds an observation period (typically six to twelve months) during which the auditor verifies that controls actually operated effectively throughout that period.

Most enterprise customers require Type II. Type I is useful as a milestone — it demonstrates readiness and can be issued relatively quickly — but it does not satisfy the requirements of most security questionnaires and procurement processes.

Stage 1 is about design. Stage 2 is about evidence. The gap between them is typically three to six months of actually running your controls and collecting proof that they worked.

The three traps that derail first-time programmes

Trap 1: Trying to cover every Trust Service Criterion immediately

SOC 2 has five Trust Service Categories: Security (CC), Availability (A), Processing Integrity (PI), Confidentiality (C), and Privacy (P). Most reports cover only Security. Unless a customer has explicitly asked for Availability or Privacy, start with Security only. Adding categories adds significant audit scope and evidence burden without proportionate business value early on.

Trap 2: Underestimating evidence collection

The observation period for Type II means you need evidence that controls ran every month for six to twelve months. That means access reviews, change approvals, vulnerability scans, and incident logs — consistently, every month, documented in a way an auditor can follow. Many organisations pass Stage 1 and then discover they have not actually been collecting evidence systematically.

Trap 3: Scope creep

Your SOC 2 scope should be your production environment and the systems that directly support it. Your internal HR system, marketing tools, and development laptops are generally out of scope. Defining scope tightly is not cutting corners — it is good audit practice. Document your scope boundaries clearly in your system description.

Controls auditors always check

Within the Common Criteria (CC1 through CC9), these are the areas where auditors spend the most time and where gaps are most often found:

• Logical access (CC6) — Who has access to production? How is it provisioned and deprovisioned? When did you last review it? Quarterly access reviews with documented evidence are the minimum expectation.
• Change management (CC8) — Every change to production should go through a defined process: ticket, review, approval, deployment, verification. Auditors will sample your deployment history.
• Incident response (CC7) — You must have a documented incident response procedure and evidence that it was followed when incidents occurred. If you had zero incidents during the observation period, auditors may probe whether your monitoring is actually detecting anything.
• Vendor management (CC9) — Third-party suppliers with access to your environment or data need to be assessed. A vendor register with basic risk classification and contract review evidence is sufficient for most audits.
• Monitoring (CC7.2) — Log collection, alerting, and evidence of review. Auditors will ask what you do when an alert fires and want to see examples.

Realistic timeline

• Months 1–3: Gap assessment, policy writing, control implementation. Target Stage 1 readiness.
• Month 3: Stage 1 audit (documentation review). Address any findings.
• Months 4–9: Observation period. Run your controls, collect evidence every month.
• Month 9–10: Stage 2 fieldwork. Auditor reviews evidence for the observation period.
• Month 11: Report issued.

What can be automated vs what needs humans

A significant proportion of SOC 2 evidence can be automated. Vulnerability scans, access logs, deployment pipelines, and monitoring alerts can all be collected programmatically and attached to controls in a GRC tool. What cannot be automated: access reviews (someone needs to make a decision about each user), management reviews (documented meeting with decisions), and vendor assessments (requires human judgment about risk).

Choosing an auditor

SOC 2 reports must be issued by a licensed CPA firm. Not all CPA firms have meaningful SOC 2 experience. When evaluating firms, ask how many SOC 2 engagements they complete per year, whether they have a dedicated technology practice, and whether they use their own control framework or AICPA's published TSC criteria directly. A firm that completes twenty SOC 2 audits per year will be significantly more efficient than one doing their third.