A SOC 2 report and a pentest do not answer every product question.

SOC 2, penetration testing and business-logic verification overlap. The useful question is whether your existing work establishes the particular promise you need to rely on.

A missing test is a gap to close, not a reason to discard an existing assessment. Reuse relevant evidence. Add the checks needed for the rule and its consequences. No single assessment establishes every possible application behavior.

Sources: AICPA’s SOC 2 reporting guide and OWASP Web Security Testing Guide v4.2: Business Logic Testing. Reviewed 9 October 2026.

Imagine a subscription upgrade that succeeds, times out before the response reaches the client, then runs again on retry. Authentication worked. Both requests were authorized. The customer still paid twice.

Turn that agreement into observations. A successful HTTP response is not enough; inspect charges, subscription state and the operation record.

1. Retry after success

   Send the same operation again. Check that the original outcome returns and the charge count stays at one.

2. Two requests at once

   Race identical operations. Check that concurrent execution cannot create a second charge or a conflicting subscription state.

3. Timeout after payment

   Interrupt the path after the provider accepts payment. Retry and reconcile the recorded payment with the subscription update.

4. Same key, different request

   Reuse an operation key with a different plan or amount. Check the agreed conflict response and that no new charge is created.

5. Retry-window boundary

   Exercise just before, at and after the agreed expiry. Check that retention and cleanup match the promised retry behavior.

These are proposed checks for an illustrative workflow, not executed billing results. They do not cover every billing risk: proration, currency rounding, refunds and provider reconciliation need their own requirements.

Here is a small example you can inspect and rerun. A reservation service must return the original reservation when the same key is retried before 24 elapsed hours. Changing key retention to 12 hours breaks that promise.

Inspect the failing inputs and observations, the revisions and execution provenance, or the instructions to rerun the fixture. The fifth case checks expiry at exactly 24 hours, outside the promised retry window.

For findings in real projects, see the public evidence register. Each case has its own scope; the reservation example is a teaching fixture.

Pick a behavior with a costly failure: duplicate payments, a lost reservation, a cross-tenant read, or a migration that drops records. Fill this out with the person who owns the promise and the engineer who can run the checks.

BUSINESS-RULE EVIDENCE CHECKLIST

Workflow and owner:
Promise, source and who agreed it:
Inputs, boundaries and failure conditions:
State that must change:
State that must remain unchanged:
Existing SOC 2 / pentest / test evidence relevant to this rule:
Missing scenarios and the check for each:
Requirement version, code revision and configuration:
Observed result and a link to the execution:
Untested conditions or conflicting expectations:
Decision needed, owner and next action:
What change would require these checks to run again:

Download the plain-text checklist ↓ · No email required.

If the expected result is disputed, resolve the requirement first. If a result is missing, mark it missing. If the implementation changed after the run, check whether the evidence still applies. Filling the fields does not make the workflow verified.

For a deeper test plan, continue to requirements-based testing or change impact analysis.

Proof connects requirements to code, hazards, checks and retained change records. That gives your team and coding agents a shared account of what must hold and which evidence supports it. Recovered intent still needs the right authority; current code is not automatically the specification.

A focused engagement starts with one component or recurring defect. We agree the behavior and scope, investigate the risky paths, run the relevant checks, and retain the results with their limitations. A finding should point to a violated promise and an inspectable observation. An unresolved product decision stays visible.

The next change should reuse that work: the requirement, regression check and reason behind it remain available, while affected evidence needs to be checked again. This complements your security testing and assurance program. It does not replace a SOC 2 examination or guarantee a clean audit.