SOC 2 Type 1 and SOC 2 Type 2 Frequently Asked Questions

Coalfire’s SOC Practice Directors Dixon Wright and Jeff Cook recently conducted a webinar on AWS and SOC Reporting, What you need to know. The presentation provided a lot of good points that organizations should know or be prepared for regardless of the technology that is being used. Below you will find a transcript of the Q&A session from the webinar.

One key point to highlight, SSAE 18 is now effective for all SOC reports after May 1, 2017.

Additional whitepaper resources for SOC reporting are:

• Service Organization Control (SOC) Reports: What are they?
• How to Determine Whether to Include the Privacy Principle for SOC 2
• SOC 2 Privacy Principal: What Changed?
• SOC Reports: An Evaluation of the Inclusive Method vs. Carve-out Method
• SOC Reporting in the Cloud
• SOC on Amazon Web Services (AWS)
• SOC on Salesforce

SOC Reporting FAQ

Q1: If my organization is in the AWS environment, do we need to have our own SOC report?

A: Yes. We discussed this a couple of times during the webinar. Even if you are using AWS to support your service, the solution you are providing to customers would still need to be SOC audited if customers are asking for it. 

Q2: Is there any end of life date for SSAE 16.

A: May 1st, 2017. For any reports that are issued after that date, SSAE 18 supersedes SSAE 16 as well as AT101, and a couple other AT standards. SSAE 18 is the new guidance standard for doing these audits.

Q3: So, does that mean SSAE 16 goes away?

A: SSAE16 was the guidance on how to do a SOC 1 audit. Now, the guidance is SSAE 18 on how to do a SOC 1 and a SOC 2 audit. They're both lumped into SSAE 18. There is more clarity in SSAE18 with the effort to get to this point. That's why transitioning to SSAE18 came about.

Q4: Regarding the distribution of reports and if reports are a restricted/proprietary document, how do we show our end users our compliance? Also, can we email our SOC reports, some large service providers are not allowing the emailing of reports?

A: At the end of the day, these reports are restricted and proprietary. Typically, SOC 1 and SOC 2 reports should only be distributed under NDA to your customers or prospects. So, you shouldn't be posting them on your website. There is an additional report called a SOC 3 report, which is a toned down version of your section 3 within your SOC 2 report.  SOC 3 is for marketing material, so that is something that you can post on your website and let folks download.

Amazon actually has a really good example for that, so if you search for “AWS SOC 3”, you can download their SOC 3 report and see what that looks like. To the other question about emailing, I think that's going to be the nature of their confidentiality provisions. Ultimately there can be some sensitive data listed within the system description, and obviously reports have exceptions that organizations don't want to be public knowledge, so that's going to be something that those large service providers are going to drive, and you're basically going to have to accept their terms.

Q5: Are customers still insisting on questionnaires and audits even if their provider has a SOC report, or does the SOC report successfully avoid this?

A: You can never guarantee that a company is going to accept it, but I will say that ninety plus times out of a hundred, the SOC report will satisfy what those people were looking for in their questionnaires or questions that they were asking. Mainly they're going to be asking about controls around logical access, change management, and risk management and those kinds of things, and that does get covered in your SOC report.

Ultimately, let's say you have one significant customer and they're the one asking about this. You could always talk to them and ask what they want to know about your service to make sure that it gets covered in the SOC 2 report. The nice thing about SOC is that it is a reporting framework as opposed to a security framework. Now, yes there are security guidelines, and I can go into the nuances of the difference between the two, but the bottom line is because it's a reporting framework, it allows you a little bit more flexibility to cater the report to what you really need it to work for.

Q6: What is the pricing and the cost of doing SOC assessments?

A: Unfortunately, the answer is:  it depends. There are things that you have to take into consideration particularly for SOC 2:

• What trust service principles do you want included?
• How large is the environment?
• How many applications are ultimately in scope?
• How many employees does your organization have in place?

