What is your patch management policy and SLA?

How to answer this security questionnaire question, with an expert response your security or GRC team can adapt.

Expert answer

Define patch SLAs by severity, for example critical patches within days and others within weeks, and track compliance against them. Expedite emergency patches for actively exploited vulnerabilities.

What the security reviewer is checking

Reviewers want a defined, severity-tiered remediation timeline — not a promise that you "patch promptly." They check whether your SLAs are realistic (critical vulnerabilities in days, not hours you cannot meet), whether scanning is continuous or ad hoc, and whether there is an exception process when a patch cannot be applied. A mature answer distinguishes between operating system patching, third-party dependency updates, and emergency out-of-band fixes for actively exploited vulnerabilities, and explains who owns each. Auditors frequently sample tickets to confirm the stated SLA matches reality, so never claim timelines your tracking data cannot support.

Example response you can adapt

This is an illustrative template, not a real vendor's security posture. Replace every claim with what is actually true for your organization before submitting it.

We maintain a documented vulnerability and patch management policy with severity-based remediation SLAs measured from detection: critical (CVSS 9.0+) within 72 hours, high within 7 days, medium within 30 days, and low within 90 days. Vulnerabilities under active exploitation, including those on the CISA Known Exploited Vulnerabilities catalog, are treated as critical regardless of CVSS score. Infrastructure is scanned continuously with an authenticated vulnerability scanner, and application dependencies are monitored through automated software composition analysis in CI. Because our platform runs on immutable container images, most patches ship by rebuilding and redeploying images rather than patching live hosts. Remediation is tracked in our ticketing system with SLA dashboards reviewed weekly by engineering leadership, and any exception requires a documented risk acceptance with compensating controls and an expiry date.

Evidence reviewers expect you to attach

Vulnerability and patch management policy with the severity/SLA table
Recent vulnerability scan summary showing open findings by severity and age
SOC 2 report section covering vulnerability management (typically CC7.1)
Sample remediation tickets or an SLA compliance dashboard export
Dependency scanning configuration evidence (e.g., SCA tool reports from CI)

Follow-up questions reviewers ask next

What percentage of vulnerabilities were remediated within SLA over the last quarter?
How do you handle zero-day vulnerabilities that have no vendor patch available?
Who approves risk acceptances when a patch cannot be applied on time?
Do the same SLAs apply to third-party and open-source dependencies?
How quickly can you deploy an emergency patch to production?

Answer every security questionnaire in minutes

Wolfia drafts accurate, cited answers to security questionnaires and RFPs from your existing documentation. See it work on your own questions.Book a demo