SOC 2 Controls List: What You Need to Implement

Controls, criteria, and points of focus

The Security criterion alone — the mandatory Common Criteria — spans nine categories (CC1-CC9). Across all five criteria there are roughly 60-plus requirements. A control is the specific safeguard you implement to satisfy a requirement: a policy, a configuration, a process, or a technical mechanism.

The AICPA publishes points of focus beneath each criterion — illustrative ways to meet it. They are guidance, not a mandatory checklist, which is why no two SOC 2 programs look identical. Your job is to choose controls appropriate to your systems and map each to the criteria it supports.

The control families auditors expect

Whatever your stack, auditors look for a recognizable backbone of controls. These are the families that appear in nearly every SOC 2:

• Access control — unique accounts, least privilege, MFA, SSO, and quarterly access reviews
• Change management — peer-reviewed, approved changes before production, with a tested rollback path
• Encryption — data protected in transit (TLS) and at rest, with documented key management
• Logging and monitoring — centralized logs, alerting on anomalies, and retention
• Vulnerability management — scanning, patch SLAs, and an annual penetration test
• Incident response — a documented, tested plan with defined roles and post-mortems
• Risk assessment — a regular, documented process that drives control selection
• Vendor / third-party management — due diligence and monitoring of subprocessors
• HR security — background checks, onboarding/offboarding, and security-awareness training
• Backup and business continuity / disaster recovery — tested restore procedures

Controls by Trust Services Criterion

Beyond the Common Criteria, each optional criterion adds its own controls:

• Availability — capacity planning, redundancy, backups, and DR testing
• Confidentiality — data classification, encryption, and secure disposal of confidential data
• Processing Integrity — input validation, processing checks, and output reconciliation
• Privacy — consent, data-minimization, retention, and data-subject request handling

Every control must produce evidence

A control only counts if it generates proof. Auditors sample evidence from across the period, so each control needs a recurring, verifiable artifact.

Design controls so evidence is produced automatically as a by-product of normal operations — pull-request approvals, deprovisioning tickets, monitoring alerts — rather than assembled manually before fieldwork.

A worked control-to-evidence mapping

The clearest way to understand SOC 2 controls is to see how each turns into evidence an auditor can sample. A representative mapping looks like this: Implementing the right controls is the core technical work behind SOC 2 compliance.

• Access provisioning follows a documented approval - evidence: ticketed access requests with manager and system-owner approval
• Quarterly user access reviews - evidence: four dated review records per year showing accounts examined and changes made
• MFA enforced on critical systems - evidence: identity-provider configuration export showing MFA policy and enrollment
• Code changes peer-reviewed before production - evidence: pull-request history with reviewer approval and CI/CD logs
• Offboarding within 24 hours - evidence: HRIS termination date compared to deprovisioning ticket timestamp
• Vulnerabilities remediated within SLA - evidence: scanner reports, remediation tickets, and the annual penetration test
• Vendors risk-assessed annually - evidence: vendor inventory plus dated risk reviews and collected subprocessor reports

Notice the pattern: every control yields a recurring, timestamped artifact. If a control cannot produce evidence like this, it cannot be tested - which is why evidence design is as important as the control itself.

Common control gaps auditors flag

Across first-time audits, the same handful of gaps generate most exceptions. Knowing them in advance lets you close them before fieldwork:

• Access reviews skipped a quarter or missing approver sign-off - the single most common exception
• Terminated users whose access was not revoked within the committed window
• Production changes deployed without a recorded review or approval
• Onboarding completed without evidence of security-awareness training
• Policies that exist on paper but do not match how the team actually operates
• Incomplete evidence populations, so the auditor cannot verify the full set of events

Each of these is preventable with automation and clear ownership, which is why a readiness assessment and continuous evidence collection pay for themselves many times over.

How many SOC 2 controls do you need?

There is no fixed number. It scales with the criteria you include and your environment's complexity. As a rule of thumb, a Security-focused program for a cloud-native company often runs 50-80 controls; complex or multi-product environments can exceed 100. More controls is not better — consistent operation of the right controls is what matters.

Build a control matrix

The single most useful artifact you can create is a control matrix: a table mapping each control to the criteria it satisfies, its owner, and the evidence it produces. It becomes your remediation plan, your audit test plan, and your maintenance checklist — and it is what lets a reviewer trace a requirement to proof in seconds.

Implementing controls is not the same as operating them

A subtle but critical point: a SOC 2 Type 2 does not test whether a control exists - it tests whether it operated, consistently, across the whole period. A change-review process that ran for two months and lapsed for one will produce an exception, even though the control technically exists. This is why operating discipline matters more than the initial build. Controls need a named owner, a schedule, and a mechanism that produces evidence every time they run, so that an access review or a vulnerability remediation is captured automatically rather than reconstructed later. Continuous monitoring closes the gap further by flagging drift - a disabled log, an over-privileged account, an expired certificate - the moment it happens, while it is inexpensive to fix, rather than surfacing it as a finding during fieldwork. The healthiest programs treat controls as living operations, not one-time configuration.

Reusing controls across other frameworks

One of the most valuable properties of a well-built SOC 2 control set is that it does not stop at SOC 2. The access management, encryption, change management, logging, vulnerability management, and incident response controls that satisfy the Trust Services Criteria overlap heavily with the requirements of ISO 27001, HIPAA, and PCI DSS. That means a mature SOC 2 program is the foundation for the next framework rather than a separate project: you map your existing controls once and satisfy multiple standards, collecting the supporting evidence through the same automated pipelines. Building controls with this reuse in mind from the start - clear ownership, consistent evidence, a single control matrix - turns each additional framework from a fresh burden into an incremental mapping exercise, which is exactly how growing companies avoid paying for the same controls several times over.

How ISpectra accelerates controls

We start from a proven control library mapped to the Trust Services Criteria, tailor it to your stack, assign owners, and wire evidence collection into your cloud, identity, and ticketing systems from day one — so controls operate and prove themselves continuously, not in a pre-audit scramble.