The Ultimate Guide to SOC 2 Requirements
SOC 2 compliance can feel like cooking without a recipe.
Your ingredients are the controls your company puts in place to convince businesses that you’re a responsible steward of their data. The final dish is a reliable audience of trusting customers.
But with no set compliance checklist — no recipe — how are you supposed to know what to prioritize?
The solution is to know SOC 2 inside and out so you can predict what angle your auditor is likely to take. You’ve already taken the first step by coming here. This article will tell you everything you need to know about the SOC 2 requirements.
What is a SOC 2 report?
A SOC 2 report (Service Organization Control) is a way to build trust in the services you provide to customers. As a third-party service organization, you work directly with a lot of your clients’ most sensitive data. A SOC 2 report is evidence that you’ll handle that customer data responsibly.
To get a SOC 2 report, you have to undergo an audit by a third-party auditor. A SOC 2 auditor will be either a CPA or a firm certified by the American Institute of Certified Public Accountants (AICPA). They’ll evaluate your information security control policies based on a flexible set of values called trust services criteria (TSC).
SOC 1 is designed specifically for service organizations that provide financial reporting services. These get their own set of standards because of the outsized risk posed to a user entity that gives another company access to its books. If any irregularities turn up in the reports, the user entity could be liable.
SOC 2 is a general standard for information security based on the trust services criteria. It’s open to any service provider and is the one most commonly requested by potential customers. It’s the one we’ll be talking about for the rest of this post.
SOC 3 is also based on the TSC but results in a shorter SOC report that’s easier to parse. Companies get a SOC 3 report to share it with the general public, building trust with customers who might not have time to peruse a full report.
SOC 1 and SOC 2 come in two subcategories: Type I and Type II. A Type I SOC report focuses on the service organization’s data security control systems at a single moment in time. In a Type I SOC audit, the auditor looks solely at documented processes, producing a SOC report in a few weeks.
A Type II SOC report takes longer and assesses controls over a period of time, typically between 6-12 months. In addition to documented systems, a Type II report considers how well those systems work in reality. The auditor runs experiments such as penetration tests to see how the service organization handles actual data security risks. Businesses often seek a Type II report after achieving a positive Type I.
What is required for a SOC 2 report?
In contrast to a certification process like ISO 27001, there is no specific checklist for SOC 2 (or any such thing as SOC 2 certification). Instead, auditors determine which controls to evaluate on a case-by-case basis. The trust services criteria provide guidelines to structure each report, but ultimately, no two SOC 2 audits will look exactly alike.
We’ve mentioned the trust services criteria several times now, so let’s unpack exactly what they are. Before you seek a SOC 2 report, know the TSC backward and forward since they’re the basis for all SOC 2 requirements.
The criteria break down into five trust services categories: security, availability, processing integrity, confidentiality, and privacy.
In the next section, we’ll explore what each of those means and what controls an auditor might devise based on each. But, before that, it’s important to understand how these categories go toward building your SOC 2 report.
Each category includes two types of criteria: common criteria (which are the same in all five categories), and specific criteria (which are present in every category except security).
All SOC 2 requirements are optional, except those that fall under security. You can be 100% certain that your auditor will examine whether you’re compliant with security’s common criteria. It’s impossible to get a positive SOC 2 report without doing that.
The common criteria are further subdivided into five series:
- CC1 series: The control environment. What is the context of your company’s controls for the category?
CC2 series: Communication and information. How do members of your team exchange information about the category?
- CC3 series: Risk assessment. How do you spot, analyze, and mitigate risks to the category?
- CC4 series: Monitoring of controls. What methods do you use to constantly improve your controls for the category?
- CC5 series: Design and implementation of controls. How do you create and implement new controls for the category?
Category-specific controls are grouped under the acronym of their category: A series (availability), PI series (processing integrity), C series (confidentiality), and P series (privacy).
When you invite a CPA to your office for a SOC 2 audit, you don’t know which criteria they’ll be checking for (except for the common criteria of security). Before the audit, your task is to “study for the test” by determining which criteria the auditor is most likely to pick out.
For example, not every service organization handles confidential customer data. A company that deals with healthcare records needs to pay close attention to the C series to comply with HIPAA. On the other hand, a company that sells cloud-based server time might be able to ignore it entirely.
What are the trust services criteria?
This section lays out the five trust services categories in-depth, along with some examples of controls an auditor might derive from each.
AICPA definition: “Information and systems are protected against unauthorized access.”
Security is the fundamental core of the SOC 2 compliance requirements. The category covers defenses against all forms of attack, from DDoS and man-in-the-middle hacks to malicious individuals physically gaining entry to your servers.
An auditor might check for two-factor authentication systems and web firewalls, but they’ll also look at policies that indirectly influence security, like policies determining who gets hired for security roles.
AICPA definition: “Personal information is collected, used, retained, disclosed, and disposed of to meet the entity’s objectives.”
Privacy applies to any information that’s considered sensitive because of its personal nature. To meet the SOC 2 requirements for privacy, an organization must communicate its policies to anybody whose data they store.
If the service organization collects any sensitive information, it must obtain consent from the subject. As much as possible, it must limit the amount of private information it collects, gather it by lawful means, and use it only for the purposes it was collected for.
Finally, when the personal information has served its purpose, the service organization is required to dispose of it.
AICPA definition: “Information designated as confidential is protected to meet the entity’s objectives.”
Confidential information is different from private information in that, to be useful, it must be shared with other parties. The most common example is health data. It’s highly sensitive, but it’s worthless if you can’t share it between hospitals and specialists.
Instead of keeping the information totally secure, the confidentiality category focuses on exchanging it securely. Meeting the SOC 2 confidentiality criteria requires a clear process for identifying confidential information.
Once identified, the confidential data must be protected until the end of a predetermined retention period, then destroyed to prevent unnecessary spreading.
AICPA definition: “System processing is complete, valid, accurate, timely, and authorized to meet the entity’s objectives.”
The criteria in the processing integrity category ask whether the systems used to store, process, and retrieve information work the way they’re supposed to. Processing integrity backs away from information security to ask whether you can trust a service organization in other areas of its work.
Some controls in the PI series refer to the organization’s ability to define what data it needs to achieve its goals. Others define processing integrity in terms of inputs and outputs. For example, if a customer inputs an order on an e-commerce website, the output is prompt delivery of the product.
Outputs should only be distributed to their intended recipients. Any errors should be detected and corrected as quickly as possible.
AICPA definition: “Information and systems are available for operation and use to meet the entity’s objectives.”
The Availability controls in SOC 2 focus on minimizing downtime. Where the processing integrity category was all about the quality of inputs and outputs, the availability series is about consistency.
Are the systems of the service organization backed up securely? Is there a recovery plan in case of a disaster? Is there a business continuity plan that can be applied to any unforeseen event?
A1 series controls ask the service organization to forecast system capacity, identify and mitigate environmental threats, and correctly identify what data to back up. Risk assessment is critically important for this category.
What is a SOC 2 readiness assessment?
Most companies conduct a readiness assessment before seeking a SOC 2 audit.
Earlier, we likened preparing for a SOC 2 audit to studying for a test. You know the material you’ve learned in the course, but you don’t know what the teacher will choose to ask you about. To be safe, a competent student reviews everything that has a chance of being relevant.
In this analogy, a SOC 2 readiness assessment is like taking a practice exam. You’ve “studied” by reviewing the TSC, determining which criteria apply to your business and documenting each related internal control. The readiness assessment serves as “practice,” estimating how the audit would go if you took it today.
A readiness assessment will be conducted by an experienced auditor — almost always someone also certified to perform the SOC 2 audit itself. In the end, you’ll receive a letter explaining where you might fall short of being SOC 2 compliant. Use this letter to conduct a gap analysis, determining what you still need to do to meet the SOC 2 requirements.
If you follow the advice you get from your readiness assessment, you’re far more likely to get a favorable SOC 2 report.
At first glance, it might seem daunting and frustrating that SOC 2 doesn’t offer a compliance checklist. But the farther you get in the process, the more you’ll begin to see that this absence is a feature, not a bug.
If the SOC 2 requirements were too rigid, they might not make sense for your business — the proverbial test that asks a fish to climb a tree. The trust services criteria make SOC 2 a versatile, adaptable standard. Working with a qualified partner can make it easy to anticipate the auditor’s moves.
Many businesses now demonstrate their commitment to security through automated compliance, letting them implement more controls with less work. Secureframe is at the cutting edge of compliance automation. So if you’re ready to start building trust, request a SOC 2 demo right now.