All of those things and more would have to be taken into consideration. The additional piece is ultimately the methodology and the track that you take, so what we suggest for first-time customers is to undergo a gap or readiness assessment. We use those anonymously, and that's where we help take you through and help you identify your controls, map those controls to the necessary criteria, and see what gaps you have for items that you can’t address. Then we come back and then do a SOC 2 type 2 assessment after all those controls have been remediated, executed, and are operating effectively over a period of time.

There's a couple different layers, but if you need further clarification on that certainly we're happy to set up a scoping call so feel free to contact us and we can get that conversation going.

Q7: What are our expectations if there are exceptions identified in AWS's report?

A: If AWS has exceptions, those exceptions would not show up in your report.

For those familiar with SOC reports in section 4, you have the objectives for the trust principles, the controls in place to meet those objectives, the auditors test of the controls, and then the results of tests (and any exceptions noted). Most of the time the goal of whoever's being audited is to have no exceptions in that report. Occasionally exceptions could come up. If there were exceptions in the AWS report, you would need to do an analysis of those exceptions to determine if they had a significant impact on your service and the service you're providing to customers.

With that in mind, many times if there are exceptions in the report there is a management response to that, and you would have to take that into consideration as well. For example, let's say there was a background check test, and for the sample tested it's determined that there wasn't a background check performed on one person. Management could say there was a reason for that, and here's the reason why. You can do an analysis of that and determine there was an exception but there was a legitimate reason for that and move on. 

Q8: what percentage of efficiency can we expect when we leverage AWS as it relates to SOC?

A: Unfortunately, that answer depends. For organizations like Coalfire that have a broad range of experience in performing IT audits and SOC reports for organizations using AWS, we’ve developed experience and a track record in understanding AWS and how organizations leverage the services. When we're on scoping calls and hear customers say that they leverage AWS, there certainly gives some comfort and it helps us to know what we're walking into.

Q9: If a company utilizes multiple cloud providers, will you need a SOC 2 report for each?

A: I'll get into a little bit more depth here. When you're performing the planning of your engagement you're going to come up with a list of vendors. Then you determine what services those vendors are performing for you, and determine if they're a subservice organization or not.

Ideally, you would want to get a SOC 2 report for each of those cloud providers if you determined that they're a subservice org. If they don't get one, it's not the end of the world. You can get similar information from them via questionnaires, conducting an internal audit, you can go do your own inspection, etc.  Coming back to SSAE 18 and the monitoring aspect of this, you would still have to do something in order to gain comfort that what you're subservice organization is doing is providing the service that you need to help meet your control objectives.

Ideally getting the SOC 2 would be the best scenario because then you could look at the report, do an analysis of it, look for exceptions and make sure that it is okay. If they don't have one, again, not the end of the world. You can do other procedures, but you would have to document those. That's part of SSAE 18 now that affects the service providers.

Q10: is there any overlap with Coalfire’s penetration testing?

A: Certainly penetration testing can be a control that's in your SOC 2 report. It's actually leveraged in a couple of different ways under the current criteria, so we recommend for any SaaS application, particularly if it's an external web application that the organization needs, to undergo penetration testing and report on that. That’s a logical extension to an already existing relationship with Coalfire that certainly helps.

There is not a definitive requirement like PCI DSS where it says you must undergo penetration testing and test for segmentation on an annual basis. But again, as the cyber landscape changes, it’s becoming a minimum requirement these days to conduct penetration testing and certainly something that's always going to pop up on vendor questionnaires, so we highly recommended organizations conduct regular penetration testing.

Q11: if I have a SOC 2 audit performed for my customer and they process transactions for their customers, do I have an obligation to provide my SOC 2 to my customer's customers?

A: We’re kind of dealing with the plot of the movie Inception here, it sounds like, a dream within a dream right? What's going to happen here is you're going to provide your SOC 2 to your customer.

What they're going to do, if they're getting their own audit (their own SOC 2) is they are going to list you as a subservice organization, and then they obtain your SOC report to do their monitoring of you. If they intend to use your SOC report, you would have to come to an agreement with your customer because these reports are considered confidential and proprietary. Therefore, your customers shouldn't be just handing your report out to their customers without your permission. You would have to come to an agreement with your customer to say, yes, I'm okay with you providing this to XYZ Company who is your customer for this reason.

