SOC 2 and Continuous Monitoring: What Auditors Expect for External Security
SOC 2 requires continuous monitoring and evidence of security controls. Learn which Trust Services Criteria map to external scanning and what auditors look for.
What is SOC 2?
SOC 2 (System and Organization Controls 2) is an auditing framework developed by the AICPA (American Institute of Certified Public Accountants) that evaluates how a service organisation manages data security. It is the de facto security certification for SaaS companies, cloud providers, and any organisation that processes data on behalf of clients.
Unlike ISO 27001 (which certifies a management system) or PCI DSS (which prescribes specific controls), SOC 2 evaluates whether your controls are effective against defined Trust Services Criteria. This makes it flexible -- you choose how to implement controls -- but it also means you need to demonstrate that your chosen approach actually works.
SOC 2 Type I vs Type II
- Type I -- evaluates the design of your controls at a specific point in time. "Do these controls exist and are they designed correctly?"
- Type II -- evaluates the design and operating effectiveness of your controls over a period (typically 6--12 months). "Do these controls exist, and have they been working consistently?"
Type II is what most clients and prospects require because it proves your controls actually function over time, not just on audit day. This is where continuous monitoring becomes essential -- you need evidence of ongoing control operation, not just a snapshot.
Trust Services Criteria relevant to external security
SOC 2 is organised around five Trust Services Categories: Security (required), Availability, Processing Integrity, Confidentiality, and Privacy. External attack surface monitoring maps to several criteria:
CC6.1 -- Logical and physical access controls
This criterion requires that you implement logical access controls to protect information assets. From an external security perspective, this means:
- Only necessary ports and services are exposed to the internet (see open ports security)
- Network boundaries are defined and enforced
- Unnecessary services are disabled
- Firewall rules are reviewed and maintained
What the auditor wants to see: Evidence that you regularly scan your external perimeter and act on findings. A continuous scanning tool that shows historical data is ideal.
CC6.6 -- Boundary protection
This criterion specifically addresses how you manage the boundary between your internal systems and external networks:
- Restricting inbound and outbound traffic to authorised connections
- Monitoring network traffic for anomalies
- Detecting unauthorised access attempts
What the auditor wants to see: Firewall configurations, network diagrams, and evidence of external scanning that validates the boundary is enforced correctly.
CC7.1 -- Detection of changes
You must have mechanisms to detect changes to your infrastructure that could introduce vulnerabilities:
- New services being deployed
- Configuration changes on existing services
- New subdomains or IP addresses
- Changes to TLS certificates, DNS records, or security headers
What the auditor wants to see: Alerting mechanisms that notify your team when external-facing infrastructure changes. This is exactly what attack surface management provides.
CC7.2 -- Monitoring for anomalies
You must monitor your systems for indicators of compromise and anomalous activity:
- Unexpected open ports
- Services running on non-standard ports
- TLS certificates issued without your knowledge
- DNS records modified outside change management
What the auditor wants to see: Monitoring dashboards and alert history showing that anomalies are detected and investigated.
CC8.1 -- Change management
Changes to your infrastructure must follow a defined change management process:
- Changes are authorised before implementation
- Changes are tested before deployment
- Changes are documented
- Unauthorised changes are detected and investigated
What the auditor wants to see: External scanning that detects unauthorised changes provides a critical compensating control. If someone bypasses your change process and deploys a new service, continuous monitoring catches it.
What "continuous monitoring" means for SOC 2
The AICPA's guidance does not specify exact scanning frequencies, but "continuous" means more than quarterly:
Minimum expectations
- Vulnerability scanning -- at least quarterly for external infrastructure, with evidence of remediation
- Configuration review -- regular verification that security configurations have not drifted
- Access review -- periodic verification of who has access to what
What top-tier organisations do
- Daily or continuous external scanning -- every domain, subdomain, and IP checked every day
- Real-time alerting -- notifications within hours when a new service is exposed or a configuration changes
- Automated remediation tracking -- SLAs per vulnerability severity with dashboards showing compliance
- Trend reporting -- month-over-month improvement in mean time to remediate
The difference between a clean audit and a painful one is often the depth and continuity of your monitoring evidence.
Evidence auditors want to see
Scan reports
Regular external scan reports showing:
- What was scanned (scope)
- What was found (findings by severity)
- What was fixed (remediation evidence)
- What remains open (with documented risk acceptance for items not yet fixed)
Reports should span the entire audit period. A single scan from last month is insufficient for a Type II audit.
Remediation timelines
Evidence that vulnerabilities are fixed within your SLA:
| Severity | SLA | Evidence needed |
|---|---|---|
| Critical | 24--48 hours | Timestamp of discovery, timestamp of fix |
| High | 7 days | Same |
| Medium | 30 days | Same |
| Low | 90 days | Same |
For context on these severity levels and SLAs, see our guide on vulnerability severity levels.
Exception documentation
For vulnerabilities that cannot be fixed within the SLA:
- Written risk acceptance signed by management
- Compensating controls documented
- Review date set for reassessment
- Justification for the exception
Change detection logs
Evidence that infrastructure changes are detected:
- New subdomain detected on [date] -- investigated and confirmed as authorised
- New port detected on [IP] -- investigated and determined to be unauthorised, closed on [date]
- TLS certificate changed on [domain] -- confirmed as scheduled renewal
Trend data
Auditors increasingly ask for trend data showing security posture improvement:
- Total findings over time (should trend down)
- Mean time to remediate per severity (should trend down)
- Percentage of findings fixed within SLA (should trend up)
How SOC 2 compares to other frameworks
| Aspect | SOC 2 | ISO 27001 | NIS2 |
|---|---|---|---|
| Type | Audit report | Certification | Regulation |
| Scope | Service organisation controls | Information security management system | Essential and important entities in the EU |
| External scanning | Expected for CC6, CC7 | Required for A.8.8 | Required for Article 21 |
| Frequency | Continuous for Type II | At least annually, continuous recommended | Continuous implied |
| Evidence period | 6--12 months (Type II) | Ongoing | Ongoing |
Many organisations pursue multiple frameworks. The good news: the evidence from continuous external monitoring satisfies requirements across all three. See our guides on ISO 27001 vulnerability scanning and NIS2 compliance for framework-specific details.
Common audit findings related to external security
These are findings that auditors frequently flag:
- No evidence of external scanning -- internal scans exist but nothing validates the external perimeter
- Scanning is point-in-time only -- quarterly scans with no monitoring between them
- No remediation tracking -- scans are run but findings are not tracked to closure
- Inconsistent scope -- some domains or IP ranges are scanned, others are missed
- No documented SLAs -- vulnerabilities are fixed "eventually" with no defined timeline
- Exceptions not documented -- known vulnerabilities are accepted without formal risk documentation
Addressing these before the audit saves significant time and prevents qualified opinions.
How SurfaceScan helps
SurfaceScan provides the continuous external monitoring and evidence trail that SOC 2 Type II auditors expect. It scans your entire attack surface on a regular cadence, detects configuration changes and new exposures, tracks remediation against severity-based SLAs, and generates exportable reports covering any date range. The dashboard provides real-time security posture visibility, and trend reporting demonstrates improvement over the audit period -- giving your auditor exactly what they need to validate CC6, CC7, and CC8 controls.
Related articles
What is Attack Surface Management? A Complete Introduction
Attack surface management (ASM) helps organisations discover, monitor, and secure all internet-facing assets. Learn the ASM lifecycle and why continuous monitoring matters.
ISO 27001 Vulnerability Scanning Requirements: What Auditors Expect
Learn which ISO 27001 controls require vulnerability scanning, what evidence auditors want to see, and how to build a compliant vulnerability management process.
NIS2 Compliance: Vulnerability Management and Attack Surface Monitoring
The NIS2 directive requires organisations to manage cybersecurity risks including vulnerability scanning. Learn who it applies to, what it requires, and how to comply.