External security testing evidence for SOC 2 readiness
SOC 2 asks you to show that you identify and fix vulnerabilities in the systems you expose. SecQon produces that evidence for your internet-facing assets: dated scans, the findings with the request that found each one, re-test transcripts, and a mapping from each finding to the SOC 2 criteria it bears on. It does not audit you, certify you, or answer the parts of SOC 2 that nobody can see from outside — and the report says which parts those are.
The problem
Your first SOC 2 audit is on the calendar, and the readiness checklist has a line about vulnerability scanning or penetration testing that nobody on the team owns yet.
You have heard that auditors want to see testing happen regularly, with findings tracked to a fix, and a one-off PDF from last year does not show that.
You do not have a security team, and you need evidence a non-specialist can produce, read and explain.
How SecQon helps
Dated, evidence-backed findings
Every finding carries the evidence we observed and the request that produced it, and every report is dated. Where a re-test reproduced the finding, the transcript is printed beside it. That is the kind of record you can hand to an auditor rather than a summary asking to be trusted.
Mapped to SOC 2 on every report
Each finding carries an OWASP Top 10 category, and every report maps those categories to SOC 2 trust services criteria — for example, access-control findings to CC6.1 and outdated-component findings to CC7.1 and CC6.8. ISO 27001 and PCI DSS mappings are available on request. The mapping is at category level and deliberately under-claims: a finding only maps to controls its category supports.
Gaps named, not hidden
Each framework table splits controls into evidenced, evidenced only in part, and not evidenced. Two OWASP categories — Insecure Design (A04) and Security Logging and Monitoring Failures (A09) — cannot be assessed from outside by anyone, and the report names them on its face instead of leaving a reassuring silence.
Testing that keeps happening
On every paid plan, monitored assets get a daily non-intrusive re-test and a full re-audit every month, so the record shows testing as an ongoing activity. The questionnaire pack reports your test cadence from scans that actually completed, not from the plan you bought.
Testing behind your login
On Growth and above you can store a session so our own checks crawl and test the pages behind your login, where most of an application actually lives, and run Deep scans that include bounded proof-of-exploit for reflected markup injection, SQL injection and SSRF.
What SecQon does not do here
- SecQon is not a SOC 2 audit and does not issue a SOC 2 report. Only an independent auditor can do that, and every SecQon report states that its mapping is not a certification of compliance.
- We test what is reachable from the internet. We cannot see encryption at rest, background checks, security training, access reviews, backups, incident response, internal logging, your development lifecycle, subprocessors, data retention, MFA policy or remediation policy — your auditor will ask for evidence of those from you.
- Automated testing is not a human-led penetration test. We do not test business logic or race conditions. Whether an auditor accepts automated external testing for a given control is their decision; ask them early.
- Six OWASP Top 10 categories have purpose-built tests on every paid scan, A07 is covered only in part, and SSRF (A10) is assessed only where a Deep scan's out-of-band check ran. A04 and A09 cannot be assessed from outside.
The plan we suggest
Growth $149 per month
Teams with a real application, not just a marketing site.
up to 10 verified assets
The checks that matter for this
- Web application pentest
A browser-rendered crawl plus bounded proofs for XSS, SQL injection and SSRF, and an active scanner on the pentest tier.
- Security headers & cookies
Missing or ineffective HSTS, CSP, clickjacking, nosniff and Referrer-Policy headers, plus cookie flags.
- TLS & certificates
Certificate trust and expiry, and whether your server still accepts TLS 1.0 or 1.1.
- API security
Your API’s own schema, read as an outsider: open operations, GraphQL introspection, CORS and leaked stack traces.
Questions people ask
Will SecQon make us SOC 2 compliant?
No. SOC 2 compliance is an auditor's opinion about your controls as a whole. SecQon gives you evidence for one part of it — external vulnerability testing — and names the parts of the framework it cannot evidence.
Which plan do we need for SOC 2?
The written report and the SOC 2 mapping start on Starter. We recommend Growth for a real application: it adds Deep scans, testing behind your login, and a crawl that finds your app's routes. Business adds the full penetration test if your auditor or customers expect one.
Can we send the report straight to our auditor?
Yes. Reports have dated share links you can send to an auditor or a customer. The report includes what the scan performed, what it could not assess, and the evidence behind each finding.
Does the SOC 2 mapping cover every criterion?
No. It maps findings by OWASP category to the criteria those categories bear on, and each table shows which controls are evidenced, evidenced only in part, or not evidenced. Many SOC 2 criteria concern internal processes no external test can see.
Is a SecQon scan a penetration test?
The Business plan and the one-off report include an automated penetration test with real attack payloads for classes like path traversal, OS-command injection and XXE. It is automated, not human-led, and the report says so. It does not test business logic.
Last reviewed on 24 Sep 2026.
See what a scan finds on your own asset
Free for one verified asset, no card needed. Paid plans add the written report, more assets and deeper scans.