SOC 2 penetration testing: choose a test that informs security

A penetration test provides evidence about exploitable weaknesses in a defined system. Its value depends on what testers examine, how they investigate it, and what engineering does with the findings. A report that omits the product’s important trust boundaries may satisfy an internal deadline while telling you little about security.

For a CTO, the useful question is not simply whether a test has been completed. It is whether the engagement challenges the controls that protect customer data and produces findings the team can reproduce, fix, and verify.

What SOC 2 does—and does not—require

SOC 2 is an attestation report, not a certification. Its criteria are principles-based; they do not impose one universal penetration-test requirement or annual cadence for every organization. Risk, the controls you describe, auditor expectations, and customer contracts determine what testing is appropriate.

Discuss the objective and expected evidence with your auditor before commissioning the engagement. If your documented control promises a particular testing frequency or scope, plan to demonstrate that commitment.

Customer assurance is a separate consideration. A buyer may require an independent application test even when your audit approach does not prescribe one. Establish those expectations early, but do not let a procurement checklist substitute for technical scoping. Neither a SOC 2 report nor a penetration test establishes that a system has no vulnerabilities.

Scope the attack surface, not just the website

Start with the architecture, sensitive data flows, and trust boundaries. OWASP’s threat-modeling guidance offers a useful basis for identifying what could go wrong and where testing should concentrate.

For a multi-tenant SaaS product, testing only the public landing page leaves the important application boundaries unexamined. Give the provider an inventory that includes APIs, background processing, administrative tools, and relevant infrastructure—not just a list of domains.

Specify exclusions and limitations explicitly. An untested mobile client, unavailable role, or inaccessible environment must remain visible in the final report. Scope should also distinguish systems you own from third-party services you cannot authorize testers to attack.

Choose a method that answers your questions

Automated scanning identifies potential weaknesses and supports recurring hygiene. A penetration test adds skilled investigation of exploitability and meaningful attack paths within an authorized scope. Tools are useful; a scanner export relabeled as a penetration test is not equivalent to that investigation.

Black-box testing starts with limited system knowledge. Gray-box testing supplies selected information or access, often including accounts. White-box testing provides deeper visibility, potentially including source code and architecture. These approaches answer different questions rather than forming a simple quality ranking.

For application authorization testing, accounts across several roles and tenants can make investigation more effective. External infrastructure testing alone cannot establish whether authenticated users can cross tenant boundaries.

Evaluate the provider and the deliverables

Ask who will perform the work and whether they have tested comparable architectures. Relevant qualifications support due diligence, but credentials alone do not establish application-specific competence. Request a sanitized sample report and discuss how the team investigates business logic, not just known software vulnerabilities.

Before signing, clarify:

• Which systems, roles, and attack paths are covered, and how effort is allocated.
• What manual investigation supplements automated tooling.
• How urgent findings are communicated before the final report.
• Whether findings include reproducible evidence, affected components, impact, and remediation guidance.
• Whether retesting is included, its time window, and what happens if fixes arrive later.
• How reports, credentials, and captured data are protected and eventually deleted.

Compare proposals on coverage and deliverables, not price alone. A lower quote may represent a narrower engagement rather than equivalent work delivered more efficiently.

Establish safe execution rules

Document authorization and rules of engagement before testing begins. Identify approved hosts, accounts, environments, testing windows, emergency contacts, and stop conditions. Agree whether denial-of-service testing, social engineering, persistence, or data extraction is excluded.

Production testing can expose real configuration issues, but it also creates operational risk. A representative staging environment may be safer, provided differences from production are recorded. Use synthetic tenant data where feasible and agree what evidence is sufficient to prove impact without collecting unnecessary customer information.

Ensure monitoring teams know how to distinguish authorized activity from an unrelated incident. Testing should not become an excuse to disable protective controls without documenting the consequences.

Worked example: a tenant-isolation finding

Consider an illustrative SaaS engagement. Assume the product has two test tenants, ordinary users, tenant administrators, and a support role. The test includes authenticated APIs and export workflows; third-party identity infrastructure is excluded.

A tester discovers that an export endpoint validates login but does not consistently enforce tenant ownership. Using synthetic records, they demonstrate that a user from tenant A can request an export belonging to tenant B.

The finding should identify the endpoint, required privileges, affected workflow, reproducible evidence, and business impact. Engineering traces the problem to a background worker that trusts a tenant identifier supplied by the request.

The fix enforces ownership before scheduling the export and again when retrieving it. Regression tests cover cross-tenant requests and relevant roles. Retesting confirms that the original path is blocked and checks related export paths. The team preserves the original finding, implementation evidence, and retest result; it does not simply mark the ticket “done.”

Turn findings into accountable engineering work

Triage findings using technical severity and business exposure. Consider required privileges, internet exposure, affected data, exploit reliability, and compensating controls. A nominally moderate issue can deserve urgent treatment when it breaks a critical customer boundary.

Assign an owner, target date, and verification method to each finding. Where appropriate, deploy an interim mitigation while preparing the durable fix. Have a designated risk owner approve any accepted residual risk, with reasoning and a review date; engineering silence is not acceptance.

Record the tested product version and environment. A result from before a major authorization redesign cannot describe the new implementation. As a practical recommendation, reassess testing needs after material architectural changes, serious incidents, or new exposure, alongside your established cadence.

Keep evidence useful for auditors and buyers

Retain the agreed scope, rules of engagement, final report, remediation records, retest evidence, and risk decisions. Keep the full report restricted because it may contain sensitive exploit detail.

Prepare a customer-facing summary describing test dates, scope, methodology, limitations, and remediation status without unnecessarily exposing attack instructions. For follow-up questions, read our assurance-review guide.

In Secani, connect the test evidence to the relevant systems, requirements, controls, owners, and review decisions. Track evidence gaps as tasks and preserve human approval of conclusions. This keeps the relationship between what was tested and what changed available for later review.

Before requesting proposals, produce a one-page scope covering trust boundaries, test accounts, exclusions, deliverables, and retesting expectations. That document gives the provider, auditor, and engineering team a shared basis for a test that informs security.