A customer request for “SOC 2 security assurance” is not automatically a request for one penetration-test certificate. SOC 2 reporting evaluates controls relevant to selected Trust Services Criteria over a defined system and period; the organisation and its auditor determine the evidence required.

External penetration testing can support risk assessment, control monitoring, change or vulnerability-management processes and remediation evidence. It does not by itself establish SOC 2 conformity, replace the service auditor or prove that every control operated throughout the period.

Start by identifying the organisation-defined control that commissions, reviews and responds to technical testing. The evidence should show not only that a vendor produced a report, but that the system boundary was controlled, relevant results reached accountable owners, exceptions were governed and remediation was verified where required. This turns the engagement into evidence of an operating process rather than a detached sales artefact.

Clarify what the customer is requesting

Ask whether the customer wants a current SOC 2 report, bridge information, a pentest executive summary, remediation status or contractual confirmation. These are different disclosures.

Route requests through security, compliance, legal and account owners. Do not send a confidential technical report merely because a customer used the phrase SOC 2.

  • Requested report type and period.
  • Relevant product or system.
  • Permitted disclosure audience.
  • Confidentiality and NDA.

Place pentesting in the control system

Document which risk, policy and control activities the assessment supports: external exposure review, secure release, vulnerability management, change assurance or independent monitoring.

The mapping should reflect the organisation’s actual control design. Do not retrofit generic control language after the test.

  • Risk assessment linkage.
  • Control owner and frequency.
  • Trigger and system boundary.
  • Expected remediation and oversight.

Define the assessed system boundary

Align applications, APIs, mobile clients, environments, infrastructure interfaces, vendors and data flows with the relevant SOC 2 system description and internal inventory.

Record exclusions and shared responsibilities. A pentest of one public app cannot support claims about unrelated services or the full organisation.

  • Products and components.
  • Production and test environments.
  • Third parties and subservice organisations.
  • Relevant data and trust boundaries.

Use risk-based scope and timing

Schedule testing according to exposure, material change, customer dependence and control commitments. Annual cadence may be a policy choice, but change-triggered testing can also be important.

Plan remediation and retest within the evidence period or document open risk and management action accurately.

  • External exposure and criticality.
  • Major release or architecture change.
  • Control-defined frequency.
  • Evidence-period and customer timing.

Preserve authorization and provider evidence

Retain the approved SOW, rules of engagement, target baseline, named provider, competence review, conflict assessment and subcontractor disclosures.

This evidence shows the work was authorised, independent as required and performed against a controlled scope.

  • Vendor selection record.
  • Independence and conflicts.
  • Signed scope and rules.
  • Assigned team and dates.

Retain readiness and execution evidence

Keep approved accounts, environment or build identifiers, test windows, change log, coverage matrix and material constraints. Avoid retaining secrets longer than needed.

Execution evidence should demonstrate that planned work occurred without requiring an auditor or customer to receive raw exploit data.

  • Release and environment baseline.
  • Role and tenant coverage.
  • Completed and constrained areas.
  • Critical escalation records.

Retain decision-ready reports securely

Keep the final executive and technical reports with controlled access, integrity and retention. Track versions and factual-review disposition.

Provide customers only the minimum authorised artefact. A scoped executive summary or assurance letter may be appropriate, but it must preserve limitations.

  • Final approved report versions.
  • Distribution and access log.
  • Coverage and limitation statement.
  • Customer-safe summary where approved.

Show remediation governance

Link each accepted finding to owner, target date, risk decision and remediation evidence. Preserve exceptions and approvals.

The goal is not to hide findings before an examination. It is to show a controlled process that evaluates and treats identified risk.

  • Ticket or risk-record linkage.
  • Accountable owner.
  • Due date and priority.
  • Formal exception or acceptance.

Use independent retest evidence

Retesting records the fixed build, steps, result, date and residual status. Keep the original finding history rather than overwriting it.

For systemic controls, test representative variants and document remaining scope. A developer statement alone is not independent closure.

  • Fixed, partial, not fixed or cannot verify.
  • Build and environment.
  • Related-path checks.
  • Final closure artefact.

Connect evidence to control operation

Maintain evidence that the control owner reviewed results, assigned action, monitored overdue items and reported material issues through governance.

Technical testing without management response may not demonstrate the intended control process. Preserve meeting or workflow evidence proportionately.

  • Owner review.
  • Risk committee or governance escalation.
  • Exception monitoring.
  • Control performance review.

Avoid unsupported assurance language

Do not say the pentest makes the platform SOC 2 compliant or guarantees security. SOC 2 is an attestation engagement performed by an independent licensed CPA firm under applicable AICPA standards.

Any customer communication should identify test date, scope and limitations and distinguish report issuance from technical remediation status.

  • No certification claim.
  • No zero-vulnerability claim.
  • No scope expansion by implication.
  • Clear point-in-time limitations.

Coordinate with the service auditor

Provide the control mapping and evidence index early enough for the auditor to assess relevance and sufficiency. The auditor may request samples or clarification.

Do not let the pentest provider decide audit sufficiency. Security, compliance and the service auditor retain their distinct responsibilities.

  1. Map the assessment to actual controls.
  2. Index scope, execution and remediation evidence.
  3. Restrict disclosure to authorised recipients.
  4. Resolve auditor questions without overstating assurance.

Use the official AICPA SOC resources for SOC reporting context and NIST SP 800-115 for assessment evidence and process. Coordinate the actual examination with the organisation’s service auditor.

Retain evidence of both testing and response

The useful assurance story is not that a vendor issued a clean certificate. It is that risk-based independent testing occurred, coverage and limitations were understood, and management governed remediation.

WIMD structures the technical evidence chain so compliance teams and auditors can evaluate it without turning a point-in-time test into an unsupported claim.

Keep the evidence index current through the examination period and record later changes or reopened findings. That chronology helps reviewers distinguish the original assessment result from subsequent remediation and management decisions.