Evidence collection for auditors from scan histories is the part of compliance work that most infrastructure teams underestimate until the auditor sends their first sample request. If you run external port scans continuously but have never had to turn that data into audit evidence, this article covers what auditors actually ask for, how to organize scan history so it holds up under scrutiny, and which mistakes cause findings even when your network was secure the whole time.
The immediate benefit is time. Teams that set up their evidence trail before fieldwork usually answer sample requests in hours. Teams that don’t can lose two or three weeks rebuilding history from logs, screenshots and memory.
What Auditors Want to See in Scan Records
An auditor isn’t checking whether you own a scanner. They’re checking whether a control worked as described for the entire audit period. For a SOC 2 Type II engagement that period is usually 6 or 12 months. Under PCI DSS v4.0.1, requirement 11.3.2 asks for external vulnerability scans at least once every three months, done by an Approved Scanning Vendor, plus rescans after any significant change.
Good scan evidence answers four questions. What was scanned, when, what was found, and what happened next. A scan report showing port 3389 open on a production IP is only half of it. The auditor also wants the ticket that closed it, the follow-up scan showing the port filtered, and the name of the person who approved the change.
Most frameworks ask for the same thing in different words. ISO/IEC 27001:2022 Annex A control 8.8 covers management of technical vulnerabilities, and 8.20 covers network security. If you need to map scan activity to specific controls, the guide on aligning port monitoring with ISO 27001 controls walks through the mapping.
Myth: One Clean Scan Before the Audit Is Enough
This is the most common misconception, and it causes real exceptions. Plenty of teams run a full external scan two weeks before fieldwork, fix everything it finds and hand over a spotless report. For a SOC 2 Type I or a point-in-time ISO certification check, that can work.
For anything that tests operating effectiveness over time, it doesn’t. A Type II auditor samples dates across the period, for example March 14, June 2 and September 27, and asks for evidence from each one. A single recent report proves nothing about February. Worse, a gap in scan history combined with a recent cleanup often reads as “the control wasn’t operating” and gets written up as an exception.
Continuous history is the fix, and it’s why continuous port monitoring matters for compliance more than any single deep scan.
Building an Audit-Ready Scan History Step by Step
An experienced GRC lead starts by agreeing on scope with the auditor before collecting anything. Which IP ranges, which hostnames, which period. If you skip this, you’ll collect evidence for 40 IPs and then discover the auditor’s sample includes a load balancer address nobody put in the inventory.
From there, the process that works in practice looks like this:
1. Freeze the asset inventory. Export the list of in-scope public IPs and hostnames with the date of export. Note every address added or removed during the period and why.
2. Export scan results in their native format. Keep the raw output, such as Nmap XML, JSON or CSV, next to any PDF summaries. Auditors rarely read XML, but having it proves the PDF wasn’t edited.
3. Hash and timestamp each export. A SHA-256 hash recorded at export time, stored apart from the files themselves, makes tampering obvious. Make sure scanner clocks sync via NTP and record timestamps in UTC.
4. Link every finding to a remediation record. Each new open port should point to a Jira, ServiceNow or GitHub issue with open and close dates.
5. Pair findings with verification scans. The closing proof is a later external scan showing the port closed or filtered, not a comment saying “fixed”.
That’s the one list in this piece for good reason. Everything else is judgment.
A Realistic Sample Request and How It Plays Out
Picture a 30-person SaaS company in its first SOC 2 Type II audit with a 6-month window. The auditor picks three dates and one population: “all new externally reachable services detected during the period”. The scan history shows 11 such events.
Nine are easy. Each one has a detection timestamp, a ticket, a change approval and a follow-up scan. Two are messy. A developer opened TCP 9200 for an Elasticsearch test cluster on a Friday and closed it the next Tuesday, and nobody filed a ticket. The port is closed now, but there’s no record of who decided it should be.
This is a recoverable situation. The team writes a short incident note that refers to the detection alert, the commit that changed the security group and the closing scan. The auditor accepts it with a minor observation instead of an exception. Without the scan history showing both the open and closed states, the team would have had nothing to reconstruct from.
Common Mistakes When Preparing Scan Evidence
The first mistake is relying on screenshots of dashboards. A screenshot shows the current state of a web interface, often without a visible date, and can’t be checked against anything. Auditors at the larger firms increasingly reject them for operating-effectiveness testing. Export the underlying records.
The second is letting retention settings eat the evidence. A scanner that keeps 90 days of history is useless for a 12-month audit window if nobody archived the older data. Check retention on day one of the period, not in month eleven. PCI DSS requires at least 12 months of audit log history, and most auditors expect scan records kept for a similar length.
The third is treating accepted risk as undocumented risk. Some open ports are supposed to be open – 443 on a web tier, 25 on a mail relay, UDP 51820 for WireGuard. If your documented port policy doesn’t list them, every scan shows them as unexplained findings. A one-page register of approved ports with owners and business reasons turns noise into evidence of a working control.
Edge Cases Where Standard Advice Changes
Air-gapped and on-prem-only environments have little or no public footprint, so external scan history may show almost nothing. That’s still evidence. A record of repeated scans showing zero reachable services is a valid control artifact, but pair it with internal scan data and firewall rule reviews.
Teams under 10 people often can’t separate duties between the person who opens a port and the person who approves it. Auditors usually accept compensating controls here, such as automated alerting to a shared channel plus a monthly review signed by a founder. For PCI scope, note that internal scan results never replace ASV reports. Your own scan history supports the story, while the ASV attestation is still required. The specifics are covered in the article on port monitoring in SOC 2 compliance.
Cloud environments with autoscaling create another wrinkle. IPs come and go hourly on AWS, Azure and GCP. Scope by tag, account or Elastic IP allocation, and explain the method to the auditor up front instead of handing over a list that’s already out of date.
FAQ
How long should scan history be retained for audit purposes?
Keep at least the full audit period plus one quarter, which in practice means 12-15 months for most SOC 2 and PCI DSS programs. Regulated financial entities under DORA or national banking rules often keep records for 5 years.
Do auditors accept automated scan reports without manual sign-off?
Usually yes for the detection part, but they also expect evidence of human review. A dated review record, such as a monthly ticket or meeting note confirming someone looked at the results, covers this.
What if the scan history has a gap of several weeks?
Disclose it before the auditor finds it. Explain the cause, show any compensating evidence like firewall change logs from that window, and describe what changed to prevent it happening again.
Final Practical Tip
Run a mock sample request against your own scan history halfway through the audit period. Pick three random dates and one new-port event, then try to produce full evidence within an hour. Whatever slows you down, like a missing ticket link, an unhashed export or a retention gap, is exactly what would have turned into an audit finding. Fixing it in month three costs almost nothing. Fixing it during fieldwork costs weeks.