SOC 2 penetration testing: when it's required

Does a SOC 2 need a penetration test?

No criterion in the 2017 Trust Services Criteria names penetration testing in its text, so no auditor can point to a single control that says "run a pen test." The term appears in a point of focus under CC4.1, which lists penetration testing, independent certification against established specifications and internal audit assessments as types of evaluation the organization may use to confirm that its controls are present and functioning. CC7.1 goes further on the outcome: the organization must detect configuration changes that introduce new vulnerabilities and exposure to newly discovered vulnerabilities, and its points of focus include vulnerability scanning. Testing supports both criteria, but a SOC 2 does not require a specific test type or a specific provider. The practical question is what evidence your auditor will accept for CC4.1 and CC7.1 given your system in scope.

The testing program belongs to your organization. You decide which applications, APIs, cloud accounts and internal networks fall within the system description, how often tests run, who signs off on findings and how remediation is tracked against the vulnerability process described under CC7.4. A testing partner such as DeployOpen can plan the scope, perform or coordinate tests, and prepare the reports and tracking records that become evidence. The CPA firm that examines you tests whether your controls operated, and it is the only party that issues the SOC 2 report. A pen test report is supporting evidence, not an attestation, and it does not replace the examination.

Whether a test is enough depends on the system in scope and the risk your auditor and customers see. A customer-facing platform that handles sensitive data usually draws more scrutiny than an internal tool, and banks reviewing a vendor often ask for a test report alongside the SOC 2 report, since their third-party risk guidance lists penetration testing reports among the independent assessments they may rely on. Before the examination period starts, confirm with your CPA firm which test types, frequency and report contents it expects, and whether scanning alone will satisfy CC7.1 for your environment. Write those expectations into your control matrix so the evidence you collect matches what the auditor will sample.

How vulnerability scans, penetration tests and internal audits differ

A SOC 2 auditor looks for evidence that security weaknesses are found and fixed, not for one specific type of test. Vulnerability scans, penetration tests, internal audits and independent certifications answer different questions, leave different records and are performed by different people, so each needs its own place in the evidence file.

Vulnerability scanning

Automated scans check systems, cloud configurations and packages for known weaknesses and for configuration changes that open new exposure. They support CC7.1, which asks for detection of new vulnerabilities and configuration drift. Your own security or platform team usually runs them, often on a schedule and after significant changes. The evidence is the scan schedule, scan reports, tickets raised from findings and proof that high-severity items were fixed. Confirm that scans cover every in-scope system, not only the production web tier.

Application and external penetration testing

A penetration test is a human-led attempt to exploit weaknesses in applications, APIs, networks or cloud configurations, often chaining several findings together. It is a practical evaluation under CC4.1, which covers separate evaluations of whether controls work. An independent tester, either a firm or a qualified internal team, performs it against a defined scope and rules of engagement. The evidence is the test report, the scope letter, retest results and remediation records. Ask whether the tester can show the method, which NIST SP 800-115 describes for planning, execution and analysis.

Internal audit assessment

Internal audit checks whether controls exist, are designed sensibly and operate as described, and it reports gaps to management and the board. Under CC4.1 it counts as a separate evaluation, though it is not a technical test. Staff independent of the control owners perform it, using a documented plan, sampling and workpapers. The evidence is the audit plan, workpapers, findings and management's responses. For a small company, check that the reviewer is genuinely separate from the people who run the controls.

Independent certification audits

An independent certification, such as an ISO/IEC 27001 certificate issued by an accredited certification body, is a point-in-time evaluation against an established specification. CC4.1 lists independent certification as a type of evaluation, and a bank's third-party review may accept it as evidence. The certifying body, not your team or your implementation partner, decides the outcome. The evidence is the certificate, the scope statement and the audit report. Confirm the certificate's scope covers the same systems your SOC 2 describes, since a certificate for a different boundary will not carry over.

