12 Commonly Recommended Security Policies for SOC 2
When it comes to SOC 2, implementing clear policies can improve internal processes, streamline your audits, and build trust with your customers.
Providing your auditor with strong, well-written and well-researched policies can be a major time-saver during your audit—especially for SOC 2 beginners. Many companies opt to use a policy template to guide them as they lay out their processes. Whatever you decide, remember that your policies are intended to support your company, not work against it. So, write them in a way that makes the most sense for your organization while still meeting the expectations.
What is a SOC 2 Policy?
Policies for your security framework (SOC 2, ISO 27001, HIPPA, etc) are reviewed by your auditor to determine your documentation aligns with the requirements within the framework. These policies define the exact systems and processes that need to be in place in order to be compliant with that framework.
If you have policy-related questions specific to your organization, join the Drata Community to talk to our compliance experts, or if you’re a Drata customer, sign up for our next Policy Power Hour.
What Policies Do I Need to Have in Place?
Writing your policies can be overwhelming, even with a template. The main thing to keep in mind is to pay attention to what makes the most sense for your organization. The list below is not exhaustive, but it does include some of the most crucial policies to incorporate.
1. Acceptable Use Policy
This policy dictates how company resources should be used by employees, both in-house and contracted.
2. Asset Management Policy
This policy defines how assets within the organization must be managed and protected.
3. Backup Policy
This policy covers the extent and frequency of backups for your company’s information, software, and systems. Having a strong data classification system makes this much easier and enables you to backup highly critical data more often.
4. Data Protection Policy
This policy includes the requirements for protecting data within the organization, including logging user activity and the procedures for reviewing the logs.
5. Incident Response Policy
This policy outlines the security personnel procedures when a security incident occurs, including detection, containment, evaluation, and reporting.
6. Information Security (IS) Policy
This policy is one of the more important ones when it comes to SOC 2, as it sets the foundation for your security program.
7. Physical Security Policy
This policy outlines the requirements for protecting information and technology resources from physical and environmental threats in order to reduce the risk of loss, theft, damage, or unauthorized access to those resources.
8. Risk Assessment Policy
This policy documents the procedures for performing periodic risk assessments, including how your organization identifies potential threats, analyzes the risks associated with the identified threats, and determines the mitigation strategies for the identified risks.
Don’t confuse this one with a RiskAssessment, which is simply the carrying out of this policy and analyzing risks in terms of how likely they are to occur and the impact they would have on your organization if they materialize.
9. Software Development Life Cycle Policy
This policy describes the process for requesting, testing, and approving changes to organizational systems prior to implementing them into production.
10. System Access Control Policy
This policy includes requirements for all things access, including authenticating, authorizing, modifying, and removing users, and using a role-based access control. Many companies also use the policy to explain how to provide privileged access and treat services accounts.
11. Vendor Management Policy
This policy outlines how vendor risk is managed within your organization.
12. Vulnerability Management Policy
This policy defines how your company detects and manages vulnerabilities.
What Policies Are Included in Drata?
While this article only focused on the 12 policies we think are most important for SOC 2, we also recommend and include the following policies:
Data Classification Policy
Code of Conduct
Disaster Recovery Plan
Encryption Policy
Responsible Disclosure Policy
Business Continuity Policy
Password Policy
Commonly Asked Questions About SOC 2 Policies
After helping thousands of customers achieve SOC 2 compliance, here are some of the most common questions we get around policies.
What Are the Most Common Policy Struggles for Startups?
The number one struggle is time. When you work at a startup, you wear a lot of hats, and finding the time to actually work on policies is hard when you have a full time job to perform. Our templates at Drata provide you with a strong place to start.
Our recommendation is to read through each section of a policy and then ask yourself, “Does this make sense for my organization?” If it does, then ask, “Is this achievable or do I need to adjust this?” and if you have to adjust it, make the change.
If the section isn’t applicable, ask yourself, “Can I explain why this wouldn’t be applicable if someone asks?” and if you can, remove that section.
In SOC 2, if an auditor sees an issue with your policy, they’ll likely just tell you to adjust it without any major issue.
Do We Have to Review Every Policy on an Annual Basis?
Yes, in general you have to review/re-approve every policy on an annual basis to make sure that they are still accurate. The purpose is to demonstrate that you are actively managing the documentation that governs your organization (the policies).
Can You Right-Size SOC 2 Policies Based on Company Size?
We definitely suggest right-sizing your policies. The software development lifecycle (SDLC) policy is a perfect example of this. In an ideal world, where you have an appropriately sized/staffed development team, a separate QA team, etc. the SDLC policy is fine. However, if your development team is only a developer and your CTO, implementing everything in your usual SDLC policy can be difficult.
In that case, it’s best to keep the policy more general. As you grow, you can make them more specific and provide clear instructions to the growing number of people you’re managing and directing.
The main thing you don’t want to do is write that you are doing something in a policy and then not implement it. Whatever you write in your policies is fair game for an auditor to ask about, so keeping it general at smaller organizations helps in that regard.
How Involved Should Our Legal Team Be in Policy Development?
It’s never a bad idea to have your legal team be part of the conversation around policies. It isn’t a requirement, but it’s very common to have a legal team/legal function review your policies prior to putting them into effect. This helps ensure your policies are enforceable. However, if you don’t have a legal team, that’s perfectly okay. No need to hire external counsel solely to review your policies.
SOC 2 policies provide that extra layer of protection for your company and your customers. Implementing clear, strong policies can improve internal processes, streamline your audits, and build trust with your customers.
Book a demo with Drata to see how we can help you achieve SOC 2 compliance.
2023 Compliance Trends Report
Drata surveyed 300 established and enterprise organizations to tap the pulse of the state of risk and compliance. In doing so, we identified related trends, perceptions, and how compliance impacts the business. This year, the primary takeaway is that a mature compliance program will accelerate a business, not slow it down.
