Penetration Tests and SOC 2: Preference, Tradition, or Requirement?

TLDR; Penetration tests are technically not a requirement for SOC 2 compliance. However, to maximize value from your SOC 2 attestation, you should consider other relevant factors such as expectations from customers, prospects, and auditors (tradition), your organizational context, and your risk mitigation strategy (preference) when selecting and implementing control activities like penetration tests. 

As a program manager in the Governance, Risk, and Compliance (GRC) team at Drata, I often answer inquiries from customers and prospects. A recent question that stood out was: “Is a penetration test a SOC 2 requirement?” This question came from a new customer who, prior to choosing us, was discouraged from conducting a penetration test for their SOC 2 audit by a Drata competitor, because “it wasn’t mandatory.”  

After choosing Drata for their continuous compliance monitoring, the customer wanted to know whether a penetration test was a SOC 2 requirement and whether they should consider conducting one during their SOC 2 observation window, so they requested Drata’s GRC team’s advice. 

Those who know me know that I get excited when I receive questions about compliance that don’t have a simple yes or no answer. So, I took this as an opportunity to educate and guide the customer to help them make an informed decision. I wanted to give them an additional perspective, so they could consider other factors beyond the minimum requirements.

Preference, Tradition, or Requirement?

One of the most challenging things about the GRC field is that it requires significant professional judgment. To add to the complexity, professional judgment is by nature subjective and influenced by individual biases, experience, and expertise. 

A decision-making technique I like to use is: Preference, Tradition, or Requirement? 

Since my days of working in public accounting, I’ve used this mental model in situations that require professional judgment to evaluate problems objectively and thoroughly. 

When it comes to compliance, requirements are usually clear-cut. An activity is either a mandatory requirement, or it is not. Sometimes the compliance requirement can be a broad objective, and the organization decides how to implement activities to meet that objective based on their preferences. Another consideration is tradition, such as industry best practices and implied requirements based on expectations from interested parties. Sometimes a specific activity or problem falls neatly into one of the categories: it’s very clear whether it’s preference, tradition, or requirement. More often than not, however, the lines are rather blurry, so it is important to consider all three. 

When responding to this Drata customer’s question about penetration testing requirements for SOC 2, I used this mental model to facilitate discussion and provide them with valuable information for their decision. 

So, when it comes to SOC 2, are penetration tests considered preference, tradition, or requirement? 

Requirements: What Does the Governing Body Say?

SOC 2 compliance, governed by the American Institute of CPAs (AICPA), does not explicitly mandate any control activities. Instead, it requires organizations to design and implement controls to mitigate risks based on SOC 2 trust services criteria, which are outcomes that an organization’s controls should ordinarily meet to achieve their objectives. 

The AICPA provides guidelines but allows flexibility in how organizations meet these criteria. I have previously written an article explaining the trust services criteria and the most recent guidelines from the AICPA. You can check it out here. 

Penetration tests are often associated with trust services criterion CC 4.1, which reads “The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.”  

Penetration tests are explicitly discussed in the following point of focus associated with this criterion:

Considers Different Types of Ongoing and Separate Evaluations — Management uses a variety of ongoing and separate risk and control evaluations to determine whether internal controls are present and functioning. Depending on the entity’s objectives, such risk and control evaluations may include first- and second-line monitoring and control testing, internal audit assessments, compliance assessments, resilience assessments, vulnerability scans, security assessment, penetration testing, and third-party assessments.

But, what does this mean? Are they required?

No, they are not. The premise of SOC 2 is that your organization must assess the risks that affect the achievement of your company objectives, and implement the necessary controls to reduce those risks to acceptable levels. Based on the results of your risk assessment, your organization must perform evaluations to validate internal controls are implemented and working. Penetration tests are simply one of those possible evaluations you may choose to perform. 

So, we have established they are not a requirement. But what about tradition and preference?

Tradition: External Expectations and the Competitive Landscape

Your SOC 2 report is more than just a record-keeping formality. Because it contains a detailed description of your system, processes, and controls, it is an artifact that your prospects and customers will likely review when conducting due diligence activities and assessing third-party risks. Because of this, a SOC 2 attestation can be a powerful way for you to earn your customers’ trust, gain competitive advantage, win new business, and close deals faster, but only when your approach to SOC 2 is customer-focused. 

What do I mean by customer-focused? When selecting, designing and implementing your controls for your SOC 2 compliance program, consider the expectations of your customers and prospects. For example, if penetration tests have been traditionally included as a control activity in SOC 2 reports by other players in your industry, your customers and prospects may expect you to have conducted them as well. 

