Ask anyone who has been through a SOC 2 audit what they remember and it is rarely the controls. It is the spreadsheet. Rows of controls, a column for "evidence", and a slow scramble to screenshot settings the week before the auditor arrives.
A chunk of that work is mechanical. Whether HSTS is set, whether TLS 1.0 is still accepted, whether an admin endpoint is exposed, whether dependency CVEs are piling up. These are observable from the outside, on a schedule, without a human taking screenshots.
What an external scan can evidence
NANOTESTING maps each finding onto the Trust Services Criteria it touches. A weak-TLS finding rolls up to CC6.7 (restriction of data transmission). A missing security header rolls up to CC6.8. A disabled dependency alert rolls up to CC7.1. The compliance view shows, per control, whether anything is at risk, whether a check ran and found nothing, and which controls an external scan simply cannot assess.
That last category matters. Physical access, workforce onboarding, and change-management policy are not visible from the public internet, and we do not pretend otherwise. The pack labels them "not assessed" rather than quietly counting them as passing.
Why "not assessed" is the honest default
The fastest way to lose an auditor's trust is to hand them a report that claims 100% coverage from a scan that only touched the external surface. Absence of a finding is not evidence a control is met. Our posture splits every framework into at-risk, assessed-and-clean, and not-assessed, so the number you show is the number you can defend.
The deliverable
Each framework produces an evidence pack with the assessment date, the hosts in scope, the per-control status, and the positive observations that back it up (for example "TLS 1.3 supported, weak versions disabled") with the source tool and timestamp. It is evidence support, not a certification. Your auditor still signs off. You just spend the meeting on the controls that need a human, not on re-screenshotting your TLS config.