Home Features When your CSP has an outage, what does it mean for your...

When your CSP has an outage, what does it mean for your SOC 2?

Misconfigured Cloud Storage Services Led to Over 200 Breaches in Past Two Years
SHARE

Last Wednesday (November 25), as people across the world began preparing for a very different 2020 Thanksgiving, a large part of the internet experienced an outage. Amazon Web Services (AWS) announced early Wednesday morning that several of their key services were impaired causing API errors and other issues, including AWS’s ability to update their own status page.

By Jeff Cook, Co-Founder & CFO at ByteChek and AJ Yawn, Co-Founder and CEO at ByteChek

This type of outage may have an impact on your SOC 2 when you use CSPs such as AWS as your infrastructure provider.  In your SOC 2, it all comes down to your commitments and system requirements regarding service delivery to your customers.

What happened?

AWS is the market leader in cloud computing services and this outage demonstrated how many well-known companies were impacted, including Tampa Bay Times, The Philadelphia Inquirer, ByteChek, Glassdoor, Coinbase, and Adobe Spark. The issue appeared to be focused solely on the US-East-1 region and AWS informed The Verge that the issue was only impacting one of the 23 geographic regions.

Fortunately, the issue was resolved within 24 hours and all impacted companies appear to be operating normally. The root cause of the issue was outlined in detail by AWS here. Many CISOs and other executives of the organizations who relied on Amazon’s US-East-1 region are re-evaluating their business continuity and disaster recovery strategies in the cloud. One could argue that this incident makes the case for multi-cloud, or at least a multi-region deployment, but those decisions should be made based on the unique needs of each organization. Something that all CISOs and other executives should be aware of is the impact of this outage on their own SOC 2 reports.

AWS (or similar CSP) and your SOC 2

If you’re hosted on AWS, they very likely are listed in your SOC 2 report as a subservice organization. Hopefully, this doesn’t come as a surprise. The AICPA defines a subservice organization as “a vendor used by a service organization that performs controls that are necessary, in combination with controls at the service organization, to provide reasonable assurance that the service organization’s service commitments and system requirements were achieved.”

In non-accountant language, this means that AWS or any other subservice organization is a critical part of your control environment. Since AWS is a part of your control environment, for SOC 2 this most likely means that they impact the commitments you make to your customers regarding the security and availability of your system or application.

According to Description Criteria 7 Complimentary Subservice Organization Controls (CSOCs) for your system description (section 3), you have to disclose your subservice organization(s) and the criteria they help you meet.  In our example, you would have AWS helping you meet criterion A1.2 by providing controls relevant to backup, recovery, and redundancy.  Think of the cloud provider shared responsibility model. The providers are responsible for the physical security and environmental security of the cloud. If they fail to meet those requirements, you fail to meet criteria in your SOC 2 report associated with physical and environmental security controls.

In the SOC 2 guide, it discusses how if there are CSOCs, your CPA will have to perform procedures to determine if you found any deficiencies in the suitability of design or operating effectiveness of controls at AWS. The CPA will also have to review the AWS SOC report to determine if they agree with your evaluation.

If it is determined that the effect of the outage did not result in you failing to achieve one or more of your service commitments and system requirements, and the CPA agrees with that evaluation, it would not be necessary to modify your SOC 2 opinion on the suitability of design or the operating effectiveness (type 2) of controls because of the effect of the outage.

However, if you believe, and your CPA agrees, that the effect of the outage at AWS resulted in you failing to achieve one or more of your commitments and system requirements, modification of your SOC 2 assertion and the CPA opinion may be necessary (likely a qualified opinion). In that case, the service auditor would include an explanatory paragraph in the SOC 2 report to describe the outage at AWS and its effects on your failure to achieve one or more of your commitments and system requirements.

This incident’s impact on your SOC 2

Keep in mind that every scenario needs to be evaluated on an individual basis, and these types of situations are not always clear as to their effect on your report.  You should always discuss these situations with your CPA or trusted advisor to determine how you are impacted by your subservice organization(s), their responsibilities, and their performance.

