Guide

Overdue vulnerabilities in Drata or Vanta: what to do before the audit

Your compliance platform gives every vulnerability a deadline. When criticals and highs pass it, the platform shows it, and your auditor can see it too. Here is how the deadlines work in Drata and Vanta, and what your options are.

Updated 2026-10-26 · Railo

The short answer

Drata gives each vulnerability a deadline from your Vulnerability Management Policy, or from its defaults (7 days for critical, 30 for high) if you have none. Its Critical and High Vulnerabilities Addressed tests fail while vulnerabilities of that severity remain open. Vanta starts the clock when it first detects a vulnerability, and a later change to your SLA applies only to new detections. Neither platform fixes code. The way out is to fix and merge the findings, or to record a risk acceptance your policy allows.

Drata: default deadlines and the tests

Drata applies these defaults when no Vulnerability Management Policy is configured (Drata help: Vulnerabilities):

Drata default vulnerability SLAs
Severity	Default deadline
Critical	7 days
High	30 days
Medium	90 days
Low	180 days

Critical Vulnerabilities Addressed (one test per connected scanner) fails if one or more critical vulnerabilities remain open.
High Vulnerabilities Addressed fails if one or more high-severity vulnerabilities remain open.
Drata states that it does not remediate vulnerabilities. It tracks status, deadlines and compliance impact.

Vanta: when the clock starts

The deadline is counted from the exact time Vanta first detects the vulnerability.
Changing your SLA settings applies only to newly detected vulnerabilities. Open ones keep the deadline they had, so a longer SLA does not rescue what is already overdue.
Business-day SLAs skip weekends but still use the exact detection time; business hours are not supported.
The History tab records SLA misses and the remediation activity used for audit evidence.

Source: Vanta help: How Vanta calculates vulnerability SLAs (updated 22 July 2026). The article gives an example window but no default for every account, so check the SLA in your own policy.

Why this matters for the audit

In a sample of 75 SOC 2 audits from January 2025 to June 2026, Lazarus Alliance found exceptions in vulnerability and configuration management in 24% of them (18 of 75). The typical cause was remediation that missed the stated deadline without a documented risk acceptance (2026 SOC 2 Audit Benchmark Report). It is one firm's sample, but it shows what auditors look at: the deadline your own policy sets, and what happened when it passed.

Your options when findings are overdue

Fix and merge. Start with criticals, then highs. Once the fix is merged and deployed, the next scan should show the finding closed. Keep the pull request, its reviewer and the merge date.
Accept the risk, in writing, if your policy allows it. Record why the finding cannot be fixed now, who approved that, and until when. Whether that satisfies the control is your auditor's call.
Remove false positives properly. If a finding is not real, mark it in the scanner with the reason, so the record explains itself.
Fix the process for next time. Most backlogs grow because nobody owns fixing between releases. Assign an owner and a weekly review of anything near its deadline.

The records to keep for each fix

Records commonly kept for each vulnerability fix
Record	What it shows
The finding, with its first-detected date	When the deadline started
The pull request	What changed, and where
Reviewer and approval	That the change was reviewed before it shipped
Merge or deploy date	When the fix took effect, against the deadline
A rescan or test result	That the finding is gone and nothing new appeared

See what SOC 2's CC7.1 and CC8.1 say about these records, or a real evidence pack with one row per finding.

Have findings to clear?

Railo fixes overdue findings as pull requests your team reviews, within one week, and hands back the records above for each one. USD 1,500 per repository, up to 25 findings.

Start a Fix Sprint