Updated October 2026.
You're halfway through your SOC 2 audit and the auditor asks for vulnerability scanning evidence. Most of your prep went into access controls and encryption, and you assumed the pentest covered scanning. Vulnerability scanning is a separate control with its own evidence, and a pentest report doesn't stand in for it. I've watched three founders scramble to produce scan reports the week before their audit window closed. This post is what I wish I could have sent them.
What CC7.1 and CC7.2 actually say
Both criteria come from the AICPA's 2017 Trust Services Criteria, in the edition with revised points of focus published in 2022. That revision changed the points of focus and left the criteria themselves alone.
CC7.1, word for word:
To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.
That is the whole criterion. It doesn't mention scanners or how often to run them. The scanning language sits in one of its points of focus, which the AICPA gives as examples of what a control can look like. The criteria document says you don't have to address every point of focus. Here is the one about scanning, as revised in 2022:
Conducts Vulnerability Scans: The entity conducts infrastructure and software vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after significant changes are made to the environment. Action is taken to remediate identified deficiencies in a timely manner to support the achievement of the entity's objectives.
And CC7.2:
The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.
In plain terms, CC7.1 asks you to find weaknesses and fix them. CC7.2 asks you to notice when something unusual happens and decide whether it's a security event. Scan output is CC7.1 evidence. Most CC7.2 evidence comes from your logging and alerting, such as cloud audit logs and alerts that someone actually reads. A scanner that watches certificates, DNS and new subdomains contributes a small part of CC7.2.
Type I vs Type II
A Type I report says your controls were designed and in place on one date. A Type II report says they operated over a period, usually somewhere between 3 and 12 months. First audits often cover 6 months and renewals usually cover 12. The scanning evidence differs a lot between the two.
| Type I | Type II | |
|---|---|---|
| What the auditor tests | The control exists on the report date | The control ran for the whole period |
| Scan evidence | Your policy plus a recent scan | Scans on your stated cadence across the period, with no gaps |
| Remediation evidence | How you handled the findings in that scan | A sample of findings from across the period, each fixed within your SLA or formally accepted |
On a Type II, a policy that promises monthly scans followed by a two-month gap over the summer turns into an exception in your report.
What your auditor asks for
The criteria leave the details to you. In practice, auditors ask for the same short list.
A written policy with your cadence and SLAs
Your vulnerability management policy states how often you scan, what's in scope, and how fast each severity gets fixed. Everything else is tested against it, so don't promise more than you'll do. A policy that says quarterly and a scanner that runs daily is fine. The reverse is an exception.
Scan output on that cadence
Vanta's help center says you typically need evidence of one scan per quarter. In my experience many auditors push for monthly. Daily or continuous scanning goes well past both.
Findings classified by severity
Critical, high, medium, low. CVSS scores are the usual basis, but any consistent system works. Auditors want output they can cite in their workpapers, which a raw JSON dump from an open-source scanner rarely is.
Proof that findings were handled
Each finding needs one of these outcomes:
- Fixed, with a follow-up scan showing it's resolved
- Accepted, with a written justification
- Mitigated, with compensating controls documented
Findings sitting open with no response become a finding in the audit itself.
Auditors pull a sample and compare actual fix times against the SLAs in your policy. These targets are common:
| Severity | Target fix time |
|---|---|
| Critical | 7 days |
| High | 30 days |
| Medium | 90 days |
| Low | Best effort |
Scope that matches your system description
Which apps and domains are tested, and do they match the system described in your report? They will check that the hosts you scan are the production ones. If a new app ships halfway through the period, it needs to appear in your scans from then on.
Scan after significant changes
The point of focus asks for scans "after significant changes are made to the environment." That ties scanning to change management, which is CC8.1. Your change management policy should say what counts as significant, for example a new service or an infrastructure change, and your scan records should line up with those changes.
The simplest way to make that true is to scan on every deploy. On AttackerView, Starter and above give each app a deploy hook URL. Call it from your CI or hosting provider after a deploy and a scan starts, so the auditor can match a scan to each release.
Authenticated vs unauthenticated scanning
An unauthenticated scan sees what anyone on the internet sees: certificates, DNS, headers, cookies, exposed files and the software versions you leak. That's a large part of your attack surface, and it's what most quarterly scans cover.
It misses everything behind the login. A scan with a real account can check whether your API endpoints return data without a session, whether admin and debug pages answer a logged-out user, and whether CORS on authenticated endpoints lets another site read the responses.
SOC 2 doesn't require authenticated scanning. If your product is a logged-in web app, though, an external-only scan leaves most of it untested. Warden and Hunter scan behind your login with credentials you provide, once you've verified the domain.
Where an external scanner fits
The criteria don't say internal or external, and auditors differ. Vanta's help center notes that some auditors insist on host-based server scanning if you run servers, and that container scanning is often enough for teams on serverless or PaaS.
AttackerView scans your external web apps. It doesn't look inside your hosts, containers, cloud configuration or source code. If you run your own servers, pair an external scanner with a host or container scanner such as AWS Inspector, and ask your auditor which layers they expect evidence for before the audit period starts.
Pentests: required or not, and when
A penetration test isn't a hard requirement. The criteria mention it in a CC4.1 point of focus, which lists penetration testing among the ongoing and separate evaluations an entity can use, next to vulnerability scans and third-party assessments. Secureframe's guidance says a pentest is "not necessarily a hard pass/fail control requirement," and that "all auditors will accept a pen test report as evidence."
The AICPA sets no timing. Secureframe's guidance is that for a Type I the pentest can fall in the 12 months before the report date, and for a Type II it should fall inside the audit period. Secureframe also says requirements vary by auditor, so confirm with yours before you book the test.
A pentest doesn't replace scanning either. It tests one moment, and CC7.1 asks for ongoing detection.
AttackerView also runs AI pentests, at €10 plus VAT per HTTP method and route you select. Whether your auditor counts one as your annual pentest is their call, so ask before you rely on it.
Keeping evidence for the whole period
A 12-month Type II window can outlast your scanner's history. AttackerView keeps 90 days of scan and finding history on Warden and a year on Hunter. On Warden, print the compliance report to PDF each quarter and file it with your audit evidence, or let Vanta or Drata hold the record.
Getting the evidence into Vanta or Drata
In Vanta, an integrated scanner fills the Vulnerabilities page by itself. Without one, you upload a "Vulnerability scan" document and a "Sample of remediated vulnerabilities" by hand. AttackerView connects to Vanta with OAuth and sends the full state of your domains and open findings every few minutes. Vanta starts each finding's SLA clock the first time it sees it and marks it remediated when it stops appearing, so Vanta's own record covers the period. Findings you accept or mark as false positives also stop appearing, so Vanta shows them as remediated too. Setup is in the Vanta integration docs.
In Drata, AttackerView uses an API key. After each scan that changes a domain's findings, it uploads a dated JSON evidence file to the Evidence Library, attached to the controls tagged for your frameworks. Each file lists the open findings with severity, affected URL, first and last seen dates, and the controls they map to. A domain with no open findings sends no file, so keep printing the quarterly report to PDF to cover clean stretches. Setup is in the Drata integration docs.
What SOC 2 does not require
Vendors have a reason to blur these lines. I sell a scanner, so weigh this list with that in mind.
- Internal or external scanning specifically. The criteria don't say.
- A penetration test. It's recommended and auditors accept one as evidence, but it isn't a pass/fail requirement.
- A specific tool. Open-source is fine if you produce the evidence above. The trade-off is your time.
- A 24/7 security operations center. CC7.2 asks you to monitor for anomalies and analyze them. For most startups that means logging plus alerts someone reads.
What this costs
For a Series A startup of 10 to 50 people, these are the ranges I see:
| Line item | Typical range |
|---|---|
| Compliance platform (Vanta, Drata, Secureframe) | $7.5K to $15K/yr |
| Auditor fees | $10K to $25K/yr |
| Annual penetration test | $5K to $25K |
| Vulnerability scanner | $1K to $6K/yr |
| Total, year 1 | $25K to $70K |
Open-source tools are free but produce raw output with no compliance mapping. Most mid-market web scanners price per target, so price your own number of apps on each vendor's page before you compare.
Before you trust the findings: verify the domain
AttackerView shows evidence and fix steps only after you prove you own the domain, either with a DNS TXT record or by serving a file from the site. Until then the app shows each finding's title and severity only (findings that contain secrets show as redacted), and compliance reports come out redacted. The same check gates storing login credentials for authenticated scans and buying pentests.
How AttackerView covers this
AttackerView is the scanner I built, so here is how it maps to the list above.
Warden checks certificates, DNS and redirects every 30 minutes, security headers, cookies and your tech stack every hour, and runs a full crawl every day. Starter runs a full scan daily. Either way you're well past the quarterly bar, and deploy hooks cover the scans after significant changes.
Compliance reports cover SOC 2, ISO 27001 and HIPAA, plus PCI DSS supporting evidence for your assessor (it isn't an ASV scan). They come with Warden, €119/mo for 15 apps or €1,190/yr billed annually, and with Hunter, €299/mo for 50 apps. The SOC 2 report groups findings under the controls they bear on, most of them CC6.1, CC6.6, CC6.8 and CC7.1. It shows when each open finding was first seen, measures open findings against 7, 30 and 90 day targets for critical, high and medium, and reports your average time to fix over the last 90 days. It doesn't list fixed findings one by one, so pull your sample of remediated findings from your ticket history or Vanta's record.
Starter, at €39/mo for 5 apps, gets security reports with findings and fixes, without the control mapping. Warden adds authenticated scanning, risk acceptance, and the Vanta and Drata sync. Accepting a risk in AttackerView doesn't record a reason, so keep the justification in your own risk register.
FAQ
Does SOC 2 require vulnerability scanning?
Not by name. CC7.1 requires procedures to detect new vulnerabilities, and scanning is listed as a point of focus under it. Scanning is how almost every company meets CC7.1, and auditors expect scan output for your production systems.
How often should we scan?
Quarterly is the minimum most auditors accept, and monthly is common. Pick a cadence you will keep, put it in your policy, and scan after significant changes too.
Is a penetration test required for SOC 2?
No, but it's recommended. When it should happen depends on your report type and your auditor, so ask before you book one. It doesn't replace scanning.
Do we need internal or host-based scanning?
The criteria don't say. If you run servers, some auditors insist on host-based scanning, while on serverless or PaaS container scanning is often enough. Ask your auditor at the start.
What do auditors ask to see?
Your vulnerability management policy with its cadence and SLAs, scan output on that cadence, a sample of remediated findings with dates, any accepted risks with a written justification, and a scope that matches your system description. For Type II, they want all of it across the whole period.
Compliance reports and the Vanta and Drata sync are on Warden, €119/mo for 15 apps. New accounts start with a 14-day Starter trial with no card, which runs daily scans but doesn't include compliance reports. When the trial ends, scans pause until you pick a plan, and the trial's scan data is deleted 7 days later. See plans.
Sources
- AICPA, 2017 Trust Services Criteria (With Revised Points of Focus, 2022), TSP Section 100. Criteria and point-of-focus text checked against the AICPA's red-lined 2022 edition.
- Vanta Help Center, What Should I Use for Vulnerability Scanning?
- Secureframe Help Center, Pen Testing Requirements