Essential Security Controls Required for SOC 2 Compliance

Reading time: ~12 minutes

Search for a list of SOC 2 controls and you'll find dozens of articles offering 60, 80, or 116 "required" controls.

Every one of those numbers is invented.

The AICPA has never published a control list. SOC 2 specifies criteria, not controls. You design the controls. Your auditor evaluates whether they satisfy the criteria. Two companies with completely different control sets can both earn a clean opinion.

This is the most misunderstood thing about the framework, and it explains why so many first-time programs waste months implementing controls nobody asked for.

That said, some controls are effectively unavoidable. If you run a SaaS product in the cloud, there's a well-worn set auditors expect to see, and their absence produces findings almost every time.

Here's what the Trust Services Criteria actually require, the controls that satisfy them in practice, and the evidence you'll be asked to produce.

First: criteria, points of focus, and controls are three different things

Copying a generic control library and then trying to live up to it is the reverse of the correct order.

Criteria are what the AICPA publishes. The 2017 Trust Services Criteria (points of focus revised in 2022) define the objectives your system must meet. CC6.1 requires that you implement logical access security measures protecting against threats from outside your system boundaries. That's an objective, not an instruction.

Points of focus are illustrative examples the AICPA includes to show what a criterion might look like in practice. They are explicitly not requirements. Auditors don't test them individually, and you aren't obligated to implement each one. Compliance vendors routinely present them as a mandatory checklist, which inflates control counts and manufactures busywork.

Controls are what you design. Specific, documented activities that satisfy the criteria. Yours to write, own, and defend.

The practical consequence: your control set should describe what your company actually does, stated precisely enough that an auditor can test it.

CC1 — Control Environment

The governance layer: integrity and ethics, board oversight, organizational structure, competence, accountability.

This series causes disproportionate pain at small companies, because the underlying practices are real but informal. The founders talk about security constantly. None of it is written down.

Code of conduct exists and is acknowledged — Written policy, acknowledged at hire and annually. Evidence: signed acknowledgments, distribution records.

Board or leadership provides security oversight — Recurring security review at the executive or board level. Evidence: meeting minutes, agendas, logged decisions.

Organizational structure and reporting lines defined — Documented org chart with security roles assigned. Evidence: org chart, job descriptions naming security duties.

Background checks performed — Screening for new hires where legally permitted. Evidence: completion records from your screening vendor.

Performance evaluations include accountability — Review cycle covering security responsibilities. Evidence: review templates, completed evaluations.

Security awareness training completed — Annual training for all personnel. Evidence: completion reports with names and dates.

The recurring failure: genuine executive attention to security, zero artifacts proving it. If your leadership discusses security monthly, put it on a calendar and take minutes.

CC2 — Communication and Information

Whether relevant information reaches the people who need it, internally and externally.

Information security policies documented and approved — Reviewed and approved annually. Evidence: approval records with date and approver.

Policies communicated to personnel — Distribution with acknowledgment tracking. Evidence: acknowledgment log covering all employees.

Security responsibilities communicated to employees — Role-specific expectations set during onboarding. Evidence: onboarding checklist, training materials.

External commitments communicated to customers — Public security page, DPAs, contract terms. Evidence: published documentation, contract templates.

Channel exists for reporting security concerns — Defined reporting path including an anonymous option. Evidence: documented procedure, examples of reports received.

Most common gap here: policies approved and filed in a drive folder no employee has opened. Approval is not communication.

CC3 — Risk Assessment

The criteria expect a recurring, documented process that identifies risks, analyzes them, considers fraud specifically, and evaluates how change affects the picture.

Formal risk assessment performed at least annually — Structured process producing a risk register. Evidence: completed assessment with date and participants.

Risks scored by likelihood and impact — Documented scoring methodology. Evidence: register showing scores and rationale.

Fraud risks specifically considered — Fraud scenarios evaluated as part of the assessment. Evidence: assessment section addressing fraud.

Risk treatment decisions documented and tracked — Accept, mitigate, transfer, or avoid, each with an owner. Evidence: treatment plan with owners and target dates.

Significant changes trigger reassessment — Defined triggers for new products, vendors, or regions. Evidence: reassessment records tied to specific changes.

A slide deck from two years ago does not satisfy CC3. Auditors look for a repeatable process, not a one-time exercise.

CC4 — Monitoring Activities

Whether you evaluate your own controls and act on what you find.

Ongoing monitoring of control performance — Compliance dashboards or automated control checks. Evidence: monitoring output, alert history.

Periodic independent evaluation — Internal audit, penetration test, or third-party review. Evidence: assessment reports with findings.

Identified deficiencies tracked to resolution — Findings register with owners and dates. Evidence: register showing findings opened and closed.

Deficiencies communicated to leadership — Reporting into management or board review. Evidence: minutes referencing findings.

An annual penetration test satisfies a meaningful portion of this series and is expected by enterprise customers regardless.

CC5 — Control Activities

Bridges risk assessment to implementation.

Controls selected to address identified risks — Risk register mapped to mitigating controls. Evidence: mapping document.

