SOC 2 Evidence from Web Scans: Templates and Examples

Your auditor does not want promises. They want proof. If you ship fast, the most reliable SOC 2 evidence you can produce is a trail of timestamped web findings that show what a real user could see, what you changed, and when you fixed it. Real-browser and authenticated scans create repeatable artifacts that hold up during sampling and walkthroughs.

This guide shows how to turn continuous web scans into SOC 2 evidence that maps to controls, survives scrutiny, and cuts back-and-forth during audit.

Map web-scan findings to SOC 2 controls

Scans generate signals. SOC 2 expects those signals to map to specific controls so an auditor can see coverage without guessing. Tie each finding to a control family and, when practical, a criterion code.

• Access control (CC6) - Use authenticated scanning to show that private pages are only accessible after sign-in. Example: unauthenticated GET to /admin returns 302 to /login. Authenticated GET with an admin role returns 200. Store the requests, responses, and headers. This supports CC6.1 and CC6.6 on restricting logical access and enforcing authentication.
• Confidentiality and data leakage (Confidentiality C1, CC6) - Run per-request leak analysis on JavaScript, HTML, and API responses. Capture proof that no API keys, access tokens, or PII appear in page source, script bundles, or network payloads. Include the offending line excerpts when leaks are found and the clean rerun after the fix.
• Vulnerability management (CC7) - Record dependency and CVE findings tied to the exact library file and version your site serves. Example: /static/vendor/jquery-3.5.0.min.js observed with CVE identifier and severities. Track the fix by version in production and show the rescanned artifact. This supports CC7.2 and CC7.3 on detecting and remediating vulnerabilities.
• Secure configuration and hardening (CC7, CC8) - Snapshot effective security headers and TLS behavior. Store examples of CSP, HSTS, X-Frame-Options, Referrer-Policy, X-Content-Type-Options, and the TLS versions accepted by your edge. Map to CC7.2 for operations monitoring and CC8.1 for configuration control.
• Email security outcomes (CC6, CC7) - Preserve proofs from an email spoofing test that attempted to send as your domain. Keep the raw headers and delivery result that show pass or block. This validates your SPF, DKIM, and DMARC setup with a real outcome, not only a TXT record dump.
• Monitoring and alerting (CC7) - Show that 24 by 7 monitoring detects change and new risks. Keep the notification record, timestamp, affected URL, and the ticket link. This demonstrates ongoing operations rather than a single point in time.
• Change management (CC8) - Tie findings to deploy identifiers and dates. Example: header removal or library upgrade associated with release 2026.05.14. Show pre-deploy baseline, change, and post-deploy verification.
• Third-party and data store access paths (CC6, Confidentiality C1) - If you use a managed backend such as Supabase or Firebase, store a record of row-level security or security rules behavior observed in production. Example: an unauthenticated crawl of public pages shows no authenticated-only rows. An authenticated session shows only rows permitted by policy.

Auditors work from controls first. Make it trivial to move from a control to a dated finding and then to the artifact that proves what happened.

Collect reproducible evidence from scans

Evidence must be repeatable. A reviewer should be able to follow your steps and reach the same result on the same date and build.

• Prefer real-browser crawling - Use a headful or headless browser to discover pages, execute scripts, and capture network traffic. Save the crawl graph, screenshots of key states, and the HAR file for the session. This mirrors a user path and reduces false positives that basic scanners produce.
• Use authenticated scanning - Document the account, role, sign-in flow, and session length. Store the sign-in request and the first post-login page to prove in-app coverage. Include any multi-factor step or magic link handling.
• Keep timestamped findings - For every issue or clean assertion, store date and time in ISO 8601, environment, URL, request, and response excerpt. If the result is a pass, keep a short note such as No exposed API keys in JavaScript across 52 pages on 2026-03-12T09:14Z.
• Include context, not only IDs - For dependency and CVE findings, record the file path, observed version, CVE identifier, severity, and the fixed version. If a library is bundled, record the bundle filename and the hash so the artifact is immutable.
• Snapshot headers and TLS - Save a text record of the exact headers sent by production, the CSP directives, HSTS max-age, frame options, and the TLS versions accepted. If possible, include the cipher suite list and whether TLS 1.0 or 1.1 is rejected.
• Preserve email spoofing proof - Attach the forged message or SMTP transcript, full headers, and mailbox result. Note whether DMARC alignment passed or failed and whether the mailbox placed the message in Inbox, Spam, or rejected it.
• Record a public grade - Capture the Buggy Index grade and badge state as of a date. Keep the screenshot or badge JSON that shows the grade and the URL it was captured from. This gives an external, continuous reference point.

