SOC 2 Compliance Playbook for Cloud Native

August 19, 2020

Part 2: SOC 2 Type 1 MVP Playbook

Click here to read Part 1: From Monster to Mascot

Of the SOC 2 principles (criteria) of security, availability, process integrity, confidentiality, and privacy, you can choose which principles to include in your SOC 2 audit but security must be included in any MVP SOC 2 audit. Now let’s dig into the high-level roadmap and discuss the key elements required to pass your own SOC 2 audit regardless of where you are on your cloud native or compliance journey

Assess scope and ownership of controls and choose the trust service criteria to include

Make sure you are clear on the shared responsibilities and who owns part or all of each control – make no mistake this is the most crucial step to a successful audit.

Service OwnerSaaSPaaSIaaS
Figure 1: Responsibility Matrix for SOC 2 controls and Audit Evidence Generation

Note the trust service criteria (availability, process integrity, confidentiality, privacy, security, etc.) all have individual controls – the owner in each box in the matrix above would be responsible for producing evidence depending on the scope of the SOC 2 audit. Audit evidence, depending on the control, could include a wide range of test cases, audit logs, documented process and procedures (change management workflows as an example) as well as operational narratives. The IT professional’s goal is to clearly state/prove your organization has met the nature of any required SOC 2 control. In cloud native environments, many of these are joint responsibilities to prove.

Example: Your organization uses AWS to host a SaaS application. As part of your SOC 2 audit, you decided to include availability and confidentiality (in addition to security which is mandatory for non-privacy principled audits). Therefore it is a joint responsibility to produce audit evidence around data and application controls. 

Security in cloud native environments is intrinsically linked to understanding the who and the how of the service owner. Remember – a non-privacy principled SOC 2 audit must include security; all other trust service criteria are optional/dependent on the needs of your stakeholders.

All public CSPs have extensively expanded their offerings in regards to off-the-shelf tools; this is part of their service around compliance, specifically SOC2. This means there is no reason to reinvent the wheel – AWS Cloudtrail, AWS Guard Duty, MS Azure all provide COTS SOC 2 reports. Google Cloud & GSuite have ready-to-download SOC 2 reports as well. 

Perform a gap analysis – remediate when necessary

You’ve mapped out your responsibility control matrix. You’ve established what will be evaluated in your SOC 2 MVP. Now it’s time to perform a gap analysis, see where you have tools and processes in place to meet audit controls and where you do not. Additional investment or adjustments to existing workflows may be required – remediate when necessary. Keep in mind some key factors which will determine the number of times you will cycle through the above steps:

  • Scope – the more trust service criteria (beyond security), the more SOC 2 controls and use cases, which in turn means the production of more audit evidence
  • Current State – are you already leveraging a framework? If you are working with COBIT or CCM from the Cloud Security Alliance, you can likely lean into those. Many times these frameworks are based on industry accepted security standards and regulations; many SOC 2 controls are covered in these frameworks
  • Third parties – the number of third parties you are working with will impact the sizing of evidence; the number of cloud providers, etc. Each control in each trust service criteria must be repeated for each third party

Ready your communication skills – prepare to create analogies to demonstrate compliance in cloud native environments

Many SOC 2 controls are in no way anchored in cloud native concepts or practices. The onus is on the IT professional to demonstrate compliance even when the use case is unfamiliar to the CPA.

Example 1:

Common Criteria 6.x  Implements Boundary Protection Systems – Section 6.x speaks to the logical and physical security aspects of infrastructure. The IT organization needs to be able to demonstrate how you detect and prevent unwanted attacks and access to systems. 

  • If you are working with an auditor who is used to seeing a physical piece of equipment for IDS/IPS, how will you develop test cases to prove the effectiveness of your IDS/IPS solution in a cloud native environment? This is your audit evidence.
  • What type of processes do you have in place to track and monitor file integrity and file access? Who has access to those logs? How can you most clearly show your strategy to an ‘outsider’?

Example 2:

Common Criteria 7.x Conducts Vulnerability Scans – Section 7.x speaks to an organization’s ability to demonstrate vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis, and after any significant change in the environment.

  • How are you going to demonstrate periodic scans if your containers are ephemeral? How do you provide ‘new world’ examples to an auditor who may simply be used to seeing traditional AV?
  • You could show your auditor that your base image source is trusted – that a package manager is in place which removes unix shells, compilers and debuggers. You could show a secrets management system is in place and never part of the base image. You could show all containers are scanned for vulnerabilities at build time in the CI pipeline. But the IT professional needs to create the analogous use cases to ‘traditional’ AV solutions and demonstrate how you not only meet the nature of the control but just may well exceed it. 

Elements of the end product – SOC 2 from an auditor’s perspective

These are the fundamental components of any SOC 2 audit regardless of type 1 or type 2 or the number of trust service criteria

  • The Service Auditor’s report is the CPA’s executive summary
  • The Management assertion is the organization’s executive summary
  • A description of the system – any diagrams, workflows documented, any end-to-end system narrative would be appropriate here
  • Tests of controls and corresponding results – this could volumes of data depending on the scope of the audit
  • Any additional information provided – potentially noting third party attestations and supporting documentation

Just as you, the IT Professional, may not have the appropriate background to perform a detailed analysis of a complex financial statement, the onus is on the IT organization to demonstrate compliance even when the use case is unfamiliar to your auditor. Our auditors are learning, just like our IT staff, about fully cloud native solutions. Be prepared and reduce confusion with clear test cases mapped neatly to SOC 2 controls; show how you are meeting (and ideally exceeding) compliance challenges. Be ready to answer ‘off script’ questions.

A call to action:

My hope is that digging into your compliance journey allows you to enhance communication across teams, and leverage this experience to implement controls as an opportunity to create real value and actually shore up security overall. Ideally this exercise will help you identify gaps and inefficiencies.

Remember that audits are ultimately about proving your capabilities to a semi-technical audience. Make sure those with great communication skills are part of your compliance initiatives and recognize you are likely tackling these SOC 2 criteria now, audit or no audit. Once the perspective shifts from a box checking exercise to proving your dedication to ensuring a secure and compliant environment to your customers, it’s less of a chore and more of a point of pride in ownership.

Related Content:

Webinar: Deciphering SOC 2 Compliance in Cloud-Native Environments

Part 1: From Monster to Mascot