Test reports as customer evidence

Customers and banks read a penetration test report for its scope, date, severity ratings and the status of each finding. The Federal Reserve's proposed guide for community banks lists penetration testing reports alongside SOC reports and industry assessments as independent assessments a bank may rely on. Share the executive summary under a non-disclosure agreement and keep the full technical report internal. Check that the report shows retesting, because an unfixed critical finding with no retest date is the most common objection in vendor reviews.

How testing feeds remediation and evidence

This sequence turns a penetration test or vulnerability scan into tracked fixes, retests and records that the CPA firm can examine. Each step produces a named artifact so the trail from finding to closure stays visible during the examination.

Define scope and system boundary
The organization, with its testing provider, sets which systems, applications, APIs, cloud accounts and locations the test covers, and matches that boundary to the system description used for the SOC 2. The owner is usually the security lead, with engineering confirming asset ownership. The step is done when a written scope statement lists in-scope assets, excluded assets, test windows and any subservice organization components that need the provider's permission. Ask the CPA firm whether it expects the test to cover the carved-out or included cloud infrastructure.
Schedule scans and tests
The team sets a recurring vulnerability scanning cadence for production and a separate penetration test for the defined scope, then records both in the change calendar so they do not collide with release freezes. Scan jobs, credentials and rules of engagement are approved in advance and stored with the test plan. The output is a dated test calendar and signed rules of engagement, which show the auditor that testing happens on a planned basis rather than only after an incident.
Triage findings by severity
Once results arrive, the security lead reviews each finding, removes false positives with supporting notes, confirms exploitability where the provider has tested it, and assigns a severity using the organization's own scale. Findings are grouped by system and by the criterion they affect, such as CC7.1 for newly introduced vulnerabilities. The output is a triaged register in which every finding has a status, a severity and a reason for its rating, so later reviewers can follow each decision.
Assign owners and tickets
Each validated finding is assigned to a named engineering or operations owner and logged in the ticketing system with a target set by the organization's own policy. Tickets link back to the test report, the affected asset and the change record that will carry the fix. The step closes when every open finding has an owner and a ticket, which gives the auditor a traceable path from detection to remediation under CC7.4.
Remediate and retest
Owners fix the issue through the normal change process, with peer review and approval recorded before deployment. The security team then retests the specific finding, either through a rescan or a targeted test by the provider, and records the result. The output is a closed ticket that links the change record, the retest evidence and the date of verification. Partial fixes stay open until the retest passes.
Record exceptions and risk acceptance
Where a finding will not be fixed within the planned window, or the fix is not technically feasible, management documents an exception with a compensating control, a business justification and the approver's name. Risk acceptance is signed by someone with authority over the risk, not the engineer who owns the system. The output is a risk acceptance record that the auditor can examine alongside the rest of the register, and that management reviews again when the exception expires.
Compile the evidence package
The compliance lead assembles the final test report, the triaged register, the ticket history, change records, retest results, exception approvals and the scan schedule into one indexed folder for the CPA firm. The reader should be able to trace any finding from its origin to closure. The step is complete when the package matches the population the auditor sampled from, and the organization can state which findings remain open at the report date.
Hand over to the auditor
The organization gives the evidence package to the CPA firm as part of fieldwork, answers questions about scope and exceptions, and confirms that the records reflect what the system actually did during the examination period. The CPA firm alone decides what it tests and what it concludes. The step closes when the auditor has the materials it requested and the open items list has been agreed, with any unresolved findings handled through the report process rather than through informal explanations.

What customers and banks look for in a test report

Customer security teams usually read a penetration test report as evidence that the service was tested by someone competent, against the parts of the system that matter to their data, and that the findings were fixed. They rarely need every technical detail, but they expect enough to judge whether the test was meaningful. A short summary with no scope statement tells them little, and a full technical report they cannot share may not help their own vendor review.

