How fast do you need to patch critical vulnerabilities for SOC 2?

SOC 2 does not specify a patching deadline. The criteria require you to identify vulnerabilities, rank them by risk and remediate them in line with your own documented policy, which means the number you write down becomes the number your auditor tests against. Most B2B software companies land on 7 to 15 days for critical findings, 30 days for high and 90 days for medium, with a separate emergency path for anything under active exploitation.

Your policy sets the clock, so pick a number you can hit

The most common finding I see in readiness work is not a slow patch. It is a policy promising 24 hour critical remediation written by a team that patches on a two week release train. An auditor samples your vulnerability reports, checks the dates and compares them to the commitment. A 15 day window you meet every time tests clean. A 24 hour window you miss twice becomes an exception in your report, and enterprise buyers read exceptions.

Three things make a window defensible:

• A severity scale you actually apply. CVSS base score alone is not enough. Note whether the asset is internet facing and whether exploit code is public.
• A documented exception process. If you cannot patch in time, record why, who approved it, what compensating control is in place and when you will revisit.
• Evidence that falls out of normal work. Scanner exports, ticket timestamps and change records, not a spreadsheet someone rebuilds the week before fieldwork.

A window for every severity, and when the clock starts

A remediation policy needs more than one number. Write a window for each severity level and say plainly what starts the clock, because that is the first thing an auditor will ask when a sampled finding looks late. If you are still setting up the process itself, start with how to run vulnerability management and come back to the numbers. A workable starting point for a SaaS company on a regular release cycle:

• Critical: 7 to 15 days from detection, shortened to the emergency path when the flaw is under active exploitation or sits on an internet facing asset.
• High: 30 days from detection.
• Medium: 90 days, or the next scheduled maintenance window if that comes first.
• Low: tracked and fixed on a best effort basis, reviewed quarterly so they do not accumulate forever.

Start the clock at detection, meaning the date your scanner, your vendor advisory feed or a test report first told you about the issue in your environment. Starting it at the public disclosure date sounds stricter but is unmeasurable for most teams, and starting it at the date someone triaged the ticket invites the obvious question of how long the ticket sat untriaged. Whatever you pick, write it into the policy so the auditor and your engineers are reading the same definition.

Adjust severity for context rather than taking the scanner's label as final. A critical CVE in a library your application never loads is not the same risk as a high severity flaw on your login page. Document the adjustment in the ticket, with the reasoning, and the auditor will usually accept it. Silent downgrades are what turn into findings.

How an auditor tests the window

In a Type II audit, the auditor will pull a population of vulnerabilities identified during the observation period, usually from your scanner or your ticketing system, and select a sample. For each item in the sample they want four dates: when it was found, how it was rated, when it was fixed and how the fix was verified. They compare the gap against your policy. If the gap is over the window and there is no approved exception, that item is a deviation.

A few deviations in a large population may still produce a clean opinion, but they will be described in the report, and that section is exactly where a buyer's security team looks first. The practical lessons follow from how the test works:

• Verification is part of the fix. Close a ticket only once a rescan or a version check confirms the vulnerability is gone. A ticket closed on a deploy that did not actually remove the flaw is a deviation waiting to be sampled.
• Your scanner coverage defines your population. If an asset is not scanned, its vulnerabilities are not in the sample, but they are still in scope for the control. An auditor who notices an unscanned production host will ask why, which is why an asset inventory for SOC 2 comes before the scanner.
• Penetration test findings count. Findings from your annual test are vulnerabilities too, and they should enter the same tracking and the same windows as scanner results.

Carve out an emergency path separate from the normal window

Routine windows assume you have time to test. Some weeks you do not. The php2shell vulnerabilities reported by Krebs, CVE-2026-109618 and CVE-2026-109619, give an unauthenticated attacker full control of an affected server, working exploits exist and the bugs are already being exploited. When the flaw sits below your application, nothing in your code protects you, so the usual release cadence is the wrong tool.

Write an emergency clause into the policy now: a named trigger such as active exploitation or an advisory from CISA or the Canadian Cyber Centre, a named decision maker, authority to ship out of band, and a requirement to log the decision. Auditors respond well to this because it shows the risk ranking is real rather than a table nobody reads.

The assets you forgot are the ones that miss the window

Patching speed is mostly an inventory problem. The marketing site on a separate host, the legacy admin panel, the thing a contractor stood up in 2019 and nobody decommissioned: none of those are in the pipeline that patches your product, and all of them are in scope for an incident. Before you argue about days, reconcile what is running against what you think is running, including subdomains and anything with a public DNS record.

Extend the same question to subprocessors. A compromised vendor host is still your incident to report under most customer contracts and under PIPEDA breach obligations. Ask your critical vendors what their critical remediation window is and whether they will notify you when they invoke an emergency patch. Collect those answers during annual vendor review so you are not sending cold emails mid incident. More on readiness scoping sits under SOC 2.

Common questions about SOC 2 patching timelines

Does SOC 2 require a particular vulnerability scanner?

No. It requires that you identify vulnerabilities on a defined cadence and act on them. Any scanner that covers your production assets and keeps dated results will do. What matters is coverage and that the output is retained for the whole observation period.

What if the vendor has not released a patch yet?

Record that in the ticket, apply whatever mitigation the vendor or the advisory recommends, such as disabling the affected feature or restricting network access, and raise a formal exception with a review date. The window is met by the documented decision, not by pretending the patch exists.

Do these windows need to match ISO 27001 or PCI DSS?

ISO 27001 lets you set your own timescales, much like SOC 2. PCI DSS is more prescriptive for in scope systems: critical security patches are expected within one month of release. If you hold more than one framework, set the policy to the strictest one so a single process satisfies all of them.

Is a vulnerability scan the same as a penetration test for SOC 2?

No. A scan is automated and runs often, and it finds known weaknesses across your estate. A penetration test is a person trying to chain weaknesses together on a defined scope, usually once a year. Auditors and buyers expect both, and the difference between a penetration test and a vulnerability scan matters when you decide what each one feeds into your remediation windows.