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:

1. Team formation: We identified the main team at Twingate that needed to be involved andassigned project management responsibilities to one individual.

2. 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.

3. 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.

4. 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).

5. 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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.