A SOC 2 controls list can be misleading because every row looks similar in a spreadsheet. In practice, some controls are mostly about documented process. Others require real technical changes in AWS, identity systems, code repositories, logging platforms, endpoints, or backup infrastructure.
That distinction matters for a SaaS company planning SOC 2 compliance. If the team treats every requirement as a paperwork task, technical findings appear late. If it treats every requirement as an engineering project, the program becomes unnecessarily expensive.
The better approach is to separate documentation-heavy controls from implementation-heavy controls, then connect both to the same control environment.
Start With the Trust Services Criteria
SOC 2 is based on the AICPA Trust Services Criteria. Security is the common criteria category used in every SOC 2 engagement. Depending on scope, a company may also include availability, confidentiality, processing integrity, or privacy.
The Trust Services Criteria are not a prescriptive technology checklist. They describe outcomes and control expectations. Companies design controls that fit their systems and risks, and the auditor evaluates whether those controls are appropriately designed and, for a Type 2 report, whether operating effectiveness is supported.
That is why no universal SOC 2 controls list applies identically to every SaaS company. The exact controls depend on scope, risk assessment, architecture, commitments, and the auditor’s approach.
Controls That Usually Need Engineering Work
Identity and Access Controls
Access controls often require direct technical implementation. This includes MFA, role-based access, privileged access management, account provisioning and deprovisioning, access reviews, and logical and physical access controls where relevant.
A policy can state that access is restricted, but the auditor will want evidence that the actual systems enforce it. Identity providers, AWS IAM, GitHub, production databases, and administrative consoles usually matter more than the wording of the policy.
Logging, Monitoring, and Incident Detection
Security logging is another engineering-heavy area. Teams may need to enable audit logs, centralize events, configure alerts, define retention, and test that important events are visible.
Continuous monitoring supports the control, but the system operations behind it must work. An incident response plan is useful only if the organization can detect, investigate, and respond to the events the plan describes.
Encryption and Data Protection
Encryption in transit and at rest, key management, secrets handling, data classification, and secure storage can all require engineering decisions. Data protection controls may also touch privacy requirements, especially when sensitive or customer data is involved.
The auditor is not looking for a generic statement that “data is encrypted.” The company needs evidence showing where encryption is configured and how exceptions are managed.
Vulnerability and Network Security
Vulnerability scans, patching, dependency management, penetration testing, firewalls, and secure network configuration are highly technical. These controls often generate the findings that advisor-only compliance models cannot fix directly.
Disaster recovery plans also have an engineering side. Backup controls, restore testing, infrastructure resilience, and availability requirements need technical validation, not only documentation.
Controls That Are Often Documentation or Process Heavy
Policies and Governance
Security policies, acceptable-use rules, vendor management procedures, incident procedures, and change management documentation are often driven by written process. The challenge is keeping the documents aligned with actual operations.
A policy should not promise a control the team does not perform. If a document says access reviews occur quarterly, the company needs a recurring process and evidence collection to prove that they do.
Risk Assessment and Control Ownership
Risk assessment is usually process-heavy, although technical teams contribute. The company identifies threats, vulnerabilities, impact, likelihood, and risk mitigation. It then uses the results to shape internal controls.
Control ownership, approvals, exceptions, and review cadence are similarly operational. They require clear responsibilities more than code changes.
Security Awareness and HR Controls
Background checks, security awareness training, onboarding, offboarding, and employee acknowledgments are generally process controls. They may be tracked through HR or compliance systems rather than cloud infrastructure.
These are easy to underestimate because they seem administrative, but missing evidence can still create audit issues.
Controls That Need Both Engineering and Documentation
Many important controls sit in the middle.
Change management is a good example. The organization may document a change policy, but the real evidence comes from pull requests, approvals, testing, release records, and production deployment practices.
Incident response is similar. A written incident response policy or plan defines roles and procedures. The technical environment must also support detection, containment, evidence preservation, and recovery.
Business continuity and disaster recovery plans need documentation, but they also require backups, restore procedures, dependencies, and testing. Privacy controls may require documented commitments plus technical data handling.
The control activities therefore need one owner who can connect policy, implementation, and evidence.
How SOC 2 Type 1 and Type 2 Change the Work
For SOC 2 Type 1, the focus is whether controls are designed and implemented at a point in time. For SOC 2 Type 2, the auditor evaluates operating effectiveness over a period.
That means a company can have a technically correct control and still struggle if it does not operate consistently. Access reviews, evidence collection, vulnerability management, and change approvals need repeatable execution.
A readiness assessment should therefore test more than whether a control exists. It should test whether the company can produce evidence that the control is actually functioning.
Evidence Collection Is Its Own Workstream
Evidence collection connects every control to the audit. Examples include screenshots, configuration exports, tickets, logs, training records, approval history, and risk records.
The evidence should show who performed the control, when it happened, what was reviewed, and what happened when an exception was found. For a CPA firm, this supports the auditor’s evaluation of internal controls and control activities.
A clean SOC 2 report depends on this operational discipline. It is not enough to complete the technical work and assume the auditor will infer the rest.
Common Scope and Terminology Questions
The term “common criteria” often refers to the SOC 2 security criteria, not the international Common Criteria product-security standard. TSC is shorthand for Trust Services Criteria. “Points of focus” are implementation considerations that help organizations understand the criteria, but they are not a separate mandatory checklist.
SOC 2 also differs from ISO 27001 and HIPAA. ISO 27001 uses a certifiable management-system model. HIPAA has regulatory requirements. SOC 3 is a general-use report related to the same trust services framework but contains less detail than a SOC 2 report.
This matters when a SaaS company builds one compliance program across multiple frameworks. The controls may overlap, but the assurance mechanisms differ.
A Practical SOC 2 Controls Planning Method
Classify each control into one of four categories:
- documentation and governance
- technical implementation
- recurring operational process
- evidence and audit support
Then assign the right owner. Security policies may belong to compliance. MFA configuration belongs to engineering or IT. Risk management may be shared. Evidence collection may be coordinated centrally.
This prevents engineers from becoming accidental compliance managers while also preventing compliance from writing controls the environment does not support.
How This Maps to the SOC 2 Framework
The SOC 2 framework is built around SOC 2 criteria rather than a universal control catalog. A company’s SOC 2 program translates those criteria into specific controls, owners, evidence, and monitoring activities. During a SOC 2 audit, the auditor evaluates whether the control design and operation satisfy the stated SOC 2 requirements.
For a SOC 2 Type 1 engagement, design and implementation are evaluated at a point in time. For SOC 2 Type 2, the auditor also tests operating effectiveness over a period. A SOC 2 compliance checklist can help organize the work, but the security posture depends on the real control environment.
A complete program should also define the organizational structure, communication and information flows, and a risk register. Those governance elements connect technical controls to risk decisions. Availability controls, data security, GDPR considerations, and the broader security framework may all influence the exact control set when they are in scope.
The Bottom Line
A SOC 2 controls list is useful only when it reflects how the company actually operates. Some controls live primarily in policies and procedures. Others live in IAM, cloud configuration, code review, monitoring, encryption, backups, and vulnerability management. Many require both.
SCI’s hands-on compliance engineering model is built around that reality. The team can own the documentation and audit workflow while also helping implement approved technical controls when it has environment access. That closes the gap between “we know what the control should be” and “the control is actually working.”