Tester qualifications: Who performed the test, their experience and whether the firm can describe its methodology in writing.
Scope and dates: Which applications, APIs, hosts and environments were in scope, what was excluded, and the start and end dates of testing.
Methodology: Whether the work followed a recognized approach, and whether it included authenticated testing, not only automated scanning.
Findings with severity: Each finding, its severity rating, the affected component and the rating scale used, so the reviewer can see how serious the results were.
Retest status and restrictions: Whether fixes were retested and confirmed, and whether the report is restricted to the client or may be shared under an NDA.

Before sharing, ask the provider whether the report can be given to customers in summary form and whether a retest letter is available.

Which parts of a pen test report the auditor and customers need

This table lists the elements a penetration test report should contain for a SOC 2 examination and explains why each one matters to the CPA firm and to customers. Use it as a checklist before you hand a report to an auditor or a customer's security team, and confirm the specifics with your CPA firm, since the criteria do not prescribe a report format.

Element	Why it matters	What to confirm
Scope and asset list	Shows which systems, applications and networks were tested, so the auditor can match the test to the system in scope under CC4.1 and CC7.1.	Does the list match your SOC 2 system description and the production assets named in your system boundary?
Test window	Dates show whether the test falls inside the period the auditor examines, and whether later changes were tested.	Does the test date fall within the Type 2 observation period, or near the Type 1 date if you have one?
Methodology	Explains how the testing was done, such as whether it was an external, internal or application test, and which standard guided it. NIST SP 800-115 is one commonly cited reference.	Does the report describe the approach in enough detail for the auditor to judge whether the test was suitable for the scope?
Tester independence	Customers and banks assess whether the tester is separate from the team that builds and runs the system. Independence supports the weight the evidence gets.	Who performed the test, what is their relationship to your engineering team, and is their work described in the report?
Findings and severity	Shows what was found and how serious each issue was judged. This is the basis for CC7.1 vulnerability detection and CC7.4 remediation.	Does each finding include a severity rating, affected asset and a clear description, and is the rating scheme explained?
Remediation status	Shows what happened after the test. Open findings without a plan invite exceptions and questions about CC7.4.	Is each finding marked fixed, in progress, or accepted, with dates and owners that match your ticket records?
Retest evidence	Proves that fixes were verified, not just claimed. Auditors and customers look for this before treating a finding as closed.	Does the retest show the original issue is resolved, and is the retest result signed off by the tester?
Risk acceptances	Documents findings the organization chose not to fix, with the reasoning and an approver. Undocumented acceptance is a common gap.	Is each accepted risk approved by management with a rationale, a review date, and compensating controls where relevant?

What changes the cost and effort of testing for SOC 2

Penetration testing cost and effort follow from what is in scope and how often it is tested. The cards below cover the decisions that most change a quote, and each one is worth settling in writing before a tester is engaged.

Systems and applications in scope

Every application, API and supporting service that falls inside the SOC 2 system description is a candidate for testing, and each one adds tester hours. A customer-facing web app with a public API takes more effort than an internal admin console, and authenticated testing with several user roles takes more again. Ask the tester to list each target, its authentication model and its role count in the written scope, since these details drive most of the quote.

Number of environments

Production, staging and any customer-specific or regional deployments may each need testing if they run the in-scope system. Testing a staging copy that differs from production can leave gaps, so teams often ask whether production testing is permitted and under what rules of engagement. Confirm which environments are covered, who approves production testing windows, and whether retesting applies to each one.

Cloud and third-party dependencies

Cloud provider accounts, managed databases, identity providers and other subservice organizations shape what a tester can touch and what the organization must authorize. Cloud providers publish their own rules on which testing is permitted without prior notice, and some activities still require approval. Confirm which dependencies are in scope, which provider permissions apply, and which findings belong to a third party and must be handled through that party's reports.

Scan frequency versus test depth

