If you're preparing for a SOC 2 Type II audit, you've probably been told you need vulnerability scanning. That's correct — but the details matter. Which controls actually require it? How often do you need to scan? What evidence does your auditor want?
This guide cuts through the ambiguity. We'll map the specific AICPA Trust Services Criteria that require vulnerability scanning, show you what auditors look for, and walk through building a scanning program that satisfies the requirements without burning your budget.
Which SOC 2 Controls Require Vulnerability Scanning?
SOC 2 is organized around the AICPA's Trust Services Criteria (TSC), which map to the COSO internal control framework. Vulnerability scanning touches several controls, but they aren't all equal. Here's the accurate mapping — with one primary control and several supporting controls.
Detection and Monitoring Procedures
Criteria: "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."
Key point of focus: The AICPA's supplemental guidance for CC7.1 specifically calls out: "The entity conducts vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after any significant change in the environment and takes action to remediate identified deficiencies on a timely basis."
Why it matters: This is the control your auditor will most directly associate with vulnerability scanning. It explicitly names vulnerability scans in its points of focus. If you do nothing else, make sure your scanning program satisfies CC7.1.
Identifies and Analyzes Risk
Criteria: The entity identifies risks to the achievement of its objectives and analyzes risks as a basis for determining how the risks should be managed.
How scanning maps: Vulnerability scanning is one of the primary mechanisms for identifying technical risks. Your scan results feed directly into your risk assessment process — you can't assess risks you haven't identified. Auditors expect to see that your vulnerability scanning program is connected to your risk assessment framework.
Ongoing and Separate Evaluations
Criteria (COSO Principle 16): "The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning."
How scanning maps: Regular vulnerability scanning serves as an ongoing evaluation of your security controls. If a scan reveals a new vulnerability or misconfiguration, that's evidence that a control may not be functioning as intended. The AICPA's points of focus for CC4.1 explicitly include penetration testing and independent assessments — vulnerability scanning falls into the same category of ongoing evaluations.
Monitors System Components for Anomalies
Criteria: 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.
How scanning maps: While CC7.2 is more directly about SIEM, log monitoring, and anomaly detection, vulnerability scanning contributes by identifying anomalous configurations or unexpected services. If a scan discovers an unexpected open port or unauthorized service, that's anomaly detection.
Management of Technical Vulnerabilities
Criteria: "Information about technical vulnerabilities of information systems in use should be obtained, the organisation's exposure to such vulnerabilities should be evaluated and appropriate measures should be taken."
Note: This control consolidates the older ISO 27001:2013 controls A.12.6.1 (Technical Vulnerabilities) and A.18.2.3 (Technical Compliance Review) into a single, more comprehensive requirement. If you're pursuing ISO 27001:2022 certification alongside SOC 2, this is the control your vulnerability scanning program needs to address.
Common Misconception
Some resources map vulnerability scanning to CC7.4 (Incident Response) and CC7.5 (Incident Recovery). This is inaccurate. CC7.4 covers what you do after a security incident is detected — containment, investigation, and remediation. CC7.5 covers restoring operations after an incident. Vulnerability scanning is about prevention and detection, not incident response. Your auditor knows the difference.
What Auditors Actually Look For
SOC 2 auditors don't just want to see that you ran a scan once. They're evaluating whether you have a functioning control — a repeatable, documented process that operates consistently over the audit period (typically 6–12 months for Type II). Here's what they'll ask for:
Required Evidence
- Scan reports covering the audit period — PDF or exported reports showing what was scanned, when, what was found, and severity ratings. Auditors want to see reports for each scan that occurred during the observation window, not just the most recent one.
- Evidence of recurring schedule — Proof that scanning happens on a regular cadence (weekly, monthly, quarterly). This can be scheduler configuration screenshots, scan history logs, or timestamped reports showing consistent intervals.
- Remediation evidence — This is where many teams fail. Auditors don't just want to see vulnerabilities found — they want to see that you did something about them. Jira tickets, commit references, or documented exception approvals showing how findings were addressed.
- Vulnerability management policy — A documented policy that defines scan frequency, scope (which assets), severity classification, remediation SLAs (e.g., critical = 7 days, high = 30 days), and roles/responsibilities.
Expected (Best Practice)
- Asset inventory — Documentation of which systems are in scope for scanning and why. Auditors want to understand your scanning coverage — they may ask "how did you determine what to scan?"
- Scan-after-change evidence — CC7.1 requires scanning "after any significant change." Show that you re-scan after infrastructure changes, not just on the regular schedule.
- Trend reporting — Are vulnerabilities decreasing over time? Can you show that your scanning program is actually improving your security posture?
Bonus (Strengthens Your Position)
- Full port coverage documentation — If you can demonstrate you scan all 65535 TCP ports rather than the default ~1000, that's a materially stronger control than the industry standard.
- False-positive management — Evidence that you verify and triage findings rather than blindly accepting raw scanner output. This shows operational maturity.
- Integration with ticketing — Automated flow from scan findings to Jira/Linear tickets shows that remediation isn't ad hoc.
How Often Should You Scan?
CC7.1 says "on a periodic basis" without specifying a frequency. In practice, auditor expectations vary — but here's the general consensus across the industry:
| Frequency | Auditor Perception | Best For |
|---|---|---|
| Annual | Weak — will likely be flagged | Nobody. Don't do this. |
| Quarterly | Acceptable — minimum bar | Small orgs with static infrastructure |
| Monthly | Good — meets expectations | Most organizations |
| Weekly | Strong — exceeds expectations | SaaS, fintech, health-tech |
| Continuous / Daily | Excellent — best practice | Regulated industries, high-sensitivity data |
Pro Tip: Scan After Changes, Not Just on Schedule
CC7.1 explicitly requires scanning "after any significant change in the environment." This means major deployments, infrastructure migrations, new services, or firewall rule changes should trigger an ad-hoc scan outside your regular schedule. Document these change-triggered scans — auditors love to see them because they demonstrate that your scanning program responds to risk, not just a calendar.
What Should Your Scans Cover?
Your scanning scope should align with your SOC 2 system description. If a system component is in scope for your SOC 2, it should be in scope for vulnerability scanning. At minimum:
Must scan
- All internet-facing systems — production servers, load balancers, API endpoints, web applications
- Cloud infrastructure — EC2 instances, GCP VMs, Azure VMs, Kubernetes clusters with external access
- Network services — DNS servers, VPN endpoints, mail servers
Should scan
- Staging/pre-production environments — especially if they have production data or are internet-accessible
- Database services — even if not directly internet-facing, port scanning can reveal unexpected exposure
- Third-party integrations — services you host that connect to partner systems
Port coverage matters
Most vulnerability scanners default to scanning the "top 1000" TCP ports — roughly 1.5% of the total 65535 port range. This means services running on non-standard ports (databases on port 27017, Elasticsearch on 9200, Docker API on 2375, Kubernetes on 6443) may go undetected.
While SOC 2 doesn't specify a required port range, an auditor may reasonably ask: "How comprehensive is your scanning?" Being able to say "we scan all 65535 TCP ports" is a materially stronger answer than "we scan the default ~1000."
Auditors won't fail you for scanning 1000 ports — but comprehensive coverage demonstrates a stronger control environment.
Building a SOC 2-Ready Scanning Program
Here's a step-by-step approach to building a vulnerability scanning program that satisfies CC7.1 and the supporting controls, without over-engineering it.
Common Pitfalls That Fail Audits
These are the mistakes that cause audit findings or management letter comments. Avoid them:
Gap in scanning history
Your policy says "monthly scanning" but there's a 3-month gap in your scan reports from July to September. The auditor will flag this as a control deficiency. Set up automated scheduled scans so human forgetfulness doesn't create gaps.
Scan results with no remediation
You have 12 months of scan reports showing the same critical vulnerability every month, with no ticket, no fix, and no documented exception. This tells the auditor your scanning program doesn't drive action. Every finding needs a response — fix it, accept the risk formally, or document why it's a false positive.
Scanning scope doesn't match system description
Your SOC 2 system description lists 15 production servers, but your scan reports only cover 8 of them. If it's in the system description, it needs to be scanned. Keep your asset inventory in sync with your SOC 2 scope.
No policy documentation
You're running scans, fixing findings, doing everything right — but you never wrote it down. SOC 2 requires documented policies that describe how controls operate. Write the policy. It doesn't need to be long.
How NoxScan Addresses SOC 2 Scanning Requirements
NoxScan was built to make SOC 2 vulnerability scanning straightforward for teams without dedicated security staff. Here's how it maps to the requirements above:
Full 65535-Port Scanning (CC7.1)
Every scan covers all TCP ports using masscan + XDP Scanner for discovery, then Nmap and ZGrab2 — enhanced with custom plugins for non-standard protocol detection — for service fingerprinting. No default-1000 limitations. Services on non-standard ports are discovered and accurately identified automatically.
AI False-Positive Filtering
AI verifies every finding before it reaches your dashboard. Your team triages real vulnerabilities, not scanner noise. This makes remediation more efficient and demonstrates operational maturity to auditors.
Scheduled Recurring Scans (CC7.1)
Configure weekly, monthly, or custom scan schedules. Scans run automatically — no manual triggering, no gaps in your scanning history. The schedule itself serves as evidence of your control design.
PDF Reports for Audit Evidence
Generate downloadable PDF reports for every scan, showing assets scanned, findings by severity, and remediation status. Hand these directly to your auditor as CC7.1 evidence. Each report maps findings to the relevant SOC 2 and ISO 27001:2022 controls.
Linear + Slack Integration
Push findings directly to Jira as tickets with severity, asset, and remediation guidance. This creates the audit trail that connects scanning (CC7.1) to remediation tracking — the evidence chain auditors want to see.
Control Mapping (CC7.1, CC3.2, CC4.1, A.8.8)
Findings are mapped to the relevant SOC 2 Trust Services Criteria and ISO 27001:2022 Annex A controls. Reports show which controls each finding relates to, making it easier for auditors to trace findings to criteria.
SOC 2-Ready Scanning. Starting at $10/mo.
Full 65535-port scanning, AI false-positive filtering, scheduled scans, PDF audit reports, and control mapping — everything CC7.1 requires.
Frequently Asked Questions
Yes. Trust Services Criteria CC7.1 explicitly requires detection and monitoring procedures to identify vulnerabilities. The AICPA's points of focus for CC7.1 specifically call out vulnerability scanning: "The entity conducts vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after any significant change in the environment." While the standard doesn't mandate a specific tool, auditors expect documented, recurring scanning as part of your control environment.
The primary control is CC7.1 (Detection and Monitoring), which explicitly requires vulnerability scanning. Supporting controls include CC3.2 (Risk Assessment — scanning identifies technical risks), CC4.1 (Monitoring Activities — scanning serves as an ongoing evaluation of controls), and CC7.2 (Anomaly Monitoring — scanning can detect unexpected services or configurations). Note that CC7.4 and CC7.5 (Incident Response and Recovery) are sometimes incorrectly mapped to scanning — those controls cover post-incident processes, not vulnerability detection.
CC7.1 requires scanning "on a periodic basis" without specifying a frequency. In practice, quarterly scanning is the minimum most auditors will accept for internet-facing systems. Monthly is the industry standard. Weekly or continuous scanning exceeds expectations and strengthens your control posture. You should also scan after significant infrastructure changes — CC7.1 explicitly requires this.
Auditors typically want: (1) Scan reports covering the full audit period showing what was scanned, when, and what was found; (2) Evidence of a consistent, recurring scan schedule; (3) Remediation tracking showing how vulnerabilities were prioritized, assigned, and resolved; (4) A documented vulnerability management policy defining scope, frequency, severity classification, and remediation SLAs. The biggest failure point is having scan reports without remediation evidence.
No — SOC 2 doesn't specify a port range requirement. Most auditors will accept scanning of commonly used ports. However, scanning all 65535 ports demonstrates a materially stronger control than the industry default of ~1000 ports, especially given that many exploited services (databases, container APIs, monitoring tools) run on non-standard ports outside the top 1000.
Yes. NoxScan provides scheduled recurring scans (satisfying CC7.1's periodic requirement), full 65535-port coverage, AI-verified findings to reduce false positives, PDF reports that serve as audit evidence, Jira integration for remediation tracking, and control mapping showing which SOC 2 and ISO 27001 controls each finding relates to. Plans start at $10/mo for 1 asset.
Vulnerability scanning is automated, recurring, and identifies known vulnerabilities across your infrastructure. Penetration testing is a manual, point-in-time assessment where a security professional attempts to exploit vulnerabilities. SOC 2 CC7.1 requires the former (scanning); CC4.1's supplemental guidance mentions the latter (penetration testing) as a separate evaluation. Most SOC 2 programs include both — automated scanning for ongoing coverage and annual penetration testing for depth.