Interview with a SOC 2 auditor: A basic guide to SOC 2 requirements
If you’re a service organization that deals with users’ confidential information, getting a SOC 2 report isn’t longer an option but a responsibility.
First, SOC 2 reports help you mitigate the risks associated with security issues.
Second, many clients request SOC 2 compliance before doing business with any company.
In a world where cybercrime is rising, SOC 2 reports can position your company as an organization that’s ethical, trustworthy, and reliable.
The question is: How can you get a SOC 2 report?
To answer that question, we interviewed K.C. Fikes, Data Analytics Practice Lead at The Cadence Group Senior Manager, Moss Adams.
We asked him six questions that’ll help you better understand SOC 2 reports and prepare your organization for the audit process.
1. What is a SOC 2 report?
“Controls mapped to the Trust Service Criteria, which support the application/platform/product, have been designed and have/have not operated for the period under review. The report explains the quality and the results of the controls. This affects whether there’s an unqualified opinion (meaning no exceptions) or a qualified opinion (some exceptions).”
In other words, SOC 2 is an attestation report that aims to analyze the operational effectiveness of service organizations’ security controls in terms of the five Trust Principles defined by the AICPA.
The word “attestation” means “evidence or proof of something.”
This means that an external auditor must come into your organization to collate evidence that proves your security controls are working properly.
If the right controls are properly mapped to the TSC and are operating effectively, the auditor issues a SOC 2 report likely with an unqualified (clean) opinion.
2. What’s different about SOC 2 compared to other security standards, such as ISO 27001?
As you may know, there are different examinations an organization can get to ensure they have the right security practices in place, including SOC 1, SOC 2, SOC 3, and, of course, ISO 27001.
So, how can you differentiate one from another? More importantly, how can you choose the right examination for your organization?
According to Fike, some of the main differences between SOC 2 and ISO 27001 include:
- “SOC is a report of controls as they are mapped to the Trust Service Criteria whereas an ISO is a certification that the 27001 standard has been adopted/implemented by an organization.”
- “ISO is very focused around the ISMS (Information Security Management Systems) and you get a certification, whereas with SOC 2 you get a report.”
- “SOC 2 is primarily targeted for U.S.-based customers, whereas ISO is widely known in the EU.”
To get a more thorough explanation of these differences, we suggest you read our complete guide, “Should you get a SOC 2 report or ISO 27001 certification?”
3. Could you give a brief walkthrough of what you typically do when a company hires you to conduct a SOC 2 audit?
Now that you understand the basics about SOC 2 reports, the question becomes: What does an auditor look for during the audit process?
In the words of Fikes:
“Assuming you’re SOC 2 Type II, we’ll come in a couple of weeks before the period of review ends. We’ll do a kickoff and talk to the key players and request populations (e.g., each instance of some sort of technology function operating, like a software change or security monitoring software logs).
“From the populations, we’ll sample some of them to see if the internal control was working. For example, we might sample 10 of the 100 software changes during the review period and see if they were peer-reviewed. We test each sample against each control. Once we’re done assessing, and if everything checks out well, then we’re done. We go and write the report.
“If we sampled something and didn’t meet the attribute of a control, we go to the company and see what happened. We tell the client that we’re missing something and look for any evidence that proves this sample meets controls. Then, we’ll look at the sample that didn’t pass, and we’ll potentially expand the samples to analyze whether it was just an outlier or a systemic issue.
“If it was an outlier, we note an exception. If it wasn’t an outlier, we might go so far as to say it was a failure of the control. Our reports would note these exceptions and failures.”
4. What are the requirements for an unqualified opinion for a SOC 2 report?
“We have controls mapped to Trust Service Criteria. Are those controls operating effectively during the period of review? If there are exceptions, it could lead to a qualified opinion. Depending on the nature and type of exception, a control can fail which could lead to a TSC failure. If all the controls are operating effectively during the period of review, then you get an unqualified opinion for a SOC 2 report.”
But what does an “unqualified opinion” actually mean?
It means the controls the auditor tested as part of the report worked properly operated effectively during the SOC 2 examination, and your clients can rely on your services.
This doesn’t mean there weren’t any issues, though.
Suppose the auditor found control issues during the audit, and you get an unqualified opinion. In that case, it means the auditor (and you) were able to fix those issues and mitigate any risk associated with them.
If you can’t fix control issues presented during the audit, the auditor will present a qualified opinion, which means the SOC report isn’t fully reliable.
5. What are trust services criteria, and what are trust services categories?
As we mentioned earlier, SOC 2 reports “map” a service provider’s controls according to the five Trust Principles defined by the AICPA.
These principles, working together, help you protect your clients’ confidential data in the most effective way possible.
What are these principles?
Fikes outlined The set of principles/criteria that cover internal controls as follows:
- Security: All reports must have this.
- Availability: How the organization keeps the app/platform up and running accessible.
- Confidentiality: Protects customer data. That is, how we collect it/edit/delete it.
- Processing integrity: Data should be processed completely, accurately, and valid.
- Privacy: How you protect personal identifiable information (PII) and what the app/platform captures/holds/disposes of, as well as who has access to it.
For explanatory purposes, let’s cover these principles more in-depth:
- Security: Involves all the processes and controls you have in place to restrict unauthorized access to your information (e.g., access controls and IT security software, like two-factor authentication and web application firewalls)
- Availability: Refers to the controls that help you provide a reliable service and ensure it can perform its main objective consistently (e.g., disaster recovery, back-ups, and business continuity planning)
- Confidentiality: Considers all the controls that protect clients’ confidential information (e.g., firewalls, permission levels, and top-grade encryption)
- Processing integrity: Includes the operations that ensure your systems can process information in a valid, accurate, and timely way (e.g., a customer places an order on your site and gets the product on time and at the right address)
- Privacy: Controls and security standards that help you handle customers’ sensitive information privately (e.g., security policies and AICPA’s privacy principles)
Depending on the industry, service type, customer needs, and unique situation, an organization’s controls may need to meet different principles.
That said, all organizations must comply with the “Security” principle, as it’s the only requirement by the AICPA.
6. Can you give a few examples of how the SOC 2 requirements can adapt to each company’s unique situation?
Again, SOC 2 requirements differ depending on the specific situation of your organization.
To better explain this point, Fike provided a few examples of these variations:
“SOC 2 provides flexibility in how a control can be met as well as flexibility on what is in and out of scope. For example, there’s control around the physical security of data, but if all of your data is in the cloud, your cloud infrastructure provider can help you meet this requirement.
“Another example: If you have two instances of cloud providers, but only one actually supports your software and customer data, you can put one of your cloud instances out of scope. SOC 2 and us, as auditors, try to understand the unique environments of each company and adjust the scope accordingly.”
Ready to become SOC 2 compliant?
SOC 2 reports might seem complicated at first glance, but they’re relatively simple once you understand a few key concepts.
Hopefully, the information provided in this interview can help you prepare for your own audit and be more comfortable with this type of report.
If you need more guidance on SOC 2 audits, Secureframe might be able to help.
We help service organizations streamline their SOC compliance processes more efficiently. To get a better understanding of our process, we suggest you read our product overview page.