SOC 2 is the most widely-adopted and requested compliance certification for SaaS vendors in the United States. In this post, we will demystify the SOC 2 audit preparation process by walking you through best practices and sharing world-class wisdom we’ve garnered from working with our clients and audit partners.
Before we get started — if you’re new to SOC 2, we recommend that you have a read through our “Introduction to SOC 2: The Only Guide You’ll EVER Need” to gain a general understanding of the certification and its requirements.
If you already have some familiarity with SOC 2, let’s get to it…
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 attestation 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 gives 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 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.
Regardless of your chosen scope, the SOC 2 process requires commitment, and team members may need to take time away from their daily tasks to focus on preparing for an audit. You should account for a loss in productivity, and ensure you are staffed accordingly. You (and the rest of your team) are in it for the long haul. To quote a diabolical lion singing to a cackle of hyenas: be prepaaaaaaared!
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 their 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 and 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|
Thank you for sticking with us during that brief detour. Now back to our regularly scheduled SOC 2 tour — please keep your hands inside the vehicle at all times.
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.
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, 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.
Your 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.
How do I choose my auditor?
Going through an audit can be a nerve-racking process. When it comes to SOC 2, the one thing you have to remember is that at its core, an audit is an auditor’s informed opinion on how well your organization’s controls meet the relevant TSCs. There are a few things you should consider when selecting an auditor:
- Accreditation: Ensure that your auditor is a licensed CPA. Only a CPA can sign off on a SOC 2 audit.
Find a reputable firm. It doesn’t have to be a brand-name firm like KPMG; one with a good reputation will suffice. If you need guidance in this area, we’re happy to provide some recommendations.
- Experience matters. An auditor with more experience is likely to have a better and more thorough understanding of SOC 2, how to evaluate controls against your organization, and the best practices that apply.
- Fit. Auditors are like snowflakes; no two are alike. It’s important that your auditor understands your business, so they can expertly assess if there are any gaps or deficiencies.
What do auditors look for?
Auditors are guided by the IIA standard Code of Ethics, which tasks auditors with being independent and objective. The documentation you developed as evidence is seen by an auditor as proof that a particular control exists, and helps them evaluate operational effectiveness (whether or not the control is performing as it should).
Using a combination of techniques, an auditor obtains an in-depth understanding of your program and how it fits into the SOC 2 framework. These techniques may include:
- Observation: Observing you perform a task relevant to specific control.
- Inquiry: Interviewing you or your team to learn about a specific process.
- Inspection: Requesting evidence of compliance with a control.
In order to satisfy the auditor’s needs, it’s imperative that documentation is both complete and accurate. The source of the information in the document has to be identified and verified, the content of the document must be written with integrity, and the documentation has to be easily accessible and retrievable for audit purposes. At the end of the day, you want your auditor to come to the same conclusion about the state and health of your information security program as you would. It’s your job to help them come to that conclusion.
At the end of this long journey, once an auditor has reviewed your work and determined that your controls, policies, and procedures meet all requirements, they will give you their stamp of approval. You can now shout from the rooftops (or post on your website) that you are SOC 2 compliant… for now. And then you can start planning for next year’s audit.
Just remember that we’re here to help.