SOC 2 does not set a patch deadline for dependencies. You write your own timeline in policy, then the auditor tests whether you met it. Pick bands by severity, move known exploited flaws to the front, and choose numbers your team can hit in a busy month.
Why there is no standard number
SOC 2 is an attestation by an independent CPA against criteria you describe, not a fixed control list with deadlines. That means a seven day target and a thirty day target can both pass, if each is followed and recorded. What fails is a policy that says seven days with a log full of forty day gaps and no exception records.
Buyers sometimes ask for a number in questionnaires. Give the one in your policy. Do not quote a competitor's number or a number you hope to reach.
Build the bands in three steps
- Start from severity labels in your scanner, such as critical, high, medium and low.
- Add an exploit signal. CISA maintains the Known Exploited Vulnerabilities catalog and recommends organizations use it as an input to their vulnerability management prioritization. A flaw on that list deserves a shorter clock than its severity label alone suggests.
- Add exposure. A vulnerable function you never call, in a dev only tool, is not the same as one in an internet facing service.
Here is a shape many small teams can run. Treat the day counts as placeholders to adjust:
| Situation | Starting target |
|---|---|
| Known exploited, reachable in production | Fix or mitigate within days |
| Critical or high, reachable | A couple of weeks |
| Medium, or not reachable | A monthly cycle |
| Low | Next planned upgrade |
Write your own figures. Whatever you choose, state the clock starts at the date the vulnerability is known to you, such as when the alert fires.
Define what "fixed" means
A fix can be an upgrade, a patch, removal of the package, or a mitigation such as a configuration change. Write that list in policy. Also define the evidence: a merged pull request, a deploy, and a rescan showing the item cleared.
Plan for the dates you will miss
You will miss some. A fix may not exist yet, or the upgrade may break a feature. Your policy should say how to record an exception: owner, reason, compensating control, review date. Keep exceptions short lived and review them at the monthly meeting.
Check your own history first
Before you finalize numbers, pull the last six months of closed vulnerability tickets and measure how long each took. If your median for high severity items is twenty days, a seven day policy is fiction. Write the number you do today, then tighten it as the process matures. Auditors respond better to a modest rule you meet than an aggressive one you do not.
Try it yourself
Open the demo and compare a flaw that is merely present with one that is actually exploitable in context. Think about how that would change your band.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's dependency scanning and reachability analysis help separate vulnerable code you call from code you do not, and its policies can encode your timelines as gates. Free scan: https://gold.safeguard.sh/scan.
Quick check
Is seven days the SOC 2 standard for critical patches?
No. SOC 2 sets no such number. Your policy sets it and your records prove you followed it.
When does the patch clock start?
Define it in policy. A common choice is the time your scanner or an advisory first reports the issue to you.
Sources
Last reviewed: 19 October 2026.