Many organizations expect or require (through contractual obligations) their vendors to periodically conduct penetration tests to identify perimeter vulnerabilities and evaluate the potential risks of external cyber threats as a common industry best practice–a tradition, in a sense. 

So, while periodic penetration tests are not technically required, they are a control activity that your customers and prospects may look for and expect when evaluating your SOC 2 report. 

Let’s assume you completed a SOC 2 examination and obtained a SOC 2 Type 2 report for your SaaS application that included the Security trust services category. Since it was not a requirement to meet the trust services criteria, you decided not to implement a penetration test control. If the tradition is that your prospects and customers in your industry expect this control activity to be conducted by their vendors, consider what could happen as they review your SOC 2 report:

• You are asked to complete lengthy security questionnaires or provide additional artifacts for your customers and prospects as they perform their periodic third-party risk assessment.  

• A prospect with strict due diligence requirements demands that you complete an ad-hoc penetration test under a tight deadline as a prerequisite to close a deal.

• In competitive deals, your prospects select a different vendor who used their security controls, including their periodic penetration tests, as a differentiator.

Additionally, you should consider expectations from the other external stakeholder: the auditor. 

It is the auditor’s responsibility to evaluate your controls, including the sufficiency in the selection of controls in regards to how they mitigate your organization’s risks, their design and  implementation and, oftentimes, their operating effectiveness.  

If you decide not to conduct penetration tests, as the control activity is traditionally expected, auditors will likely scrutinize your decision-making process and assess your selection of alternative evaluations against your risk assessment and your company’s environment to validate risks are appropriately mitigated. Remember: while penetration tests are not technically a requirement to meet trust services criterion CC4.1, the onus is on you to demonstrate how your selected controls are sufficient to mitigate risks based on this criterion. 

Therefore, as penetration tests have become common practice, the decision on whether to perform periodic penetration tests for your SOC 2 compliance program should also take into account the expectations of external parties like your customers, prospects, and auditors.

Preference: Organizational Context and Risk Mitigation Strategy

When it comes to SOC 2 compliance, you can choose your own controls to meet your unique objectives based on the trust services criteria. This flexibility allows your organization to customize your approach to security controls based on your specific risks, resources, and strategic goals. 

For some organizations, the preference might lean towards comprehensive penetration testing as a proactive measure to ensure robust security. For others, particularly smaller organizations with limited resources, the preference might be towards alternative evaluations such as vulnerability scanning, regular code reviews, red-team exercises, and dynamic application security testing (DAST), to name a few. 

Even if you do select periodic penetration testing as one of your control activities, the SOC 2 trust services criteria gives you flexibility on how to implement the control, such as the frequency (annual or more frequently), type (black-box or external vs. white-box or internal penetration testing), scope (specific web applications, network, client-side penetration testing), etc. 

Ultimately, the implementation of control activities is aimed at reducing risks to an acceptable level, and that risk mitigation strategy needs to take into account your unique organizational goals, available resources, and competing priorities.

SOC 2 provides an opportunity to use compliance to add value beyond a check-the-box exercise by allowing you to tailor control activities based on your unique needs to improve your overall security posture. The decision on whether to perform periodic tests, and the implementation of the control activity, should take into account your organizational context and your preferred risk mitigation strategies.

The Takeaway

While penetration tests are not explicitly required for SOC 2 compliance, as you consider whether or not to implement the control activity, you should evaluate other factors beyond just meeting the minimum requirements. 

The SOC 2 attestation process can be more than a check-the-box exercise. It can be an opportunity to demonstrate your commitment to security, earn customer trust, and differentiate your business in a competitive market. However, to achieve that, you must consider the expectations from your customers, prospects, and auditors when selecting, designing and implementing control activities such as periodic penetration tests. 

Additionally, you should consider your organizational context including risks, resources, and strategic goals, as well as your overall risk mitigation strategy. 

The decision-making model “preference, tradition or requirement” is a helpful tool to make thorough and objective evaluations and to navigate the nuanced world of security compliance effectively. 

And what about that customer who sparked this discussion? After our conversation, they looked back at the most recent security questionnaires they had completed and, guess what? Virtually all of them included a question about their most recent penetration testing. 

So, they chose to partner with one of Drata’s service partners to conduct an external penetration test during their SOC 2 observation period. They realized that, in this situation, following the “tradition” positioned them favorably with their customers and prospects, showcasing a proactive approach to risk management beyond the minimum compliance requirements.