When our customers are eager to begin their SOC 2 preparations, they always ask us which policies they should draft first? We don't have them start there, rather we start them with a risk assessment. Here's why.

Don't start with policies!

There is a common misconception that the first step in a SOC 2 journey is to write policies. The pitfall of this guidance is that everyone will have a different opinion about which policies are truly important. Arguably, every organization should have change management, incident management, and logical access policies. And probably a few more. 

Organizations will hear some very creative advice on other policies to start with and how to approach them. Does the business continuity plan need to include disaster recovery, or are these separate documents? What about patching — can the policy and procedures and SLAs be combined into one document? Is a code of conduct the same thing as an employee handbook? Are both of these documents necessary? We call this buckshot approach to preparing for a SOC 2 audit security theater, and we wrote a blog about it.

What is a SOC 2 compliance checklist?

A SOC 2 compliance checklist, is in theory, a nifty idea. It can be used to guide busy staff through the compliance process. A checklist may look something like this: 

• Draft the following 7 policies ...
• Configure this list of 11 Cloud Provider monitoring settings ...
• Enable GitLab with the following automated ‘gates’ at control points ...
• Set up logging on these 5 tools ...
• And on and on.

The danger of compliance checklists

The danger of a policy-first approach is that it reduces compliance activities to a checklist. Organizations following a checklist approach inevitably end up doing too much busywork by creating useless policies, applying meaningless controls, or even overlooking entire processes that are key to the functionality of their product. The checklist approach to compliance also assumes that your organization is the exact same size and maturity as everyone else. We know this is not the case!

Security frameworks can be used as a guide, but should not be used as a checklist. Only you know the landscape and maturity of your security function and its underlying processes. One size does not fit all!

SOC 2 requirements

A SOC 2 is not a certification, it is an attestation. This means that management picks which criteria — like the SOC 2 Trust Service Criteria — are in scope and then shows how the criteria are met with their own, unique controls. In plain English, if you want to demonstrate how your organization demonstrates the Availability Criteria, you will need to identify the controls you have in place. A checklist is not going to help as only you know how you demonstrate how your organization meets this criteria. The controls that you choose are at your discretion.

Risk-based approach: know why a control is in place

With the checklist approach, you set up a compliance task only to check a box. The end result is that when an auditor asks your HR lead about the process around requiring background checks, you don't want him to say, “I don’t know why we do it - I just know it is a SOC 2 control.” 

Instead, you want your HR lead to say, “We do it because we handle very sensitive data and we want our customers to know we take the confidentiality of their end-user data very seriously. If we find a red flag in a background check, we take that into consideration in our hiring decision. In such an instance the CEO will need to ‘sign off’ if we want to proceed with the hire.” In the second scenario, not only does the HR lead know what is done with background check results, but also knows WHY the process exists. This is a risk-based approach.

There is no such thing as a “SOC 2 control”

What? Blasphemy! There are no SOC 2 controls? That is right. Your controls exist regardless of the framework you choose to follow. Each control, alone or as part of a well-defined process, should address risks specific to your organization. Define your risks and you will know the most efficient and effective way to address them. 

Using the example above, your HR Lead performs the background check as part of a process that addresses a risk specific to your organization. Not because it is a SOC Control. The risk might be: Sensitive customer data may inappropriately accessed, removed from the system by unscrupulous employees. Not handling sensitive information? Maybe reference checks are more cost-effective and meaningful.  

Adaptive, risk-based approach for the WIN 

At Strike Graph, we advocate for a thoughtful, risk-based approach to compliance. You can check out our blog about performing a simple, yet effective risk assessment. We right-size compliance efforts by guiding our customers through a simple and effective Risk Assessment process. Customers can also add their own, unique risks into our solution. Risks are then addressed with audit-proven suggested controls, or with user-defined controls, resulting in a security landscape uniquely your own.

Thoughtfully honing in on your risks will ensure that you are efficiently tackling only what is important to your organization, not what is important to your neighbors’. In a SOC 2 audit, for example, your task is to show how your unique control environment meets the SOC 2 criteria — not how other organizations do. Don't fall into the checklist trap!