So you have built a Software-as-a-Service (SaaS) application on top of AWS or another infrastructure-as-a-service provider. It’s likely one of the reasons you did so was to leverage the AWS SOC 2 compliant infrastructure. Service organizations like AWS receive SOC 2 reports to demonstrate to stakeholders such as investors and clients that the AWS infrastructure is secure and available. In addition, users of AWS want to know that AWS’ controls are suitably designed and operating effectively. Leveraging the AWS SOC 2 to create your own SOC 2 compliant application is common amongst our clients.
Occasionally, we get asked by our clients,
“AWS already has a SOC 2, do we need our own SOC 2 as well?”
The answer is it depends on your clients and stakeholders. Just because AWS is responsible for some of the controls to meet the SOC 2 criteria, doesn’t mean that your company is not responsible for other controls to meet the SOC 2 criteria. If your clients have savvy auditors, they will also ask for assurance that the controls that are your company’s responsibility are designed and operating effectively.
If you build your application on top of AWS or Azure, your company’s SOC 2 will not include the controls that are AWS’ or Azure’s responsibility. Those are carved out of the report and the report only covers the controls your SaaS company has in place to meet the applicable SOC 2 Trust Services Criteria.
Over the years we have come across a few SaaS companies that have gotten SOC 2 audits before clients insisted, but those are usually when the company is in an industry that is highly regulated, such as the financial industry. Most of our clients are contractually bound or required to have a SOC 2 report.
In short, you can try giving the AWS SOC 2, where requested, in lieu of your own. If it makes the security related questions stop, then good job. If not, then consider getting your own SOC 2 report.
Do We Save on SOC 2 Compliance by Utilizing AWS?
AWS is compliant with just about every standard and regulation you can think of. Using AWS or another provider for your IaaS is a great way to leverage another service organization’s controls to build a SOC 2 compliant application. Because you have utilized AWS, the number of applicable SOC 2 controls covered in your report will be less than if you were responsible for those controls yourself. A good audit firm will pass along the time savings associated with testing fewer controls and you should receive a savings on fees for your SOC 2 report.
If you have other subservice providers that are required to meet some of the SOC 2 criteria as they relate to your SaaS, then those may be carved out of the report as well so that the only controls that are included, are those that are your own SaaS company’s responsibility as they relate to the applicable SOC 2 criteria.
What is a Service Organization vs. a Subservice Organization?
What is a Service Organization?
The AICPA defines a service organization as “The entity (or segment of an entity) that provides services to a user organization that are part of the user organization’s information system.”
What is a Subservice Organization?
The AICPA defines a subservice organization as “a service organization used by another service organization to perform some of the services provided to user entities that are likely to be relevant to those user entities’ internal control over financial reporting.” You could also think of subservice organizations as the entities that service organizations outsource some of their operations to.
An example is a company that offers its clients a SaaS solution that is hosted by a infrastructure-as-a-service (IaaS) provider, which provides physical security, environmental control, and monitoring services for the SaaS company. In this case, the SaaS company is the service organization and the IaaS is the subservice organization.
What is a Carve-Out Report?
See our previous article covering carve-out vs. inclusive SOC reports.
The carve-out audit method allows a service organization to describe services performed by a subservice organization within its system description, but excludes the subservice organization’s controls within the service organization’s SOC 2 report. While this approach excludes subservice organizations’ controls, the service organization is required to note (within its description of its “system”) the controls used to effectively monitor the subservice organization.
Monitoring Subservice Organizations
One of the recent updates provided within the AICPA’s SSAE 18 omnibus guidance includes additional monitoring of subservice organizations. See our previous article related to SSAE 18 and monitoring subservice organizations.
Service organizations should ensure they have monitoring controls for subservice organizations in place. The monitoring should include obtaining SOC 1 and SOC 2 reports from subservice organizations and reviewing the controls and results of control testing in the reports.
If a SOC report is not available from a subservice organization, reviews could include reviewing and reconciling output reports, holding discussions with the subservice organization, site visits to the subservice organization, and testing controls at the subservice organization by members of the service organization’s internal audit function, etc.
It is customary for SaaS companies to use subservice organizations such as Amazon AWS as an IaaS provider. In these cases the SaaS company has outsourced the performance of certain controls to a subservice provider. The controls outsourced to AWS may also address some of the SOC 2 criteria. In that case, the service organization (SaaS company) should monitor the subservice organization to ensure that they are performing the controls related to SOC 2 requirements consistently. This can be accomplished by reviewing AWS’ SOC 2 report and the relevant areas to your SaaS service.
The controls needed to meet the SOC 2 requirements that are your company’s responsibility should be included within a separate SOC 2 report. Please contact us at Linford & Company if you would like to discuss your adoption of a subservice organization and the impact that might have on the scope and fees associated with your SOC 2 report.