SOC 2 Compliance: The Complete Introduction

SOC 2 Compliance: The Complete Introduction

Are you looking to develop, streamline, or mature your SOC 2 compliance program? Do you think  SOC 2 would make a beneficial addition to your organization’s risk management and compliance program? Are you a SaaS company or similar service provider looking to build trust with customers, reduce due diligence efforts, and increase sales? Do you want to improve your organization’s information security program and don’t know where to start? This SOC 2 Guide is designed to be a starting point for understanding and executing a SOC 2 program, including:

  1. An overview of the SOC 2 framework structure and requirements, with an at-a-glance summary.
  2. Key steps in the SOC 2 process, including definitions, resources, and examples.
  3. A summary of the SOC 2 compliance flow. 
  4. Relationships to other standards and documents including ISO 27001, COSO Internal Control – Integrated Framework (ICIF), and SOC 1 and SOC 3.

CrossComply customers can go a step further to learn how to perform the various necessary activities described below within AuditBoard — simply click here to log in and follow the “CrossComply Connection” prompts for additional guidance. 

What is a SOC 2?

SOC 2 is shorthand for several things: a report that can be provided to third parties to demonstrate a strong control environment; an audit performed by a third-party auditor to provide said report; or the controls and “framework” of controls that allow an organization to attain a SOC 2 report. In other words, SOC 2 is a “report on controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy,” according to the AICPA. The SOC 2 framework is published by the American Institute of Certified Public Accountants (AICPA) and is a voluntary cybersecurity attestation most widely used by service organizations with primarily US-based customers, partners, and other stakeholders. 

To receive a SOC 2 report, an organization must go through a third-party audit of their system and organization controls, providing those auditors with evidence and documentation to demonstrate that internal controls are appropriately represented by management — which is a long way of saying that third party auditors make sure companies looking for a SOC 2 attestation is walking the talk in terms of their security controls.

In order to get ready for a SOC 2 audit, an organization needs to implement policies, procedures, and controls to meet the criteria of the SOC 2. Although the American Institute of CPAs (AICPA) does not perform SOC 2 audits, they do provide guidance for what criteria makes a company compliant with SOC 2 requirements. During the implementation process, an organization might have to develop and launch access controls, data protection controls, and consider an internal audit to prepare for the external audit.

The benefits of an unqualified SOC 2 report, depending on the type of SOC 2 report (there are two types), are numerous and include:

  • Streamlining due diligence or security questionnaire efforts — many customers, partners, and stakeholders would prefer to review a SOC 2 report over custom responses to due diligence or security questionnaires.
  • Improve trust with customers, partners, and stakeholders.
  • Attestation of strong internal controls design and/or operating effectiveness.

 ISO 27001, which has considerable overlap with the SOC 2 criteria, is popular internationally and was established by the International Organization for Standardization (ISO) to fulfill a similar need. 

SOC 2 Framework at a Glance

SOC 2 Framework at a Glance

The SOC 2 framework is designed to be used by all types of service organizations, and is currently very popular among SaaS companies. As such, the criteria provide flexibility in how they can be applied and therefore audited. Unlike more prescriptive cybersecurity frameworks, SOC 2 allows the service organization to define how its cybersecurity controls are implemented, provided they meet the intent of the criteria they satisfy, and address risks sufficiently.

SOC 2 is closely aligned to the 17 principles in the COSO framework published in 2013. It uses these principles as the baseline of many of the Common Trust Services Criteria described in the next section.

SOC 2 has become the de facto standard in the U.S. for service organizations to attest to the quality of their controls related to provided services. Service organizations wishing to do business with customers in the U.S. know that it’s become critical to obtain SOC 2 attestation  in order to earn new business and/or maintain existing business.

The InfoSec Survival Guide: Achieving Continuous Compliance

What Are the SOC 2 Requirements?

Trust Services Criteria

