Understanding and Preparing for a SOC 2 Audit

Written by Brenna Lee on June 4, 2021

Share This Article

Compliance is not something to take lightly or push to the side, especially in an organization that leans heavily on technology in service of the business. Every day, new software-based companies pop up, and competition can be fierce — the last thing you want to be known for in this competitive landscape is being non-compliant. Failing compliance audits tells current and potential customers that your organization is non-secure and untrustworthy which can result in a huge loss of public confidence, customer adoption, and overall profitability.

Familiarity with different compliance standards such as SOC, PCI, GDPR, and HIPAA is important in terms of retaining a positive, trusted brand image, as well as for staying in line with current security and privacy standards and practices. This is where understanding and preparing for a System and Organizational Controls (SOC) audit comes in handy. If your service organization is involved in the storage and use of personal information, which these days is just about every organization, then creating a SOC 2 roadmap will be an integral part of your company’s future. 

Without this roadmap, you’re leaving your company vulnerable to non-compliance with SOC 2, resulting in a less secure system, more openings for data breaches, and loss of trust in your brand and products. To avoid this, it’s paramount that you recognize what SOC 2 is and its importance in relation to the longevity and security of your company.

The main driver of a SOC 2 audit is through customer requests. There may also be a regulator that requests the report, but SOC 2 has picked up a lot of traction in the market and is well-known in the realm of people that are looking to work with organizations that ultimately process confidential data in some way. If your customers haven’t asked for a SOC 2 report yet, they will soon, especially if you’re using technology to deliver your product or service.

What is SOC 2?

There are a few different types of SOC audits — SOC 1, SOC 2, and SOC 3. A SOC 1 audit is focused on internal controls related to financial reporting. A SOC 2 audit is designed to address a service organization’s controls that are involved in its operations and compliance. As for a SOC 3 audit — the SOC 2 and SOC 3 frameworks cover the same subject matter, and they are based on five Trust Service Categories. However, a SOC 2 report is a restricted-use report, meaning it is intended for use by the service organization’s management, customers, prospective customers, and business partners, while a SOC 3 report can be distributed to the public for anyone to reference.

A SOC 2 report is the most detailed report, and it’s used across organizations that use technology to provide their product or service — it doesn’t have to be relevant to just financial reporting like a SOC 1. There are two subcategories — SOC 2 Type I and SOC 2 Type II. A SOC 2 Type I report assesses the design of security processes at a specific point in time, whereas, a SOC 2 Type II assesses the effectiveness of those controls over a period of time.

During a SOC 2 audit, your organization is not assessed against any standards other than the ones that have been laid out by management. There are no external standards that need to be met — your full focus can remain on your organization’s internal controls and infrastructure. Essentially, you are able to set the standard that your customers need and demand and ensure that you are meeting those standards as audited by a third party.

Key Attributes of the SOC 2 Audit

SOC 2 was developed by the AICPA and is centered around the five Trust Service Categories that are all based on underlying criteria. The relevant criteria to be assessed on will depend on the Trust Service Categories selected by management / the organization, and various control owners throughout the organization will have different responsibilities based on the organization’s needs.

The entire scope is defined by management and some key attributes that are included in the scope of a SOC 2 report are infrastructure, software, data, procedures, and people. A SOC 2 report generally covers a 6-12 month period and is typically performed annually. Some companies opt for a SOC 2 Type I audit when it’s their first time, because it focuses on an opinion at a single point in time over the design of controls only, which in turn helps define and improve future controls and processes. Otherwise, it’s very common for organizations to undergo a SOC 2 Type II audit.

Trust Service Categories and Their Applicability

There are five Trust Service Categories that can be included in the scope of a SOC 2 audit. The categories are: security (also referred to as common criteria), availability, confidentiality, processing integrity, and privacy. Security is a required category, but management can also choose any or none of the other categories to be included in the report. If contracts with customers don’t specify the categories that will be included in a SOC 2 report, then the decision rests solely on management’s shoulders and will be based on the organization’s specific commitments to customers and system requirements.

The five Trust Service Category definitions as developed by the AICPA are as follows:

Security (Required)

Definition: 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 your organization’s ability to meet its objectives.

Applicability: Applicable to most outsourced environments when users of the system require assurance regarding the provider’s security controls for any system.

Availability (Optional)

Definition: Information and systems are available for operation and use to meet your organization’s objectives.

Applicability: Most applicable when there are commitments regarding processes to achieve system availability in SLAs (service-level agreements) as well as disaster recovery.

Confidentiality (Optional)

Definition: Information designated as confidential is protected to meet your organization’s objectives.

Applicability: Most applicable when there are commitments regarding your organization’s practices for protecting sensitive information.

Processing Integrity (Optional – Uncommon)

Definition: System processing is complete, valid, accurate, timely, and authorized to meet your organization’s objectives.

Applicability: Most applicable for a variety of nonfinancial and financial scenarios when there are commitments as to the completeness, accuracy, timeliness, and authorization of information and transactions.

Privacy (Optional – Uncommon)

Definition: Personal information is collected, used, retained, disclosed, and disposed of to meet your organization’s objectives.

Applicability: Most applicable where the provider interacts directly with end users and gathers personal information. It provides a mechanism for demonstrating the effectiveness of controls for a privacy program.

SOC 2 Audit Planning and Your Bottom Line

Compliance isn’t something to take lightly, especially in a world where organizations are leveraging technology more than ever to deliver their products and services. Customers take security seriously, and they want to make sure that your organization does too. Protect your bottom line by doing your due diligence regarding SOC 2 compliance and proving to prospects, leads, and current customers that you’re the best, most secure choice for their software needs.

Check out our recent SOC 2 compliance webinar for a more in-depth look at differences between the Trust Service Categories and the criteria associated with each.

Brenna Lee

Brenna is a Content Writer at JumpCloud that loves learning about and immersing herself in new technologies. Outside of the [remote] office, she loves traveling and exploring the outdoors!

Continue Learning with our Newsletter