SOC 2 Bootcamp Part 2: Policies and Controls

SOC 2 Bootcamp Part 2: Policies and Controls

Categories: SOC 2 Tags:

Welcome to part two of SOC 2 Bootcamp coving policies and controls! Quick refresherwe borrowed Bluth Company and Associates from Arrested Development. Monica works for Bluth Company and is in charge of getting their SaaS product, Banana Stand, SOC 2 compliant. 

In SOC 2 Bootcamp Part 1: Scoping and Auditor Selection, the Bluth Company kicked off its SOC 2 journey. Monica has internal buy-in, selected an auditor, defined Trust Service Categories, completed scoping and wrote their Service Organization’s Description of Controls.

This second webinar focuses on the meat of SOC 2, the policies and controls. We dive into a handful of policies required for SOC 2, what’s involved and the necessary controls to stay compliant. 

Guided by Jitendra Juthani, InfoSec risk and compliance expert at Tugboat Logic, Monica and the Bluth Company examine policies and controls and the risk assessment required for SOC 2. In addition, Jitendra discusses how to analyze a vendor’s SOC 2 report and what to do if they aren’t SOC 2 compliant. 

SOC 2 Definitions

What is a policy? From a very high level, a policy governs certain aspects of your organization and your processes. It defines roles and responsibilities and what you’ve committed to as an organization. 

What is a control? While policies show what you do, a control is how you do it, similar to a procedure or a to-do list. It’s how you implement and enforce a policy.

What is evidence? Evidence is proving that your policies and controls are in place and functional. It’s like an artifact. But, it supports the control activity your defined, demonstrating to an auditor that you’ve implemented your controls.

How Is It All Connected?

Policies, controls and evidence are all connected, but it’s not as simple as one policy to one control to one piece of evidence. Instead, it can be one to many, like a spider web. 

Let’s use an example. You have a policy stating that sensitive data requires restricted access. How you do that is by implementing a control that limits access to authorized people only. But this policy can have multiple controls linked. For example, your policy around information security includes controls for how you grant access and revoke access. Those same controls can relate to your password policies. 

An auditor will ask for the policy and controls, and then they’ll look at the evidence you provide. The evidence demonstrates the effectiveness of your policy. It’s tempting to jump ahead but collecting evidence instead of building policies and controls doesn’t work. If you only supply evidence, auditors have nothing to compare against, which doesn’t show if your program actually works. 

The Ultimate Survival Guide to SOC 2 Compliance

Feeling iffy about SOC 2? Download The Ultimate Survival Guide to SOC 2 Compliance and get the help you need to ace your next audit.

Download eBook


The Bluth Company is using Tugboat Logic’s platform to get their SOC 2, but out in the real world, companies can use a multitude of software or good ol’ spreadsheets to get the job done. The requirements are the same, regardless of using technology to streamline the process. 

Every policy has a purpose and it needs to be defined. Next, you tackle the scope and what the policy will cover at a high level. Finally, you include your policy statements. 

For our example, let’s explore the Information Security Policy. The purpose is to manage the effectiveness of your overall information security within the organization. 

The scope and policy statements answer questions like:

  • How are you going to develop and implement this program? 
  • How do you continuously improve this program? 
  • What are the roles and responsibilities?
  • How will it be monitored?
  • How will it be communicated and distributed to your organization and how often?

You can have binders and binders of documented policies, but they have no value if you’re not communicating them to your organization. Some policies may only be relevant to specific departments, while others must be read and acknowledged company-wide. 

For example, generic policies, like your HR policy, acceptable use policy, information security policy, and email usage policy, apply to everyone within the organization. The Bluth Company uses Tugboat Logic’s platform, and it distributes policies to your users and shows who’s read and acknowledged them. If you’re not using software, spreadsheets and emails are sent and maintained by whoever was named in your roles and responsibilities. 