SOC 2 is made up of five Trust Services Criteria— Security (Common Criteria), Availability, Processing Integrity, Confidentiality, and Privacy. Each SOC 2 report uses the Security Trust Services Criteria as the baseline for each report, meaning that every SOC 2 will include the Common Criteria within the Security category. Each organization can then opt to add in any of the remaining four Trust Services Criteria (TSCs) — Availability, Confidentiality, Processing Integrity, and/or Privacy — depending on their type of business, organizational goals, or customer/ partner demands. Each of the five categories has a specific focus:

  • Security (Common Criteria): Information and systems are protected against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, and privacy of information or systems and affect the entity’s ability to achieve its objectives. Security forms the baseline for any SOC 2 report and will be included in every SOC 2 report. Organizations can opt to have an examination performed only on Security controls. Some controls that would fall under the Security TSC are: firewall and configuration management, vendor management, identity, access, and authentication management, and if applicable, data security and data center controls.
  • Availability: Information and systems are available for operation and use to meet the entity’s objectives. Examinations that include the Availability criteria take a deeper dive into recovery controls, service-level agreements, and capacity planning.
  • Processing Integrity: System processing is complete, valid, accurate, timely, and authorized to meet the entity’s objectives. The Processing Integrity criteria focuses on data inputs and outputs, data quality, data processing timing, and reporting.
  • Confidentiality: Information designated as confidential is protected to meet the entity’s objectives. Confidentiality as a TSC reviews a company’s maintenance of confidential information and disposal thereof. Various types of data can be classified as confidential by a company, including customer data, sensitive data, intellectual property, and contracts among others.

  • Privacy: Personal information is collected, used, retained, disclosed, and disposed of to meet the entity’s objectives. Privacy explicitly deals with personal information — that is, information related to real human beings and their identities. Personal information can take the form of HIPAA-protected information, personally identifiable information (PII), and other types of sensitive data related to a person. This criteria overlaps significantly with HIPAA and other privacy-centric frameworks and guidance and can help organizations demonstrate a dedication to privacy. The Privacy criteria, crucially, requires controls around data breaches and incident disclosure.

SOC 2 Trust Services Categories

Trust Services Criteria

Each of the five Categories includes numerous Trust Services Criteria, which are the specific criteria used to assess a service organization’s environment. The Trust Services Criteria are also organized numerically as shown below. This numbering system indicates a specific topic/domain in which the criteria fall (i.e., Monitoring of Controls, Risk Assessment).

SOC 2 Trust Services Criteria

Points of Focus

Each Trust Services Criteria includes one or more Points of Focus. The Points of Focus are provided as guidance to auditors and service organizations to aid in the design of suitable controls to meet the associated criteria. While compliance to all Points of Focus within the criteria is not required, auditors may use these as determining factors in the suitability of the design of the control(s) being assessed. For the criteria aligned with COSO principles, the COSO Points of Focus are included in the SOC 2 Framework and, as needed, supplemented by additional points of focus specific to the nature of the SOC 2 report. Service organizations should use their best judgment in determining which Points of Focus are applicable to the service being provided as well as their unique organization.

SOC 2 Structure Diagram

SOC 2 Structure Diagram

SOC 2 Scoping and Framework Application

SOC 2 is unique from most cybersecurity frameworks in that the approach to scoping is highly flexible. Typically, service organizations will only choose to include the Criteria that are relevant to the service they provide. Most importantly, service organizations should choose the Category or Categories that their customers would expect to see in a SOC 2 report. While the organization chooses the applicable categories, the inclusion of Security (Common Criteria) is mandatory. As such, if an organization wants to report to their customers on compliance with the Privacy category, they are required to meet requirements of both Security criteria and Privacy. 

The table below shows examples of the types of service or industry that would be relevant to each of the Trust Services Categories. The table is not exhaustive and other examples may be relevant.

Trust Services Categories Use Cases

Once the appropriate Category or Categories are selected, a service organization must then determine if each of the Trust Services Criteria within the applicable Category or Categories applies to the service being provided.

Trust Services Criteria Scoping Decision Tree

Service organizations should be prepared to provide justification to SOC 2 auditors on why certain Trust Services Criteria do not apply. Typically, it would apply to situations where an activity specified in the criteria is not performed by the organization at all, or is outsourced to a third party. Often a carve out method is used in the SOC 2 report for such instances — please see the Assessing Against the SOC 2 Framework section below for more details.

