If you've started shopping for a SOC 2 auditor or a compliance automation platform like Secureframe, you've probably run into the same wall: there is no single official "SOC 2 controls list." SOC 2 is built on the AICPA's Trust Services Criteria (TSC), a framework of criteria — not a fixed checklist of controls — which means every company ends up designing its own control set to satisfy those criteria. That flexibility is powerful, but it also means teams waste weeks reinventing controls that hundreds of other companies have already built and tested.
This guide breaks down what actually goes into a SOC 2 controls list in 2026: how many controls most companies implement, which categories auditors focus on hardest, how Type I and Type II differ in practice, and where automation platforms like Secureframe help — and where they stop short, especially for software supply chain and engineering-heavy controls.
What Is a SOC 2 Controls List, Exactly?
A SOC 2 controls list is the set of internal safeguards a company implements to satisfy the AICPA's Trust Services Criteria, most recently revised in the 2017 TSC (with points of focus updated in 2022). There are five Trust Services Categories — Security, Availability, Processing Integrity, Confidentiality, and Privacy — but only Security (also called the "Common Criteria," CC1 through CC9) is mandatory for every SOC 2 report. The other four are optional, selected based on what your customers care about; a payments company might add Processing Integrity, while a healthcare SaaS vendor might add Confidentiality and Privacy.
Each of the nine Common Criteria families breaks into "points of focus" — roughly 30 to 35 total — that auditors use as a rubric. Companies then map their own controls to those points of focus. In practice, a mid-sized SaaS company (50-500 employees) typically ends up with 60 to 120 discrete controls; larger, multi-product organizations can exceed 200 once you count control activities across access management, change management, vendor risk, and incident response separately for each product line.
How Many Controls Do You Actually Need to Implement?
Most companies pursuing their first SOC 2 Type II implement somewhere between 60 and 100 controls, not the 300+ line items some compliance vendors show in marketing screenshots. Secureframe's platform, for example, ships with a control library that can list upward of 150-200 pre-built controls and 100+ policy templates, but auditors don't expect you to activate every single one — they expect controls that are relevant to your environment and, critically, that you can prove were operating consistently for the entire audit window.
A realistic first-year scope looks like: 8-12 controls for CC1 (control environment, e.g., background checks, org chart, code of conduct), 10-15 for CC6 (logical access — SSO enforcement, MFA, quarterly access reviews), 8-10 for CC7 (system operations — vulnerability scanning cadence, patching SLAs, intrusion detection), and 6-10 for CC8 (change management — pull request approvals, CI/CD gating, deployment approvals). Companies that try to boil the ocean with 250+ controls in year one usually end up with weaker evidence per control, which is what actually triggers auditor exceptions.
What Controls Do Auditors Scrutinize Hardest?
Auditors spend the most time on CC6 (logical and physical access controls) and CC7 (system operations), because these generate the most evidence and the most exceptions. Concretely, expect your auditor to pull evidence for: every production access grant and revocation over the audit period (commonly a 6-month Type II window, though it can run 3-12 months), MFA enforcement logs for all privileged accounts, quarterly (or more frequent) access recertification, and a vulnerability management process with a documented remediation SLA — a common benchmark is critical vulnerabilities patched within 15-30 days and high within 60-90 days.
For software companies specifically, CC8 (change management) is where supply chain gaps show up. Auditors increasingly ask for evidence that code changes go through peer review, that CI/CD pipelines enforce branch protection, and — since the 2020-2024 wave of supply chain incidents (SolarWinds, 3CX, the 2024 XZ Utils backdoor) — that third-party dependencies and build artifacts are scanned and attested before release. This is a gap most compliance automation platforms, including Secureframe, don't natively close, because they're built around HR, cloud config, and ticketing integrations rather than build pipelines, SBOMs, or artifact provenance.
How Is a SOC 2 Type I Different From Type II in Terms of Controls?
The controls list is nearly identical between Type I and Type II — the difference is the time dimension, not the control count. A Type I report is a point-in-time assessment: your auditor confirms that a control (say, "MFA is required for all admin console access") is designed correctly and in place on a single date. A Type II report requires the same controls to be operating effectively over an observation period, typically 6 months for a first report and up to 12 months for renewals.
This matters for planning: a company can pass Type I with a control that was configured the week before the audit. Type II requires continuous evidence — access review logs from month 1 and month 6, not just the current state. Roughly 90%+ of enterprise buyers now ask specifically for Type II before signing a contract, so most companies treat Type I as a stepping stone completed in 2-3 months, then move into a Type II observation window immediately after.
How Does Secureframe's Approach to Controls Compare to What You Actually Need?
Secureframe's strength is breadth: it auto-maps a large control library to multiple frameworks (SOC 2, ISO 27001, HIPAA, PCI DSS) so one set of evidence can satisfy several audits at once, and it automates collection from HR systems, cloud providers (AWS, GCP, Azure), and MDM tools. For controls like background checks, security awareness training completion, and cloud configuration drift, that automation genuinely removes weeks of manual screenshot-gathering.
Where it comes up short is engineering-native evidence: SBOM generation, dependency and container image vulnerability data, build provenance (SLSA-style attestations), and CI/CD pipeline integrity. Those map directly to CC7 and CC8 points of focus, but a general-purpose GRC platform typically pulls from ticketing and cloud APIs rather than the build system itself, so teams end up bolting on separate scanners and manually uploading evidence anyway — the exact toil the platform was supposed to eliminate.
How Safeguard Helps
Safeguard was built to close that specific gap. Instead of treating software supply chain security as a manual evidence upload, Safeguard continuously generates the artifacts your CC7 and CC8 controls actually require: SBOMs for every build, dependency and container vulnerability scans mapped to your patch SLA, and cryptographically verifiable build provenance so auditors can see — not just take your word for — that what shipped matches what was reviewed and approved.
For teams already running Secureframe or a similar GRC platform for HR- and cloud-config-driven controls, Safeguard slots in as the source of truth for the engineering-side controls that platform can't natively populate: change management evidence tied to actual commits and pipeline runs, vulnerability remediation timelines pulled straight from scan results instead of spreadsheets, and continuous artifact attestation instead of point-in-time screenshots. The result is a controls list where every CC6-CC9 item has live, auditable evidence behind it, cutting audit-prep time and closing the exact supply chain gaps that auditors — and increasingly, enterprise security questionnaires — are asking about in 2026.