SOC 2 FAQ

Developed by the American Institute of Certified Public Accountants (AICPA), a SOC 2 Report attests to the ability of a service organization’s internal controls to manage client data in a secure and trustworthy manner. This independent report attests to the results of a comprehensive audit that focuses on system-level controls that process client data. This is in contrast to a SOC 1 report focusing on financial reporting controls.

Generally, if you have a “SOC 2,” they are referring to a SOC 2 Type 2 Service Auditor’s report that includes the Security and Availability Trust Services Criteria. A SOC 2 Type 2 report covers the design and documentation of controls and provides evidence as to how the organization actually operated the documented controls over an extended period of time (usually a year).

When a service organization undergoes a SOC 2 audit, they specify whether the auditor will perform a SOC 2 Type 1 or SOC 2 Type 2 audit. A SOC 2 Type 1 report attests to the design and documentation of a service provider’s controls and procedures as of a specific date. However, the SOC 2 Type 1 report does not cover the actual operation of the controls.

Like a SOC 2 Type 1 report, a SOC 2 Type 2 report covers the design and documentation of controls. A SOC 2 Type 2 report also provides evidence as to how the organization actually operated its controls over a period of time (usually six months or more). It is important to note that the scope of the controls covered in a SOC 2 Type 1 versus a SOC 2 Type 2 report can be the same. That is, a Type 2 report is not inherently more stringent than a Type 1 report. The key difference is whether controls are examined “on paper” at a point in time or in operation over a period of time.

The SOC 2 Trust Services Criteria (formerly called the SOC 2 Trust Services Principles) are the full set of criteria that can potentially be included in a SOC 2 examination. The latest Trust Services Criteria are required to be used in any SOC 2 report issued on or after December 15, 2018.

There are currently five Trust Services Criteria: Security, Availability, Confidentiality, privacy, and Processing Integrity. Of these five, only Security is mandatory to be covered in every SOC 2 examination.

The others can be covered or not based on their applicability to the service being offered. Each of these five criteria includes many other criteria, and there is significant overlap among them.

Trust Services Criteria (TSC) are the domains or scope covered in a SOC 2 report. Not all TSCs are required. In fact, only the common criteria are required (also referred to as the Security TSC). Other TSCs should be added to a report to answer common risk-related questions received from clients or to address risks facing the company and its unique service offering. For example, if the availability of healthcare data is extremely important to a service offering, then the availability criteria may be included in the SOC 2 report in addition to the security criteria.

We have had prospective clients say they wanted all of the TSCs included within their SOC 2 report because they wanted it to be the strongest report possible. While the logic makes sense, not all TSCs may apply to a particular client’s service. For example, if your company does not process transactions, processing integrity is probably not applicable.

We have heard of firms including TSCs when they are not applicable within a report and then explaining why they are not applicable within the report. That’s not advised. Your best bet is to select criteria that are applicable to your services and answer the risk-related questions you hear most from your clients and prospective clients.

The Trust Services Criteria are noted below:

• Security: The system is protected against unauthorized access (both physical and logical). Examples of commonly reviewed SOC 2 security controls relate to the restriction of logical access within the environment to authorized individuals. Also, security configurations such as password complexity, MFA, and branch protection rules
• Availability: The system is available for operation and use as committed or agreed. The availability criteria require that an organization document a DR and BCP plan and procedures. In addition, it requires backups and recovery tests to be performed.
• Confidentiality: Information that is designated “confidential” is protected according to policy or agreement. In many cases, this covers business-to-business relationships and the sharing of PII or sensitive data from one business to another.
• Processing Integrity: System processing is complete, accurate, and authorized. Processing integrity may be relevant to organizations that process transactions such as payments, or errors made by your organization, such as flawed calculations or processing, can impact your clients’ financials or significant processes. If processing integrity is relevant and included in a SOC 2 report, the auditor will review evidence that processing is complete and accurate and that errors related to processing are identified and corrected.
• Privacy: The privacy criteria should be considered when “personal information is collected, used, retained, disclosed, and disposed of to meet the entity’s objectives.” It’s important to note that the privacy criteria apply to personal information. This differs from the confidentiality criteria, which apply to other types of sensitive information.

Privacy Versus Confidentiality Criteria

There are numerous flavors of privacy requirements in place throughout the world. Some, such as GDPR and CCPA, apply to all citizens in a particular area and give protections to all citizens in that area. Currently, privacy requirements in the United States follow a sectoral approach where laws apply to industries or types of data rather than a standard approach for all citizens.

The AICPA’s privacy criteria are applicable only if your organization deals directly with data subjects and collects data such as PII from those data subjects as part of the service.

The collection of emails and contacts for marketing purposes by organizations is not typically enough to warrant the inclusion of privacy criteria. In many cases, an organization is entrusted with PII or sensitive data collection by another organization. This is considered confidential by the AICPA (B2B data sharing). If your organization collects data directly from consumers, the privacy criteria may be relevant. Processing integrity is unique to each organization if it’s relevant because no two organizations process their transactions in the exact same manner.

