Once you’ve defined controls that meet the SOC 2 criteria, it’s time for your first SOC 2 audit. (See part two of this series if you still need to define your controls.) During your audit, you’ll prove to auditors that your controls operate effectively so that your auditors will issue a SOC 2 report. This is an important step in bootstrapping your customers’ trust in your company.
Typically, your first SOC 2 Type 2 audit will cover a six-month period. This article will explain what happens throughout those six months.
The particular auditor you work with will have a much larger impact on your experience than the firm that employs them. Auditors should have the Certified Information Systems Auditor credential and possibly also be a Certified Information Systems Security Professional.
Once you have a short list, speak with prospective auditors about your architecture, technology stack, and development process. The audit process will be much more efficient if, for example, your auditor already understands your cloud provider and the concept of continuous deployment. You should also ask your auditor about their experience with companies the size of yours, as the controls and evidence a 1,000-person company has may differ greatly from the controls and evidence a 100-person company has.
After you’ve chosen your auditor and had an introductory meeting to give them an overview of your controls, you’ll set the date for the start of your audit period. Before that date, all of your controls need to be operating and in a state that you’ll be able to provide evidence at the end of the audit period that each control was operating at the beginning of the audit period and continuously from that point onward. Your introductory meeting may uncover gaps in your controls or in your plans for providing evidence. That’s OK! It’s perfectly normal to need to delay the beginning of your first audit period to ensure you’re totally prepared.
Once your audit period begins, you’ll go about your normal business and may not speak to your auditor until the last month of your audit period.
You and your auditor will schedule time toward the end of your final month, but still within your audit period, for your actual audit. At small companies, this tends to be one to three days.
A few weeks before their arrival, your auditor will send you their Document Request List (DRL). And a few weeks after the end of your audit period, your auditor will send you their report.
The Document Request List spreadsheet is the agenda for your audit. During your meeting time with your auditor, you’ll need to ensure they talk to every control owner and collect all the other evidence they request.
Auditors provide the Document Request List early so you can practice and prepare but also so you can suggest alternative evidence. Review the Document Request List before your auditors show up to minimize surprises and maximize efficiency while they’re on-site or on a call with you.
Once your auditor is satisfied that your controls meet the relevant criteria, they’ll start to request evidence that your controls are doing what you say they do. You may offer evidence in a different form than your auditor expects, as long as it shows the control is operating effectively to the auditor’s satisfaction.
The tried-and-true method for auditing most any control is population sampling. First, you enumerate every time the controlled process happened during the audit period – underscoring the importance of automatic record-keeping. Auditors choose some number of samples based on the size of the population but usually not more than 25. You must then provide evidence, usually screenshots, that the control operated effectively in each of those sampled cases.
Screenshots may seem an odd choice, but they offer auditors some amount of protection from deception. It’s harder to mislead with terminal output or web pages that auditors can observe being loaded than it is with text files provided asynchronously. (Not that you’re interested in misleading auditors; it’s just nice to understand the method to their madness.)
Even when you’ve taken humans out of the loop by using some technology to enforce a control, you can audit its effectiveness by enumerating every action that technology took and taking samples from that population.
When it’s easy to identify the population and easy to gather evidence for each sample, there’s no reason to avoid doing so. Sometimes, though, one or both of these steps is tedious, and so it’s worth auditing the control differently. The most common alternative is to demo the technology that enforces the control and provide evidence that it has been in effect during the entire audit period.
Auditors will almost always request meetings with control owners to provide evidence with context and clarification as needed. This is the ideal time to demonstrate processes or the operation of some technology, so auditors can see a control operating firsthand.
Technology-enforced controls like mandatory code review can be demonstrated by going through the process live in front of your auditor. It’s likely, especially during your first audit or after adding or changing a control, that the auditor is interested in seeing the code or configuration that enforces the control to ensure that it’s been operating continuously throughout the audit period.
It’s important to document your plan for gathering evidence for each controls and practice doing so ahead of a first audit. You won’t be able to play out the conversation with your auditor any more than you can a job interview or an improv scene, but being familiar with the motions you’ll take to gather evidence will make everything run more smoothly.
If an evidence-gathering process takes a long time, go ahead and run it beforehand. Take screenshots along the way, and be prepared to discuss the process and evidence that resulted with your auditor.
Lots of evidence-gathering is fast, though, and it can be very effective to gather it live with your auditor while you’re discussing your controls. Write yourself a walkthrough (much like you see online for video games), so you know precisely what to do step by step.
Here are some things every control owner should keep in mind as they meet with auditors:
The relentless march of SaaS products into streamlining every facet of business has reached SOC 2 compliance. You absolutely don’t need any of these SaaS products to have a very good compliance program (spreadsheets will be enough) but they are worth a look because they can give you a valuable head start on policies and controls that meet many of the SOC 2 criteria.
We’re not here to make endorsements of any particular tool or even to attempt to enumerate every player in the market. You should know that while many of these tools cost upwards of $10,000 a year, they broker discounted rates with auditors that make the cost difference negligible. They won’t save you (much) money but they can save you considerable time.
Consider the following to decide whether a particular tool is right for you:
In addition to evidence, you’re expected to write a description of the system that’s audited. It’s your opportunity to set the stage, explaining your business, your objectives, and your infrastructure. This description is eventually included in the final SOC 2 report, under Section 3.
This is the customary place to disclose who your subprocessors are and what you rely on them to do. Subprocessors are vendors who handle data on behalf of your customers. Your hosting provider, for example, is a subprocessor. You can reference their SOC 2 reports and specifically call out controls of theirs on which you rely to meet your objectives. For example, anyone using AWS is relying on AWS’ controls to meet physical security, equipment decommissioning, and many other SOC 2 criteria.
You should also call out user-entity controls. Every piece of software has embedded in its design some expectations for how it’s going to be used. These are called user-entity controls and they make assumptions your product makes about your customers explicit.
One outcome of these assumptions or expectations being made explicit is that it gives customers the best chance of choosing the right vendor. Another is to prevent “bad” customers from preventing you from meeting your objectives. User-entity controls get everyone on the same page.
For example, a service that provides document-editing software sets the expectation with customers that content should not contain payment card data or protected health information. The document-editing service provider can’t prevent a customer from entering such information, so it falls to the customer to understand how to use the service appropriately.
A SOC 2 report follows a predictable format. It’s very verbose and formal. There’s lots of boilerplate and even verbatim copying from the Trust Services Criteria.
If you receive your first SOC 2 report, and you don’t like what it says, you do have the option of starting over. This will delay getting a report into your customers’ hands. Note well that you can never do this after you’ve given a SOC 2 report to anyone because they’re going to expect continuous coverage from that day forward. There is no taking a year off from SOC 2 compliance.
Finally! The whole point of this SOC 2 compliance program is to speak to customers, win their trust, and then win their business. Remember? It’s been a long road.
Your SOC 2 report, just like the canned CAIQ questionnaire that may have preceded it, is meant to save you time. So once an NDA is signed, get your SOC 2 report in your customers’ hands. Let them digest it and come back with their hopefully diminished if not altogether eliminated list of questions. When your customers have follow up questions, be sure to answer them as fully as they want. You’re not talking to your auditor anymore, you’re selling your product.
If you’re early in your compliance journey, be sure to start with part one on how to delay SOC 2 compliance without sabotaging your business and part two on reading the criteria, writing controls, and preparing for your first SOC 2 audit. Stay tuned for part four which will look ahead to your second audit and how to evolve your SOC 2 compliance program as you grow.
By the way, there’s no easier way to show auditors granular access to AWS and network segmentation between development and production than Substrate is the right way to use AWS, designed with SOC 2 compliance in mind.