For SaaS companies in a SOC 2 audit
Evidence for your Type 2 window, every day of it.
A Type 2 auditor samples the whole observation period, not the week before fieldwork. Attack Surface Scan checks your internet-facing systems on a schedule and turns that history into an evidence pack: every scan day logged, gaps disclosed, findings mapped to the Trust Services Criteria, and accepted risks with an owner and an expiry date.
Growth plan: $49/month, daily scheduled scans across five domains. No card required to start.
What the auditor asks, and where the answer is
Four questions come up in every vulnerability-monitoring walkthrough. Each has its own section in the evidence pack, so the answer is a page reference rather than a meeting.
Did the control run all period?
A Type 2 report covers a window of usually six to twelve months, and the auditor samples dates inside it. The evidence pack logs every day with scan activity, splits scheduled from manual runs, and lists any day the schedule missed. A gap is disclosed, not smoothed over, which is what makes the rest of the log believable.
What did it find, in our criteria?
Findings are mapped to the Trust Services Criteria the auditor tests: CC7.1 for vulnerability and configuration monitoring, CC6.6 for exposure at the boundary, CC6.7 for encryption in transit, CC3.2 for risk ranking, CC4.1 for ongoing evaluation. ISO 27001 Annex A references sit alongside for teams certified to both.
Who accepted this risk, and until when?
Some findings are fine to live with. Muting or accepting one requires a reason and an expiry date, and the pack's exception register shows the host, the finding, who decided, why, and when the decision lapses. When it does, the finding reopens and alerts again.
Is this really your estate?
Nothing is scanned until control of the domain is proven. The scope section lists every domain with its proof method (DNS record, HTTP file, mailbox or emailed approval) and when that proof was last confirmed. DNS and HTTP proofs are re-checked nightly.
Mapped to the criteria you are tested on
The evidence pack opens its framework section with this table, so the auditor reads your monitoring in their own vocabulary.
| Criterion | What it asks | Where the pack evidences it |
|---|---|---|
| CC7.1 | Detect configuration changes that introduce vulnerabilities, and susceptibility to newly discovered ones. | Coverage, coverage gaps and the daily scan log; current posture by framework; remediation against fix-time targets. |
| CC4.1 | Ongoing evaluations show controls are present and functioning. | Coverage by domain: scans, first and latest scan, score and trend across the period. |
| CC3.2 | Identify and analyse risks, and decide a response. | Findings ranked by severity, including CISA KEV matches; the exception register and its full history. |
| CC6.6 | Protect against threats from outside the system boundary. | Exposed services, administrative interfaces and HTTP security headers. |
| CC6.7 | Protect information in transmission. | TLS configuration, certificate validity and HSTS. |
ISO/IEC 27001:2022 Annex A references (A.8.8, A.8.9, A.8.20, A.8.24 and A.5.7) appear in the same table for teams certified to both. For the reasoning behind each mapping, read turning external monitoring into SOC 2 and ISO 27001 evidence.
In production at CalendarBridge
CalendarBridge is a SaaS product built by the team behind Attack Surface Scan, and it holds a SOC 2 Type 2 report. Attack Surface Scan is how it monitors its external attack surface: the evidence pack was built for that program first.
16 production hosts
Web app, API, authentication, help centre and marketing hosts, all under scheduled monitoring.
430+ completed scans
Since monitoring began in August 2026, every one retrievable by date with its findings.
One evidence pack
Generated for the audit period on demand, rather than reconstructed from screenshots the week before fieldwork.
Figures as of September 2026, production hosts only.
Why monitoring between pen tests matters
Your penetration test is a snapshot. A SaaS estate changes every week, and these are the changes that turn into findings, or incidents, between one test and the next.
A certificate quietly fails to renew
Automated renewal breaks more often than it should, and the first sign is usually a customer's browser warning. Certificates are checked every six hours on Growth.
A preview or admin host goes public
A new subdomain shows up in certificate transparency logs, or a database port answers from the internet after an infrastructure change. Both are flagged on the next scan.
Software you run joins the exploited list
When CISA adds a vulnerability to its Known Exploited list, detected software is matched against it on the next scan, so "are we affected?" has a dated answer.
A header or DNS record regresses
A deploy drops HSTS, or someone loosens a DMARC policy while debugging email. Configuration checks run on every scan and the change feed shows when it happened.
Honest scoping: this is external, non-intrusive monitoring. It does not see inside your network, it is not a penetration test or a PCI ASV scan, and it does not make you compliant. It produces the evidence that one control operated, every day of the period. For the broader picture (cyber insurance, ISO 27001, security questionnaires) see compliance evidence.
Common questions
Which SOC 2 criteria does Attack Surface Scan support?
Mainly CC7.1, which expects detection and monitoring procedures for configuration changes and newly discovered vulnerabilities. The evidence pack also supports CC4.1 (ongoing evaluation), CC3.2 (risk identification and response), CC6.6 (threats from outside the boundary) and CC6.7 (encryption in transit). It supports those controls; it does not by itself satisfy any of them, and your auditor decides what evidence is sufficient.
Does it replace our annual penetration test?
No. A penetration test is a person trying to break in at one point in time; this is automated, non-intrusive monitoring of what is visible from outside, every day in between. Most SOC 2 programs want both, and auditors read them as different controls.
What happens if a scheduled scan is missed?
The evidence pack lists it. Each day since scheduled scanning began with no completed scheduled scan appears in a coverage-gaps table, measured against your plan's cadence. Auditors trust a log that discloses its own gaps far more than one that has none.
How does our auditor check the pack is genuine?
The PDF's SHA-256 fingerprint is registered the moment it is generated, so your auditor can confirm any copy is unaltered at attacksurfacescan.com/verify without an account. Each pack also carries a report ID, and every day in its scan log corresponds to scans you can open in the account's scan history. If your auditor wants to see it live, add them as a team member for the fieldwork.
We use a compliance automation platform. Does it connect?
There is no native connector to platforms such as Vanta or Drata today. Teams upload the evidence pack as the evidence for their vulnerability-monitoring control, and the REST API (on Growth and above) exposes scans and findings if you want to automate the hand-off.
Which plan does a SOC 2 program need?
Growth: daily scheduled scans across five domains with up to 100 hosts each, certificate checks every six hours, unlimited manual scans and the REST API. Starter scans weekly, which some auditors accept for a small estate; daily is the stronger story.
Is Attack Surface Scan itself SOC 2 certified?
No, and nothing about using it makes you compliant. It produces evidence for your program. Every check is read-only and runs only against domains you have proven you control.
Start the log before the window opens
Evidence only covers the days it was collected. The best time to start monitoring was the first day of your observation period; the next best is today.
Start your 7-day trialNo card required to start. Cancel any time.