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 is why...
Don't Start with Policies!
There is a common misconception that the fist 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.
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 busy work 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!
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.
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!
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!