As SOC 2 is not a standard but a report, there is no SOC 2 “compliance” per se. Instead, you need to pass a technical audit that determines whether your organization has created, documented, and is following a wide range of policies and procedures that encompass the Security Trust Services Criteria and any other criteria that are within the scope of your audit.

For many service organizations, security criteria are of primary interest to their clients and other stakeholders. Therefore, the scope of a SOC 2 examination, and thus the requirements for SOC 2 “compliance,” might only include the Security criteria.

A SOC 2 Report is an independent report, issued by a CPA firm, that covers a service organization’s internal controls that relate to securing and managing client data.

A SOC 1 report focuses on financial reporting controls rather than security controls.

The American Institute of CPAs (AICPA) specifies the components of a SOC 2 report and what information each component needs to include. But it does not specify a format for SOC 2 reports. This allows auditors to organize their reports as they see fit.

An actual SOC 2 Type 2 report addresses different criteria and includes different controls and tests of controls specific to the organization being audited.

Unlike some other information security standards like PCI DSS, which have very specific requirements, the policies, procedures, and technical controls you need to put in place to comply with SOC 2 are unique to each organization.

An organization designs its own controls, in line with its business practices, to comply with the relevant SOC 2 Trust Service Criteria.

SOC 2 reports can be Type 1 (aka Type I) or Type 2 (aka Type II) reports.

Type I SOC 2 reports are dated as of a particular date and are sometimes referred to as point-in-time reports. A Type I SOC 2 report includes a description of an organization’s system and a test of the design of relevant controls. A Type I SOC 2 tests the design of a service organization’s controls but not their operating effectiveness.

Type II SOC 2 reports cover a period of time (usually 12 months), include a description of the service organization’s system, and test the design and operating effectiveness of key internal controls over a period of time.

Type II SOC 2 reports cover a period of time (usually 12 months), include a description of the service organization’s system, and test the design and operating effectiveness of key internal controls over a period of time.

Licensed CPA firms that specialize in information security audits are the only organizations that should perform SOC 2 examinations. There are some organizations that perform SOC 2 audits and have a CPA firm sign off on their report even though the CPA firm did not perform the audit. We recommend staying away from that approach. We also recommend selecting a firm that has experienced IT auditors and not only financial audit CPAs. When selecting a firm to perform a SOC 2, we recommend asking for the resumes of any of the auditors that will complete the work. Then, ensure the selected firm has auditors with the appropriate skills and expertise. Certifications such as CISA or CISSP are good to look for. Also, check references and ensure the selected firm has experience in the field you are in.

On December 15, 2018, new SOC 2 guidance went into effect, and all reports following that date must include the updated SOC 2 criteria.

A SOC 2 is not a certification, but it’s commonly referred to as one. You do not get a certification at the end of the audit; rather, you get an audit report with either a clean report opinion or a qualified opinion.

A clean report opinion simply means all is well and the auditors have a positive view of your organization’s controls. This is the end goal every organization wants! A clean SOC 2 report!

A qualified opinion report, on the other hand, is exactly what you think it is. It is the auditor’s negative view of your organization’s controls. The auditor may have identified some inconsistencies and irregularities as part of the audit and drawn negative conclusions about the operational effectiveness of the controls. This is not the desired outcome.

The answer is yes; based on the nature and complexity of the organization, an alternative equivalent of a BOD can be used to demonstrate compliance with the requirement.

This can include the presence of an Executive committee, council, or senior management team.

All required controls come with your program, so they are required for your SOC2 compliance. You also have the ability to link controls to policies; see the Mapping Controls to Policies section here.

All required controls come with your program, so they are required for your SOC2 compliance. There can be instances where you do not adhere to certain controls as they are not relevant for your business. For example, if you are a consulting organization, you do not need to show adherence to controls regarding changes that are tested and approved, as you do not do any in-house development. In these situations, you can exercise control by following the instructions here.

Yes, encryption will be necessary.

All required controls and policies are adopted in your program, so they are required for your SOC2 compliance. Again, based on question #2 above, if change management does not apply to your business, you can submit a request for deletion of that policy.

This is more about our control over naming conventions and does not have any impact on your program.

You have the flexibility to modify your controls. Please see here for more details.

We recommend using groups to get started. If you want to do a heavy lift, you can start with IT or Security groups. The HR or Leadership groups can be a little lighter on the control side and can give you some quick wins.

Our controls are not designed to be one-and-done because TrustCloud believes you have to continuously monitor your environment. Each of our controls comes with a defined frequency when they need to be re-attested and fresh evidence is required. If all your controls are updated, your program is effective. If you have multiple controls that are “out of date,” then that program is essentially not effective. Please see here for more details.

It depends on your auditors. In general, a pen test is required for SOC 2, but some audit firms would make an exception for Type 1 and allow organizations to skip this requirement or demonstrate an “intention” to have a pen test done at some point in the near future. 

Regardless, any company doing a SOC 2 would eventually do a Type 2, which absolutely requires pen testing. As such, it’s advisable to err on the side of caution and get one.

On top of that, SOC 2 or not, all organizations should conduct pen testing at least every year to see how vulnerable they are.