Last month I had the opportunity to give a talk on SOC 2 at the ISACA/IIA GRC conference in Orlando, FL. The talk was titled "All Your Vendors Have a SOC 2, Now What?" and included insights from my own work maintaining the SOC 2 program at Conveyor as well as lessons learned from our work parsing SOC 2 reports for our clients. The audience had many questions, most of which we didn't have time to address. So we wanted to discuss a subset of those questions here to make sure the dialogue continues.
Slides from the talk are embedded at the bottom. If there is anything we missed or that needs clarification, we would love to hear from you!
Q: Which are the most important differences between SSAE18 and SSAE22 effective June 15, 2022?
These are not specific to SOC 2, but we expect more pushback from the AICPA on quality and integrity of attestation engagements. Within SOC 2, this will mean more room for auditors to push back on meaningless evidence that doesn’t actually indicate the trust services and service commitments are actually being met.
Second, we expect to see more disclosure on procedures/testing methods. More detail in the SOC 2 Type 2 reports, and more descriptions of the basis for the attestation.
Explicit permission for an adverse conclusion is the third big change, but the jury is out as to what this will mean in practice. Perhaps just giving auditors more leverage with clients. I don’t know if we’ll see an increase in adverse conclusions or other kinds of issues. I don’t expect to see a public wall of shame or other disclosure mechanism for adverse conclusions. The first wave of reports SOC 2 subject to these updates will be hitting a compliance artifact near you soon! See additional details here.
Q: Also, discuss the role of internal auditor when reviewing SOC 2.
A: This can vary significantly based on the size and structure of your business. Internal Audit can play a role in determining that the overall vendor review process (CC9.2) is suitably designed and functioning. As there can be a significant amount of jargon and filler in SOC reports, a trained auditor can also help empower the system owner to get the meaningful sections and understand deficiencies. In that case, the system owner can still own the responsibility of making a risk decision about the system.
Q: We are getting more SOC2 reports instead of Third Parties answering the questionnaire. Therefore, we sift through a SOC2 and match to defined security controls. Assuming this is a good thing to do, what recommendations do you have for making this more efficient?
A: Skip all the manual work and use Conveyor to parse the control information out of the SOC 2 report and automatically match to those controls.
Q: In your opinion, who's responsibility (internally) is it to review the User Entity Controls?
A: Ultimately the system owner internally should be responsible for fully understanding the scope and potential risks of a tool they will be owning. Asking the Head of Sales to read a 150 page SOC report can be a losing battle. With tools like Conveyor you can process the SOC report and associated documentation, and generate a one page risk assessment/summary the system owner should be responsible for reviewing and signing off on.
Q: SOC 2 and ISO 27001 seem relatively similar. Do you find that one holds more weight with customers/ 3rd party risk mgmt?
A: In general, SOC 2 is widely accepted in the United States, and ISO 27001 is widely accepted in the EU. There might be more respect for the integrity of the ISO audit process vs SOC 2, but they are close. Many vendors end up doing both, as the incremental cost of the second audit is small compared to the addressable market it unlocks. The benefit of a SOC 2 is you get a full description of the system and controls. One the other hand, most vendor only share their ISO certificate, and possibly the Statement of Applicability that covers which controls are in scope. Less than 1% of companies are sharing the actual ISO audit reports that list non-conformities and specifics about control performance.
Q: Any perspective on companies that have outsourced all things IT, and try to send you the SOC2 of their cloud/IT provider?
A: That’s not going to work as well in the future as it did in the past. Customers are more aware of the scope of security in the cloud and the layers of responsibility involved. It’s not just “the cloud” and AWS’s SOC 2 report.
Q: As the international community (ex: EU) move away from giving weight to SOC 2 reports and leaning into ISO, where do you see SOC reports in 5-10 years?
A: If SSAE22 changes are an indicator, AICPA will try to find a balance between accessibility and quality/integrity/independence of the audit. In general we see a lot of potential markets for many different standards. We don’t think any one specific security control standard will be winner-take-all.
Q: If an organization provides their SOC 2 report, should a Security Onboarding Questionnaire still be filled out (eg SIG Lite)?
A: If the SOC 2 report is thin and the vendor is potentially high risk, yes.
Q: Vendors in Europe do not have SOC usually, but ISO27001. Will this be good enough to accept instead of SOC type 2, specially for SaaS cloud apps
A: Generally, yes, enterprise customers in the US will accept an ISO 27001 certification in lieu of a SOC 2 Type 2 audit report. They may still have follow-up questions, however, or require you to complete a security questionnaire.
Q: How are resilience principles integrated into SOC2 criteria?
A: Availability as a Trust Services Criteria, covering training/preparing for incidents, monitoring, disaster response/recovery, and security incident response.
Q: Thoughts on vendor SOC report terms that say you cannot share and don't include your auditors as an approved group(e.g. AWS)?
A: That’s frustrating, what’s the point?
Q: With these type challenges does it make sense to require the specific functions a vendor must include in their SOC 2 to help standardize requirements?
A: This would be more like ISO 27001, where the control descriptions are specified. There is certainly market demand for that.
Q: Should external auditors (as 3rd party vendor collecting company’s data) have SOC reports and share with the client?
A: If you are sharing corporate confidential or sensitive information with a third party they should be subject to some type of review. A SOC 2 might not be applicable if the third party does not provide a specific software system. SOC for Cybersecurity is an audit report that looks at the overall cybersecurity controls at an enterprise.
Q: You refer to a company's SOC report for the company, but aren’t SOC reports specific to a product or service? When is a SOC for a company in general? Is this Possible? We also get customers asking for our company SOC, our response is that the SOC is not generic to the company but specific to a product or service. Thoughts?
A: Both are right, kind of. The report is an attestation that controls are in place, and applies to both technology and governance. Every report has a section on the scope that speaks specifically to which components of the business and technology are covered by the report. For example, if you want to use AWS S3, your secure usage of that service will depend on both whether the technical encryption features work as intended, and whether AWS runs a competent security management program, including hiring trustworthy employees and protecting their credentials that can access customer data. The encryption part is product-specific, but the employee security is at the AWS level. A given SOC 2 report will include both. If you get the customer the SOC report that covers the products they intend to use, you will always be right. For companies that do not offer a specific software product, SOC for Cybersecurity is an option.
Q: Triangulate: vendors tend to refuse to provide any additional documentation as they say it has been tested within their SOC 2.
A: This is the core incentive problem in trust building today. Vendors want to answer questions once, but customers need their own view of the vendor’s controls, and one size does not fit all. Answering questionnaires is painful, so neither side wants to do the legwork. The high cost and friction turn it into a leverage issue between the customer and the vendor. We built Conveyor to radically reduce the cost of translating vendor data into usable, actionable assessments for customers.
Q: With so many subservice relationships, how far down the rabbit hole do we need to go for oversight of 4th and 5th parties?
A: For knowing who has access of PII, all the way to the end. For security risk, there’s some reasonable depth but at some point it stops being signal and starts being noise. How much risk do you have from a marginal vendor vs AWS or GCP? How much risk do you reduce by going deep on those linkages? I don’t know.
Q: We are wanting to do business with a vendor and they have the SOC in process. What’s the compensatory doc can we ask for?
A SOC 2 Type 1 report, if available. A previously completed security questionnaire, if they have one available. If they can’t produce anything, you may just have to accept they are going to be inherently high risk, and adjust based on your use case for that vendor. Make the vendor agree in a contract to a date for having an audit completed. Ask the vendor for proof of a signed engagement letter with a CPA firm who is going to complete the audit.
Q: Are Bridge letters applicable to SOC 2 reports? I thought a Bridge letter was only applicable to a SOC 1?
A: Yes, we commonly see bridge letters for SOC 2 Type 2 reports when a customer wants assurance today that the information security program is still operating with no material changes or incidents, since the last report period. So if the last report was issued in January and it’s August now, a customer may ask for a bridge letter to ensure things are materially unchanged since then.
Q: Have you encountered a vendor with a “passable” SOC 2 report but it was identified as an untrustworthy representation?
A: It’s not an industry secret that quality varies across SOC 2 reports, control descriptions, test descriptions, and what an auditor will accept without an exception or a qualified opinion. This again relates to the SSAE22 changes. If the vendor is not being clear or you can’t tell if the auditor’s test has integrity, that often needs to be followed up on.
Q: Do you see more companies doing a SOC2+ where the + adds another framework like HITRUST.
A: We have seen a small percentage of reports include these. Ultimately it makes the report very unwieldy to read. Some reports will use Section V (Additional Information from Management) to provide an un-audited mapping between the SOC 2 controls that are in place and the ISO 27001 Annex A controls to demonstrate mature coverage of a control baseline.
