Bottom Line Up Front (BLUF):

By design, it is up to individual audit firms (CPA firms) to decide, based upon their understanding of the SOC 2 requirements, whether to mandate vulnerability scans and penetration tests as a necessary part of a service provider’s design of controls to meet the Trust Services Criteria.

Our position, based upon our understanding of the Trust Services Criteria, the SOC 2 Guide, and risk management as a discipline, is as follows:  service providers seeking a successful SOC 2 examination and subsequent SOC 2 report must conduct regular vulnerability scans to meet the intent of CC7.1

Service providers have options in meeting the requirements of CC4.1 related to periodic security assessments and do not necessarily need to obtain an annual penetration test if they engage in other ongoing security assessments (e.g. ISO 27001 certification, Internal Audit, etc.)

Context:

There has been much confusion lately in the SOC 2 market as companies seek to understand the need-to-haves vs. the nice-to-haves when it comes to obtaining a SOC 2 report.  Much of this confusion was brought about by the December 2018 upgrade of the Trust Services Criteria, and associated Point of Focus, intended to align SOC 2 with the 2013 COSO framework.

If you are confused by what this all means, you are in good hands – even among CPA firms (the entities that issue SOC 2 reports), there is debate and disagreement over what the Points of Focus mean, whether controls need to be designed for every Point of Focus, or whether they can be considered general guidelines and nice-to-haves.

According to the SOC 2 Guide, the AICPA’s intent with the Points of Focus were to be helpful guidelines to firms designing controls to meet the spirit of the related Trust Services Criteria and to align the TSC to the COSO 2013 framework.

Before I head down that rabbit hole, which could be its own lengthy blog post that may only actually be appreciated by CPAs debating their doctrine, let’s address the question that is the title of this blog post.

Background:

In many cases, young, high-growth technology companies seeking to achieve SOC 2 compliance at the behest of their clients, prospects, or funding partners may want to do the minimum to design, implement, and operate a right-sized control framework that balances improved security, SOC 2 compliance requirements, and the burden of auditing on a company evolving faster than controls can be put into place.

Whether it’s a cost concern, an inconvenience, or just another project to be avoided, companies are wondering if performing an annual penetration test and/or quarterly vulnerability scans is necessary from a SOC 2 compliance perspective.

Disclaimer: It goes without saying that obtaining an annual penetration test and conducting regular vulnerability scans are considered best practices.  Also, for a definition and write-up on the nuances among security assessments, see my colleague, Ryan Basden’s forthcoming blog on the subject later this month.

Answer:

Like many things in life, there is not a definite answer to the topic in question, but I will 1) attempt to explain why that is and 2) take a stance on the matter and provide a risk-based and standards-based rationale for our position.

1)  Why is there not a definite answer?

Because a SOC 2 report is not a certification, but rather an auditor’s opinion.  Instead of using a defined control set (e.g. ISO 27001 Annex A Controls), SOC 2 specifies criteria for which adequate controls must be designed (often by you or your audit firm, or by working in conjunction with one another.)

This leaves room for interpretation on what controls are needed to meet the criteria. Every auditor may have a different opinion on this.  Enter the new SOC 2 Points of Focus as additional guidance to make way for further debate and confusion among audit firms.

So who is right?  I will let you be the judge of that.  It suffices to say that if you have already selected your audit firm for SOC 2 reporting, it matters less who is right and more what position that CPA firm, or more specifically, that firm partner is taking on the matter.

While the context I give below may give you some intelligent talking points that could sway their stance on the matter, your best bet is to work with your audit firm team to discuss a right-size approach for your company, and perhaps, even a roadmap to maturity.

2)  Taking a Stance

Having read the SOC 2 guide in its entirety, SSAE-18, obtained the little known and relatively obscure ‘Advanced SOC for Service Organization Certificate’ from the AICPA, and consulted several other CPA firms on this matter, as well as my team of security professionals at risk3sixty, we have enough context to form a reasonable risk and standards-based approach to the question dogging us since the beginning of this blog.

3)  Final Side Note

In order to delay the inevitable for another moment, it is fair to note by playing the Devil’s advocate, that nowhere in the SOC 2 Criteria itself is it mandated that firms obtaining their SOC 2 report get a penetration test and/or vulnerability scan.

Technically, you could design controls around the need for penetration testing and vulnerability scanning and still meet the standard.  However, the question then becomes, ”What risk are you not addressing by failing to do penetration testing and vulnerability scanning?”

This is where the auditor opinion matters because audit firms may take a stance that they do not feel comfortable issuing a SOC 2 report (with their firm opinion on it for a company unwilling to obtain a penetration test and do regular vulnerability scans.

And if the audit firm is unwilling to issue a report without controls addressing penetration testing and vulnerability scanning, then you are down a report or in need of a new audit firm.

4)  Our Approach

Risk3sixty has a relatively short answer to the big question of this post.  Even though the SOC 2 criteria do not explicitly require penetration testing and vulnerability scanning, they are specifically mentioned in the Points of Focus, and as a security firm first and a CPA firm second, we cannot envision issuing a SOC 2 report on the information security posture of an organization without adequately addressing the risk associated with misconfiguration and patch management as well as a lack of periodic security assessments.

Related to vulnerability scanning, CC7.1 from the SOC 2 Common Criteria (Security) states that:

“To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.” 

Under this criteria, there is a related point of focus that states:

“The entity conducts vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after any significant change in the environment and takes action to remediate identified deficiencies on a timely basis.” 

Given the risks associated with misconfiguration and patch management, our stance is that firms should engage in quarterly (minimum) vulnerability scanning, whether they are performed internally or by an external party.

Beyond scanning, we advocate for vulnerability management to close high-risk findings from those scans and reduce the associated risks.  This involves a disciplined process with an identified process owner responsible for this lifecycle of vulnerability management.

Related to penetration testing, CC4.1 (COSO Principle 16) states:

”The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.” 

An associated point of focus for CC4.1, related to all engagement utilizing the TSC, states:

“Management uses a variety of different types of ongoing and separate evaluations, including penetration testing, independent certifications made against established specifications (for example, ISO certifications), and internal audit assessments.”

Since there are many types of security assessments, we hold the opinion that a penetration test is not a requirement as long as the entity can demonstrate that another security assessment is being done on a regular basis.  Such options may include but are not limited to Internal Audit, ISO certifications, HIPAA Security and Privacy Assessments, etc.

Summary

Based upon our assessment of the associated risk, acknowledgement of the intent of SOC 2 reporting, and considering the needs of the general reader of the SOC 2 report, vulnerability scans are mandatory to meet CC7.1, whereas penetration tests are not necessarily mandatory to meet CC4.1 so long as there is another periodic security assessment being conducted by the entity seeking to obtain a SOC 2 report.