800+ IT
News
als RSS Feed abonnieren📚 The Definitive Guide to SOC 2 Compliance
💡 Newskategorie: IT Security Nachrichten
🔗 Quelle: twingate.com
This article is part of the Twingate Infosec Compliance Series. Written for IT admins, security ops, and anyone else tasked with implementing infosec requirements imposed by compliance standards, this series explains common standards, how they relate to information security, and how to get started with attaining compliance.
If you provide technology products or services to other businesses, you’ll likely have encountered SOC 2. This article provides a comprehensive guide to SOC 2: what it is, why it’s important, and the process behind achieving SOC 2 compliance.
What is SOC and who does it apply to?
SOC stands for System and Organization Controls, and it refers to a suite of three reports known as SOC 1, SOC 2, and SOC 3. SOC reports are written by independent auditors at the request of a “service organization,” which is an organization that provides information systems to other organizations as a service (SaaS companies are a common example). The report describes internal security and other types of controls over those information systems that the service organization has implemented.
SOC reports are issued by an auditor after the completion of an audit conducted in accordance with frameworks established by the American Institute of Certified Public Accountants (AICPA) for reporting on the internal controls implemented in an organization.
When organizations say they are “SOC compliant,” what they really mean is that they have completed a SOC audit and have had a SOC report issued. It does not necessarily mean they have adequate security controls, or even that they have properly implemented all of those controls. SOC compliance is not a binary pass/fail concept.
Why should you care about SOC 2?
Because your customers likely care about it, particularly if you sell B2B services. Companies need to maintain appropriate information security practices across their own organizations, as well as ensuring that their supply chain is doing so too. To do this, companies perform vendor security risk assessments of prospective vendors. To assist with this process, it is commonplace for customers to collect security information by asking their service providers for a SOC 2 report.
A SOC 2 report helps customers understand the security-related controls that the vendor has established to support the delivery of its services in a secure and compliant manner. Because the report is produced and certified by a qualified auditor, it can provide independent assurance that a vendor’s security practices meet a customer’s requirements.
What are the differences between SOC 1, 2, and 3?
SOC 1 focuses on internal controls over financial reporting. A customer might typically request a SOC 1 report from a service organization if that organization’s services impact the customer’s financial data (particularly if the customer is a public company).
SOC 2 is more general than SOC 1 and focuses on internal controls with respect to 5 areas called Trust Services Criteria (TSC). The five areas are: security, availability, confidentiality, processing integrity, and privacy. All SOC 2 reports must cover the security TSC, and may optionally cover any combination of the other 4 TSC. The report is usually obtained by an organization such as a SaaS company and provided to its customers and prospective customers who want to review the organization’s security posture.
SOC 3 is a condensed version of the SOC 2 report that provides less detail than the SOC 2 report. The SOC 3 report is intended for more general use and circulation. You’ll sometimes see companies make a SOC 3 report publicly available on their website, but require you to write in to obtain their SOC 2 report.
What is a Type 1 and Type 2 report?
Each SOC report comes in a Type 1 and Type 2 variant. A Type 1 report is based on an audit conducted at a single point in time (i.e. the service organization had these controls in place on this specific date). A Type 2 report is based on an audit conducted over a period of time, and attest to the maintenance of those controls by a service period throughout that period.
Type 2 reports are typically conducted on an annual basis, but when a company is getting their first Type 2 report done, they may choose a shorter period like 3 or 6 months in order to obtain a report that they can provide to customers sooner.
Which SOC report do you need? Should you get a Type 1 or Type 2?
In general, the most common report for technology providers is SOC 2, and that is typically the report that customers prefer to see. A Type 2 report should be the goal.
Type 2 reports are more desirable because they provide more assurance to customers. Type 1 reports only provide a snapshot of compliance at a point in time, and do not provide evidence that compliance is consistently maintained (kind of like driving at the speed limit only when there are cops around).
To get a Type 2 report, you have to wait for at least a few months for the audit period to be completed. A common question is whether it’s worth getting a Type 1 report before getting a Type 2? Maybe - this is a question of cost and opportunity.
Getting a Type 1 report will add to your costs. We’ve found that the audit fee for a Type 1 report is about 80% of the cost of a Type 2 report. Your auditor may be able to give you a discount for doing both, but don’t expect it to be significant.
On the other hand, if you are going to lose a customer opportunity unless you can provide them with a SOC report quickly, then the extra expense may be worth it. However, in our experience, customers may be willing to accept a letter from an auditor that states you are currently going through a Type 2 audit period, with an indication of when it’s due to be completed, plus an assurance that you will provide the report once it’s available.
Another argument for doing a Type 1 before a Type 2 is that it lets you see if your compliance is in good shape upfront, rather than waiting 6 months only to find out that you have deficiencies. While true, there may be a better approach. You should check with your auditor whether they can perform a readiness check before you start the Type 2 audit period. These can be conducted at significantly lower prices since they don’t need to write a report with their name on it. A readiness check will give you an idea of whether there are any gaps you need to remediate before embarking on a Type 2.
Which TSC should you get?
As noted above, SOC 2 audits can cover up to five TSCs. Security is the only mandatory TSC and you can select any combination of other TSCs to get audited against. Each TSC comes with its own set of controls that auditors will inspect (and therefore result in a higher audit cost). Whether you should select additional TSCs will be driven by your customers’ expectations and the type of service you offer. For example, if you offer a mission critical system where downtime has a severe impact on customers, then you might consider adding the availability TSC. It is relatively uncommon for a service to be audited against all five TSCs.
When starting out, consider just auditing the security TSC. This will keep your scope of work down, as well as audit fees. For future audits, you can consider adding new TSCs, which will, at that point, only result in incremental work. In the meantime, you can provide customers with reassurance regarding the areas that other TSCs cover through other means. For example, the SLAs you offer and your availability of track record (e.g. as demonstrated via a status monitoring page) may offer customers sufficient comfort regarding availability. Ask your auditors if they have a view on what TSCs they’d recommend for your business.
Who’s responsible for SOC 2 compliance?
SOC 2 is heavily focused on information security, so IT teams perform a lot of the heavy lifting and are commonly tasked with overseeing SOC compliance in a company. However, SOC involves other teams as well, such as HR, Legal and Procurement.
Twingate’s SOC 2 journey in brief: what the process looks like
Now that you have decided to obtain a SOC 2 audit, here’s what an initial audit process could look like, based on our own experience of completing our first SOC 2 Type 2 audit:
Step 1. Auditor Selection
SOC is an accounting framework so you can expect your SOC auditor to be an accounting firm. As at the time of writing, the cost for a SOC 2 audit ranges from approximately $10,000-40,000. The main factor that will drive cost is who you select to be your auditor. At the top end are the “Big 4” accounting firms, and at the lower end are regional accounting firms. The scope of your audit (Type 1 or 2, TSCs selected, nature of your services to be audited) will also impact cost.
Companies sometimes choose to go with a larger firm for brand name recognition, and potentially if they have a very large scope of work that a larger firm will be better resourced to handle. However, audit reports produced by smaller firms can be just as effective at meeting customer requirements. In fact, there are some smaller firms that have done SOC reports for some very well known and established internet companies.
Some questions you should consider asking prospective auditors:
- What are your fees and what factors impact them?
- What TSCs would you recommend for my service?
- What controls will you evaluate against?
- What does the process look like after you sign the engagement letter?
- What does the audit process look like?
- How long will it take to receive the audit report after the audit is completed?
- Who should we involve from our side?
- Who is the team on your side who will be involved, and who is the day-to-day POC?
- What are other companies you’ve audited in the past? In our industry?
- How many companies do you audit each year?
Once we signed up with our auditor, we had a series of scoping calls before the audit period started where they familiarized themselves with our services and environment. Together, we tailored a set of a controls adapted for our company that we would be audited against. These calls also gave us an opportunity to ask questions about their thoughts on different approaches to implementing certain controls and the types of evidence they would request during the audit.
SOC audits are also service-oriented and service-specific, meaning that if your organization offers multiple services to customers, you can select which services you want to be covered by the SOC audit and report.
One key thing to note about SOC 2 compliance is that organizations get to design their own controls. Auditors aren’t so much evaluating the adequacy of controls as they are evaluating whether a company has actually implemented the controls the company claims they have. It is up to your customers to review your controls list and evaluate if those controls are sufficient for their purposes.
Step 2. Audit Readiness: Attaining & Maintaining Compliance
Our auditor provided us with a spreadsheet containing the list of controls we’d be audited against and now it was a matter of working through them line by line. The basic steps we followed were:
- Team formation: We identified the main team at Twingate that needed to be involved and assigned project management responsibilities to one individual.
- Initial review: The main team held an initial meeting over Zoom and then worked through each row of the spreadsheet. For each row, we assigned a DRI (directly responsible individual) and, if work was needed to implement the control, we pencilled in a due date. We then scheduled regular status check ins, and each of us went off to work on our assigned tasks.
- Implementation work: Over the period of several weeks, each team member worked on implementing the controls they were responsible for (i.e. the “attaining compliance” phase) and would meet regularly for the status check ins. We also created a SOC compliance channel in Slack that we used to progress things between meetings and to coordinate cross-functional work.
- Audit window start: Once we felt we were in a good position, we alerted our auditor when our audit period should start. The start of the period marked when we needed to have all our controls in operation (i.e. the “maintaining compliance” phase).
- Audit window end: About a month before the end of our audit window, we reached out to our auditor to start scheduling the audit work they would need to perform.
One tip: If your initial audit period is for less than a year, make sure you conduct any annual tasks within that audit period. Otherwise, your auditors will be unable to verify that control. For example, if you do annual risk assessments and conduct one just before your audit period, then you will have to perform another risk assessment within your window in order for the auditors to be able to verify that control.
Step 3. The Audit Process: Ascertaining Compliance
The audit process primarily involved auditors collecting evidence that we were complying with the controls (this is referred to by auditors as “fieldwork”). Evidence was collected through three main methods: (1) interviews, (2) screenshots and documents, and (3) inspection of Vanta, which is a system we used to help automate aspects of SOC compliance. The process for us was iterative, with our auditors following up on a few items to request further information or clarifications. We ended up sitting through over 4 hours of live interviews.
Screenshots were often requested to verify system configurations - sometimes we uploaded them to a secure shared folder, and other times we would show our systems over a Zoom screenshare and the auditors would take their own screenshots. Sampling was also an approach used in some cases to verify compliance. For example, if you have a control that requires you to perform annual performance reviews of employees, your auditor may pick a few random names and request to see their reviews (the details of which can be redacted).
After the fieldwork was completed, our auditor finished a draft of the audit report. During that time, they also asked us to supply some text for Section 3 of the report, which includes a company overview and a description of the service being audited.
Our auditor let us review the draft so that we could correct any factual inaccuracies and typos. If there are any deficiencies in the way that you have implemented your controls, the auditor will identify them as exceptions in your SOC 2 report (happily, we didn’t have any). Finally, the auditor will issue the SOC 2 report. If you made it this far, congratulations!
Step 4. Now that you have a SOC report, what do you do with it?
Tell people you have it!
- Write a blog post announcing the availability of your SOC report.
- If you have a public webpage with infosec security or compliance information, mention your SOC report.
- Make sure your sales and customer support teams are armed with it, so they can provide it to customers on request. (Some customers may request a refreshed SOC report each year.)
One common question about SOC 2 reports is whether you should make them publicly available for download, or whether you should require an NDA to be signed first?
Unless your auditor is requiring otherwise, this is really a matter of personal preference. On the one hand, requiring an NDA may make it seem like a company is trying to hide a sub-optimal report (even if it’s a perfectly good report). On the other hand, SOC 2 reports are supposed to be for customers and prospective customers only, and releasing them under NDA is common practice. In the latter case, you might wish to obtain a SOC 3 report and make that freely available, since SOC 3 reports are intended for public consumption.
Additionally, it’s common to make non-customers fill out a sales lead form in order to obtain a SOC 2 report. After all, interest in your SOC 2 report is often a good signal of purchase intent.
Finally, even though you now have your SOC 2 report in hand, your work is not over. You’ll likely have transitioned straight into your next audit period and so you’ll need to continue maintaining compliance in order to obtain a clean audit in 12 months.
Infosec requirements under SOC 2
As mentioned above, the controls audited by a SOC 2 audit are technically up to an organization to define. However, in reality if you compare the SOC reports of two different organizations you are going to find similarities. This is mainly because organizations don’t come up with a list of controls in a vacuum, but start off with a framework (such as COSO) from which controls are derived in a structured manner. Additionally, in order to have a credible infosec program, there are a base set of categories of controls that you need to implement.
Typical examples of categories of controls for the security TSC include:
- Access controls
- Code management and environments
- Communications
- Incident response
- Network security
- Organizational security
- Policies
- Risk assessment
- Vendor management
How Twingate helps with SOC 2 compliance
Access controls are an extremely common category of controls that SOC 2 audits cover. After all, ensuring that only authorized individuals have access to the approprate resources is fundamental to security. It won’t come as a surprise that at Twingate, we use our own product to meet these requirements.
Here are five ways that Twingate helps businesses to meet SOC 2 access control (and other control) requirements:
- Implementation of granular access controls. Twingate enables access controls to be applied to all manner of private corporate resources on a very granular, least privileged basis. Twingate also enables minimum password complexity requirements and two-factor authentication to be applied to all types of applications and services, even ones that do not natively support them, such as SSH. Learn more.
- Facilitation of personnel offboarding. When an employee or contractor leaves your company, it’s common that their access needs to be revoked in a timely manner. Because Twingate overlays access controls over all your private resources in combination with your identity provider, disabling an individual’s SSO account will disable access to all resources secured by Twingate - even if the resource has a separate account for logging in. Learn more.
- Facilitation of access reviews. Another common control is regularly reviewing access control lists (quarterly reviews are a typical cadence). Because the responsibilities of personnel change over time, this is an important exercise to ensure that users’ access rights to resources remain relevant and continue to adhere to the principle of least privilege. By centralizing users’ access rights in one location, Twingate makes access reviews quicker and easier, as well as enabling on-the-spot changes to access rights. No longer do you need to review multiple, disparate systems. Learn more.
- Extensive logging of network activity. Twingate’s logging and analytics capabilities provide visibility into network access activity across your entire enterprise network. This helps you to meet SOC controls regarding the monitoring of anomalous or suspicious network activity for security purposes. Learn more.
- Facilitation of audits. Centralization of access controls in a single system makes it easy for you to provide evidence of compliance with access controls to SOC auditors.
A number of our customers have deployed Twingate to help with SOC 2 compliance. Contact us to learn more about how Twingate can help you to get ready for a SOC 2 audit.