SOC 2 from your auditor’s perspective: what they actually look at on your website

SOC 2 is mostly about people and process — but a meaningful slice of the Trust Service Criteria is verifiable from the public web. Here is what auditors check for CC6.6, CC6.7, CC6.8, and CC9.1, and where audits commonly get qualified opinions.

SOC 2 is not a regulation. It is an attestation report issued by an independent auditor (a CPA firm) confirming that a service organization has the controls in place to meet selected Trust Service Criteria. For B2B sellers in 2026, a clean SOC 2 Type II report is the single most common gating requirement for enterprise contracts.

Most of SOC 2 is about people and process — access reviews, change management, incident response, vendor management. But a meaningful slice of the Trust Service Criteria is verifiable from your public web surface, which is where auditors increasingly start their work.

The Trust Service Criteria, in plain English

SOC 2 reports cover one or more of five Trust Service Criteria:

• Security (always included) — the system is protected against unauthorized access, both physical and logical.
• Availability — the system is available for operation and use as committed.
• Processing Integrity — system processing is complete, valid, accurate, timely, and authorized.
• Confidentiality — information designated as confidential is protected.
• Privacy — personal information is collected, used, retained, disclosed, and disposed of in conformity with the entity's objectives.

Most B2B SaaS sellers get a SOC 2 report covering Security alone (the easiest path to a yes from procurement). Confidentiality is the second most common addition. Availability is common for infrastructure providers. Processing Integrity is rare. Privacy is rare and largely overlaps with separate privacy attestations.

The web-verifiable controls — what auditors actually check

CC6.6 — Boundary protection

Your platform protects against unauthorized access at the network boundary. Web-verifiable evidence: WAF in front of public endpoints, rate limiting on auth endpoints, no obvious admin interfaces exposed to the internet, proper IP allowlisting on management consoles.

CC6.7 — Restricted transmission of data

Data in transit is restricted to authorized parties. Web-verifiable evidence: HTTPS enforced site-wide, HSTS set with reasonable max-age, TLS 1.2+ only with strong cipher suites, no mixed-content warnings. This is the single most-checked control in a typical SOC 2 audit because it is the easiest to verify externally.

CC6.8 — Malicious software prevention

Controls to prevent the introduction of malicious software. From a web perspective: Content-Security-Policy that prevents loading untrusted scripts, integrity attributes (SRI) on third-party scripts, a documented dependency-update process.

CC9.1 — Risk mitigation

Identifies risks and acts on them. Web-verifiable evidence: a security contact / vulnerability disclosure policy reachable from the public site, a security.txt file at /.well-known/security.txt, a documented response time SLA.

The two-report pattern: Type I vs Type II

• SOC 2 Type I — a point-in-time attestation: on this specific date, these controls were designed and in place. Quick to produce (4-8 weeks). Useful as a starting point.
• SOC 2 Type II — a period-of-time attestation (typically 3 to 12 months): over this period, these controls were designed, in place, AND operating effectively. This is what enterprise procurement actually requires. Slower (3-12 month observation window plus 4-6 weeks of audit work).

A clean Type II is the answer to the question “does this vendor reliably do what they say they do over time.” A Type I says “they say they will.” Buyers prefer Type II and will often accept Type I as a bridge for a young company.

Common reasons SOC 2 audits get qualified opinions

A qualified opinion is the auditor's way of saying “controls were largely in place but with exceptions.” A handful of recurring web-layer reasons:

• HSTS missing or set with too-short max-age — fails CC6.7 evidence.
• One legacy subdomain still accepting HTTP — taints the site-wide HTTPS attestation.
• A third-party script loaded without SRI on a page that handles sensitive operations — fails CC6.8.
• No vulnerability-disclosure path on the public site — fails CC9.1 evidence.

All four are 30-minute fixes. None of them are caught by the people-and-process focus of a typical SOC 2 readiness assessment. This is the gap Plumb fills.

How to use a Plumb scan in a SOC 2 cycle

1. Pre-audit, run a Plumb scan. The SOC 2 section of the report enumerates exactly which web-verifiable Trust Service Criteria pass and which fail.
2. Close every finding before the observation window starts. Auditors want evidence over time. A finding that closes during the observation period still creates a noted exception. Close it before.
3. Provide the before / after Plumb reports to your auditor as part of the technical-controls evidence package. They contribute directly to CC6.6, CC6.7, CC6.8, and CC9.1 walk-throughs.
4. Re-scan quarterly during the observation period. A trailing record of clean Plumb reports is operational evidence that the controls are operating effectively, which is exactly what a Type II attests to.

Plumb is not a replacement for a CPA firm. It replaces the manual portion of the auditor's web-layer review — the part that gets scrubbed before the auditor arrives anyway — and gives your team evidence to show the work was done.