SOC 2 Framework Execution 

In order to successfully execute a SOC 2 program, organizations should implement ongoing key control activities to align with the Trust Services Criteria. The activities that must be performed to ensure compliance with SOC 2 requirements will primarily be driven by the service organization’s SOC 2 scope. Specifically, each Trust Services Category will drive a set of activities that must be performed to ensure compliance. We’ve summarized some of the key control activities commonly required for SOC 2 compliance and the frequency by which the activity needs to be performed. The list below does not include a complete list of key control activities to address all of the individual Trust Services Criteria — a complete listing of the TSCs is available in CrossComply via the UCF® integration.

  • Establish an Information Security Program – Reviewed/Updated at least annually.
  • Create, Maintain, and Promulgate Policies and Procedures – Reviewed/Updated at least annually.
  • Third-Party Risk Assessment / Vendor Reviews – Based on the organization’s policies/procedures, but at least annually.
  • Conduct a Risk Assessment of the In-Scope Environment – Based on the organization’s policies/procedures, but at least annually.
  • Mitigate Identified Risks – Ensure documented mitigation plans exist for applicable risks. Ensure mitigation plans are implemented.
  • Establish and Maintain a Compliance Evaluation Program – Based on the organization’s policies/procedures, but at least annually.
  • Document and Update In-Scope Control Activities – Reviewed/Updated at least annually.
  • Establish a Logical Access Management Program – Based on the organization’s policies/procedures, but at least annually.
  • Establish a Physical Access Management Program – Based on the organization’s policies/procedures, but at least annually.
  • Establish and Maintain an Information Asset Inventory – Reviewed/Updated at least annually.
  • Establish and Maintain a Data Classification Matrix – Reviewed/Updated at least annually.
  • Define and Maintain System Configuration Standards – Reviewed/Updated at least annually.
  • Conduct Vulnerability Scans and/or Penetration Testing – Based on the service organization’s policies/procedures, but at least annually.
  • Create and Maintain a Security Incident Response Plan – Reviewed/Updated and tested at least annually.
  • Perform Logging and Monitoring of the In-Scope Environment – Based on the service organization’s policies/procedures, but at least annually.
  • Establish and Maintain a Change Management Program – Ensure change records exist for all in-scope components during the defined time period.

It’s important to remember that SOC 2 requires documentation of control activities for all in-scope control activities, as well as the ability to prove that the control activity is operating effectively over the time period identified in the report. The latter only applies to a SOC 2 Type II audit, described in more detail in the next section. Evidence will be required during the SOC 2 external audit.

Assessing Against the SOC 2 Framework

Any organization can assess itself against SOC 2 Trust Services Criteria. SOC 2 includes a requirement for an evaluation program to be created and maintained. This can be either an internal or external assessment program, or both. 

Internal / Self-Assessments

Ideally, internal assessments will follow the same practice as external assessments. A best practice for SOC 2 compliance is to assess all controls within the scope of an organization’s SOC 2 compliance program at least annually. However, organizations may choose to assess only high-risk controls within the assessment cycle. Internal assessments should always use the defined Trust Services Criteria to ensure compliance.

External Assessments/Audits

As required by the AICPA, only CPA organizations can conduct SOC 2 audits and create corresponding reports. There are two types of reports that can be created by a CPA organization after performing a SOC 2 assessment:

  • Type I Report: A report on the service organization’s controls at a single point in time. This point in time is determined by the service organization and the auditor but is typically defined by the duration timeframe of the audit. A Type I report evaluates the design of controls as of a point in time.
  • Type II Report: A report on the service organization’s controls over a period of time**. The time period is determined by the service organization and is typically a full calendar year but can be as little as three months (this is the minimum time period allowed for a Type II). A Type II report evaluates the design and operating effectiveness of controls over a period of time.

