Get insights on SOC 2 controls, learn about the Trust Services Criteria framework, and apply the SOC 2 control checklist to get ready for audit.
SOC 2 controls ensure that an organization’s processes and systems are created in such a way as to secure client data from any kind of risks. And for SaaS, startup and technology companies, this is a key part of the compliance process.
The following guide describes SOC 2 controls in plain English, provides practical examples of them, shows the mistakes people make with SOC 2 controls and links SOC 2 controls with ISO 27001 controls.
SOC 2 controls are those controls that an organization adopts for dealing with security and other pertinent Trust Services Criteria.
SOC 2 examinations evaluate controls against the following Trust Services Criteria:
These are the criteria used to assess and report on controls in these areas.
Different from the basic checklist where all organizations adopt the same set of controls, the organizations choose controls that are relevant to their systems, services, risks, and commitments.
The Trust Services Criteria provide the foundation for understanding what SOC 2 evaluates.
Security is the core Trust Services Criterion for SOC 2.
Security controls refer to measures aimed at safeguarding systems and information from any form of unauthorized access, disclosure, damage, and other types of security risks.
In the SaaS environment, staff are required to authenticate their identity using MFA prior to accessing any production system.
Implementing MFA but not reviewing access regularly.
Having a security control in place is not always enough. Organizations should also maintain evidence showing that the control is operating as intended.
Availability controls help ensure that systems and services are available as committed to customers.
Availability controls help organizations ensure that systems and services are available for operation and use as committed or agreed.
A SaaS company continuously monitors its production environment and has documented procedures for responding to service outages.
Having a disaster recovery document but never testing it.
A SaaS organization constantly monitors its production infrastructure and has documented processes for handling downtime of services.
Process integrity refers to how systems process transactions and information accurately, completely, and timely.
The goal is to ensure that the system executes the tasks that it was meant to do.
A financial SaaS application validates transaction data before processing it and generates alerts when processing errors occur.
Focusing only on system security while ignoring data processing accuracy.
An effective system may cause business issues if it processes data improperly.
Confidentiality controls ensure confidentiality of data for which an organization has made a commitment to keeping it confidential.
Confidential data must be identified by organizations and access to such data should be restricted to only those authorized individuals.
The SaaS provider encrypts the sensitive customer data when it is at rest or in transit.
A common mistake is protecting data in production but not protecting sensitive data in backups or development environments.
Privacy focuses on how personal information is collected, used, retained, disclosed, and disposed of.
Organizations should establish processes for handling personal information according to their privacy commitments and applicable requirements.
A SaaS company documents what personal information it collects, why it collects it, how it uses the information, and how long it retains it.
Creating a privacy policy but not aligning actual data practices with the commitments made in that policy.
A practical SOC 2 control checklist can help organizations identify the major areas they should evaluate before an audit.
| Control Area | Example Control | Example Evidence |
|---|---|---|
| Access Control | User access is reviewed regularly | Access review records |
| MFA | MFA is enabled for critical systems | System configuration |
| Security Monitoring | Security events are monitored | Monitoring reports |
| Risk Management | Security risks are assessed | Risk assessment |
| Incident Response | Security incidents follow documented procedures | Incident records |
| Change Management | Production changes are reviewed and approved | Change tickets |
| Vendor Management | Vendors are assessed for security risks | Vendor assessments |
| Employee Security | Employees receive security training | Training records |
| Backup | Critical systems are backed up | Backup reports |
| Disaster Recovery | Recovery procedures are documented and tested | Test results |
| Data Protection | Sensitive information is protected | Encryption/configuration evidence |
| Policy Management | Security policies are reviewed periodically | Policy review records |
A checklist can help organize preparation, but it should not replace a risk-based assessment of the organization’s actual environment.
Understanding common mistakes can help organizations avoid unnecessary audit issues.
Having a security policy does not automatically demonstrate that the related control is operating effectively.
Make sure policies are supported by actual processes, systems, responsibilities, and evidence.
Waiting until the audit begins to collect evidence can create unnecessary pressure.
Maintain evidence throughout the audit period.
It is possible for staff members to be reassigned or terminated but still have access rights enabled in the system.
Perform regular access reviews and document such access reviews.
The cloud providers, SaaS applications, and other vendors pose security threats.
Set up a vendor management program which addresses third-party risks.
SOC 2 compliance should not be viewed as mere preparation of documentation for audit purposes.
Establish continuous procedures for controls, evidence collection, risk management, and identification of gaps.
SOC 2 and ISO 27001 both address information security, but they use different approaches and structures.
SOC 2 is based on the AICPA’s Trust Services Criteria, while ISO/IEC 27001 defines requirements for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS).
ISO/IEC 27002 provides guidance on information security controls, including areas such as access control, cryptography, human resource security, and incident response.
| SOC 2 | Related ISO 27001/27002 Area |
|---|---|
| Access Control | Access Control |
| Security Policies | Information Security Policies |
| Risk Management | Information Security Risk Management |
| Incident Response | Incident Management |
| Vendor Management | Supplier Relationships |
| Change Management | Change Management |
| Business Continuity | ICT Readiness / Business Continuity |
| Data Protection | Information Protection / Cryptography |
| Employee Security | People Controls |
| Monitoring | Logging, Monitoring and Detection |
Important: These are related areas, not one-to-one equivalents. ISO/IEC 27001 uses a risk-management approach to determine the controls an organization needs; Annex A serves as a reference set rather than a universal list that every organization must implement.
Yes.
Organizations pursuing both frameworks can map overlapping controls and reduce duplicated compliance work.
For example, a single access control process may provide evidence relevant to both SOC 2 and ISO 27001.
This can help organizations:
SOCLY.io helps organizations simplify SOC 2 compliance by bringing key compliance activities into a centralized platform.
With SOCLY.io, organizations can streamline:
This approach helps organizations move from a one-time audit preparation exercise toward a continuous compliance program.
For SaaS companies, SOC 2 controls commonly cover areas such as:
The exact controls needed depend on the organization’s systems, services, risks, and commitments.
For startups, building these controls early can make future enterprise security reviews and compliance requirements easier to manage.
SOC 2 Controls are the measures that organizations adopt for addressing the relevant Trust Services Criteria and risks associated with those criteria.
The five Trust Services Criteria are Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the common criterion, while organizations may also include other criteria depending on their needs and commitments.
There is no single universal checklist that applies identically to every organization. The controls needed depend on the organization's systems, services, risks, and applicable Trust Services Criteria.
A SOC 2 control checklist can nevertheless be useful for organizing readiness activities.
Some common aspects are access management, MFA, security monitoring, incident management, change management, vendor management, risk assessment, employee security , backup, and business continuity.
Not really. There can be much commonality in both, but they are quite different in terms of their structure and requirements. SOC 2 relies on the Trust Services Criteria, and ISO/IEC 27001 outlines the requirements for the ISMS.
Yes. Compliance automation solutions can assist companies to manage their controls, gather evidence, monitor compliance actions, manage remediations, and stay audit-ready.
Depending on the control and the risk of the organization, the proper reviewing period should be determined. The critical controls may need to be continuously monitored or frequently reviewed.
Control management for SOC 2 doesn’t necessarily mean keeping spreadsheets, documents, and evidence separately.
SOCLY.io provides solutions for startups and enterprises in managing SOC 2 controls, performing compliance tasks, gathering evidence, and being audit-ready.
Your trusted partner in compliance automation. Turn complex regulations into clear, automated workflows.
By submitting, you agree to our Privacy Policy and Terms of Service
