Turning a Website Security Scan Into SOC 2 and GDPR Evidence

A SOC 2 auditor or a GDPR data protection assessment will eventually ask what technical measures protect your systems. An external scan of your public-facing website is genuinely useful evidence toward answering that. It is not, on its own, the answer.

What These Frameworks Actually Ask For

SOC 2's Trust Services Criteria require you to demonstrate controls around logical access (who can get into what, and how that's enforced), transmission and storage confidentiality (encryption in transit and at rest), system monitoring (do you actually notice when something goes wrong), and secure configuration of the systems handling data. GDPR's Article 32 covers similar ground under "security of processing" - appropriate technical and organizational measures proportionate to risk, plus the ability to detect, respond to, and recover from a breach.

Both frameworks are explicit that this isn't only a technical exercise. Policies, access reviews, vendor management, incident response plans, employee offboarding - all of it counts, and none of it is visible from outside your network.

Worth knowing if you're new to SOC 2 specifically: Security is the one mandatory Trust Services Criterion every report covers. Availability, Processing Integrity, Confidentiality, and Privacy are optional additions you scope in based on what your business actually does. An external website scan mostly speaks to Security, and to a lesser extent Confidentiality where it can see things like exposed secrets or verbose error output - it has nothing to say about Availability commitments or Privacy program specifics, which are evaluated through entirely different evidence.

What an External Scan Can Actually See

A scanner pointed at your live website sees exactly what anyone on the public internet sees: your TLS configuration, your response headers, whether secrets or internal paths leak into client-side code, the versions of dependencies your app ships, how your server responds to malformed or probing requests, and whether that posture stays consistent when checked repeatedly over time. That's a real, useful slice of your security posture, and it's one an auditor will ask about regardless.

What it categorically cannot see: whether you actually run access reviews on a schedule, whether your vendor contracts include the right data processing terms, whether your incident response plan has ever been tested, whether an employee who left six months ago still has a valid credential somewhere. None of that has a footprint on your public website, so no scan - ours or anyone else's - can speak to it.

A scanner finding is evidence relevant to a control, not proof the control is met. That distinction is the whole point of this article, and it's worth keeping in mind for anything that claims to help with compliance, not just this one.

Concern Categories a Scan Surfaces

Rather than a flat list of findings, it's more useful to think in terms of the concern categories a scan actually surfaces, since each maps loosely to a different control family an auditor cares about:

• Secrets exposure - API keys, tokens, or credentials leaked into client-side code or public repos. Maps to access-security and confidentiality controls.
• Transport encryption - TLS configuration, certificate validity, whether HTTP actually redirects to HTTPS. Maps to security-of-processing / transmission confidentiality controls.
• Access control signals - authentication and authorization behavior visible from outside, like exposed admin routes or missing auth checks. Maps to logical access controls.
• Injection risk - inputs that aren't sanitized against common attack patterns. Maps to malicious-code-prevention controls.
• Dependency vulnerabilities - known CVEs in the libraries your app ships. Also maps to malicious-code-prevention and general security-of-processing controls.
• Information disclosure - stack traces, internal paths, or verbose error messages leaking implementation details to anyone who triggers an error. Maps to confidentiality controls.
• Monitoring gaps - signals that nothing is watching for anomalous behavior, like a TLS certificate drifting toward expiry unnoticed or a security header that silently disappeared after a deploy. Maps to system-monitoring and breach-notification-readiness controls.
• Configuration hardening - security headers, cookie flags, CORS policy, and similar server-level settings. Maps to network- and configuration-security controls, and design-by-default expectations under GDPR.

Using This as Evidence, Not a Checkbox

The practical way to use a scan in an actual audit: run it on a schedule, not once, and keep the dated reports. A single screenshot proves your site passed a check on one day. A repeated, timestamped history proves the control was operating continuously - which is closer to what SOC 2 actually wants to see. Then file it alongside the non-technical evidence (policies, access review logs, vendor assessments) rather than in place of it. The scan covers the technical, externally visible slice; the rest of the audit still needs the rest of the picture.

Scanverra's SOC 2 / GDPR security auditorganizes findings into exactly these concern categories and maps each one to the relevant Trust Services Criteria and GDPR articles, with the same disclaimer built into the product itself - it's meant to be a useful starting point for gathering evidence, not a substitute for an actual audit.