FillTrust

How to answer

How quickly do you patch known vulnerabilities?

The question is not whether you patch. It is whether you can name the window and show that you meet it.

A model answerImplied, not stated

We scan our production infrastructure and application dependencies continuously. Critical vulnerabilities are remediated within [7] days, high within [30] days, and medium within [90] days, measured from the date the finding is triaged.

Square brackets are yours to fill in. FillTrust grades an answer like this implied, not stated when your documents support it.

Answered from
Your vulnerability management policy, and the change or patching section of your SOC 2 report.
Evidence to attach
Occasionally a redacted scan report, or a screenshot of your scanner showing current findings by severity. A reviewer asking for this is usually checking that the tool exists, not reading the findings.
Where it is asked
CAIQ v4.0 · TVM-03SIG LiteISO 27001 Annex A · A.8.8

Every questionnaire asks some version of this, and it is one of the few where a specific number is better than a careful sentence. Reviewers are looking for a documented window per severity, because that is the thing that can be audited later.

The trap is that a target is not a measurement. Writing "critical vulnerabilities are patched within 24 hours" costs nothing and commits you to something you may not do. If your last critical finding sat for nine days because the fix was in a vendor dependency, the honest answer is a 7-day window with an exception process, not a 24-hour window you missed. Reviewers meet the first answer constantly and the second one rarely, and the second one is the one that survives a follow-up.

Say what the clock starts on. There are three reasonable answers: public disclosure, the scanner surfacing it, or your triage deciding it applies. They can differ by a week for a dependency buried three levels down. Pick one, write it in the policy, and answer with it.

Cover the whole estate or say which part you mean. Application dependencies, container base images, the operating systems under your workloads, your CI runners and your employees' laptops are five different patching problems with five different owners, and a company of fifteen people usually has an honest answer for two of them. Answering for the two you have and naming the rest as managed by the platform is a stronger position than an unqualified yes.

Where this usually lands as "implied". Most small teams have a scanner running and a habit of fixing things quickly, and no written window at all. FillTrust will find the scanner in your documentation and infer the rest, which is exactly the case the grade exists for: your documents suggest a practice they never state. Writing the window down once turns this question, and the four others that ask it differently, into a confirmed answer for good.

How this one goes wrong

Specific to this question, not general advice.

  • Quoting a target you do not measure. "Critical within 24 hours" is easy to write and impossible to evidence, and the follow-up question is always what your actual mean time to remediate was last quarter.
  • Answering for the application and forgetting the base images, the CI runners and the laptops. A questionnaire that asks about patching usually means the whole estate.
  • Treating the SLA clock as starting at disclosure. Reviewers expect it to start when the finding reaches you, and expect you to say which you mean.

There are another two hundred of these in the file.

FillTrust drafts every one from your own documents and shows the passage behind each answer, including the ones it refuses to answer.

Or write this answer down once and publish it on a Trust Center of your own, which costs nothing.