Back to this specific outage, let’s say you commit in your SLA that you will deliver 99.99% service availability in any given month to your customers.

Scenario 1:

Since AWS was able to resolve the issue in a timely manner, it’s fair to assume that they have still met their availability commitments in the aggregate with no modifications to their SOC 2 opinion. In that case, you would review their SOC 2 Type 2 report that includes this period of time with the outage.  In your review, you determine that the outage did not materially affect availability, and you still met your commitment to 99.99% uptime. The CPA evaluates your review, looks at the AWS SOC 2 report and agrees with your determination.  No modification of your SOC 2 report is needed.

Scenario 2:

Now, let’s hypothetically determine that this outage did last for a significant amount of time which resulted in AWS not meeting their availability commitments (qualifying their SOC 2). Because of this AWS outage, your service availability for November dipped to 96%.

Due to AWS’s deficiency in their controls to deliver backup and recovery, and they’re being an integral part of your control environment (as a subservice organization) you have determined that you, in turn, have failed to meet your availability commitments to customers. This would potentially cause your SOC 2 opinion to be modified (qualified) with an explanatory paragraph stating the modification is due to failures at AWS.

What about DC4 (system incidents)

In the system description, DC4 discusses incidents and their effect on causing you to not meet your commitments and system requirements.  Similar to what we talked about above, if an incident causes the failure to meet commitments and system requirements, then you would disclose it in DC4 even if it came from the subservice organization.

We usually say a good rule of thumb (not official by any means) is if the organization sent out a press release, mass email, or something else to discuss an incident, then it likely would need disclosure.  With the AWS outage last week, they sent out emails and it was widely publicized, so likely that will require disclosure, even if it doesn’t modify the SOC 2 report.

Conclusion

The lessons learned from this outage will continue to develop as we learn more information and assess internal practices and processes. One lesson that you should immediately consider is how these outages from major cloud service providers impact your compliance efforts, specifically SOC 2 examinations. Security leaders must understand the long-term impacts beyond uptime and downtime of any incident and ensure all levels of management are aware of what this means to the organization.


About the Authors

Jeff Cook brings his information assurance and public accounting experience to ByteChek as a professional with over 9 years of IT audit and consulting experience and over 20 years of experience in public accounting and auditing. Jeff has worked extensively on SOC in addition to providing IT audit support for traditional financial statement audits. Jeff also has a functional knowledge of ISO standards, CSA STAR, C5, FISMA, and FedRAMP.

Jeff is also heavily involved with the AICPA, volunteering with the development of the SOC and CITP programs. Jeff was part of the SOC 2 working group, helping to develop the 2018 version of the AICPA SOC 2 guide, has developed numerous trainings for the AICPA, and is a prior recipient of the AICPA IMTA Standing Ovation Award for outstanding professional achievement in the IT specialization area.

Jeff is a part of the AICPA CITP credential committee, the AICPA IMTA SOC task force, and the AICPA Eye on Technology task force. Jeff is also a Board Member for Community IT, a Washington, DC-based managed service provider for non-profits. Jeff is a prior board member for the Maryland Association of CPAs.

AJ Yawn, Cloud securityAJ Yawn is the Co-Founder and CEO of ByteChek. He is a seasoned cloud security professional that possesses over a decade of senior information security experience with extensive experience managing a wide range of cybersecurity compliance assessments (SOC 2, ISO 27001, HIPAA, etc.) for a variety of SaaS, IaaS, and PaaS providers.

AJ advises startups on cloud security and serves on the Board of Directors of the ISC2 Miami chapter as the Education Chair, he is also a Founding Board member of the National Association of Black Compliance and Risk Management professions, regularly speaks on information security podcasts, events, and he contributes blogs and articles to the information security community including publications such as CISOMag, InfosecMag, HackerNoon, and ISC2.

Disclaimer

Views expressed in this article are personal. The facts, opinions, and language in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same.