Q12: How long will it take to complete a SOC 2 type 2 report?

A: It depends on where you're within your control framework and your internal compliance strategy. If you've undergone other assessments like PCI or ISO, SOC is essentially a logical extension to that just in a different reporting format, and many times you can undergo SOC 2 type 2 immediately. If you have no compliance initiatives underway, or have never been through any we’d recommend conducting a gap analysis. From start to finish, for a customer that is going through SOC and has never been through any type of compliance initiatives, our SOC gap assessment process can take anywhere from two to six months. I would say the average is probably be around three months. Then you have to wait to let those controls operate effectively for six months, so then that obviously pushes you to at least nine months.

For the audit, we typically will come in towards the end of a period and do the majority of our procedures and then issue reports somewhere around one and a half months after field work is conducted. To have a Type 2 report in hand to be able to provide the customer would be anywhere from nine to twelve months, I would say is a pretty good gauge. If that's going to be a requirement from your customers to have a report issued by a certain date, certainly keep those timelines in mind because it does take long given the review period aspect.

As mentioned earlier - about the difference between type 2 and type 1 report - you certainly have the ability to provide a type 1 report, but we found in most circumstances, that doesn't provide much assurance to customers, and they're always in their contracts going to demand type 2 reports. A SOC 2 Type 2 should almost always be your goal for SOC reporting.

The SOC 1 Type 1 report can provide you a stepping stone. So let's say that your customers were demanding to see progress. You can definitely get a type 1 once you have all the controls in place and your remediation is complete you can use that as evidence that you are “working on it” and you’re “getting there.” You can say you have a type 1 report, and you just need time to pass in order to get to a type 2. I've seen a lot of clients use the type 1 in that respect to show progress.

Q13: Does a compliant ISO 27001 report preclude the need for SOC 2?

A: What is our favorite answer when it comes to IT and IT security? It depends. And the reason it depends is it's going to really depend on if the customer is willing to accept that ISO 27001 report in place of a SOC 2. Some may be fine with that, some may not. This is what scoping and planning discussions are for, so you can work with ISO and SOC together, get a little bit more convergence between the two, and have one firm out there doing these multiple assessments for you.

Q14:  Regarding expiration and inspection period, during the inspection period is the org considered certified if it is a new inspection? 

A: If you're familiar with PCI requirements, PCI requires organizations to undergo a Report on Compliance every year if you meet a certain criteria. For SOC reporting there is no external body saying, “XYZ organization, you must do this on an annual basis.” It's almost always customer driven.

At the end of the day, the opinion and the report we're providing you isn't giving you a sale of certification, but saying that we've assessed the controls as it relates to the SOC 2 criteria, and we believe that these controls are designed and operating effectively during the stated period of time.

And that period of time is going to be something that's most likely going to be customer driven. That's why we recommend doing it on an annual basis and having an annual reporting cycle, so that there are no gaps and you don't have to provide bridge letters.  In most circumstances, it's going to come back to customer demand and making sure that you're meeting the demand so that you can continue to do business with those customers.

Q15: I have a data center with a SOC 2 in addition to ISO 27001. Is a data center visit/cost on our own SOC 2 necessary?

A: This is where the carve out method comes into play for subservice organizations. Let's use AWS as our example. If AWS is the data center that has SOC 2 compliance as well as ISO compliance, you would list them as a subservice organization and if you do the carve out method, you would not need to go visit their data centers. All you would have to do is obtain those reports, do an analysis of the reports to make sure that they're meeting, or they're helping you meet, your control objectives and then make sure you list them as a subservice org in the system description. We showed some of those examples earlier of how leveraging S3 and other AWS services help you meet your objectives. To answer your question, no. If you have them as a subservice organization and you're doing the carve out method, you would not have to go do your own data center visit.

Q16: I'm not a service provider, so I don't need a SOC audit, correct?