Reproducibility turns scanner output into accepted SOC 2 evidence. If you remove an artifact, note where it moved. If an artifact is redacted, record the reason and the scope of redaction.

Templates and tracking workflow

Standardize how you present scan outputs. Concise templates help teams fill in evidence within minutes and keep a clean chain from detection to remediation to validation.

Template: Evidence log entry

• Control: for example CC7 Vulnerability Management
• Scan scope: domain, environment, auth role
• Method: real-browser crawl, authenticated scan, per-request leak analysis
• Finding: concise result, such as No exposed API keys in JavaScript responses across 52 pages
• Artifacts: paths or links to screenshots, HAR, or captured responses
• Timestamp: ISO date and time
• Owner: name or role
• Status: pass, issue found, issue fixed

Template: Issue ticket from a finding

• Title: Outdated jQuery 3.5.0 with CVE-XXXX-YYYY observed on /app
• Source: dependency and CVE scanning
• Impact: link to CVE summary and affected functionality
• Repro steps: load URL, inspect network, confirm library filename and version
• Proposed fix: upgrade to the fixed version observed in staging and recommended by the scanner
• Fix prompt: paste the ready-to-use prompt from copy-paste fix prompts into your AI editor
• Validation: rerun scan, attach updated artifact showing new version and clean result

Template: Weekly monitoring rollup

• Window: date range
• Buggy Index: grade at start and grade at end
• New findings: count and one-line summaries
• Resolved: count and list of tickets closed
• Headers and TLS changes: additions such as HSTS or CSP updates
• Email spoofing: last test result and date
• Open risks: items pending past SLA, with owners

Attach the original fix prompt and the AI patch diff to the ticket when a finding ships. Keep the pre-fix artifact and the post-fix artifact. This gives a clean before and after record that auditors can sample without extra meetings.

Prepare for auditor review

Make it easy for an auditor to navigate from controls to evidence to remediation without a guided tour. Treat your scan outputs as the population and your index as the map.

• Organize by control - Create a folder per control with subfolders for Findings, Artifacts, and Tickets. Auditors work by control and want all related proof in one place.
• Use predictable filenames - Example format: 2026-03-12_CC7.2_headers-and-tls_prod_pass.png. Chronological, scannable names reduce time spent cross-referencing.
• Provide a controls-to-evidence index - A single document that lists each control with links to its latest scan entry and artifacts. Include the contact for each control.
• Show continuous coverage - Include a 24 by 7 monitoring summary that shows rescans, new alerts, and response times. SOC 2 values ongoing evaluation over one-time checks.
• Demonstrate realistic testing - Highlight real-browser crawling, authenticated sessions, and the specific roles tested. This proves you validated the system as users and attackers actually experience it.
• Annotate exceptions with context - If you accept a short-term risk, note the business reason, scope, and target fix date. Well documented exceptions are acceptable.

Operational checklist

1. Enable real-browser crawling for production and key in-app paths. Capture the crawl graph and HAR. This reveals what a user can actually load and surfaces hidden pages.
2. Configure authenticated scanning for at least one read-only role and one admin role. Prove least privilege and privileged flows both work as intended.
3. Run per-request leak analysis on representative sessions. Detect exposed API keys, tokens, and PII in scripts and network payloads before attackers do.
4. Record security headers and TLS audit on every production deploy. Confirm hardening controls remain active after changes.
5. Log dependency and CVE results weekly. New CVEs appear daily. A dated trail shows exposure windows and fixes.
6. Execute an email spoofing check monthly. Preserve headers and delivery results to show whether defenses hold in practice.
7. Store artifacts with timestamps and stable links or screenshots. Reproducibility is what turns a scan into accepted SOC 2 evidence.
8. Open a ticket for every finding and attach copy-paste fix prompts. Shorten time to remediation and keep the decision trail.
9. Publish or capture your Buggy Index grade and badge each month. An external grade communicates posture to leadership and auditors.
10. Maintain a controls-to-evidence index and a weekly rollup. This speeds sampling and reduces meeting time.

Keep scope practical. Focus on production and one staging environment. Let continuous scanning generate daily signal, then curate that signal into a small, trustworthy evidence set.

Key takeaways

• Map each web-scan signal to a specific SOC 2 control and criterion family.
• Favor real-browser, authenticated, timestamped artifacts that a reviewer can reproduce.
• Standardize evidence logs, issue tickets, and weekly rollups to cut audit friction.
• Show ongoing coverage with continuous monitoring and a dated Buggy Index grade.
• Use fix prompts to reduce remediation time and preserve a clean before and after trail.

Close the loop by reviewing the evidence index before your audit window opens. If an outsider can follow the trail from control to artifact to fix without help, you are ready.