The great philosopher Plato said, “a good decision is based on knowledge and not on numbers.”
With all due respect to Plato, he did not have to pay for compliance assessments in ancient Greece.
But of course, he’s not all wrong—not even when it comes to compliance—you do need knowledge to proceed towards your end goal of a completed report and successful audit.
If you’re someone who is considering a SOC 2 audit, be it due to customer request or just because, you may already understand that this examination will evaluate your product or service on a more operational and security-oriented level.
You may even already grasp that during a SOC 2, your scope will be evaluated against a set of trust service categories (TSCs) that provide the backbone of the assessment.
But what criteria are actually within those categories? And which ones will you need for your SOC 2 audit? At Schellman, we have a decade’s experience in SOC 2 examinations, and we want to help you navigate what can be a complex process.
So, read on, and you’ll be able to make your decision the Plato way, with complete knowledge of precisely what inclusion of each category will mean for your SOC 2 examination. From there, we’ll give you some guidelines for your internal conversations when making your choice—afterwards, you’ll be that much closer to pinning down what you need from your upcoming SOC 2 report.
The 5 Categories for SOC 2 Reports
Breakdown: Your auditor will assess how well your scope is protected against unauthorized access, use, or modification. If you’ve got the controls in place, they’ll get evaluated for how they prevent potential information theft, unauthorized use of data or disclosures, or abuse of software, among other things.
- Examples of security controls include tools like firewalls for both your network and web applications, multi-factor authentication, and intrusion detection.
*Security is the one trust service category that is generally required for every SOC 2 audit.
Breakdown: If included, your auditor will assess if your scoped system is available for operation and use as promised. You may have an agreement with customers to ensure some level of accessibility to this product or service you’re having evaluated. If that’s the case, both parties will have agreed to a set level of availability, and your auditor will check to make sure you’re honoring your commitment.
- Security and availability can be highly related categories within the context of each organization, as the security controls within your network can play directly into network performance facilitating availability, say, but they do not always go hand-in-hand.
3. Processing Integrity
Breakdown: If included, your auditor will assess that your scoped system does everything it’s supposed to, i.e., that it delivers the appropriate data the right way, at the right time, in a complete manner.
- An important distinction to note when considering this category: processing integrity does not necessarily translate to data integrity. Your examination would evaluate whether your process does what you say it should—not whether the data being input into said process is necessarily accurate or complete.
Breakdown: If included, your auditor will assess whether the information you’ve designated as confidential is protected. Again, this may go back to the contract signed, but data is considered confidential if access to it, as well as its disclosure, is restricted to certain people or organizations. Think business plans, intellectual property, or sensitive financial information, among other things.
- Transmission of data can often cause problems with this, which makes encryption an important control for protecting confidentiality. Similar to the relationship between security and availability, a connection between security and confidentiality can also exist, depending on your internal setup, since IT security tools like firewalls and other access controls can be used to ensure confidentiality as well.
Breakdown: If included, your auditor will assess your controls for your scoped system’s collection, use, retention, disclosure and disposal of personal information in conformity with your privacy notice if you have one, as well as with set criteria within AICPA’s generally accepted privacy principles (GAPP).
- Privacy is distinguished from confidentiality through the data itself—privacy protects personal identifiable information (PII), that which can identify a specific individual (e.g., name, address, Social Security number). In some situations, PII can also constitute information related to health, race, sexuality, and religion.
How Do You Choose the Right TSCs?
That’s probably what you’re wondering now, right?
Unfortunately, there is no checklist or even guidance on this, and it is entirely up to you to decide what to include.
We’ve been in this industry a long time, providing hundreds of SOC 2 reports every year to companies of differing types and industries, so we’ve seen a lot of different directions this tailoring can go. Though your organization will still forge its own way in the end, if you need help—more knowledge—here’s the main thing you need to understand:
Your eventual selection of your TSCs should be predicated entirely on your service commitments and requirements.
What that means is, however many categories you choose to include should be solely indicative of the commitments you have regarding your data and systems. Those requirements will provide the criteria basis for your auditors to evaluate against, and so inclusion beyond those categories that are relevant wouldn’t make sense—there simply wouldn’t be enough to speak to.
We said before that the security category is “generally required” for all SOC 2 audits—that’s because, typically, organizations do make service commitments around securing data (with rare exceptions). Assuming you are one of said organizations with promised security standards, that’s one TSC down.
Next, it’s time to drill down into the rest of your commitments. The specific part of your business—a service, system, or product—that you are auditing for reassurance, that’s your scope. Regarding this scope, ask yourself the following questions:
Did you make any specific commitments to make your scoped system available/accessible to customers?
Did you agree to ensure the integrity of, say, transactions, your scoped system is making, or any other data stream processes it is involved with?
Is that data that is stored or moving through your scoped system designated as confidential or private, per the stipulations we laid out above?
Answering these, by reviewing your contractual agreements and terms of service, should give you a more complete picture of what trust service categories should be included in your SOC 2 report. Being evaluated against each will provide validation to your customers that you are following through on all your promises to safeguard their data.
However, we should make clear that even though you might have commitments in each of these categories, you are not required to actually add them to your audit scope. That may seem confusing, but it’s true.
What we typically see is organizations opting to only include security (and availability, depending) for their first-year audit. When their customers do request a SOC 2, they don’t usually stipulate specific TSCs, which allows the organization to opt instead just to get their feet wet with the process and minimal categories involved. As time progresses and the other categories become relevant, they add in more criteria as relevant to their needs.
So, to sum it all up—the promises you’ve made to your customers should serve as the sole guidance for the inclusion of different categories, but there is nothing that says you are mandated to answer to every commitment, especially during your first SOC 2 examination.
Next Steps in Your SOC 2 Journey
The good news is, after all that you’re now in a position Plato himself would approve of when it comes to deciding on exactly which of these trust service categories will serve you best. You’ll now need to look inward towards the specifics of your commitments, but even after discerning all that, you may still find you have some questions about the particulars of what SOC 2 will look like for you.
That’s because, even aside from TSCs, there are a lot of other factors that will play into how your audit ultimately goes. It can be tricky to find a good marriage between validating your customers’ trust in you, honoring the commitments you need to honor, and things like budget and resources. If you’re still a little unsure, don’t worry.
Plato would probably agree that more information would help you work out most of these particulars, and if you’re wondering what else to think about, here are some links to get you further along in your SOC 2 decision-making and preparation:
- What is the SOC audit process?
- What is the difference between Type 1 and Type 2 in SOC 2?
- What are the four phases to the SOC assessment?
- How do I prepare for a SOC 2 audit?
With all that knowledge in hand, you’ll then, more than likely, want to speak with a service auditor to get their opinion on your organizational particulars or to understand what kind of audit methodology is best for you.
As one of your many options in this area, we at Schellman are happy to speak with you and answer any questions you may have.
About the AuthorMore Content by Schellman & Company