Organizations leveraging third parties (referred to as sub-service organizations) to support compliance with select criteria will often use the carve-out method for their external audit reporting. A carve-out method allows the service organization to rely on the sub-service organization’s controls to demonstrate compliance, and the service organization is not required to implement their own internal controls to address those. All such exclusions need to be described in the final report.

Like most external compliance audits, there is a cost associated with SOC 2 external audits and the associated report. 

Achieving Ongoing SOC 2 Compliance

Maintaining SOC 2 compliance basically follows the same requirements as other cybersecurity frameworks. However, one important nuance to consider is for organizations maintaining annual Type II reports. 

To ensure that no exceptions are noted in an annual Type II report, organizations must be certain they can provide evidence that controls operated effectively over the preceding year. This means that controls must be tested based on the organization’s defined policies and procedures and evidence gathered on the cadence defined in these documents. For example, if a service organization’s policies and procedures say they conduct quarterly logical access reviews, that organization will need to provide quarterly evidence from the preceding year confirming those reviews were conducted.

Overview: SOC 2 Framework Compliance Flow

SOC 2 compliance doesn’t have to be overly complicated. We’ve broken down the process flow for achieving and maintaining SOC 2 compliance, from standard GRC process steps for initial setup and audit readiness, through interactions with your SOC 2 external auditor, as well as how to ensure ongoing compliance.

Initial Setup/Audit Readiness

  1. Scope Framework: Decide which Categories to include. Scope Criteria based on applicability. 
  2. Identify/Document Controls: Document control statements for existing controls. Identify gaps where controls don’t exist. 
  3. Implement Controls for Gaps: Implement controls for in-scope criteria that are not satisfied with current controls.
  4. Framework Execution: Ensure key activities are performed prior to control testing. 
  5. Gather Evidence for Internal Testing: Gather evidence showing control activities are in place. 
  6. Internal Self-Assessment: Document test plans for each control. Perform testing by using collected evidence. Identify issues where controls are not operating effectively. 
  7. Issue Management and Remediation: Remediate issues by correcting activities that are causing them. Retest controls until they pass. 

External Audit Process

  1. Issue Evidence Requests: Receive Request List (sometimes known as a PCB, IRL, or DRL)  from auditor. Issue evidence Requests to control owners.
  2. Review/Submit Evidence to Auditor: Review evidence for correctness. Submit evidence to auditor for review. 
  3.  Auditor Testing / Walkthroughs: Auditors perform testing of controls and walkthroughs. 
  4. Report Preparation: Preparation of audit report and QA process. Review of draft report. 
  5.  Report Issuance: Final report provided.  

Ongoing Compliance 

  1. Identify Internal Testing Schedule: Identify required recurring controls to be tested. Create a testing cycle for remaining controls. 
  2. Gather Evidence for Internal Testing: Gather evidence showing control activities are in place. 
  3. Internal Self-Assessment: Perform testing by using collected evidence. Identify issues where controls are not operating effectively.
  4. Remediate Issues: Remediate issues by correcting activities that are causing them.
  5. Retesting Cycle: Retest controls upon remediation of issues. Continue testing and remediation until all issues are resolved. 

How Does SOC 2 Relate to Other Standards and Documents?

Relationships exist between SOC 2 and other standards and documents. ISO 27001, COSO Internal Control – Integrated Framework, and SOC 1 and 3 are examples of standards and documents that are either directly related to the SOC 2 Trust Services Criteria or are frequently referenced in relation to SOC 2. 

ISO 27001: Standard for building an Information Security Management System (ISMS).

  • Very similar framework.
  • High level of commonality in requirements between both frameworks.
  • Where SOC 2 is used for US-based companies, ISO 27001 is used by companies outside the US.

COSO Internal Control – Integrated Framework: Framework for implementing an internal control structure to meet various compliance goals.

  • Basis for most of the Common Criteria (Security) Category in SOC 2.
  • SOC 2 provides additional requirements within each Category to add specificity to the COSO framework.
  • Also used to support Sarbanes-Oxley Act (SOX) requirements.

SOC 1: Report on controls relevant to Internal Control over Financial Reporting (ICFR).

  • Focus is on processes related to financial reporting; often used to support financial audits. *
  • Potential overlap of IT General Controls (depending on report scope).

