PartnerStack was recently audited as SOC 2 type 2 compliant across all five trust services criteria: security, availability, processing integrity, confidentiality, and privacy.
Depending on what you know about SOC reports already, your reaction to that statement could range from “that’s incredible!” to “I have no idea what you’re talking about.” If you already know a lot about SOC 2, you can skip a bit ahead.
However, if you’d like to learn more about what SOC 2 means — and why you should care about it if you’re in the B2B space — then I’m here to walk you through it. As head of Security and Compliance at PartnerStack, I led us through our recent SOC 2 auditing process, built on my experience in auditing and compliance at companies like FreshBooks, EY, and KPMG. That’s why I know how important SOC 2 really is to B2B software companies.
In this article, I’ll cover:
- What a SOC report is
- Why SOC 2 compliance matters, especially in B2B
- Why PartnerStack aimed for the best SOC 2 result possible
What is a SOC report?
Short for "system and organizational controls", a SOC report provides an independent assessment of an organization’s ability to provide systems that process data accurately and securely.
Designed by the American Institute of Certified Public Accountants (AICPA), a SOC audit can only be performed by a licensed certified public accountant (or CPA). There are two different types of SOC reports, but it started as just one. The first, now referred to as SOC 1, is all about assessing a service organization’s internal control over financial reporting relevant to user entities (aka their customers).
The second type of SOC report — and the one I’ll focus on in this article — is SOC 2, which measures an organization’s controls relevant to security, availability, processing integrity, confidentiality, and privacy. This report type was created specifically to serve the needs of cloud businesses that frequently work with customer and user data.
(Okay, there is technically a report called SOC 3, but it’s just a less detailed version of a SOC 2 report meant for public distribution. Everything I say below applies to it as well. Moving on!)
Related: The definitive guide to easy partner payouts.
Why does SOC 2 compliance matter?
If you work in B2B, SOC 2 compliance matters for both your own products and the products you purchase or integrate with.
Modern digital businesses are made up of many interconnected products and services. Just think of how many places your prospect and customer data passes through, like your product, your CRM, your marketing automation tools, your partner management platform, and anything that serves as an intermediary between them (e.g. tools like Zapier or Workato). Beyond customer information, proprietary information about your business is stored in and passed between all of those tools as well.
A single weak link within these interconnected systems can expose data and hurt product availability. That’s why whether you’re selling products to businesses, or purchasing products for your business, you should look into whether those products are SOC 2 compliant. The more mature a business is, the more likely they are to ask about your SOC 2 compliance as part of their purchasing process.
The 5 trust services criteria of SOC 2
To understand exactly what a SOC 2 report proves about a business, we’ll be looking at the five trust services criteria I mentioned above — security, availability, processing integrity, confidentiality, and privacy — as the AICPA defines them. And since those definitions can be pretty dense, I’ll also provide a bit of context on what each of the criteria really means to a business.
Security
What the AICPA says
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.
What it means
The AICPA’s definition of security covers two different but equally important areas:
- Preventing unauthorized access to data. When you submit data yourself or collect it on behalf of your own users or customers, that data is transmitted and stored securely so that it can’t be accessed by anyone without your permission.
- Protection against system failure. Whether due to glitches or bad actors, the system should be resilient against events that could affect the service’s accuracy, availability or usefulness.
Availability
What the AICPA says
Information and systems are available for operation and use to meet the entity’s objectives. Availability refers to the accessibility of information used by the entity’s systems as well as the products or services provided to its customers.
What it means
Meeting the AICPA’s standard of availability means being able to monitor a system’s availability to users and provide timely maintenance that minimizes system downtime. There’s no standard specified for what constitutes adequate availability, just that the organization has taken meaningful measures to ensure availability.
Processing integrity
What the AICPA says
Processing integrity refers to the completeness, validity, accuracy, timeliness, and authorization of system processing. Processing integrity addresses whether systems achieve the aim or purpose for which they exist and whether they perform their intended functions in an unimpaired manner, free from error, delay, omission, and unauthorized or inadvertent manipulation.
What it means
The criteria for processing integrity compliance is all about whether the user can trust what the system (or product) does and the data it presents. Actions the user takes within the system must produce the expected outcome, and any data within the system must be accurate.
Confidentiality
What the AICPA says
Confidentiality addresses the entity’s ability to protect information designated as confidential from its collection or creation through its final disposition and removal from the entity’s control in accordance with management’s objectives. Information is confidential if the custodian (for example, an entity that holds or stores information) of the information is required to limit its access, use, and retention and restrict its disclosure to defined parties (including those who may otherwise have authorized access within its system boundaries).
What it means
Information that’s meant to stay secret stays secret. That doesn’t mean no data is ever shared; just that if it is, it’s done so with permission and only with authorized parties. It’s worth noting that information isn’t necessarily confidential by default, so you have to define which types of information are meant to stay confidential.
See more: Best ways to use a learning management system (LMS).
Privacy
What the AICPA says
Personal information is collected, used, retained, disclosed, and disposed of to meet the entity’s objectives. Although confidentiality applies to various types of sensitive information, privacy applies only to personal information.
What it means
What the AICPA definition of privacy means by personal information is information that is provided and associated with an individual user. There are several sub-criteria for meeting the SOC 2 standard for privacy, including (but not limited to):
- Choice and consent: Users are made aware of their options regarding how their data is used and have control over what happens to it
- Access: Users have the ability to review and update their own personal information
- Disclosure and notification: Personal information is shared only with consent; breaches and incidents are reported to users and the appropriate authorities
- Monitoring and enforcement: The organization has processes in place to respond to privacy-related questions and disputes
Do you need to fulfill all 5 criteria?
Nope! A SOC 2 report can state that you’re compliant in any number of the five trust services criteria. The only area where compliance is mandatory to complete a SOC 2 is the security trust services criteria.
It’s actually pretty rare for companies to fulfill all five criteria in their SOC 2 reports — some big name companies like GitHub, Amazon Web Services, Slack, Stripe, and more aren’t compliant across all five trust services criteria. Depending on the type of data they work with, it often isn’t necessary.
SOC 2 type 1 vs. type 2: what’s the difference?
Yes, there are multiple types of SOC reports, and each of those have their own sub-types. Simple, right?
When performing an audit for SOC 2 compliance, there are two types of SOC 2 reports you can do:
- Type 1 assesses the objectives of the system as described by an organization’s management, and whether the system as designed can achieve them
- Type 2 does the same, but also measures how effective the system is at achieving those objectives across a specified period of time
That means while a SOC 2 type 1 report says that the system is designed to be trustworthy and secure, only a SOC 2 type 2 report proves that that’s already happening.
Which is why a type 2 report means so much more.
PartnerStack’s result: SOC 2 compliance in all 5 trust services criteria
As I said at the start of this article, PartnerStack’s recent SOC 2 type 2 report confirmed that PartnerStack is compliant with all five trust services criteria of SOC 2.
I also mentioned that most SOC 2 criteria aren’t mandatory, and some of the most recognizable companies don’t fulfill them all. So why did PartnerStack aim to fulfill all five trust services criteria?
- We handle data from multiple different parties, including companies managing their partner programs, and the partners who participate in those programs. We want all types of users to have complete trust in the PartnerStack platform.
- PartnerStack often sits between and talks to other tools in a company’s tech stack, like their marketing automation tools, CRM, and sometimes even with their product through custom integrations. Any data that passes through our system needs to be secure.
- PartnerStack is the only partner management platform that handles paying out partners. As we’re dealing with financial transactions and payment information, the security and privacy of this information is paramount.
The final reason is… because we could. After digging deep into how our product works, and based on my experience performing SOC 2 audits in the past, I genuinely believed we could trailblaze in this area and set a new standard for how partnerships platforms handle and secure data.
I’m happy to say we succeeded.
