Synced 16 Jun 2026 15:24 UTC Account
← All guides

SOC 2 & ISO 27001: evidencing vulnerability & patch management

Audit evidence · 7-min read · Open compliance editions → · updated June 2026

Auditors don't want promises — they want evidence. The good news: SOC 2 and ISO 27001 ask for largely the same artefacts for vulnerability management, just in different words. Produce them once, present them per control.

What maps to what

ControlWhat it expectsEvidence to show
SOC 2 CC7.1Detect vulnerabilities & anomaliesInventory + scan/monitoring output, risk-ranked
SOC 2 CC8.1Manage changes & patchesRemediation records with owners + dates; re-verification
ISO 27001 A.8.8Manage technical vulnerabilitiesDefined process, timely risk-based action, records
ISO 27001 A.5.21ICT supply-chain securityComponent inventory (SBOM) + third-party vuln tracking

The evidence checklist

  • A current inventory of assets/products and components — see reading an SBOM.
  • A risk-ranked findings list (exploited-first) — see prioritising patches.
  • Remediation records: what, who, when, and the decision (patched / mitigated / accepted).
  • Re-verification that fixes landed.
  • Trend reporting over time — see building a VM program.
One source, many frameworks: IsItPatched's compliance editions generate exportable evidence packs for 16+ standards from the same underlying data — so a single stack assessment serves SOC 2, ISO 27001 and more.

Turn this into action. What auditors actually want to see for CC7.1 / CC8.1 and Annex A 8.8 — and how to produce that evidence without a spreadsheet marathon.

Open compliance editions — free →

Frequently asked questions

What do SOC 2 auditors want for vulnerability management?

Evidence that you detect vulnerabilities (Trust Services Criteria CC7.1) and manage changes/patches through a controlled process (CC8.1): a current inventory, a risk-ranked list, remediation records with dates, and proof you re-verify.

Which ISO 27001 controls apply?

Primarily Annex A 8.8 (management of technical vulnerabilities) and A.5.21 (managing ICT supply-chain security). Auditors look for a defined process, timely action proportional to risk, and records.

Do I need a separate tool per framework?

No. The underlying evidence — inventory, prioritised findings, remediation history — is largely the same; frameworks just ask for it in their own vocabulary. Produce it once, present it per control.

How does IsItPatched help?

It produces the prioritised findings and exportable evidence packs that map to these controls — see the compliance editions and My Stack exports. It is supporting evidence, not a certification.

This guide is informational and maps common control intentions to practical evidence. It is not audit, legal or certification advice; confirm scope and sufficiency with your auditor. See our disclaimer.

← Browse all guides · Security glossary →