SOC 2 Reports and Penetration Tests

Originally published by MJD.

Written by Mike DeKock, CPA.

We get asked a lot about whether penetration testing is required to complete a SOC 2 report. The short version of the answer is “no” - there are no explicit requirements for penetration testing (or any controls) within a SOC 2 report. The longer version is nuanced but generally gets answered by asking a few questions:

Do you have any customer contracts requiring a penetration test? If yes, then it’s required. Granted, that one is easy, but other aspects of the decision aren’t quite as clear. Here are some additional considerations:

• Do you have future relationships that may require it? The process doesn’t happen overnight, so you might consider prioritizing it.
• Do you have other methods to reduce risks to an acceptable level?
• Would it be helpful to have a second set of eyes?
• Could it demonstrate the strength of your security program?

So, a penetration test isn’t required to complete a SOC 2 report, but it is highly advisable. Penetration testing is the most common requirement we hear as the last component to close a deal with an enterprise customer (along with having a SOC 2 report). And it’s generally the first recommendation we make if you want to grow your compliance security program and haven’t done penetration tests before.

‍

What is a penetration test?

A penetration test (or pentest for short) is a type of security test designed to identify vulnerabilities in your computer system, network, or application that an attacker could exploit. By having a third party perform a penetration test, you’ll get an overview of your overall security posture, including vulnerabilities identified, plus detailed replication and remediation suggestions so you can improve your security program.

Risk reduction is the ultimate goal of a penetration test, so it makes sense that it supports SOC 2 reports.

‍

So how do you decide what is necessary for a SOC 2 report?

SOC 2 is actually an adjective that describes the compliance framework and the auditor’s report that details how you protect customer data, intending to help establish trust with your customers. A SOC 2 auditor evaluates the controls you have in place to protect the customer data you process and ensures you are doing what you say you will do.

The American Institute of Certified Public Accountants (AICPA) has developed a set of criteria (the trust services criteria) to evaluate an organization’s controls; they are organized into the following five categories:

• Security
• Availability
• Confidentiality
• Processing Integrity
• Privacy

Security is generally the only category that must be covered in a SOC 2 report, but ultimately the categories covered depend on the types of services you provide. The selected categories define the areas your security program will be audited against, but laws, regulations, and customer requirements determine your organization's requirements. You decide on the policies and procedures you implement to meet those requirements and should tailor your internal controls to your risks and the resources available. So, thinking about it like that, completing penetration tests is an example of a control that can be used to help meet certain requirements in various categories.

A SOC 2 report typically includes a control matrix that maps your controls against the applicable trust services criteria to visualize the key controls you identify as necessary to meet your commitments to the relevant criteria. Each report includes the common criteria (CC) relevant to all five trust services categories, plus any specific criteria for additional categories you select.

The common criteria are organized into nine categories:

• CC1: Control Environment
• CC2: Communication and Information
• CC3: Risk Assessment
• CC4: Monitoring Activities
• CC5: Control Activities
• CC6: Logical and Physical Access Control
• CC7: System Operations
• CC8: Change Management
• CC9: Risk Mitigation.

‍

Within the matrix, those nine categories outline the criteria you are required to evaluate and describe the controls you’ve implemented and consider necessary to meet your objectives. Below is an overview of the specific criteria that may be supported by performing a penetration test. Note: The criteria and requirements included below are not the complete set.

Risk Assessment

• CC3.1: The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives.
• CC3.4: The entity identifies and assesses changes that could significantly impact the system of internal control.

Monitoring Activities

• CC4.1: The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.
• CC4.2: The entity evaluates and communicates internal control deficiencies promptly to those parties responsible for taking corrective action, including senior management and the Board of Directors, as appropriate.

Control Activities

• CC5.1: The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.
• CC5.2: The entity also selects and develops general control activities over technology to support the achievement of objectives.

Logical and Physical Access Controls

• CC6.8: The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity’s objectives.

System Operations

• CC7.1: 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.
• CC7.2: The entity monitors system components and the operation of those components for anomalies indicative of malicious acts, natural disasters, and errors affecting the entity’s ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.
• CC7.3: The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and/ if so, takes actions to prevent or address such failures.

The AICPA provides points of focus for each criterion meant to represent important characteristics of each, but each organization is unique, and the application of any individual control is not universal. So, it’s important to use your judgment when applying the trust services criteria to your organization. However, the illustration does demonstrate the coverage penetration testing can provide for your security program and its importance in achieving effective internal controls.

Admittedly, that was a long-winded way of saying that penetration tests aren’t required to complete a SOC 2 report, but they are a great tool in general on your quest to build a strong security program.

Thanks to our friends at Software Secured for partnering with us on this article. Software Secured is one of our amazing penetration testing partners who share our passion for adding value and enhancing the customer experience.

About the Author

Mike DeKock, CPA

Most people describe me as a passionate, unconventional thinker with a unique talent for simplifying the complex. I have a degree from the University of Iowa, am a licensed CPA, and started my career as a financial statement auditor, where I developed a passion for process improvement and became a subject matter expert in applying the audit and attestation standards. I spent much of my career as a general practitioner, but when I began focusing on SOC reports in 2017, everything became clear, and I discovered the next step in my career path. I started MJD Advisors in 2021 with a niche focus on SOC reports for technology companies, and I hope I never have another job.