What SOC 2 Actually Requires From Your Security Stack (Plain English)

If you've ever read the actual SOC 2 Trust Services Criteria, you know it's written in a way that seems deliberately designed to require outside interpretation. Phrases like "the entity implements logical access security measures" and "complementary user entity controls" are technically meaningful but practically useless without translation.

The good news: once you strip away the audit language, SOC 2 Type II is asking a fairly straightforward set of questions about your security stack. Can you prove who has access to what? Can you show that access is appropriate? Can you demonstrate that you'd know if something went wrong? This post answers those questions concretely - with the tooling decisions that actually satisfy auditors.

Section 01 - What SOC 2 is - and what it isn't

Risk tag: The basics

SOC 2 is not a product certification or a security standard in the prescriptive sense. It's an auditing framework developed by the AICPA that evaluates whether your controls are designed and operating effectively against a set of Trust Services Criteria. The five criteria are Security, Availability, Confidentiality, Processing Integrity, and Privacy - but only Security (also called the Common Criteria) is required. The rest are optional and scoped based on what you promise customers.

The distinction between Type I and Type II matters practically: Type I is a point-in-time assessment of whether your controls are designed correctly. Type II covers a period of time - typically 6 to 12 months - and requires evidence that those controls actually operated as described throughout that window. Auditors aren't just reviewing your policies; they're pulling samples of access reviews, change management records, and incident logs to verify that what you wrote down is what you did.

This is why the tooling decisions you make before starting your observation period matter. You need infrastructure that generates evidence automatically, not processes that require manual documentation after the fact.

Section 02 - Access control: the category that consumes most of your audit

Risk tag: Criteria CC6

The Common Criteria section on Logical and Physical Access Controls - CC6 - is where most of the evidence burden sits. It requires that you restrict access to information assets based on job role, review that access regularly, revoke it promptly when someone leaves, and use authentication controls commensurate with the sensitivity of what's being protected.

In practice, this means an auditor will ask you to produce: a list of everyone with access to production systems, documentation showing that list was reviewed on a defined cadence, and evidence that terminated employees were removed within your stated timeframe. They'll also want to see MFA enforcement documented at the policy level, not just enabled as an option.

The tooling that satisfies CC6 most cleanly is a centralized identity provider with SSO enforced across your critical systems, combined with an automated access review workflow. An IdP like Okta or JumpCloud gives you a single authoritative source of truth for who has access to what. Pair that with a compliance automation platform and access reviews become a scheduled, auditable process rather than a spreadsheet exercise before each audit.

Tools that fit:

• Okta - IdP + SSO enforcement, generates access logs auditors can pull directly
• JumpCloud - lighter-weight alternative for teams not ready for Okta's overhead
• Vanta / Drata - automates access review workflows and maps evidence to criteria

Section 03 - Monitoring and anomaly detection: you need to prove you'd know

Risk tag: Criteria CC7

CC7 covers System Operations and requires that you monitor your environment for threats, detect anomalies, and respond to incidents in a documented way. This is the criteria that catches organizations that have policies on paper but no operational reality behind them.

Auditors will ask for evidence of your monitoring configuration, examples of alerts that fired during the observation period, and documentation of how those alerts were triaged. They'll also review your incident response plan and - in a Type II audit - look for evidence that it was actually followed when something happened. A policy document dated two weeks before the audit window closes is a red flag.

The practical requirement here is log centralization plus alerting on meaningful events. You don't need a full SOC operation. You need CloudTrail or equivalent cloud audit logs flowing into a central platform, with documented alerts on high-signal events: privileged access changes, authentication failures at scale, unusual data movement. The evidence artifact is the alert history and the response record, not the sophistication of your detection logic.

Tools that fit:

• Datadog - log aggregation + alerting with audit-ready query history
• Panther - SIEM built for cloud-native stacks, maps detections to compliance frameworks
• AWS CloudTrail + CloudWatch - baseline cloud audit logging; necessary but not sufficient alone

Section 04 - Change management: every production deployment needs a paper trail

Risk tag: Criteria CC8

CC8 addresses Change Management and requires that changes to your production environment are authorized, tested, and documented before deployment. This criteria is frequently underestimated by engineering teams who interpret it as a bureaucratic overhead rather than a control that auditors verify with hard evidence.

What auditors actually pull: a sample of production deployments from your observation period and the corresponding change records - who approved them, what testing was performed, and whether any emergency changes were reviewed after the fact. Organizations that deploy via "push to main and hope" have no evidence trail to provide.

The good news is that modern CI/CD tooling satisfies CC8 almost by default if configured correctly. Required pull request approvals, protected branches, and deployment gates in your pipeline generate the authorization evidence automatically. The gap is usually documentation - teams have the controls in place but haven't linked them to their SOC 2 scope or described them in the required policy language.

Tools that fit:

• GitHub / GitLab - branch protection rules and PR approval history serve as change authorization evidence
• Linear / Jira - links tickets to deployments, giving auditors a clear change-to-approval chain
• Vanta - auto-collects GitHub PR data and maps it to CC8 evidence requirements

Section 05 - Vendor risk and risk assessment: the criteria most teams skip

Risk tag: Criteria CC9 + risk

CC9 covers Risk Mitigation and requires that you identify, assess, and manage risks to your environment - including risks that originate with third-party vendors. The risk assessment component is often the last thing a startup formalizes, and it's one of the first things auditors probe because it reveals whether security is genuinely operationalized or just documented for the audit.

A SOC 2-ready risk assessment isn't a theoretical exercise. It's a documented inventory of the threats relevant to your environment, a scoring of their likelihood and impact, and evidence that mitigating controls are in place and tracked. It should be reviewed at least annually and updated when your environment changes materially.

Vendor risk is a separate but adjacent requirement. If a subprocessor has access to customer data - your cloud provider, your data warehouse, your support tooling - you need documentation that you've reviewed their security posture. In practice this means collecting SOC 2 reports or equivalent certifications from your critical vendors and storing them somewhere retrievable. Auditors will ask for this list and sample it.

Tools that fit:

• Vanta / Drata - built-in risk register templates mapped to SOC 2 criteria
• Whistic / OneTrust - vendor risk management with automated security questionnaire workflows
• Notion / Confluence - workable for early-stage if structured correctly; not ideal at scale

SOC 2 doesn't require a perfect security program. It requires a consistent one. Auditors aren't grading you on the sophistication of your controls - they're verifying that what you said you'd do is what you actually did, across the entire observation period.

The compliance automation platforms - Vanta, Drata, Secureframe - are genuinely useful not because they do the security work for you, but because they make the evidence collection continuous rather than frantic. The companies that struggle with SOC 2 audits aren't the ones with weak security programs. They're the ones with decent security programs and no audit trail.

Start with access control and monitoring. Get your IdP enforcing SSO and MFA. Get your logs centralized. Document your change management process in a way that maps to what your tooling already does. The rest of the criteria build on that foundation.

SOC 2 is not a destination. It's a forcing function for operational discipline - and that's actually worth having.