Segregation of duties enforced — No single person can develop, approve, and deploy. Evidence: access configuration, approval workflow settings.

Policies translated into operating procedures — Documented runbooks. Evidence: procedure documents linked from policies.

Control ownership assigned — A named person per control. Evidence: control matrix with individual owners.

Segregation of duties is the sticking point at small companies. Auditors generally accept compensating controls — mandatory peer review, logged and monitored break-glass access — when headcount makes true separation impossible. Document the compensating control explicitly rather than hoping nobody notices.

CC6 — Logical and Physical Access

The largest series by control count, and where most audit effort concentrates.

Identity and authentication

MFA required for all system access — Enforced at the IdP with no standing exceptions. Evidence: IdP policy configuration, exception list.

SSO used for in-scope applications — Centralized identity provider. Evidence: application inventory showing SSO status.

Password policy enforced technically — Complexity and rotation configured at the IdP. Evidence: dated configuration screenshots.

Shared and service accounts controlled — Inventory, justification, credential vaulting. Evidence: account inventory, vault configuration.

Authorization and provisioning

Access granted based on documented approval — Request and approval workflow before provisioning. Evidence: approved tickets for a sample of new users.

Role-based access with least privilege — Defined roles mapped to job function. Evidence: role definitions, permission matrix.

Privileged access restricted and reviewed — Admin rights limited and separately tracked. Evidence: privileged user list with justification.

Access reviews performed on a defined cycle — Quarterly or semiannual, with sign-off. Evidence: completed reviews showing reviewer, date, and actions taken.

Access revoked on termination within a defined SLA — Offboarding checklist triggered by your HRIS. Evidence: ticket showing termination time and revocation time.

Access reviews and offboarding evidence are the two most commonly failed controls in first-time SOC 2 audits. Not because companies don't do them, but because they leave no artifact.

Revoking a departing employee's access in fifteen minutes proves nothing if no ticket records it.

Encryption and data protection

Data encrypted in transit — TLS 1.2 or higher on all external endpoints. Evidence: configuration, SSL scan results.

Data encrypted at rest — Disk and database encryption enabled. Evidence: cloud console configuration.

Encryption keys managed securely — KMS with restricted access and rotation. Evidence: key policy and rotation settings.

Production data restricted in non-production — Anonymization, masking, or prohibition. Evidence: policy plus technical enforcement.

Network and endpoint

Network boundary protection configured — Security groups, firewalls, WAF. Evidence: rule configuration and review records.

Production access restricted to authorized personnel — Bastion, VPN, or zero-trust access layer. Evidence: access configuration, authorized user list.

Anti-malware deployed on endpoints — EDR or equivalent across managed devices. Evidence: coverage report showing enrolled devices.

Endpoint hardening enforced — Disk encryption, screen lock, patch level via MDM. Evidence: MDM compliance report.

Physical access

If you're fully cloud-hosted, data center physical controls are carved out to your infrastructure provider. You still own physical security for offices where in-scope systems are accessed.

Office access restricted to authorized individuals — Badge system or equivalent. Evidence: access list, badge logs.

Visitor access controlled and logged — Sign-in procedure and escort policy. Evidence: visitor log.

Data center physical security — Inherited from your cloud provider. Evidence: their SOC 2 report.

Data disposal

Media securely wiped or destroyed on decommission — Documented sanitization procedure. Evidence: destruction certificates, wipe records.

Customer data deleted per contractual commitments — Defined retention and deletion process. Evidence: deletion logs, retention configuration.

CC7 — System Operations

Detection, response, and recovery.

Vulnerability scanning on a defined cadence — Automated scanning of infrastructure and applications. Evidence: scan reports across the observation window.

Vulnerabilities remediated within SLA by severity — Documented SLA, for example critical within seven days. Evidence: tickets showing detection and resolution dates.

Penetration testing performed annually — Third-party test against production or equivalent. Evidence: test report plus remediation tracking.

Patch management process operating — Defined cadence for systems and dependencies. Evidence: patch reports, dependency scan results.

Security event logging enabled and centralized — Aggregation covering in-scope systems. Evidence: log configuration and retention settings.

Logs monitored and alerts triaged — Alerting rules with defined response. Evidence: alert history showing investigation and closure.

Baseline configurations defined and monitored for drift — IaC or configuration management with drift detection. Evidence: baseline definitions, drift alerts.

Incident response plan documented — Severity levels, roles, escalation, communications. Evidence: approved IR plan.

Incident response plan tested — Tabletop exercise or real incident retrospective. Evidence: exercise records or post-incident reviews.

Incidents logged, tracked, and reviewed — Incident register with root cause analysis. Evidence: tickets with resolution and RCA.

The gap that appears over and over: monitoring is configured, alerts fire into a Slack channel, and nobody dispositions them. CC7 wants evidence of response, not just detection. An alert with no recorded action is worse than no alert — it demonstrates a control that exists and doesn't operate.

CC8 — Change Management

One criterion, heavily tested, because it's easy to sample and easy to fail.

