Preparing for a SOC 2 audit
If you’ve been through any audit before, you are well aware of how tedious and time-consuming it can be for your team and yourself. If you haven’t, think of spreadsheets. Spreadsheets everywhere!
The People
After you’ve made the decision to pursue a SOC 2 attestation, here’s something to keep in mind when drafting your audit preparation strategy. You may want to create a task force of employees from the IT or security team, with support from team members familiar enough with your technical systems. Having an executive or manager own this process with the team will also be hugely beneficial.
The SOC 2 process requires commitment, and team members may need to take time away from their other tasks to focus on preparing for an audit. You should account for a loss in productivity and ensure you are staffed accordingly.
The Process
The first thing you will want to do is analyze the 43 Common Criteria and determine which points of focus are relevant to your business. The following six steps will guide you in this process, but if this feels like an overwhelming decision, it’s time to phone a friend and ask for help (*cough* TrustCloud).
Step 1: Define Your Audit Objectives
Before you throw yourself and your team into the bottomless pit known as audit preparation, you may want to take a few minutes (or days) to get aligned around why you’re pursuing a SOC 2 certification in the first place. Do you have a regulatory reason to become SOC 2 compliant, and are there specific requirements you are aiming to satisfy? Was this requested by a customer? If so, what information is your customer hoping to learn from the audit, and by what date are they expecting to see a report?
Why is asking questions important?
Accurately defining your audit objectives will help you better determine the scope of your audit and what evidence and documentation you will need to submit to an auditor. For example, if your customer is concerned about data confidentiality, then you may want to consider adding the ‘Confidentiality’ and ‘Privacy’ categories and their corresponding set of criteria to your audit scope.
When should I start preparing for a SOC 2 audit?
Equally important as determining the scope of the audit is having a clear understanding of your audit target date. Generally speaking, since the audit process can be lengthy and can involve work you haven’t yet accounted for, you should get started as early as possible.
Additionally, some SOC 2 tasks may require the purchase of a third-party tool (for example, a tool that helps you with vulnerability scanning or endpoint management) and kicking off the process as soon as you can allow you more time to plan, discover, integrate, and become familiar with using such tools.
What type of audit should I pursue?
You can choose to pursue SOC 2 Type I, or SOC 2 Type II. There are valid reasons to choose either one, and your decision will depend on your specific requirements. A Type I audit is quicker than the more comprehensive Type II, mostly because the Type II process involves a three to six-month observation period, whereas, in Type I, your controls are verified only once. If your customer wants to see something quickly, you may decide to show a Type I attestation while you and your team work towards a Type II report.
Step 2: Determine the Scope of Your Audit
Once you’ve defined your audit objectives, you will need to determine the scope. As you may expect, the bigger the scope, the more time-consuming the process. Unless you’ve got unlimited resources, you will need to tightly manage the scope of your audit.
What do you mean by “scope”?
As part of a SOC 2 audit, you will show how your infrastructure, software, procedures, policies, people, and data adhere to the Trust Service categories (security, availability, confidentiality processing integrity, and privacy) that are part of your scope. Reducing scope — by choosing fewer of these categories — means that fewer of your resources may need to be examined by an auditor. Your scope will be based on your objectives.
When it comes to SOC 2, there isn’t a one-size-fits-all approach, so the good news is that you get to decide what aspects of your business you would like observed and audited as a part of this process. This is why we highly, highly recommend that you define your audit objectives well in advance.
Check out our Audit scope article for a deep dive and guidance on how to define your scope.
Step 3: Conduct a readiness assessment
When first considering a SOC 2 audit, conducting a readiness assessment lets you quickly identify your gaps and better plan how to allocate your resources. There are quite a number of criteria for you to map your business stack to, and it may seem overwhelming, but you don’t have to do it by yourself. Hang tight! We’re going to show you how.
But if you insist on DIYing your way through SOC 2 preparation, promise us that you will not use a spreadsheet.
How do I assess my readiness?
If you’re using a compliance automation tool (such as, say, TrustOps), you start by identifying the relevant controls that need to be adopted. Having the right controls is a vital part of the SOC 2 process, so let’s take a few minutes to outline these in more detail. We think it’ll be worth your time.
The beauty of doing a readiness assessment in a tool is that it can be done at any point in the process, as you will need it to chart your progress. However, the initial one will identify your gaps, so you know what you currently have and what you need to start creating.
SOC 2 controls are grouped into Trust Service Criteria, and these criteria are then further grouped into the broad categories we mentioned above. The set of criteria you adopt will depend on which categories you’ve chosen to include within the scope of your audit, and being familiar with the available Trust Service Criteria can help you decide what’s right for you. We’ve outlined these criteria below.
Criteria common to all five Trust Service categories (also known as “common criteria”):
| Common Criteria | Title | Description | Example of Controls |
| CC1 Series | Control Environment | Covers the service organization’s commitment to integrity and ethical values, evidenced by the employee handbook, code of conduct, board of directors oversight, and the ongoing monitoring of hiring and employee performance standards. | Employee manual, code of conduct, employee confidentiality agreement, board of directors oversight, security awareness training, employee performance reviews |
| CC2 Series | Communication and Information | Support the proper functioning of internal controls by establishing communication channels for information surrounding quality control (lines of authority, boundaries of the system, relevant changes, etc.). | Customer support channel, release notification, escalation procedures |
| CC3 Series | Risk Assessment | Included to demonstrate that the service organization is assessing potential risks that will impact its operations and putting plans in place to mitigate these risks. | Risk management, risk register, inventory management, fraud risks |
| CC4 Series | Monitoring Activities | Covers the ongoing evaluation of monitoring systems at the service organization and notification procedures to alert relevant personnel in the event that a breakdown is detected. | Internal audit assessment review, vulnerabilities scanning, penetration testing, board of directors oversight |
| CC5 Series | Control Activities | Covers the process of identification, analysis, and mitigation of risks. The service organization should implement controls to mitigate the risks identified as part of the risk assessment it undertook. Controls are monitored on an ongoing basis, and risk assessment is performed at least annually. | Risk management, risk register, control owners |
| CC6 Series | Logical and Physical Access Controls | Restrict and manage logical and physical access to protect your information assets and prevent any unauthorized access. | Multi-Factor Authentication (MFA), access review, terminated access, data retention, firewalls, IDS, Bring-Your-Own-Device (BYOD), data prevention tool |
| CC7 Series | System Operations | Manage your system operations to detect, monitor, and mitigate any deviations from set procedures. | Centralized logging and monitoring, incident response plan and testing, security events meeting |
| CC8 Series | Change Management | Design and implement a controlled change management process and prevent unauthorized changes. | Change management workflow, source code repository, automated deployment, production changes notification |
| CC9 Series | Risk Mitigation | Identify, select, and develop risk mitigation activities for risks that deal with business disruptions and the use of any vendor services. | Risk management, risk register, disaster recovery plan, and testing, vendor risk assessment, and due diligence |
Additional specific criteria for the availability, processing integrity, confidentiality, and privacy categories:
| Common Criteria | Title | Description | Example of Controls |
| A series | Availability | The availability principle focuses on the availability of your system. Monitor, evaluate, and maintain your infrastructure, software, and data to ensure you have the processing capacity and system components needed to meet your business objectives. | Capacity planning, backup plan, testing, failover |
| PI Series | Processing Integrity | The processing integrity principle focuses on the quality of delivered data. Any data processing should be timely, accurate, valid, and authorized. | Input and output processing, error report, output reconciliation process |
| C Series | Confidentiality | The confidentiality principle focuses on restricting access to and disclosure of confidential data so that only specific people can view it. Confidential data may include sensitive financial information, business plans, customer data in general, or intellectual property. | Confidentiality agreement, data retention, data disposal |
| P Series | Privacy | The privacy principle focuses on the system’s adherence to the client’s privacy policies and the generally accepted privacy principles (GAPP) from the AICPA. This SOC category considers methods used to collect, use, and retain personal information, as well as the process for disclosure and disposal of data. | Privacy policy, data disposal, access rights |
Once you’ve selected the controls appropriate to your business and goals, the next step is to determine which systems and business processes need to conform to these controls and add them to your compliance program. There isn’t always a clearly-defined way to meet these controls, as the SOC 2 criteria are open to interpretation. It is up to you to achieve the goals set by each criterion by properly implementing the appropriate controls.
For your initial readiness assessment, our recommendation is to use existing systems and processes rather than try to create new ones. This approach will provide you with a baseline on which you can later improve. You might find yourself in need of purchasing security tools and services to improve your security and business processes. Some examples of these include performing pen testing, enrolling in asset management, and conducting background checks. We have a full article dedicated to tools and services to help you in this process.
Finally, you’ll need to validate the mapping between the controls you’ve implemented and the criteria requirements. This helps the auditor understand your approach and frame what you’ve created within the framework offered by SOC 2.
Using a tool such as TrustOps helps you make this process a lot faster. We’ve done the legwork of figuring out how your compliance program maps to various standards, and once we learn about your stack, we can show you where you stand. It looks something like this:
And if you’re not using a compliance automation tool…? Well… once you hit bottom, give us a call.
Step 4: Document Policies and Procedures
Now that you have a good sense of what you want to accomplish, what controls you need to adopt, and where your gaps are, the next step is to start creating the plethora of documentation needed to meet your audit requirements. This documentation usually takes the form of a set of policies and procedures.
While written policies have traditionally been used to train employees on your organization’s expectations, they also act as crucial measuring tools for auditors, who evaluate whether your organization meets its compliance requirements. Without clear documentation, an auditor will have a difficult time ascertaining whether you’re doing what you say you are.
Step 5: Evidence collection
Written policies must be supported by evidence. Anything mentioned in your policy has to be backed by clear, verifiable supporting documentation.
Our team should prepare by gathering all relevant documentation and materials needed to add credibility to your policies and procedures. At the end of the day, passing an audit doesn’t simply require that you tell an auditor what you’re doing — you must show them tangible proof.
For example, if you tell the auditor that you walk every new hire through an onboarding deck, your evidence should include the deck, as well as records of calendar meetings during which the deck was presented. When collecting evidence, it’s helpful to think: how can I prove or demonstrate that I am doing what I’ve said I’m doing?
Once you’ve collected and stored all your evidence and can consistently pass all necessary checks, it’s time to select an auditor.
The Audit
It is recommended to get a SOC 2 Type 1 audit the first time around. Once a type 1 audit is concluded, the organization can go for a Type 2 right away or wait couple months to start the type 2. After the type 2 is completed, an examination audit is not due until a year thereafter.
The outcome of the annual review of your SOC 2 controls and program is a SOC 2 attestation report, not a certification.
