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.
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.
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.
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. Theyre both lumped into SSAE 18. There is more clarity in SSAE18 with the effort to get to this point. Thats 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 shouldnt 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 thats 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 dont want to be public knowledge, so thats going to be something that those large service providers are going to drive, and youre 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 theyre 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, lets say you have one significant customer and theyre 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 its a reporting framework, it allows you a little bit more flexibility to cater the report to what you really need it to work for.
A: Unfortunately, the answer is: it depends. There are things that you have to take into consideration particularly for SOC 2:
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 thats 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.
Theres a couple different layers, but if you need further clarification on that certainly were happy to set up a scoping call so feel free to contact us and we can get that conversation going.
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 whoevers 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 youre 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, lets say there was a background check test, and for the sample tested its determined that there wasnt a background check performed on one person. Management could say there was a reason for that, and heres 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 were on scoping calls and hear customers say that they leverage AWS, there certainly gives some comfort and it helps us to know what were walking into.
Q9: If a company utilizes multiple cloud providers, will you need a SOC 2 report for each?
A: Ill get into a little bit more depth here. When youre performing the planning of your engagement youre going to come up with a list of vendors. Then you determine what services those vendors are performing for you, and determine if theyre 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 theyre a subservice org. If they dont get one, its 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 youre 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 dont have one, again, not the end of the world. You can do other procedures, but you would have to document those. Thats part of SSAE 18 now that affects the service providers.
A: Certainly penetration testing can be a control thats in your SOC 2 report. Its actually leveraged in a couple of different ways under the current criteria, so we recommend for any SaaS application, particularly if its 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 thats 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 customers customers?
A: We’re kind of dealing with the plot of the movie Inception here, it sounds like, a dream within a dream right? Whats going to happen here is youre going to provide your SOC 2 to your customer.
What theyre going to do, if theyre 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 shouldnt 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, Im okay with you providing this to XYZ Company who is your customer for this reason.
A: It depends on where youre within your control framework and your internal compliance strategy. If youve 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 thats 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 doesnt provide much assurance to customers, and theyre 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 lets 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. Ive seen a lot of clients use the type 1 in that respect to show progress.
A: What is our favorite answer when it comes to IT and IT security? It depends. And the reason it depends is its 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 youre 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.” Its almost always customer driven.
At the end of the day, the opinion and the report were providing you isnt giving you a sale of certification, but saying that weve 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 thats most likely going to be customer driven. Thats why we recommend doing it on an annual basis and having an annual reporting cycle, so that there are no gaps and you dont have to provide bridge letters. In most circumstances, its going to come back to customer demand and making sure that youre 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. Lets 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 theyre meeting, or theyre 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 youre doing the carve out method, you would not have to go do your own data center visit.
A: In most circumstances, that is probably the case. Its going to ultimately depend on your customers. Your customers may need assurance on the services that youre 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 youre 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 youre 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 theyre 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 youre outsourcing them as contractors. Even if you use a third party to hire those contractors, thats 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 theyre 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:
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 customers 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.
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: Our third parties — uses AWS — and we have to educate them that AWSs SOC is not the same as their own SOC report, is this publicly available to point out that the AWS SOC report is not ‘their’ SOC report?
Yes! You can point them to this webinar, which can be obtained here. Alternatively, you can provide them a whitepaper Jeff Cook wrote on the topic here.
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.
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.
Q24: 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).
Q25: 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.
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.
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.
Q28: 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.
Yes, the auditor’s opinion has standard language for unqualified vs qualified. This will be very clear in the audit report.
Q30: 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.
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.
Q32: 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.
Q33: With SOC, could a company “report” that they dont 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.
Q34: 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.
Q35: 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.
Q36: 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.
If you have questions about SOC 1, 2 or 3 reports and the Type 1 or Type 2 report, please contact us.
SOC Analyst (Cybersecurity) Interview Questions and Answers – SOC Processes
Katie Ginder-Vogel, Contributing Author, has been writing about technology for over 15 years. She enjoys telling stories about how people use software and hardware to grow their businesses, keep their customers information secure, and transform industries. She holds a B.A. and M.A. in English from Stanford University. To contact Katie, visit her on LinkedIn.
1: What is the difference between the SOC 2 Type 1 and SOC 2 Type 2 audit?
That is a good question and one I get asked on a very regular basis. The Type 1 audit only assesses if the proper controls are in place at a point in time and typically requires just a couple of examples that the controls are in place. The Type 1 audit also assesses if you have adequate controls defined to meet each Trusted Services Criteria (i.e., Security, Availability, Processing Integrity, Confidentiality, and/or Privacy) you’re pursuing. Also in a Type 1 audit, the auditor does not include their opinion on the operational effectiveness of your controls or a detailed description of tests performed on those controls.
A Type 2 audit, on the other hand, assess the operational effectiveness of your controls by having you provide multiple evidence for the same controls over time, usually through sampling.
How are SOC 1 and SOC 2 different?
Depending on the service or system you provide, third parties might ask whether you’re SOC 1- or SOC 2-compliant.
You might think that SOC 2 is an updated version of SOC 1, but they are actually two different frameworks. You might be required to complete one SOC audit or both.
SOC 1 is less common, and applies when you host financial information that could affect third parties’ financial reporting.
SOC 2 applies for all other types of sensitive information related to the third party. If you don’t host financial data, this is the only compliance audit you should complete.
By contrast, if you only host financial information, you don’t need to complete SOC 2.
Organisations that host both types of data will need to complete both compliance audits.
What do you look for when examining an organization?
“Assuming you’re type II, we’ll come in a couple weeks before the period of review ends. We’ll do a kick off and talk to the key players and request populations (e.g., instances of some sort of technology function in operation, like a software change or security monitoring software logs).
“From the populations, we’ll sample some of them to see if the control was working. For example, we might sample 10 of the 100 software changes during the review period and see if they were reviewed by peers.
“Then, we’ll test each sample against each control.
“After this assessment, if everything worked out correctly, we will start writing the report.”
FAQ
What are the two types of SOC 2?
How many SOC 2 controls are there?
