Every SOC 2-style audit comes down to evidence. Reviewers do not ask whether you believe you are secure; they ask what you can show, dated and repeatable, that your controls actually ran. Vulnerability management is one of the areas they inspect most closely, and VAPT, short for vulnerability assessment and penetration testing, is the toolset that produces the evidence. The gap between teams that pass comfortably and teams that scramble is rarely the size of their budget. It is whether their testing was designed to leave an audit trail.
This guide covers what VAPT and SOC 2 actually require of each other, which testing activity produces which piece of evidence, and how to build a file a reviewer can work through in an afternoon. It does not promise certification: no scanner certifies you, and no report replaces a formal audit. What good evidence does is shorten and smooth the path to one.
VAPT folds two activities into a single programme. The vulnerability assessment is the automated, broad layer: it inventories what you expose, checks it against known issues, and hands you a ranked list of fixes. The penetration test is the human, deep layer: a tester actively tries to exploit the most important targets to prove what an attacker could achieve. As separate services they were covered in our guide to penetration testing and vulnerability assessment, so the short version here is the division of labour. The assessment owns breadth and continuity. The test owns depth and confirmation.
| Layer | What it produces | Evidence value | Typical frequency |
|---|---|---|---|
| Vulnerability assessment | Asset inventory, scanned findings, severity rankings | Dated, repeatable records of the control running | Weekly to monthly |
| Penetration test | Confirmed exploitable paths, impact narrative, report | Human-reviewed assurance on key targets | At least annually |
| Remediation follow-up | Ticket records, retest results, closure dates | Shows findings were actioned, not just filed | After each finding |
The phrase "audit-ready" means the output of each layer survives being reviewed by someone who was not there when the work happened. Three properties make that true, and they are worth checking against whichever testing programme you already run.
A reviewer's first question about any artifact is when it was produced and what it covered. A scan from six months ago with no target list is not evidence of a control running; it is a historical curiosity. Every report in your VAPT file should state the date of the testing window, the exact assets covered, and the method used, so the reviewer can map the record to the control description in your policies.
This matters more than it sounds. SOC 2-style criteria describe controls in terms of frequency and scope, and your evidence must show the criterion and the execution line up. If your policy says monthly external scanning but your file contains three reports in the last year, the control is not evidenced regardless of how thorough those three reports were. An automated assessment is cheap to run, which is exactly why repeatable frequency is achievable and expected.
The second thing reviewers look for is what happened after discovery. A findings list is a starting point; a closed findings list is evidence. The strongest vulnerability management records show each finding moving through a visible lifecycle: discovered, triaged, actioned, retested, and closed, with dates at every step.
This is also where the quality of the initial evidence decides outcomes. If every Critical and High finding carries reproducible exploit evidence, triage is fast and defensible, and there is no debate about whether the finding was real. If the list is full of unverifiable version-string guesses, you spend the audit explaining false positives instead of showing fixes. Proof-backed scanning, the standard we build our own reports around, is genuinely easier to audit because each finding carries the request, the response, and the payload behind it. Our detailed guide to proof-backed security scanning walks through how reproducible evidence is what separates a finding you can act on from one you can only argue about.
The final piece of the evidence file lives outside the scanner: the remediation records. Tickets, change notes, and the retest report that confirms a fix held are what turn a scan history into a compliance story. Reviewers want to see that the process is a loop, not a stack of reports. The retest hook is the detail that separates mature programmes from cosmetic ones, because it shows someone checked that the fix survived rather than assuming it did.
If you run an external assessment with proof-based findings, the retest step is straightforward: rescan the affected asset, confirm the finding is gone, and keep the before-and-after pair in the file. That pair is the single most convincing artifact in vulnerability management evidence, because it shows detection and correction with nothing left to interpretation.
SOC 2 criteria are written around activities, and the common criteria that touch vulnerability management are easy to recognise even before you read your trust services report cover to cover. They cluster around the system being monitored for problems in its operation, which is the vulnerability scanning and review activity, and around threats being identified and new information being acted on, which is the penetration testing and patch response activity. Your VAPT programme feeds both.
The mapping is not complicated, but it has to be written down. For each criterion you claim, state which VAPT activity produces the evidence, where it is stored, and who reviews it. A one-page mapping table in your evidence index stops a reviewer from having to reconstruct your process, and a reviewer who does not have to reconstruct it is a reviewer who finishes on schedule.
Two parts of the scanning stack deserve special mention in this mapping because reviewers probe them most often. First, the depth of coverage: if your assessment scans the public surface only, say so, and pair it with an internal or credentialed check if the criterion expects one. Second, how severity is assigned. A report that ranks findings with an industry-standard score such as the Common Vulnerability Scoring System (CVSS), and references known issue records like those in the National Vulnerability Database (NVD), is far easier to defend than one using a black-box proprietary number. Standards travel, which is exactly what an external reviewer needs.
An audit-ready file does not need to be large, but it needs to be organised. A structure that works well in practice is one folder per reporting period, containing four things:
The management summary is worth writing carefully, because it is usually the first thing a reviewer reads, and it shapes how every document after it is judged. It does not need to claim perfection. Honest summaries that say what was found, what was fixed, and what was accepted as residual risk are more credible than glossy ones that imply the surface never had a problem, because every reviewer has seen a surface that does.
For a startup or SaaS team, the challenge with VAPT and SOC 2 is that the full set of controls usually descends from enterprise practice: millions in tooling, a dedicated security function, and a year of effort. The criteria themselves do not require that shape. They require evidence that testing runs, findings are handled, and the loop is documented. That is achievable at startup scale, and it looks like this.
Run your external attack surface scan every month, which costs little and continuously documents what the internet can reach. Aim the annual penetration test at the assets that would hurt most if compromised, which is where human effort pays off. Keep the remediation ledger in your normal ticketing tool, so closing a finding is indistinguishable from closing any other security task. Together these three habits produce the dated, scoped, repeatable evidence a SOC 2-style audit wants, from infrastructure that a two-person team can actually operate.
Not on its own. SOC 2-style criteria commonly expect both vulnerability management and, at minimum, annual penetration testing. An automated assessment covers the vulnerability management layer, but a human-led test is typically still expected. Run the assessment continuously and the penetration test annually, and feed the results into one evidence file.
Dated scan results, a prioritized findings list, evidence that unverified findings were confirmed or downgraded rather than dropped, remediation tracking, and a retest confirming fixes held. The report should show when testing ran, what it covered, and how findings moved from discovery to closed.
SOC 2 itself does not prescribe a fixed interval; your service organization picks an interval and documents it. Common practice for an internet-facing control is a scan at least monthly, with a fresh scan whenever a major change lands. What matters to a reviewer is that the interval is written down and followed.
One scanner covers the vulnerability management layer, not the whole system. The evidence file also needs the penetration test report, remediation records, and the policies that say how often testing runs and who decides when something is fixed. The scanner produces a strong input; the programme around it produces the compliance story.
VAPT and SOC 2 are a strong pair because each supplies what the other would otherwise have to guess. SOC 2 gives the testing programme a reason to run on a documented schedule, and VAPT gives the audit dated, scoped evidence that the control is real. The teams that sail through tend to be the ones who designed their testing to leave a trail from the start: consistent frequency, proof-backed findings, a visible remediation loop, and a one-page summary that answers the questions before they are asked. Certification is still a formal event, but with the right evidence, it becomes a presentation rather than a rescue.