Evidence tied to a control
Connect each relevant finding and retest to the control owner, system boundary, and evidence period it supports.
Security evidence your SOC 2 work can trace
Connect authorized pentest findings and cloud attack-path evidence to your actual systems and controls. Keep every result reproducible, time-bound, owned, and retested after remediation.
Operating model
From system boundary to retested evidence
Start with your control design and auditor’s evidence expectations. Trident supplies technical testing evidence for review; it does not turn a product dashboard into an audit opinion.
01
Define the boundary
Name the in-scope systems, identities, data, controls, examination period, and authorized testing rules.
02
Collect current evidence
Run scoped application and cloud testing, then preserve findings with their source context and timestamps.
03
Map and review
Connect relevant evidence to the organization’s controls with the control owner and auditor’s expectations visible.
04
Fix and retest
Remediate confirmed gaps, replay the proof, and keep both the original and post-fix result in the evidence history.
Evidence
Proof a reviewer can follow
Useful evidence answers what was tested, under which authorization, on which system version, what happened, who owns the control, and whether the fix was retested.
Gaps tied to reachable risk
Prioritize a control gap by the application, identity, cloud, and data path it can open—not by a generic severity label alone.
Reproducible findings
Keep the preconditions, test steps, request, response, impact, and retest result available for technical review.
Evidence history
Record when evidence was produced, which system version it covered, and which change should make it stale.
Application and cloud context
Review web and API behavior alongside cloud identities, trust policies, exposure, and sensitive-data access.
Remediation with a retest
Route the fix to the owning team, preserve the original proof, and verify closure after the change.
Evidence quality
Current enough to trust
Avoid universal control counts and unsupported compliance percentages. The useful measure is whether the evidence is current, scoped, and connected to the control it supports.
Scoped
To your system boundary
Traceable
From control to evidence
Reproducible
For technical review
Retested
After remediation
FAQ
SOC 2 and penetration testing
Does SOC 2 require a penetration test?
The applicable Trust Services Criteria, system description, risks, controls, auditor expectations, and customer commitments determine the evidence needed for a specific SOC 2 examination. A penetration test can support security-control evidence, but organizations should confirm scope and timing with their auditor.
Can Trident issue a SOC 2 report or certify compliance?
No. Trident is a security testing and cloud risk platform. It can help organize technical evidence and remediation work, but an independent licensed CPA firm performs the SOC 2 examination and issues the report.
What SOC 2 evidence can penetration testing support?
Depending on scope, penetration testing can provide evidence about authorization boundaries, externally exposed services, application and API weaknesses, cloud access paths, remediation, and retesting. The evidence must still be mapped to the organization’s actual controls and examination period.
Make the technical evidence easier to review.
See how Trident connects authorized testing, cloud paths, remediation ownership, and retest history for your in-scope systems.