Preparing for a SOC 2 audit

Estimated reading: 11 minutes 1559 views

Preparing for a SOC 2 audit – If you’ve been through an audit before, you are well aware of how tedious and time-consuming it can be for your team and yourself. If you haven’t, just imagine doing all the work with spreadsheets.

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. Create a task force of employees from the IT or security team, with support from team members familiar enough with your technical systems. Assigning an executive or manager to this process is 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

Analyze the 43 Common Criteria and determine which points of focus are relevant to your business. The following six steps guide you through this process, but if this feels like an overwhelming decision, contact the TrustCloud team.

Step 1: Define Your Audit Objectives

Before preparing for an audit, you need to get aligned around the following questions:

  1. Why are you pursuing a SOC 2 certification?
  2. Do you have a regulatory reason to become SOC 2 compliant, and are there specific requirements you are aiming to satisfy? 
  3. 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 helps 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, 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?

It is important to have a clear understanding of your audit target date. As the audit process can be lengthy and 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 will give 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 depends on your specific requirements. A Type I audit is quicker than the more comprehensive Type II audit, 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 can decide to show a Type I attestation while working towards a Type II report.

Step 2: Determine the Scope of Your Audit

After defining your audit objectives, you need to determine the scope. As you may expect, the bigger the scope, the more time-consuming the process. 

What do you mean by “scope”?

As part of a SOC 2 audit, you need to show how your infrastructure, software, procedures, policies, people, and data adhere to the Trust Service categories (security, availability, confidentiality, integrity, and privacy) that are part of your scope. Reducing scope by choosing fewer of these categories means fewer resources are examined by an auditor. So your scope is based on your objectives.

When it comes to SOC 2, there isn’t a one-size-fits-all approach, so you get to decide what aspects of your business are to be observed and audited as a part of this process. This is why TrustCloud highly recommends that you define your audit objectives well in advance.

Check out the article Audit Scope to learn more about how to define your scope.

Step 3: Conduct a readiness assessment

For the SOC 2 audit, conduct a readiness assessment to identify your gaps and better plan on allocating your resources. There are quite a number of criteria for you to map your business stack to, and it may seem overwhelming, but it can be automated. Contact TrusCloud for more information.

How do I assess my readiness?

If you’re using a compliance automation tool (such as, say, TrustOps), you can 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 take a few minutes to outline these in more detail. 

A benefit of doing a readiness assessment with a tool is that it can be done at any point in the process, as you will need it to chart your progress. The initial part identifies gaps, so you know what you currently have and what you need to create.

SOC 2 controls are grouped into Trust Service Criteria, and these criteria are then further grouped into the broad categories as mentioned above. The set of criteria you adopt depends on which categories you’ve chosen to include within the scope of your audit, and being familiar with the available Trust Service Criteria helps you decide what’s right for you. The outlined criteria are 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, as 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 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, and 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. 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, 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 provides 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 need to validate the mapping between the controls you’ve implemented and the criteria requirements. This helps the auditor understand your approach and your frame of reference within the framework offered by SOC 2.

Using a tool such as TrustOps helps you make this process a lot faster. Figure out how your compliance program maps to various standards. TrustCloud can show you where you stand after understanding your stack. It shows the Readiness Overview as shown in the following screenshot:

SOC2 readiness overview

And if you’re not using a compliance automation tool, contact the TrustCloud support team for further assistance.

Step 4: Document Policies and Procedures

Once 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 a plethora of documentation to meet your audit requirements. This documentation takes the form of a set of policies and procedures.

Organizational policies also act as crucial measuring tools for auditors to evaluate whether your organization meets its compliance requirements. Without clear documentation, it becomes difficult for an auditor to confirm whether you’re doing what you say you’re doing.

Step 5: Evidence collection

Anything mentioned in your policy is backed by clear, verifiable supporting documentation called evidence. And all written policies are supported by evidence. 

By gathering all relevant documentation and materials, you add credibility to your policies and procedures. Passing an audit doesn’t simply require you to 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, you can now 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 audit right away or wait a couple months to start the Type 2. After Type 2 is completed, an examination audit is not due until a year later.

The outcome of the annual review of your SOC 2 controls and program is a SOC 2 attestation report, not a certification.

Join the conversation

You might also be interested in

Defining roles and responsibilities effectively

In today’s dynamic business landscape, clearly defined roles and responsibilities are the cornerstones of...

Corrective Control – Building a resilient security posture

By implementing these three types of controls in a balanced manner, organizations can not...

Who is a third-party vendor, a subprocessor and a third-party supplier?

These three terms are often used interchangeably, but, are so very different. Highlighting the...

Define your SOC 2 audit scope

Define your SOC 2 Audit Scope - The scope sets the boundaries of the...

The role of Board of Directors in SOC 2 compliance: necessity or strategic advantage?

The SOC 2 COSO Principle 2 addresses the roles and expectations of the BoD...

Use TrustCloud to accelerate NIST 800-171 readiness and self-attest

Use TrustCloud to accelerate NIST 800-171 readiness and self-attest as it comes with built-in...

SOC 2 Program Checklist

Checklist for a successful SOC 2 Type 2 Preparation...

Are the terms of service the same as the master service agreement?

Master Service Agreement (MSA) and Terms of Service (ToS) are two distinct legal documents...