Automated vulnerability scans run often and cost little to repeat, while a manual penetration test is a bounded engagement with a tester's judgment at its center. Scans support the detection work described under CC7.1, but they do not replace a test that chains weaknesses or tests business logic. Ask whether the quote covers recurring scans, a single annual test, or both, and who runs and reviews each one.

Retest rounds

Findings usually come back to the engineering team for fixes, and a retest confirms that each fix works. The number of retest rounds, whether they are included in the fixed fee, and how long the tester keeps the engagement open all affect total cost. Ask for the retest terms in writing, including how retests are reported and whether the report will show closed findings alongside the original test.

External firm or internal staff

An external firm brings independence and a report customers and banks recognize, and its fee is paid to the firm. Internal staff cost salaries and tooling time, and their work is harder for an outside reader to assess for independence and objectivity. Many organizations combine both, with internal teams running recurring scans and an external firm performing the annual test. Confirm who will sign the test report, what qualifications the testers hold and how they are supervised.

Who owns testing, who performs it, and who attests

The organization owns its controls, its test scope and every remediation decision, even when an outside firm runs the tests. Management decides which systems, applications and cloud accounts fall inside the SOC 2 boundary, approves the rules of engagement and accepts or rejects findings. A penetration testing partner plans and performs the tests, or coordinates them if some work is done by another specialist, and then organizes the output into a report and evidence package. Neither the testing partner nor the readiness consultant issues a SOC 2 report, and neither can state that the organization is SOC 2 compliant. Only the independent CPA firm performing the examination issues the report and its opinion.

Keep the roles separate in writing before testing starts. The engagement letter with the tester should name who approves the scope, who receives findings, who tracks remediation in the ticketing system, and who signs off that a finding is closed. Testers should be independent of the engineers who fix the issues they report, so that a remediation team does not grade its own work. For a small team this may mean a retest by a different engineer or an external party rather than the same person who wrote the patch. Confirm with the tester how retesting is billed and whether it is included in the quoted scope.

The CPA firm will expect to see how test results fit the system description. During fieldwork, the auditor may compare the systems, components and services covered by the tests with what management has described as in scope, and may ask whether any tested asset is missing from the description or from the boundary of the controls. Ask the auditor early which test reports and dates it will accept as evidence, and whether it expects the tester's methodology, scope letter and retest records to be retained. Those answers determine how the testing contract, the evidence folder and the system description should be written.

Questions buyers ask about SOC 2 penetration testing

Is a penetration test mandatory for a SOC 2 report?

No criterion in the 2017 Trust Services Criteria names penetration testing as a requirement. The term appears only in a point of focus under CC4.1, which lists penetration testing among the kinds of separate evaluation an organization may use to confirm that its controls are present and functioning. Points of focus help design and evaluate controls; they are not separate requirements, and not every point of focus has to be addressed. The real question is whether your own evaluation program gives the auditor enough evidence that your security controls work. Many customers and banks still expect a recent penetration test report, so confirm with your auditor and your largest customers which evidence they will accept.

How often should a SOC 2 penetration test be run?

The criteria do not set a frequency. The right cadence depends on how often your system changes, how much you expose to the internet, and what your evaluation program has committed to in its own documentation. Organizations often tie tests to major releases, significant infrastructure changes, and a regular calendar cycle, then record the schedule in their policies. The auditor will test whether you did what you said you would do, so a schedule you cannot keep is worse than a modest one you can. For a Type 2 report, the test dates should fall inside the observation period. Ask your auditor which cadence they expect to see in your description and control matrix.

Are vulnerability scans alone enough for SOC 2?

Scans can satisfy part of the picture, but usually not all of it. CC7.1 covers detection and monitoring for configuration changes that introduce vulnerabilities and for exposure to newly discovered vulnerabilities, and its points of focus include conducting vulnerability scans. A scan finds known issues in a defined scope. A penetration test, by contrast, tries to chain weaknesses and shows what an attacker could reach. Many organizations run scans continuously or weekly and add periodic penetration tests for the CC4.1 evaluation. Document both, track findings to remediation under CC7.4, and confirm with your auditor whether scans alone meet your scope and the expectations of your customers.