SOC 3: A report on general effectiveness of your overall internal control program that is intended to be shared publicly.

  • Can only be issued once a SOC 2 has been completed.
  • SOC 3s can be shared publicly.

SSAE Standards: Standards used by CPA organizations to assess organizations against numerous AICPA standards/frameworks. 

  • No relationship other than an auditing standard used by auditors conducting SOC audits.
  • Applies to all SOC reports.
The InfoSec Survival Guide: Achieving Continuous Compliance

Using CrossComply to Manage the SOC 2 Framework

CrossComply has broad functionality that can help with automating many of the activities necessary to become SOC 2 compliant and maintain that status in perpetuity. CrossComply customers can learn how to perform the various necessary activities described above within AuditBoard— simply click here to log in and follow the “CrossComply Connection” prompts for additional guidance.

Frequently Asked Questions About SOC 2

What is the SOC 2 framework?

SOC 2 is shorthand for several things: a report that can be provided to third parties to demonstrate a strong control environment; an audit performed by a third party auditor to provide said report; or the controls and “framework” of controls that allow an organization to attain a SOC 2 report.

What are the SOC 2 requirements?

Depending on the report’s scope, a SOC 2 can have many requirements. Some of the key requirements include:

  • Establish an Information Security Program – Reviewed/Updated at least annually.
  • Create, Maintain, and Promulgate Policies and Procedures – Reviewed/Updated at least annually.
  • Third-Party Risk Assessment / Vendor Reviews – Based on the service organization’s policies/procedures, but at least annually.
  • Conduct a Risk Assessment of the In-Scope Environment – Based on the service organization’s policies/procedures, but at least annually.
  • Mitigate Identified Risks – Ensure documented mitigation plans exist for applicable risks. Ensure mitigation plans are implemented.
  • Establish and Maintain a Compliance Evaluation Program – Based on the service organization’s policies/procedures, but at least annually.
  • Document and Update In-Scope Control Activities – Reviewed/Updated at least annually.
  • Establish a Logical Access Management Program – Based on the service organization’s policies/procedures, but at least annually.
  • Establish a Physical Access Management Program – Based on the service organization’s policies/procedures, but at least annually.
  • Establish and Maintain an Information Asset Inventory – Reviewed/Updated at least annually.
  • Establish and Maintain a Data Classification Matrix – Reviewed/Updated at least annually.
  • Define and Maintain System Configuration Standards – Reviewed/Updated at least annually.
  • Conduct Vulnerability Scans and/or Penetration Testing – Based on the service organization’s policies/procedures, but at least annually.
  • Create and Maintain a Security Incident Response Plan – Reviewed/Updated and tested at least annually.
  • Perform Logging and Monitoring of the In-Scope Environment – Based on the service organization’s policies/procedures, but at least annually.
  • Establish and Maintain a Change Management Program – Ensure change records exist for all in-scope components during the defined time period.

How can the SOC 2 framework be applied?

The SOC 2 framework can be applied by first establishing the SOC 2 scope and included Trust Services Criteria, then by establishing controls to meet the intent of each criteria.

What are the steps for SOC 2 framework execution?

The general cycle for SOC 2 reporting and execution begins with readiness and preparing for the SOC 2, then performing some kind of internal assessment in compliance with SOC 2 requirements, before engaging a CPA firm to conduct a formal SOC 2 audit and issue a report.

Alan

Alan Gouveia is Head of Customer Experience, CrossComply at AuditBoard. Alan has worked in the GRC and cybersecurity space for over 20 years across multiple industries and organizations of different sizes. He specializes in a collaborative approach to GRC and cybersecurity, showing customers how to work across the entire organization to achieve business goals. Connect with Alan on LinkedIn.

Molly

Molly Mullinger was a Manager of Customer Experience at AuditBoard. Molly joined AuditBoard from EY, where she provided consulting services over regulatory compliance, including SOX compliance, technical accounting matters, and software implementations. Connect with Molly on LinkedIn.