SOC 2 Requirements: Everything You Need to Know
SOC 2, short for Systems and Organization Controls, is a security framework developed by the American Institute of Certified Public Accountants (AICPA). SOC 2 is structured around 5 Trust Service Criteria and is used to assess whether an organization’s internal controls are effective at protecting customer data.
What Is SOC 2?
SOC 2 is a compliance standard developed by the American Institute of Certified Public Accountants in order to evaluate the security practices of service organizations. It is based around five Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy.
However, unlike rigid standards such as PCI DSS (which require specific technical safeguards), SOC 2 is designed to give organizations the freedom to choose controls that fit their environment. The effectiveness of their chosen controls is then verified through an independent audit. A completed SOC 2 report therefore shows that an organization takes cybersecurity seriously and demonstrates their trustworthiness to potential clients and business partners.
SOC 1 vs. SOC 2 vs. SOC 3
The number 2 in the name SOC 2 leads some to believe that SOC 2 iterates on an earlier framework or acts as a kind of sequel or replacement. This is not the case. In reality, SOC 1, SOC 2 and SOC 3 are three different reports intended for different audiences and aspects of an organization.
SOC 1: Internal Control over Financial Reporting โ SOC 1 focuses on the financial reporting of an organization. It has a narrower scope than SOC 2 and is intended for service organizations that process financial data on their clients behalf, such as payroll or payment process services.
SOC 2: Trust Services Criteria โ SOC 2 is intended for service organizations of all types. It covers all controls that affect systems used to process customer data and produces a detailed report intended for a limited audience of trusted partners due to the sensitive information contained within.
SOC 3: Trust Services Criteria for General Use โ SOC 3 has the same scope and requirements as SOC 2, but the final report is adapted for general audiences and use in marketing materials. SOC 3 therefore uses simplified descriptions and excludes sensitive details about the organization’s internal controls. Because SOC 3 examinations are essentially the same as SOC 2, organizations can ask an auditor to issue both reports during the same audit.
SOC for Cybersecurity โ While SOC 2 is limited to systems used to process customer data, SOC for Cybersecurity addresses an organization’s entire cybersecurity risk management program. It produces a report suitable for general audiences that does not includes sensitive details about internal controls.
SOC for Supply Chain โ The SOC for Supply Chain audit is aimed at organizations that manufacture or distribute products and intended to assure entities further up the supply chain that the controls in place to protect the manufacturing or distribution process are effective.
SOC 2 Type 1 vs. SOC 2 Type 2
In addition to the different SOC reports an organization can choose from, there are two different audit types you can complete when it comes to SOC 2:
SOC 2 Type 1: A Type 1 audit is a momentary snapshot of your internal controls. Based on the system description you have submitted, the auditor evaluates whether your controls are suitable to protect customer data in the covered systems. It is an assessment of the design of your controls.
SOC 2 Type 2: A Type 2 audit determines the effectiveness of your controls over a period of time, typically either 6 or 12 months. The auditor will test your controls and collect evidence to evaluate whether your controls are working as intended. It is an assessment of the design and implementation of your controls.
What Does a SOC 2 Report Look Like?
When an auditor completes their review of your organization, they produce a SOC 2 report. The SOC 2 report confirms the suitability and effectiveness of your chosen controls, allowing you to prove to potential clients and business partners that you run an effective cybersecurity program.
A SOC 2 report consists of three parts:
A description of your IT systems and the controls you have put in place to meet the relevant trust service criteria.
A written assertion by your management that the description is accurate and the controls are suitably designed and operating effectively.
A report by the service auditor stating whether the management assertion is correct and detailing the tests conducted to arrive at this opinion.
Typical testing procedures for SOC 2 involve interviewing staff, inspecting systems and testing controls. However, SOC 2 gives service auditors the freedom to choose the nature, timing and extent of testing needed to obtain sufficient evidence for a report.
What Are Description Criteria in SOC 2?
SOC 2 provides a set of description criteria in order to help organization’s structure the description of IT systems and controls that they need to submit as part of the SOC 2 audit process. The full list of the 2018 SOC 2 Description Criteria can be downloaded from the AICPA website. You can find a brief overview of the 9 description criteria below.
DC1: Types of services โ Identifies the type of service provided by the organization that is the focus of the SOC 2 examination, such as fintech, customer support or managed IT services.
DC2: Principal service commitments and system requirements โ Service commitments are objectives an organization sets for itself and communicated to users in various forms, such as contracts, policies or service level agreements. System requirements specify how systems should function to support these objectives, for example by laying out intervals for access reviews or requirements for the enforcement of separation of duties.
DC3: System components used to provide the service โ Identifies the specific components that are used to provide the service. Can be broken down into five categories: infrastructure, software, people, procedures and data.
DC4: Identified system incidents โ A list and description of system incidents that either impacted the ability to fulfill service commitments or resulted from controls not operating effectively / not being suitably designed. Can list either incidents prior to the audit (for Type 1) or during the audit period (for Type 2) and should cover the nature, timing and extent of each incident.
DC5: Applicable trust service criteria โ Lists the trust service criteria the organization is audited against and the controls implemented to meet the requirements of each applicable criterion.
DC6: User entity controls โ Refers to controls that the customer performs as part of the system design submitted by the organization. For example, the organization may rely on its customer to notify them when new users are to be authorized for access to specific data or when access is to be revoked. It then falls to the customer to provide this information.
DC7: Subservice organization controls โ Describes controls that the organization requires subservice organizations to perform in combination with internal controls in order to meet trust service criteria. Requires a description of the type of service provided by the subservice organization and the controls necessary as part of the system design.
DC8: Irrelevant criteria โ Allows organizations to list any criteria that are not relevant to their system description. An example could be controls implemented at the client level that cannot be disclosed in the SOC 2 report. In this case you would note the reason for their omission instead. However, when it comes to subservice organizations, note that criteria do not become irrelevant even if all related components or processes are fully outsourced.
DC9: Significant changes โ Lists significant changes during the type 2 audit period, such as changes to the services offered, your IT architecture and environment, security personnel or new legal and regulatory requirements. Must include an appropriate level of detail. For example, when the change occurred and a description of state before and after.
What Are the 5 Trust Service Criteria in SOC 2?
The SOC 2 framework is based around five trust service criteria that represent overall goals your internal controls should achieve and are used to evaluate whether the controls you have described in your system description are suitable and effective to achieve these goals.
The five trust service criteria in SOC 2 are:
Security: Information systems are protected against unauthorized access, data breaches and attacks that could impact their availability, integrity, confidentiality and privacy.
Availability: Information systems meet operative needs and their availability is ensured through appropriate means.
Processing integrity: The processing of client information follows operational objectives and is valid, accurate, timely and complete.
Confidentiality: Information designated as confidential is protected through appropriate means.
Privacy: Personal information is collected, stored, processed and disposed of according to the organization’s objectives and all relevant laws and regulations.
Note: The 5 Trust Service Criteria are used to structure SOC 2 and assess organizations against different control objectives. The full list of requirements needed to meet each criterion is considerably longer.
What Are Common Criteria in SOC 2?
Common criteria are a set of requirements that are part of every SOC 2 audit, unlike additional criteria that are only relevant to one of the five overarching goals like availability or privacy.
More specifically, common criteria address the security of your system, the first of the five trust service criteria. The logic here being that if your environment is not secure, there is no way for you to guarantee its confidentiality, availability or any of the other key goals of SOC 2. Effective internal controls therefore require strong cybersecurity, no matter which criterion you are tested against.
Do SOC 2 Audits Cover All Trust Service Criteria?
As the hiring organization, you can decide which of the trust service criteria you want to include in your SOC 2 report. The common criteria related to security are always part of the examination, but the other four criteria are optional. That being said, your auditor can decide if excluding certain criteria is likely to be misleading and decline to complete the engagement.
What Is the Difference Between Confidentiality and Privacy?
The trust service criteria privacy and confidentiality have a lot in common: Both relate to who information is disclosed to and for what purpose. The difference between the two is that privacy only covers personally identifiable information (PII) like birthdays or social security numbers, while confidentiality relates to any kind of restricted information, such as internal documents and financial data.
Is SOC 2 Mandatory?
SOC 2 is a voluntary certification and not mandatory under any law or regulation. However, many clients make SOC 2 a prerequisite for business relationships, which makes it a de-facto necessity for service organizations. SOC 2 is especially widely used in the US and among SaaS businesses.
ISO 27001: Access Governance Requirements
Everything you need to know about the IAM requirements of ISO 27001.
SOC 2 vs. ISO 27001
Unlike SOC 2, ISO 27001 as well as NIST standards such as NIST 800-53 and NIST 800-171 put a much stronger focus on specific technical safeguards, outlining recommended approaches to fulfill the security requirements of these frameworks.
This makes ISO 27001 more detailed than SOC 2, which can be an advantage for organizations that need clear and exhaustive guidance. However, SOC 2 offers a more flexible approach to cybersecurity, giving organizations the freedom to pick and choose controls that align with their environment and operations.
While ISO 27001 does allow orgs to skip controls that are not relevant to their environment, they need to provide a valid reason in their statement of applicability โ meaning you do need to go through every recommended control listed in Annex A.
SOC 2 Requirements Explained
The requirements for SOC 2 can be broken down into three parts:
The 17 principles of the COSO framework (which SOC 2 aligns with), broken down into 5 components
Supplemental requirements around access control, operations, risk mitigation and change management
Additional category-specific criteria for availability, processing integrity, confidentiality and privacy (only relevant if these are part of your examination)
To understand how you can go about implementing the necessary controls for every part of SOC 2, we will go into more detail about the specific requirements below.
CC1: Control Environment
The control environment refers to the set of guidelines and processes that drive internal controls, beginning with the management responsibility to set goals and provide adequate resources for your organization’s security efforts.
Requirements include:
Management establishes policies and practices necessary to achieve objectives.
Management designates oversight responsibilities with clear roles and lines of reporting.
All relevant components of the organization and external parties are taken into consideration.
CC2: Information and Communication
To operate effectively, an internal control scheme must be supported with correct and up-to-date information shared with all relevant parties within the organization. To this end, organizations must:
Capture data sources and process and classify relevant information and manage the resulting information assets.
Communicate information needed to support functioning controls to all relevant stakeholders, including management and staff.
Communicate relevant information to external parties about objectives, controls, changes, incidents or system failures.
CC3: Risk Assessment
Understanding the risks your organization faces is key to designing suitable controls that allow you to control and mitigate said risks. As part of this criterion, your entity has to:
Establish objectives that comply with relevant standards and regulations, reflect management choices and consider acceptable risk tolerances.
Identify risks, threats and vulnerabilities that threaten business objectives and determine how to respond to these risks.
Assess changes to the IT environment, leadership, business model or external relationships that could affect risks and the effectiveness of internal controls.
CC4: Monitoring Activities
To ensure that internal controls remain functional and effective, organizations undergoing a SOC 2 examination need to implement suitable monitoring activities that allow them to detect deficiencies and take corrective action. This requires you to:
Implement a mix of different evaluations, integrating them with business processes and adjusting their scope and frequency depending on risk.
Assess results and take corrective action, monitoring whether deficiencies are resolved in a timely fashion.
CC5: Control Activities
The term control activities describes a wide range of processes and safeguards that an organization may choose to implement in order to mitigate risks to the security, availability, processing integrity, confidentiality and privacy of client data.
The right mix of controls depends on both the business processes you need to secure and the structure of your IT environment. Essential considerations when it comes to control activities are:
Basing control activities on your risk assessment and the specific environment, complexity and scope of your organization.
Determining relevant business processes and implementing appropriate controls at both a technology, infrastructure and organization level.
Reviewing policies and procedures periodically to ensure their continued relevance and effectiveness.
CC6: Logical and Physical Access Controls
SOC 2 requires entities to restrict access to information assets, ensuring that only authorized individuals can view or process sensitive data. To this end, organizations need to manage both physical access to their premises and logical access to information systems.
Your approach to access control should follow best practices such as Role-Based Access, the Principle of Least Privilege and Separation of Duties. Every step of the process, from secure authentication to managing credentials and governing access privileges, must be effectively managed by the organization. This involves:
Creating, managing and classifying an inventory of information assets.
Identifying and authenticating users prior to access, using multi-factor authentication where deemed necessary to mitigate risks.
Using access control structures such as role-based access, periodically reviewing roles to ensure appropriate access.
Implementing encryption to protect information assets and communication channels, safely disposing of removable media and storage devices.
Using anti-malware software and restricting the installation of software and unauthorized changes to IT systems and configurations.
Access Governance Best Practices for Microsoft Environments
Everything you need to know about implementing access control best practices in Active Directory, from implementation tips to common mistakes.
CC7: System Operations
This section covers common criteria related to the ensuring the continued operation of your IT systems, which range from monitoring for vulnerabilities and signs of disruption to implementing an incident response plan to guide your emergency activities, as well as a recovery plan that will help you restore functionality. Points of focus include:
Conducting vulnerability scans and implementing monitoring procedures to detect unauthorized changes or system components in the environment.
Creating an incident-response program to contain and mitigate ongoing incidents, assigning roles and responsibilities to clearly guide remediation actions.
Developing a recovery plan in order to restore affected systems, which is tested regularly to ensure effectiveness.
Evaluating detected security incidents, taking measures to prevent reoccurrence and improve security procedures.
Assessing the impact on personal or confidential information and following breach disclosure protocols.
CC8: Change Management
Under the SOC 2 framework, changes to your IT environment or business processes need to be carefully considered in order to avoid unintended consequences that could threaten your service commitments and system objectives. Your change management program needs to:
Design, approve, document and manage changes to your environment throughout the entire lifecycle of the affected system.
Take into consideration system resilience and the protection of personal and confidential information.
CC9: Risk Mitigation
In addition to risks in managing your own IT environment and business processes, you also need to consider risks to your operations arising from vendors and business partners. Your risk evaluation should cover not only security incidents, but also the threat of service disruptions or suppliers going out of business. Steps towards risk mitigation involve:
Identifying vulnerabilities to your network arising from third-party access by vendors and business partners.
Setting requirements for vendors and partners, assessing their performance and addressing identified issues.
Creating a procedure for safely terminating business relationships, ensuring the removal of partners from IT systems and the safe return of information assets.
Obtaining privacy and confidentiality commitments from business partners consistent with your own commitments.
Additional Criteria for Availability
Unlike the common criteria used in every SOC 2 examination, these requirements only apply if you choose to include availability as part of the audit. Testing against this objective involves additional consideration to business continuity and steps to minimize service disruptions, such as:
Monitoring and forecasting processing capacity to manage demand and avoid constraints.
Identifying and safeguarding against environmental threats that could endanger the availability of provided services.
Implementing backup and recovery procedures, including offsite storage and alternate processing infrastructure.
Testing business continuity plans and the completeness of backup data.
Additional Criteria for Confidentiality
SOC 2 requires your organization to protect information assets of all types from unauthorized access. However, the trust service criteria for confidentiality include additional requirements for confidential information.
Identifying and designating confidential information based on internal definitions and objectives.
Retaining confidential information for no longer than is necessary to achieve its intended purpose and/or comply with laws and regulations.
Creating a procedure to safely destroy confidential information at the end of its retention period.
Additional Criteria for Processing Integrity
Trust service criteria around processing integrity are designed to ensure the quality and accuracy of data your organization collects, processes and stores. They include:
Defining the data, specifications and processing activities necessary to support the service you provide.
Detecting and correcting errors in data processing activities.
Protecting data from tampering, theft, destruction or deterioration.
Additional Criteria for Privacy
If you include privacy in the scope of your SOC 2 audit, you will have to fulfill additional requirements both around protecting personally identifiable information and disclosing your privacy practices.
Informing data subjects of your organization’s privacy practices.
Obtaining consent from subjects before collecting personal information, informing them of the choices available to them and obtaining information by fair and lawful means.
Limiting the collection and retention of personal information to only what is necessary to achieve business objectives, processing it only for the intended purpose and disclosing it only when appropriate.
Responding to data access requests in a reasonable time frame, correcting and updating data upon request.
Evaluating whether third-parties are in compliance with privacy commitments and remediating the misuse of personal information if not.
SOC 2 & IGA: Essential Governance Capabilities
As you can see from this list, SOC 2 demands a wide range of controls across both technology, processes and people. Whether you are focusing on the shared requirements focused on cybersecurity or including additional trust services criteria in your audit: You need the right tools to pass your SOC 2 examination.
One essential component of a successful SOC 2 strategy is Identity Governance & Administration. IGA not only required to implement the logical access control structures required by SOC 2, it streamlines routine IT tasks such as lifecycle management or processing access requests. This frees up your IT team, helping you get audit-ready faster!
How IGA and SOC 2 go hand-in-hand:
You need an IGA solution in order to implement the access control measures required by SOC 2.
Centralized access governance makes it easy to create reports or view historical data, allowing you to pull up access data your auditor requests in seconds.
Automated user lifecycles and streamlined governance gives you the time to focus on other aspects of SOC 2 compliance
tenfold: The Stress-Free Approach to Identity & Access Governance
If you are preparing for SOC 2, there is simply no way around Identity Governance & Administration. But that does not tell you which solution is the best fit for your org.
Here’s the problem: Conventional IGA platforms require extensive scripting and customization to set up. Despite offering basic connectors, workflows and common interactions are built from the ground up for every deployment. This makes setup complex, costly and time-consuming. Multi-year setup phases are not uncommon, with many projects ending up unfinished or in distress.
By contrast, tenfold is designed for quick and easy deployment, allowing you to go from unmanaged access risk to full control and automation in as little as a few weeks. Our fully functional out-of-the-box plugins and no-code configuration make tenfold a breeze to set up, manage and operate. In fact, the entire platform can be run on the side by a single admin.
Learn more about how tenfold can help you get ready for SOC 2 by booking a personal demo with our team or signing up for a free 30 day trial of our solution.