A: In most circumstances, that is probably the case. It's going to ultimately depend on your customers. Your customers may need assurance on the services that you're providing them, so if you are not providing services then you likely would not have to provide assurance. If you are not a service provider and you're getting requests for SOC reports, I would consult a third party and get their opinion on it. We can certainly have that conversation with you if that comes.

Determining what is the driver behind the client requests would be determining if the SOC audit is needed or not.

Q17: When considering the definition of a "subservice organization," where do you draw the line between such an organization performing a part of the services being provided by the service organization and not being provided?  ... For example, the service, say, is providing software as a service. If part of the development of that software is outsourced to a 3rd party contract development firm, is that 3rd party considered a subservice organization?  ...  If so, what would be an example of one that is not.   ... If not, what would be an example that would not be obvious, but yet considered a subservice organization?

A: This really depends on the nature of that service that you're outsourcing, we do actually have one organization that essentially develops applications from scratch for customers, hands over the executable, tell the customer to implement it. In that circumstance, because they're responsible for the security and secure coding of that application, if any updates need to be made for the change management process, I would certainly consider them a subservice organization.

Let’s use an example where you are outsourcing IT personnel to do coding on the application that you own, manage and are responsible for the change management process. In that scenario, you may have a Github repository with people in Eastern Europe actually coding the application for you and are not part of your organization, but you're outsourcing them as contractors. Even if you use a third party to hire those contractors, that's not likely a scenario where those folks would be considered a subservice provider. They would be treated more as a contractor, and you would need to ensure that you have controls around the onboarding of those contractors. Background checks are a key component regarding onboarding in a SOC report.  That would involve making sure that those contractors are not criminals, as well as making sure they're only granted access privileges that they may need to do their job. Those are going to be control considerations, but not necessarily something that you would need to carve out of your report.

Q18: Are there some obvious "must start right away" process/procedures if we are heading towards establishing project for SOC 2?

There are quite a few policies/procedures that will be beneficial for a SOC purposes.  These range from organizational to security policies, but they all will play a role.  A good base could include:

• Information Security Policy/System (or information) security plan (SSP)
• Incident response plan
• Disaster recovery plan
• Security awareness (and training)
• Human resources plans (hire, termination, handbook, etc.)
• Acceptable Use/Rules of behavior
• Configuration management
• Risk assessment
• Change management
• Logical Access
• Backups
• Data Classification and handling procedures (retention and disposal)

Q19: Can a company use any audit firm to perform their SOC 1 or SOC 2 engagement? Is there a risk that a customer or a customer's auditor rejects the SOC report if it comes from an audit firm that is not well known (no a big4 report)?

Companies can use any licensed and registered CPA firm that is qualified to perform SOC audits.  CPA firms must undergo peer reviews for their attestation practices.  These peer reviews help determine if a firm is performing their engagements in accordance with AICPA and other applicable guidance.

Q20: Can you give an example of what evidence of monitoring could look like?

For monitoring of a subservice organization (like AWS), you would ideally obtain their SOC report and review it to determine that what AWS is doing meets your expectations and helps you meet your control objectives.  Documentation of this review, along with any other inquiries, (and conclusion) should be kept as part of your monitoring evidence.  We typically see this documented via memo or with a ticketing system.

Q21: How Cloud CSA Cloud Matrix can be mapped with SOC requirements?

The AICPA has made a mapping of SOC 2 plus additional subject matter (including CSA STAR) here.  An illustrative example of this is also provided here.  Coalfire also has internal SOC mapping to CSA and other certification requirements.

Q22: How does SOC compare to PCI or NIST (FedRAMP)?

PCI and NIST are more geared toward security frameworks, whereas SOC is a reporting framework.  This means that PCI and NIST have defined minimum standards to meet security requirements, whereas SOC has objectives for security, and your company just reports what you do to achieve an objective. 

For example, NIST may say that password complexity should be a 15 character minimum, with a mix of alphanumeric and special characters.  For SOC, 8 characters alphanumeric may be acceptable because logical access objectives just state that identification and authentication requirements are established. 

Q23: How does the SOC apply when you are co-located?  I.e. the data center is a colocation data center?

