Guide

Vulnerability remediation evidence for SOC 2

What the SOC 2 criteria say about fixing vulnerabilities, the records teams usually keep for each fix, and the gaps that turn into audit exceptions.

Updated 2026-10-26 · Railo

The short answer

SOC 2 does not set a deadline for fixing vulnerabilities. Under CC7.1, one point of focus is that the organisation scans for vulnerabilities and “takes action to remediate identified deficiencies on a timely basis”. Your own policy defines “timely”. Under CC8.1, changes are authorised, tested and approved before they ship. So for each finding, teams usually keep the finding, the change that fixed it, its review, the date it took effect, and a rescan.

What the criteria say

CC7.1 asks that the organisation uses detection and monitoring to find configuration changes that introduce vulnerabilities, and susceptibilities to newly discovered ones. Its point of focus “Conducts Vulnerability Scans” covers periodic scans, scans after significant changes, and timely remediation.
CC8.1 covers how changes to infrastructure, data, software and procedures are authorised, designed, documented, tested, approved and implemented. A security fix is a change like any other.
Neither gives a number of days. Compliance platforms supply defaults instead: Drata, for example, uses 7 days for critical and 30 for high when no policy is set (Drata help).

Source: AICPA, 2017 Trust Services Criteria, TSP section 100. Quotes are from the edition with the March 2020 updates. The points of focus were revised in 2022, so check the edition your auditor uses.

The records teams usually keep

Evidence commonly kept for vulnerability remediation
Record	Criterion it supports	Where it usually lives
Vulnerability management policy with deadlines by severity	CC7.1	Policy documents, your compliance platform
Scan results across the audit period	CC7.1	Your scanner, synced to the compliance platform
Each finding with its first-detected date	CC7.1	Scanner or ticket
The change that fixed it	CC8.1	Pull request
Review and approval of that change	CC8.1	Pull request review
Merge or deploy date	CC7.1 and CC8.1	Git history, deploy log
A rescan showing the finding gone	CC7.1	Scanner, or a rescan recorded with the fix
Documented risk acceptance for anything not fixed in time	CC7.1	Ticket or risk register

This is what teams commonly keep, not a list from the AICPA. Your auditor decides what evidence they need.

Gaps that turn into exceptions

Findings fixed after the policy deadline, with no documented risk acceptance.
Fixes pushed straight to the main branch without review, which leaves no approval record.
Findings closed in the scanner with nothing linking them to the change that fixed them.
A policy that promises deadlines the team has never met.

If your platform already shows overdue findings, see overdue vulnerabilities in Drata or Vanta.

A sample evidence pack

A Railo Fix Sprint ends with one row per finding: what was found, where, what happened to it, who fixed it, how the fix was checked, and the pull request it merged in. See the pack from our rehearsal sprint on OWASP NodeGoat on the sample evidence page, or download the CSV.

It is a record, not a certificate. It does not make anyone compliant, and it does not replace your auditor's judgement. The audit evidence page lists what Railo records for every fix.

Have findings to clear?

If your audit window is closing with findings still open, we fix them as reviewed pull requests within one week and hand back the records above. USD 1,500 per repository, up to 25 findings.

Start a Fix Sprint