Turning External Monitoring Into SOC 2 and ISO 27001 Evidence

What auditors actually ask for

Every framework conversation eventually reduces to two questions: is the control designed sensibly, and did it operate throughout the period? The second is where teams get burned. A SOC 2 Type II report covers a window — commonly six to twelve months — and the auditor samples inside it: show me the scan from February, the alert it raised, and what you did about it. A tool you switched on the week before fieldwork produces one data point; a control that "operated" needs a trail.

This is what makes continuous monitoring unusually cheap evidence. You do not prepare it, export it, or reconstruct it from Slack archaeology — it accumulates because the tool ran. The work is knowing which control each piece of output belongs to, which is the rest of this article.

Mapping to SOC 2

The Trust Services Criteria never name a tool or a scan cadence, but three Common Criteria are where external monitoring evidence lands:

• CC7.1 expects you to detect and monitor for configuration changes that introduce new vulnerabilities, and for susceptibility to newly discovered ones. Scheduled external scans of TLS, DNS, headers and exposed services — with a change feed showing what moved between scans — is that control in operation. A port that opened overnight, alerted on the day it opened, is exactly the artifact CC7.1 sampling looks for.
• CC4.1 is the monitoring criterion inherited from COSO: you evaluate whether your controls are working. A posture score trending over months, and findings moving from raised to resolved, is evidence that someone is looking at the monitoring rather than just paying for it.
• CC3.2 covers risk identification. Subdomain discovery from certificate transparency logs is a concrete answer to "how do you learn about infrastructure you did not inventory?" — a question that is otherwise hard to answer honestly.

The practical unit of evidence is the pair: the dated finding and the dated resolution. An auditor sampling three months of alerts wants to see each one acknowledged, fixed, or formally accepted. If your tool lets you mute a finding with a review date, that mute record is a risk-acceptance artifact — keep it, do not be embarrassed by it. Accepted risk with a name and a date reads far better in fieldwork than a suspiciously clean dashboard.

Mapping to ISO 27001:2022

The 2022 revision of Annex A made two controls almost purpose-built for this category of tooling:

• A.8.8 — management of technical vulnerabilities. You need to show how you learn about weaknesses in your infrastructure and what happens next. External scan history with severities and remediation state is the "learn about" half with dated records instead of a described process; your ticketing shows the "what happens next" half.
• A.5.7 — threat intelligence. New in 2022, and many organizations struggle to evidence it without buying a feed they never read. Certificate transparency monitoring and lookalike-domain watching are threat intelligence in the plain sense: external information about emerging threats to you specifically — a cert issued for your domain by a CA you do not use, a typosquat registered last Tuesday — collected and acted on.
• A.8.9 — configuration management gets partial support: an externally observed diff of your DNS records, TLS versions and header policy over time is corroborating evidence that configuration drift is detected, even though the control itself is broader.

Security questionnaires: attach, don't compose

Before most companies ever face an auditor, they face a customer's vendor-review spreadsheet. "Do you perform external vulnerability scanning of your infrastructure?" appears on nearly every one. The weak answer is a paragraph describing intentions. The strong answer is last week's dated report — scope, findings, severities, and the date on the first page — attached as-is. Assessors process hundreds of these; an artifact they can file beats prose they have to evaluate, and it usually ends the follow-up thread before it starts.

Point-in-time proof

Audit requests are frequently retrospective: not "what is your posture," but "what was it in March?" If every scan is retained and any of them exports as a dated PDF, that question is a download. If not, it is an afternoon of reconstruction from screenshots and memory — and reconstructed evidence invites exactly the scrutiny you were trying to avoid.

What external monitoring does not cover

Being clear about scope is part of being credible with an auditor, so: continuous external monitoring evidences the external monitoring rows of a controls matrix and nothing else.

• It is not a penetration test. Passive observation finds misconfigurations and drift; it does not attempt exploitation, and frameworks that expect periodic penetration testing still expect it.
• It is not a PCI ASV scan. PCI DSS requires quarterly external scans by an Approved Scanning Vendor; only an ASV can produce that artifact.
• It does not see inside: authenticated vulnerability scanning, endpoint posture, cloud configuration review and code security are separate controls with separate evidence.
• And no tool makes you compliant. SOC 2 and ISO 27001 assess a management system — policies, people and process. Monitoring output is evidence within that system, not a substitute for it.

An evidence checklist for the next audit

• Scans on a schedule for the entire period — cadence documented, no multi-week gaps you cannot explain.
• Alert trail preserved where it landed (email, Slack, webhook receiver), with timestamps.
• Every sampled finding traceable to a fix or a dated, named risk acceptance.
• A dated report exportable for any month the auditor picks.
• Subdomain inventory fed by certificate transparency, so "how do you find unknown assets?" has an answer.
• The gaps named: penetration testing, internal scanning and ASV scans tracked as their own controls, not assumed covered.

Frequently asked questions