SOC 2 Penetration Testing: Scope, Cost and Report Acceptance

SOC 2 penetration testing should begin with an agreed deliverable: the system being tested, the assessor the recipient will accept, the evidence required, and the work needed after a finding. A price becomes meaningful only after those responsibilities are clear. If an enterprise customer has asked for a pentest report before signing a contract, resolve its acceptance requirements before paying for a test.

Les AICPA describes SOC as assurance services CPAs may provide concerning organizational controls. A technical penetration-test report and a CPA’s SOC examination report are different deliverables. Testing may supply evidence for a security review; buying a testing tool does not purchase a SOC 2 examination or guarantee the recipient’s acceptance.

For a SaaS team, the first useful artifact is a short scope brief that the reviewer can challenge before testing starts. Keep the accepted version with the quote and report so later disagreements can be traced to a concrete decision.

Agree what the reviewer needs before selecting a provider

Ask the auditor or customer security team which system, environment and release the requested assessment should cover. Record the required test dates, authenticated roles, exclusions, assessor qualifications and retest expectations. If an existing control or contract already defines these details, bring that language into the scoping conversation. A vague request for a “SOC 2 pentest” is not a sufficient purchase specification.

Les Trust Services Criteria are criteria for evaluating controls, not a vendor-specific product specification. Map the proposed assessment to your documented controls and obtain the reviewer’s interpretation where needed. Do not copy a tool’s list of vulnerability categories into an audit plan and assume that it establishes the agreed system boundary.

Independence deserves its own question. If the recipient requires an independent third-party assessor, a self-operated software run does not meet that description merely because an AI agent performs the requests. Clarify who conducts the assessment, who reviews the evidence, who signs or takes responsibility for the report, and who answers follow-up questions. Purchase the delivery model that matches those responsibilities.

Scope a SaaS workflow rather than a list of URLs

Consider a fictional customer portal with a browser interface, an API and an administrative console. The customer wants assurance about account separation before allowing employees to use it. A useful brief identifies the deployed release, two dedicated tenant fixtures, ordinary-user and administrator roles, and the workflows that create, read, export and delete synthetic records. The example is a planning model, not a claim that a particular product completed these tests.

A domain alone hides important differences. Two accounts with the same role may be needed to test tenant separation. One administrator account may reach every page while revealing little about ordinary-user restrictions. An API description can help identify operations but still omit a sensitive export route. Write down the security property you need to evaluate and the account context under which it should hold.

Record access prerequisites separately from test results. If a session expires, SSO is unavailable, or required synthetic records do not exist, resolve that limitation before interpreting the affected checks. “Not reached” should remain visible in coverage notes. It should not silently become “tested with no issue found.” This distinction is useful regardless of whether the tester is a person or an automated system.

NIST’s Guide technique pour les tests et l'évaluation de la sécurité de l'information connects planning, testing, analysis and mitigation. Use that separation in your engagement record: the authorized plan, observed results and remediation decision should be distinguishable. Agree permitted methods, traffic limits, stop conditions and the contact for an unexpected operational effect before execution.

Compare the cost of the same completed job

There is no useful price comparison until the unit of delivery is clear. A software subscription, a metered test task and an independently delivered assessment can assign setup, investigation, report review and follow-up to different parties. Ask each supplier to describe those responsibilities before comparing the headline amount.

Build a budget with separate lines for the product or service, access preparation, evidence review, remediation and retesting. Include model or infrastructure charges only where your arrangement actually bills them separately. Keep internal engineering time visible without pretending it is a new supplier charge. This is a budgeting method, not a claim that every assessment incurs every category.

For a one-off customer request, compare the incremental cash required to produce the accepted deliverable. For a continuing testing program, also consider repeat setup, maintenance of test accounts and recurring review. A lower first-run price can be a poor fit if every subsequent release requires rebuilding the workflow. An annual subscription can also be unnecessary when the immediate need is a single externally accepted assessment.

Ask for a scope-matched quote with exclusions. Does it include private API access, multiple roles, tenant checks, reporting, review of disputed findings and one retest? What happens if access fails? Which changes require a new scope or additional usage? These answers make a price interpretable. Avoid converting a credit allowance into a guaranteed number of complete pentests without measured consumption and a stated scope.

Review the evidence before approving the report

OWASP’s reporting guidance treats the report as communication for both executive and technical readers. It recommends documenting scope and limitations, explaining business impact, providing actionable finding details, and protecting sensitive content. It also presents the work as a point-in-time assessment. Use those principles to review the deliverable rather than judging it by its length or appearance.

Choose one finding and follow it backward. Can an engineer identify the acting account, required preconditions, affected resource, request sequence and observed result? Does the evidence show the claimed security-property violation, or only an unexpected status code? A successful response may be an allowed public record or a login page. The report must explain why the observation matters in the agreed application context.

Follow the same finding forward into remediation. Name an owner, a proposed correction and a retest condition. In the fictional tenant example, the retest should check that tenant A can no longer read tenant B’s synthetic record while A can still read its own permitted record. That positive control helps distinguish an authorization correction from a broken feature. It is a recommended test design, not a completed product benchmark.

Control mappings should preserve this evidence trail. A label linking a finding to a control can help a reviewer locate supporting material, but it does not establish that the control operated throughout an examination period. Keep the test dates, deployment identity, unresolved findings and management decisions visible. The compliance owner and reviewer can then assess what the technical evidence supports.

Use the sample report as a buying check

Penligent’s homepage offers a 19-page English sample pentest report with synthetic data and a sign-in or free-account step. It illustrates scope, findings, remediation and retest structure with SOC 2 and ISO/IEC 27001 context. Review that example before deciding whether to evaluate the workflow for your own application. The sample is not a certification or a guarantee of auditor acceptance.

To inspect it, open the homepage section titled “Pentest evidence for your next security review” and choose “Download Sample Pentest Report.” Give the intended recipient the format and proposed scope, then ask what is missing. Resolve the assessor question before treating a self-operated software report as a customer deliverable.

Confirm report-export entitlement, included usage and checkout terms before paying. Access to a sample and access to export your own assessment are separate questions. Begin with a bounded owned target, inspect one result and establish the next useful task before increasing spend. If the recipient requires independent delivery, settle that requirement before choosing software.

Questions to resolve before the engagement

Does purchasing a pentest report complete SOC 2?

No. A pentest report documents technical assessment work. The SOC examination concerns organizational controls and has its own professional responsibilities. Agree how the technical evidence will be used with the reviewer; do not substitute a tool-generated report for the examination.

Should we buy software or an independent assessment?

Start with the recipient’s assessor requirements and your team’s ability to operate and review the workflow. Software can support internal testing, but an independent-assessor requirement calls for an accepted external engagement. A hybrid workflow still needs named responsibility for setup, validation, reporting and follow-up.

How often should testing happen?

Document the cadence required by your controls, contracts, risk assessment and reviewer, and identify changes that trigger another assessment. Specify what a retest covers and when a broader new scope is necessary. Do not inherit an interval from a product’s scheduling feature and present it as your audit requirement.

The purchase is ready when the scope, assessor, evidence and follow-up obligations agree. That gives engineering a test it can operate, finance a cost it can interpret, and the recipient a deliverable it has had the opportunity to assess before the work begins.