Changes authorized before implementation — PR approval enforced by branch protection. Evidence: branch protection settings, sample of approved PRs.

Changes tested before production deployment — Automated tests plus staging validation. Evidence: CI pipeline results for sampled changes.

Segregation between developer and deployer — The approver cannot be the author. Evidence: repository configuration and sample evidence.

Emergency changes follow a defined process — Documented expedited path with retroactive review. Evidence: emergency change records with post-hoc approval.

Infrastructure changes managed under the same process — IaC changes go through review. Evidence: sample infrastructure PRs.

Rollback capability exists — Documented rollback procedure. Evidence: procedure plus examples of rollbacks performed.

Auditors sample changes from the full population, and they will find the hotfix pushed at 2 a.m. during an outage. Define the emergency path before the audit rather than explaining its absence afterward. An emergency process with retroactive documented review is acceptable. No process is not.

Population completeness matters more here than anywhere else. When you hand over a list of changes, the auditor will ask how you know the list is complete. Be ready to show the query and its parameters.

CC9 — Risk Mitigation

Business disruption and vendor management.

Business continuity plan documented — Covering key disruption scenarios. Evidence: approved plan.

Vendors inventoried with criticality assessment — Vendor register with risk tiers. Evidence: complete register.

Security due diligence before onboarding — Review of vendor SOC 2 or security posture. Evidence: review records for sampled vendors.

Critical vendors reviewed periodically — Annual review of high-tier vendors. Evidence: completed reviews with dates.

Contracts include security and confidentiality terms — Standard clauses, DPAs where applicable. Evidence: executed agreements for sampled vendors.

Vendor management is consistently underbuilt. Most teams have a list of SaaS subscriptions in a finance spreadsheet and call it a vendor register. The criteria expect criticality assessment, diligence at onboarding, and recurring review of the vendors that matter.

The optional categories, and what each one costs you

Security is mandatory. These four are elective, and each adds real work.

Availability — Capacity planning, backup configuration and retention, environmental protections, DR plan, and DR testing. Include if you have uptime commitments. The control most often failed: backups configured but never restore-tested. Configured backups are not tested backups.

Confidentiality — Identification of confidential information, retention aligned to commitments, secure disposal at end of retention. Include if customers send data under contractual handling restrictions.

Processing Integrity — Input validation, processing accuracy and completeness, output review, error handling. Include only if accurate processing is the product: payments, payroll, billing, analytics pipelines.

Privacy — Notice, choice and consent, collection limitation, use and retention, access rights, disclosure, data quality, monitoring and enforcement. By far the heaviest category. Don't add it unless a customer has specifically required it, and understand it does not substitute for GDPR or CCPA compliance.

The ten controls that carry the most audit weight

If you're triaging, these get tested hardest and fail most often.

1. Access reviews — performed on cycle, with documented reviewer and resulting actions
2. Termination access revocation — with timestamped evidence, not just the outcome
3. MFA enforcement — no standing exceptions, including service and admin accounts
4. Change approval — technically enforced, covering emergency changes
5. Vulnerability remediation within SLA — with detection and closure dates
6. Security awareness training — completed by everyone, tracked
7. Incident response testing — an exercise, not just a document
8. Vendor reviews — actually performed for critical vendors
9. Log monitoring with response — evidence of triage, not just alert generation
10. Backup restoration testing — under Availability scope, non-negotiable

So how many controls do you actually need?

For a first-time Security-only scope at a cloud-native SaaS company: typically 60 to 120.

If you're looking at 300, someone has confused controls with tasks. "Enable MFA" is a task. "MFA is enforced for all users accessing in-scope systems, with exceptions requiring documented approval" is a control.

More controls is not better. Each one has to be performed consistently across the entire observation window and produce evidence. An inflated control set is a larger surface area for exceptions.

Six ways control design goes wrong

Writing controls you don't perform. A control that exists on paper, gets tested, and fails is worse than never having claimed it.

Vague frequency language. "Periodically" is untestable. Say quarterly, monthly, annually — then perform it on that cadence, because the auditor will check every occurrence in the window.

Confusing tool deployment with control operation. Buying an EDR doesn't close an endpoint control. Deploying it everywhere, monitoring coverage, and remediating gaps does.

Controls owned by teams. "Engineering owns this" means nobody owns it. Name a person.

Controls with no evidence path. Before finalizing any control, answer: what artifact proves this happened, and can I export twelve months of it? If that's unclear, redesign the control.

Ignoring population completeness. Auditors need to trust your sample came from a complete population. Controls built on manually maintained lists are hard to defend.

Where to start

Don't start by implementing controls. Start by determining which ones you already have.

Compare your current environment against the criteria, classify each gap as a design problem or an operating consistency problem, and sequence remediation from there. Design gaps cost money. Operating gaps cost time, because you can't retroactively create a history of a control working.

Build the control set that describes what your company genuinely does. Make each one produce an artifact. Give every one a named owner.

That's the whole discipline.

This post reflects the 2017 Trust Services Criteria with points of focus revised in 2022. If you're reading it long after publication, verify current AICPA guidance.