SOC 2 Readiness Assessment has become a buzzword amongst the community of founding teams that are starting companies that sell their services to big businesses. And why shouldn't it be? Most startups with that particular go-to-market strategy will almost certainly need to successfully complete a SOC 2 examination to satisfy enterprise requirements at some point now or in the future. So, "readiness" is a natural first step.
Today we'll zoom in on a particularly misunderstood topic -- one that is even misunderstood by many of the SOC 2 Readiness Assessment providers. If it's misunderstood by some of the companies that are conducting SOC 2 Readiness Assessments, we'll bet it's also misunderstood by the founder-led teams that they serve.
Today's misunderstood topic is the interplay between service organization commitments and contractors. Lets dive in:
Early on in the SOC 2 examination process, the auditor will be doing quite a bit of information gathering. Interviews with the management team. Information requests to the management team. Gathering of information that the company publicly discloses on their website or elsewhere. A good SOC 2 Readiness Assessment will also touch on this same information-gathering effort -- although typically in a lighter way than a full SOC 2 examination.
You get the idea.
Whatever the commitments, a diligent auditor bases much of the remaining SOC 2 examination process on what they discover at this stage. A well-run service organization has security controls (and other controls as well) that are "suitably designed" (to use auditor lingo) for the particular commitments that the company has made.
When founding teams begin their venture together, our observation is that they almost always end up relying on one or more contractors. It could be as simple as a founding team that outsources some product development to an offshore firm. Or a founding team that needs to be able to offer 24x7 customer support but doesn't have enough full-time staff to handle that with FTEs. Or a team that has an impressive new algorithm but needs the help of a DevOps professional to package it for use in a cloud environment.
Although these are just examples, just about every early-stage technology company that we know, has some level of reliance on contractors. And that's fine. As long as you understand the implications for SOC 2.
Here's the rub.
You've got commitments. For example, a commitment that all all client information is stored in a single-tenant environment.
You've got contractors. For example, a DevOps contractor who is responsible for configuring the cloud-based databases where your client information is stored.
And, you've got daily operational norms that may or may not be documented or managed -- such as that contractor using a small set of production data to locally test a database configuration before standing it up in the cloud.
And, therein lies the challenge: when your company relies on contractors for a function that has the ability to cause you to either satisfy or not satisfy a service commitment, that means that your contractor's practices should be "in scope" for SOC 2. And preferably, "in scope" for your SOC 2 Readiness Assessment.
If you haven't begun your SOC 2 Readiness effort (we can help), now is a great time to ensure that you have policies and practices in place that ensure that your contractors are fulfilling the commitments you've made. It's not just a matter of having your employees doing the right thing -- anyone that could get in the way of your ability to fulfill service commitments is very much a part of the SOC 2 examination scope.