5 Lessons Learned from Getting SOC 2 Type II Certified as a Startup
SOC2 doesn't have to be painful. Here's your complete guide to getting SOC2 Type II certified as a startup.
July 31, 2024
Engineering and product teams use OneSchema to easily build out best-in-class data import capabilities for their customers. Instead of spending months writing data validations and handing CSV parsing edge cases, focus your development resources on your core product development. With minimal engineering investment, improve your customer activation rates and launch better onboarding than your competitors.
From the earliest days of our business, we heard loud and clear from customers that the lack of SOC 2 Type II certification would block them from doing business with us. And with good reason: as a data processor, we handle our customer’s customer’s sensitive business data and PII. Demonstrating robust security practices would be critical in building trust with our service.
We’re about to complete our second SOC 2 Type II audit. We wanted to share our learnings and best practices around achieving a strong security posture while maintaining product development velocity as an early-stage startup.
SOC 2 is an auditing standard maintained by the American Institute of Certified Public Accountants (AICPA) to test an organization’s internal controls for security and privacy. It’s an objective, third-party system that signals to your customers that they can trust your platform to handle their information in a secure way.
SOC 2 defines criteria for managing customer data based on five “trust service principles” — security, availability, processing integrity, confidentiality, and privacy.
In practice, managing customer data can range from ensuring that you have proper internal communication for system updates to checking that you have a recent test of your incident response plan. Multiple departments likely will be involved in your SOC 2 audit. Typical stakeholders at a startup will include individuals who handle functions in engineering, IT, product, HR, legal, and compliance.
There are two types of SOC 2 — Type I and Type II.
SOC 2 Type I reports cover your company’s systems and controls — and whether the auditor believes you appropriately designed your controls to address all Trust Service Principles. The assessment for Type 1 reports is conducted at a single point in time.
SOC 2 Type II reports include coverage of your company’s systems and controls. They also track the design and operational effectiveness of those systems and controls over a period of time (between a 3 to 12 month period).
A Type II report provides a higher level of rigor, given that it tests the compliance program and the control execution over a long period of time. This is nearly always the required compliance certification if you’re looking to work with enterprise customers in the United States. We have also found that many of our SMB customers expect SOC 2 Type 2 as well.
SOC 2 reports are issued by external auditors and evaluate the extent to which a vendor complies with various security controls. The certification is based on this SOC 2 report, which assesses systems and processes that exist at the company.
When we were in YC, we got conflicting advice about if we should invest in SOC 2 from the beginning. If your business doesn’t handle sensitive customer business data, you may run into fewer concerns around data security, and SOC 2 may be a lower priority for you. However, it was a critical business decision for us that removed a core friction point in our deal cycles. Here are three factors that made SOC 2 Type II valuable for us:
A SOC 2 Type II certification gives your customers confidence that your organization complies with all modern security standards, such as frequent penetration tests, data encryption in flight and at rest, modern encryption protocols, disaster recovery procedures that are tested frequently, role-based access control, 2-factor authentication, etc. Instead of having to send over a detailed questionnaire to confirm specific practices their security team cares about, your customer can trust that a 3rd-party auditor has already tested these controls.
Given that it’s conducted over a window of time (3 to 12 months), a SOC 2 Type II report gives your customer more confidence than your responses to a security questionnaire would. A questionnaire is unable to verify that you’ve been compliant over time.
Maintaining a SOC 2 Type II certification also requires companies to audit the security practices of their vendors — and most companies with a SOC 2 certification require all of their vendors to be SOC 2 Type II compliant as well. So, even if you have a fantastic security posture, without the confirmation of a SOC 2 audit, many customers' policies won’t allow them to move forward with you as a vendor. In some cases, it may even be a contractual obligation with their customers to only leverage vendors who have a SOC 2 Type II certification.
SOC 2 doesn’t actually have to be as time consuming as you might think, especially if you designed your systems from the ground up with an eye toward modern security practices.
The bulk of SOC 2 resources we found while going through the process were targeted toward larger, more traditional companies. As a smaller company, you’ll likely have a smaller codebase, fewer employees, and less complex business processes. All of these things will reduce the load on getting your first SOC 2 certification, though you’ll likely need to implement a few new processes around compliance.
The earlier you invest in compliance, the easier it is to scale and maintain compliance.
Here are two examples of how investing in compliance early can help save you significant effort in the long term:
Example 1: creating technical debt.
If you design your infrastructure without considering the implications for SOC 2, you may need to undo choices you made and create significant technical debt. We’re currently leveraging DuploCloud on AWS to configure our settings in a SOC 2 compliant way and manage multi-region hosting. If we hadn’t been aware of the infrastructure considerations around SOC 2, we would’ve had to re-architect our system to handle multi-tenancy with data isolation and retention. Instead, we had the right architecture in place from the get-go.
Example 2: more employees = more compliance tasks to be completed.
A very common reason SOC 2 certifications get delayed is difficulty staying on top of your employees to complete all required compliance tasks. You can integrate many of these tasks into your onboarding processes if you have robust security policies in place early. Retroactively tracking down all employees to complete their certification tasks when you’re trying to get your certification is a headache.
To my mind, this is the most important factor for having a smooth SOC 2 process, especially as a startup. We’ve heard from other startups that their auditors were understaffed and ignored them up until the last week of their audits, leading to a number of exceptions on their final SOC 2 reports.
This shouldn’t happen. Before heading into an audit, your auditor should have a deep understanding of your infrastructure and policies — and be able to identify risk points. They’re your partner in achieving a compliant security posture, and given that many of the SOC 2 rules are open to interpretation, a good auditor can highlight which of your policies may need to be revised or overhauled.
A good auditor will also have a strong understanding of business operations for a company your size. If you work with an auditor that specializes in working with enterprise software companies, they may push you toward policies that are unnecessary or don’t make sense for your organization’s size.
Utilizing a SOC 2 automation platform can greatly reduce the effort needed to achieve compliance. While the exact features of platforms vary, they can help you save time by providing:
At OneSchema, we evaluated Vanta and Secureframe. We ended up going with Vanta because they had better supported integrations for our stack.
Vanta’s innovations have fundamentally changed the SOC 2 landscape. Before Vanta, a SOC 2 audit was a much less well-defined process. While AICPA publishes Trust Services Criteria as a framework for auditors to leverage, the criteria are open for interpretation. Vanta turns the criteria into a clear checklist for you and your auditor to leverage, and automates checking for compliance for many of the criteria.
The team at Vanta is very knowledgeable and have been a great compliance partner for us. Their platform easily integrated into our infrastructure and we have yet to encounter any issues. They’re frequently launching new features relevant to startups. We love their Trust Report feature, which has been helpful for quickly sharing a live overview of our security program with sales prospects.
Working with your auditor to plan your audit will help ensure you get a clean report. If you miss key milestones in your audit, your auditor may note an “exception” on your SOC 2 report, which will highlight to customers an area in which your security posture is insufficient.
If you fail to scope the necessary tasks and set realistic milestones, components of the audit can slip. This can create misalignment between departments and result in delays or SOC 2 reports that aren’t completely clean. A clear timeline will allow each department to prioritize their SOC 2 responsibilities and avoid last-minute prioritization changes to meet audit deadlines.
Creating a checklist, such as this one from Vanta, can be helpful in managing the different action items involved from different parties.
The more effort you put into earlier audits, the easier future audits will become for you.
You’ll likely have policies that will need to change between audits as your business changes. For example, your physical security policy would likely need to change if your company went from in-office to remote-first. Similarly, your escalation paths in your business disaster recovery plan would likely change as your company added in a new layer of senior management.
We’ve found it helpful to proactively identify areas in our policies that would need to change in a subsequent audit. In future audits, we’ll be able to focus more carefully on those areas.
It’s also worth considering how your policies will apply to other compliance standards. SOC 2 is one of the more comprehensive compliance certifications, so often if you have great SOC 2 policies, you’ll already have made significant progress toward achieving other compliance standards like HIPAA and ISO 27001.
While we received a lot of advice early on not to invest in SOC 2, we have high conviction that an early investment was the right decision for our business. Within our target market (SaaS companies), compliance has gone from a nice-to-have to table stakes. Many of our largest and most impactful deals wouldn’t have been possible without SOC 2 compliance.
The decision will be specific to your SaaS business — do you handle sensitive customer data? Are your customers compliance conscious? Do most of your customers also maintain SOC 2 compliance?
If you’re considering getting SOC 2 certified and want to talk, feel free to reach out to us at founders@oneschema.co. Happy to share our experience with auditors, compliance platforms, or anything else!
Note: SOC 2 is different from SOC 1, which focuses on an organization's financial statements and financial reporting. There is also SOC 3, which reports on the same information as SOC 2, but SOC 2 is a restricted use report and SOC 3 is a general use report meant for a broad audience.
{{blog-content-cta}}
Engineering and product teams use OneSchema to easily build out best-in-class data import capabilities for their customers. Instead of spending months writing data validations and handing CSV parsing edge cases, focus your development resources on your core product development. With minimal engineering investment, improve your customer activation rates and launch better onboarding than your competitors.
From the earliest days of our business, we heard loud and clear from customers that the lack of SOC 2 Type II certification would block them from doing business with us. And with good reason: as a data processor, we handle our customer’s customer’s sensitive business data and PII. Demonstrating robust security practices would be critical in building trust with our service.
We’re about to complete our second SOC 2 Type II audit. We wanted to share our learnings and best practices around achieving a strong security posture while maintaining product development velocity as an early-stage startup.
SOC 2 is an auditing standard maintained by the American Institute of Certified Public Accountants (AICPA) to test an organization’s internal controls for security and privacy. It’s an objective, third-party system that signals to your customers that they can trust your platform to handle their information in a secure way.
SOC 2 defines criteria for managing customer data based on five “trust service principles” — security, availability, processing integrity, confidentiality, and privacy.
In practice, managing customer data can range from ensuring that you have proper internal communication for system updates to checking that you have a recent test of your incident response plan. Multiple departments likely will be involved in your SOC 2 audit. Typical stakeholders at a startup will include individuals who handle functions in engineering, IT, product, HR, legal, and compliance.
There are two types of SOC 2 — Type I and Type II.
SOC 2 Type I reports cover your company’s systems and controls — and whether the auditor believes you appropriately designed your controls to address all Trust Service Principles. The assessment for Type 1 reports is conducted at a single point in time.
SOC 2 Type II reports include coverage of your company’s systems and controls. They also track the design and operational effectiveness of those systems and controls over a period of time (between a 3 to 12 month period).
A Type II report provides a higher level of rigor, given that it tests the compliance program and the control execution over a long period of time. This is nearly always the required compliance certification if you’re looking to work with enterprise customers in the United States. We have also found that many of our SMB customers expect SOC 2 Type 2 as well.
SOC 2 reports are issued by external auditors and evaluate the extent to which a vendor complies with various security controls. The certification is based on this SOC 2 report, which assesses systems and processes that exist at the company.
When we were in YC, we got conflicting advice about if we should invest in SOC 2 from the beginning. If your business doesn’t handle sensitive customer business data, you may run into fewer concerns around data security, and SOC 2 may be a lower priority for you. However, it was a critical business decision for us that removed a core friction point in our deal cycles. Here are three factors that made SOC 2 Type II valuable for us:
A SOC 2 Type II certification gives your customers confidence that your organization complies with all modern security standards, such as frequent penetration tests, data encryption in flight and at rest, modern encryption protocols, disaster recovery procedures that are tested frequently, role-based access control, 2-factor authentication, etc. Instead of having to send over a detailed questionnaire to confirm specific practices their security team cares about, your customer can trust that a 3rd-party auditor has already tested these controls.
Given that it’s conducted over a window of time (3 to 12 months), a SOC 2 Type II report gives your customer more confidence than your responses to a security questionnaire would. A questionnaire is unable to verify that you’ve been compliant over time.
Maintaining a SOC 2 Type II certification also requires companies to audit the security practices of their vendors — and most companies with a SOC 2 certification require all of their vendors to be SOC 2 Type II compliant as well. So, even if you have a fantastic security posture, without the confirmation of a SOC 2 audit, many customers' policies won’t allow them to move forward with you as a vendor. In some cases, it may even be a contractual obligation with their customers to only leverage vendors who have a SOC 2 Type II certification.
SOC 2 doesn’t actually have to be as time consuming as you might think, especially if you designed your systems from the ground up with an eye toward modern security practices.
The bulk of SOC 2 resources we found while going through the process were targeted toward larger, more traditional companies. As a smaller company, you’ll likely have a smaller codebase, fewer employees, and less complex business processes. All of these things will reduce the load on getting your first SOC 2 certification, though you’ll likely need to implement a few new processes around compliance.
The earlier you invest in compliance, the easier it is to scale and maintain compliance.
Here are two examples of how investing in compliance early can help save you significant effort in the long term:
Example 1: creating technical debt.
If you design your infrastructure without considering the implications for SOC 2, you may need to undo choices you made and create significant technical debt. We’re currently leveraging DuploCloud on AWS to configure our settings in a SOC 2 compliant way and manage multi-region hosting. If we hadn’t been aware of the infrastructure considerations around SOC 2, we would’ve had to re-architect our system to handle multi-tenancy with data isolation and retention. Instead, we had the right architecture in place from the get-go.
Example 2: more employees = more compliance tasks to be completed.
A very common reason SOC 2 certifications get delayed is difficulty staying on top of your employees to complete all required compliance tasks. You can integrate many of these tasks into your onboarding processes if you have robust security policies in place early. Retroactively tracking down all employees to complete their certification tasks when you’re trying to get your certification is a headache.
To my mind, this is the most important factor for having a smooth SOC 2 process, especially as a startup. We’ve heard from other startups that their auditors were understaffed and ignored them up until the last week of their audits, leading to a number of exceptions on their final SOC 2 reports.
This shouldn’t happen. Before heading into an audit, your auditor should have a deep understanding of your infrastructure and policies — and be able to identify risk points. They’re your partner in achieving a compliant security posture, and given that many of the SOC 2 rules are open to interpretation, a good auditor can highlight which of your policies may need to be revised or overhauled.
A good auditor will also have a strong understanding of business operations for a company your size. If you work with an auditor that specializes in working with enterprise software companies, they may push you toward policies that are unnecessary or don’t make sense for your organization’s size.
Utilizing a SOC 2 automation platform can greatly reduce the effort needed to achieve compliance. While the exact features of platforms vary, they can help you save time by providing:
At OneSchema, we evaluated Vanta and Secureframe. We ended up going with Vanta because they had better supported integrations for our stack.
Vanta’s innovations have fundamentally changed the SOC 2 landscape. Before Vanta, a SOC 2 audit was a much less well-defined process. While AICPA publishes Trust Services Criteria as a framework for auditors to leverage, the criteria are open for interpretation. Vanta turns the criteria into a clear checklist for you and your auditor to leverage, and automates checking for compliance for many of the criteria.
The team at Vanta is very knowledgeable and have been a great compliance partner for us. Their platform easily integrated into our infrastructure and we have yet to encounter any issues. They’re frequently launching new features relevant to startups. We love their Trust Report feature, which has been helpful for quickly sharing a live overview of our security program with sales prospects.
Working with your auditor to plan your audit will help ensure you get a clean report. If you miss key milestones in your audit, your auditor may note an “exception” on your SOC 2 report, which will highlight to customers an area in which your security posture is insufficient.
If you fail to scope the necessary tasks and set realistic milestones, components of the audit can slip. This can create misalignment between departments and result in delays or SOC 2 reports that aren’t completely clean. A clear timeline will allow each department to prioritize their SOC 2 responsibilities and avoid last-minute prioritization changes to meet audit deadlines.
Creating a checklist, such as this one from Vanta, can be helpful in managing the different action items involved from different parties.
The more effort you put into earlier audits, the easier future audits will become for you.
You’ll likely have policies that will need to change between audits as your business changes. For example, your physical security policy would likely need to change if your company went from in-office to remote-first. Similarly, your escalation paths in your business disaster recovery plan would likely change as your company added in a new layer of senior management.
We’ve found it helpful to proactively identify areas in our policies that would need to change in a subsequent audit. In future audits, we’ll be able to focus more carefully on those areas.
It’s also worth considering how your policies will apply to other compliance standards. SOC 2 is one of the more comprehensive compliance certifications, so often if you have great SOC 2 policies, you’ll already have made significant progress toward achieving other compliance standards like HIPAA and ISO 27001.
While we received a lot of advice early on not to invest in SOC 2, we have high conviction that an early investment was the right decision for our business. Within our target market (SaaS companies), compliance has gone from a nice-to-have to table stakes. Many of our largest and most impactful deals wouldn’t have been possible without SOC 2 compliance.
The decision will be specific to your SaaS business — do you handle sensitive customer data? Are your customers compliance conscious? Do most of your customers also maintain SOC 2 compliance?
If you’re considering getting SOC 2 certified and want to talk, feel free to reach out to us at founders@oneschema.co. Happy to share our experience with auditors, compliance platforms, or anything else!
Note: SOC 2 is different from SOC 1, which focuses on an organization's financial statements and financial reporting. There is also SOC 3, which reports on the same information as SOC 2, but SOC 2 is a restricted use report and SOC 3 is a general use report meant for a broad audience.
{{blog-content-cta}}