What will the auditor sample from penetration testing evidence?

Auditors generally test whether the evaluation happened as described, whether findings were recorded, and whether they were remediated. For a Type 2 report, expect requests for the test reports from within the observation period, the scope and rules of engagement, the tester's qualifications where relevant, the list of findings with severity, and tickets or change records showing fixes and retests. They may select a sample of tests or findings and ask you to trace each one from report to closure. Exceptions usually come from missed tests, findings without owners, or fixes that were never verified. Ask your auditor for their evidence request list early, because sampling methods and required fields vary by firm.

What should a penetration test report contain for a SOC 2 audit?

The report should show what was tested, when, by whom, and how. Auditors and customers look for a defined scope that matches your system description, the test dates, the methodology, the tester's organization and the individuals who performed the work, and a findings section with severity, affected assets and reproduction steps. Each finding should link to a remediation record and a retest result. Vague reports that cannot be matched to a system boundary are difficult to rely on. NIST SP 800-115 describes planning and conducting technical tests, analyzing findings and developing mitigation strategies, and it is a useful reference for what a rigorous report covers. Confirm the exact fields with your auditor and with any bank that reviews your vendor file.

Can our internal security team perform the penetration tests?

Internal staff can perform tests, and CC4.1 allows separate evaluations to be performed by people within the organization. The practical questions are independence, skill and documentation. An auditor will ask whether the testers are sufficiently separated from the teams that built and operate the controls, whether their methods are documented, and whether their work is repeatable. Many organizations use internal staff for routine scanning and engage an outside firm for periodic penetration tests, because an external report carries more weight with customers and banks. An implementation partner can help prepare the test scope, environments and evidence, but the organization owns its controls, and only the independent auditor issues the SOC 2 report.

Who pays for penetration testing and what drives the cost?

The organization pays for penetration testing, whether it buys an external firm's test or staffs its own team. The external fee depends on the size and complexity of the scope, the number of applications, APIs, cloud accounts and networks included, the depth of testing, the number of retests, and the testers' experience. Internal cost comes from staff time, tooling and training. Penetration testing is typically a recurring cost because the system changes, and retests add to it. No standard price applies to every SOC 2, so ask any provider for a written scope and a quote that separates the initial test from retests and remediation support.

How DeployOpen scopes testing and prepares evidence for SOC 2

DeployOpen plans and runs security testing on self-hosted open-source platforms inside your own infrastructure, then documents the results so your team can hand them to the CPA firm. We do not issue SOC 2 reports; the independent CPA firm tests and opines on your controls.

How we scope

Agree in writing which systems, applications, APIs and cloud accounts the penetration test covers before work starts.
Confirm rules of engagement, testing windows, test accounts and the points of contact for production-impacting activity.
Map each test to the criteria it supports, such as CC4.1 evaluations and CC7.1 vulnerability detection, so the scope matches your assurance need.

How we build

Prepare a reproducible test environment that mirrors the production configuration you agree to test, and record its version and state.
Run authenticated and unauthenticated tests, with findings classified by severity and linked to the affected asset and control.
Retest remediated findings and record the before and after results so the closure trail is complete.

How we hand over

Deliver a written test report with methodology, scope, tools used, findings, reproduction steps and recommended remediation.
Provide a remediation tracker that ties each finding to an owner, a due date you set, and the retest result.
Give your CPA firm and your own team a clear evidence index so the testing record can be reviewed without reconstruction.

How we support

Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before testing begins.
Ongoing support, retesting and continuous testing are available as a retainer after the initial engagement.
Ask us to confirm which parts of the evidence your organization must produce itself, and which your CPA firm will request directly.

SOC 2 penetration testing