If your company uses a co-location (CoLo) data center to store your data, that co-location data center would be considered a subservice organization.  Your company would then have to report the CoLo as a subservice org in section 3 in your report, disclosing what service they provide, what objectives they help you meet, what controls you expect them to have in place, and how you monitor their compliance with their controls (your monitoring controls).

Q24: is there any formal guidance published on how to perform risk assessment on sub-service organizations?

The new SSAE 18 standard from the AICPA describes the requirements for monitoring of subservice organizations.  A Coalfire summary can be found here, and the official document from the AICPA can be found here.

Q25: Is there any synergy using our Coalfire PCI tools (Coalfire One)?

Our SOC practice also uses Coalfire’s CoalfireOne tool. For engagements where there are multiple frameworks involved, our teams work together to ensure that evidence is only requested once. Keep in mind that timing of engagements is important due to evidence going stale after 90 days.

Q26: SOC2 reports can be expensive to do.  Will a CAIQ do instead?

Ultimately this is going to be up to your customers and what they are requiring from you.  If your customer demand or contractual obligations are requiring SOC specifically, you would have to consider a SOC 2 for the specific criteria they are looking for.  However, you can ask your customers if CAIQ would be an acceptable alternative, making sure the results of the CAIQ would meet their requirements.

Q27: What is the estimated cost of this audit and should community colleges have a SOC?

The cost of a SOC audit depends on the size of the system(s) being audited, how many control objectives (SOC 1) or trust principles (SOC 2) are included for the report, and if a type 1 or type 2 audit is being performed. 

Determining the purpose of the report (why is it needed) would determine if SOC is appropriate for community colleges.

Q28: Are the Service Auditors required to clearly indicate their opinion i.e. unqualified vs. qualified?

Yes, the auditor’s opinion has standard language for unqualified vs qualified.  This will be very clear in the audit report.

Q29: How do make sure my company has all controls documented or listed for my cloud subservice organization?

You should determine internally what controls you think your subservice organization should have in place that would help you meet your control objectives.  For example, if you are using AWS, you would want to make sure they have availability controls related to replication in order for you to meet your availability objectives to your customers.

Once you determine what you think AWS should have, you would obtain their SOC report to see that those controls are in place and operating effectively.

Q30: How much of a SOC 2 report can be automated?

The report itself is not automated. However, as a service organization, you can can technically automate any control used to satisfy the SOC 2 criteria as long as it designed appropriately and monitored for operating effectiveness.

Q31: For carve-out method when is it required to send customer both our soc and provider SOC? AWS will not let provider SOC go out but our carve-out makes references to it.

If you are using the carve-out method, you would not be required to issue the SOC reports of subservice organizations in addition to your own SOC report.  You would only disclose in your report that the subservice organizations are “carved-out” from testing, but you would show your monitoring controls of subservice organizations.

Q32: With SOC, could a company "report" that they don't encrypt anything, or have firewalls, or AV, or....?

Yes, however if the controls are deficient to the point that they are not meeting the associated objectives of the trust principles, it could lead to a qualified or adverse audit opinion.

Q33: How many/which trust principals need to be included in order to take the place of a general questionnaire

It would depend on what is in the questionnaire, but we’ve seen success with the most common SOC 2 report including security, availability, and confidentiality.

Q34: how do we leverage other SOC-2 reports on our subservices to start scaling down the cost of the SOC-2 reports on our own products?

Depending on what services your subservice organizations are providing will determine how much can be leveraged in your SOC 2 report.  You would still have to consider your own controls along with shared responsibility in your report (you can’t just outsource the entire report).  For example, if you use AWS, you can leverage how you use them, but you still have your controls for access as well as the shared responsibility of settings and configurations.

Q35: I have a datacenter with a SOC-2 in addition to an ISO 27001, is a datacenter visit/cost on our own SOC-2 necessary? even if it is my own company owned datacenter?

In this case, you would treat the datacenter as a subservice organization and use the carve-out (more likely) or inclusive (less likely) method to report them in your SOC 2 report.

Can we help your organization?

If you have questions about SOC 1, 2 or 3 reports and the Type 1 or Type 2 report, please contact us.