When you look at other frameworks like ISO 27001 and NIST, there’s a significant overlap in policies and controls. This can be a lot to manage when it comes to business continuity and disaster recovery because everything needs to be compatible. So down the road, if you want to become PCI compliant on top of your SOC 2, you’ll need to track changes and make sure policies are consistent and aligned with one another. 

Maybe a framework has updated its requirements or your company has grown. You’ll need to update your policies. Auditors want to see those changes and the evolution of your program. You need to show auditors when the policy was developed, when updates occurred, how often it’s reviewed, any significant changes made within the organization and who reviewed it. Then, you can align your changes and the review process in such a way so that you’re not sending one policy at a time to your employee to review. 

For example, let’s say you’re remodeling your termination policy. You make your changes, management signs off and you distribute it to your employees. Auditors want to see all those steps, including employee acknowledgment. If employees haven’t reviewed and acknowledged your update to the termination policy, and something goes wrong, they’re not at fault. However, you are and auditors will see those gaps. 

Control Design and Implementation

Now it’s time to tackle all the controls you want to implement based on your policies and the scoping the Bluth Company completed in the first webinar. First, let’s explore the business continuity policy. It ensures your business can still run in the face of a potentially disruptive event, like the loss of critical employees.

One of the controls around the business continuity policy is that you have a plan in place. This control includes testing the plan annually and how you test it. For example, is it a desktop review or do you complete a scenario-based exercise? You’ll also need to share the results. This one takes time to implement.

Let’s take a look at a control that’s easier to implement: segregation of duties in changes. Your company has different environments, like development, test and production, and access should be granted based on roles. For example, allowing a developer access to the production environment creates risk and this control mitigates that risk.

Risk Assessment

As a service provider, you need to look at what could go wrong. That’s what the risk assessment does. It identifies risks to your business. And not just cyber threats, but also acts of terrorism, natural disasters and basic employee turnover. 

As part of this process, the management team identifies different risks relevant to your business. Then, they assess the impact and likelihood of those risks and how to treat them. For example, to mitigate cybersecurity risks, companies purchase cyber insurance. They transferred the risk.

Some risks are mitigated. Mitigating controls don’t eliminate the risk because that’s not possible. But the impact on the business, whether it be financial or reputational, is minimized. 

Risk assessments need regular updates because your environment isn’t static. The world around you changes, your business grows, new technology is developed and there are always unknown risks.



Vendor Compliance Review

You’re a service provider and use Amazon Web Services (AWS) as a vendor. You use the cloud to store and post system data. This means your client’s information is there too, and they want to be sure that AWS has the right processes, security controls and confidentiality processes in place. So you need to evaluate your vendor’s compliance process annually. 

You need to go through various checklist items for vendor compliance questionnaires to review their policies. But you can’t go to AWS with 300 questions. So instead, you request their SOC 2 report and review it. Look at their scope and check if it’s a qualified or unqualified report from their auditor.

You’ll need to supply your auditor with information like when you received the vendor’s SOC 2 report, the period their report covers, their Trust Service Categories, and which ones are relevant for the services that you’re using from them.

But what if your vendor doesn’t have a SOC 2 attestation? How do you evaluate them for your own SOC 2? First, ask if they have other certifications like ISO 27001. You want to see that they have processes in place that an independent auditor has reviewed and certified. If they don’t have anything to show you, send them a questionnaire. 

Example questions to ask vendors without certification include:

  • How do you manage security? 
  • How do you manage encryption? 
  • Where do you store data? 
  • How do you manage the accesses? 
  • Do you have a business continuity plan if something goes wrong?

Request that the vendor responds and provides some evidence. For example, if they state that they have an information security policy, have them provide a copy as evidence.

To learn more, watch the entire SOC 2 Bootcamp Recap Part 2: Policies and Controls, or schedule a walkthrough with Tugboat Logic!

Everything SOC 2, All the Time

SOC 2 got you stumped? Check out our library of SOC 2 resources.

Learn More