A patch management policy fails an audit for one of two reasons: it describes a process nobody actually follows, or it follows a process nobody wrote down. Auditors are not grading your prose. They are checking whether the document matches the tickets, the tickets match the timestamps, and the timestamps match the SLA the policy itself defines. This is a working template for building that alignment, section by section, with the specific clauses that ISO 27001, PCI DSS, SOC 2, and similar frameworks expect to see.
What a patch policy must cover: scope, asset classes, ownership, exceptions
Start with scope, because an auditor’s first question is always “does this apply to the system in front of me?” A policy that says “all company systems” without defining boundaries invites the auditor to test edge cases: contractor laptops, IoT badge readers, the build server nobody remembers provisioning. Define scope by asset class, not by department:
- Servers and network infrastructure (physical and virtual, on-premises and cloud)
- Endpoints (workstations, laptops, mobile devices under MDM)
- Application and middleware layers (runtimes, libraries, containers, orchestration platforms)
- Firmware and embedded devices (network appliances, IoT, out-of-band management interfaces)
- Third-party and SaaS components you configure but do not patch directly
For each class, name an owner role, not a person. “The Infrastructure Team Lead” survives staff turnover; “John from IT” does not, and an auditor who finds a named individual who left the company eighteen months ago will flag the whole document as stale. Ownership should map to who has the authority to approve a patch, not just who technically deploys it, because those are frequently different people and auditors ask for both.
Exclusions belong here too. If end-of-life systems, isolated OT networks, or vendor-managed appliances are out of scope, say so explicitly and state the compensating control (network segmentation, vendor SLA, planned decommission date). An unexplained gap looks like an oversight; a documented and justified exclusion looks like governance.
Defining severity tiers and remediation deadlines that match your risk appetite
Every framework wants to see remediation timelines tied to severity, but few dictate the exact numbers. PCI DSS 6.3.3 is the exception: critical and high-risk patches must be installed within one month of vendor release, which is a useful anchor even if you are not in scope for card data. ISO 27001 Annex A control 8.8 and SOC 2 CC7.1 require a documented process and evidence of timeliness, but leave the thresholds to you, provided they are risk-based and consistently applied.
A workable starting structure ties severity to a CVSS band and adjusts for exploit status and exposure:
| Severity tier | Typical CVSS range | Remediation SLA | Escalation trigger |
|---|---|---|---|
| Critical | 9.0 to 10.0, or lower with known exploitation | 15 calendar days | Active exploit in the wild or internet-facing asset |
| High | 7.0 to 8.9 | 30 calendar days | Asset holds regulated data |
| Medium | 4.0 to 6.9 | 90 calendar days | Repeated finding across two consecutive scans |
| Low | 0.1 to 3.9 | 180 calendar days or next release cycle | None; tracked for trend reporting |
Two clauses make this table audit-proof. First, define the clock start explicitly: patch availability date, scan detection date, or ticket creation date. Auditors will pick a sample and recompute the interval themselves; if your stated clock start does not match your ticketing timestamps, the finding is a policy violation even if the underlying patch was fast. Second, state how severity is adjusted when a vendor score does not reflect real exposure, for example a critical CVSS score on a service that is not reachable from any network segment. Write the downgrade rule as policy (“severity may be reduced one tier when the affected service has no network path to it, with justification recorded in the ticket”) rather than leaving it as an informal judgment call, because undocumented severity overrides are one of the most common findings in patch policy reviews.
Approval, testing and maintenance-window rules written as policy instead of folklore
“We test in staging first” is not a control until it specifies what testing means, who signs off, and what happens when staging is unavailable or does not exist for a given asset class. Write out the testing gate as a decision table: which changes require a staging deployment, which require only a rollback plan, and which (an actively exploited zero-day on an internet-facing host) are allowed to skip standard testing entirely under an emergency change process. Name the emergency process explicitly and cap how long it can be invoked before a retroactive review is mandatory.
Maintenance windows should be defined by asset criticality, not by convenience. A policy that says “patches are applied during the monthly window” without naming what happens to a critical finding discovered on day two of a thirty-day window will not survive a walkthrough. State the out-of-band deployment threshold (for example, any critical-tier finding triggers deployment outside the standard window within the SLA regardless of the maintenance calendar).
Approval is where most policies go vague, and where auditors probe hardest, because unclear approval chains are how unauthorized changes slip through. Specify who approves a standard patch (often automatic, logged, and reviewed retrospectively), who approves an emergency patch (a named role with authority to bypass the standard window), and who approves a deferred or rejected patch (see the next section). Platforms that route these decisions through a formal gate, rather than an email thread or a verbal nod in a stand-up, produce the timestamped approval record auditors ask for on the spot. If your environment already uses staged sign-off for other change types, the same pattern applied to patching through a tool like a dedicated approval gate gives you that record without extra manual logging.
Exception and risk-acceptance clauses that survive an audit
Every environment has patches that cannot be applied on schedule: a vendor dependency that breaks with the update, a legacy application with no maintenance window, a system slated for decommission in ninety days. Auditors do not expect zero exceptions. They expect exceptions to be governed, time-bound, and re-reviewed, and they will treat an exception log with no expiration dates as evidence that the exception process is a rubber stamp.
A defensible exception clause requires, at minimum:
- A named business or technical justification, not “not enough time”
- A compensating control (network isolation, additional monitoring, WAF rule, disabled service) recorded alongside the exception
- An expiration date, after which the exception must be re-approved or the patch applied
- A named approver with the authority to accept residual risk, distinct from the person requesting the exception
- A ceiling: exceptions above a defined severity (commonly critical, sometimes high) require sign-off from a role above the requesting team, such as a CISO or risk committee
Store risk acceptances in the same system that tracks the underlying vulnerability, not in a separate spreadsheet that nobody reconciles against the scan results. When an auditor samples a critical finding and finds a spreadsheet row claiming “accepted risk” with no linked ticket, no expiration, and no compensating control, that single sample can undermine confidence in the entire exception population.
Evidence requirements: what you must be able to show for every patch cycle
Policy language describes intent; evidence proves execution. For each patch cycle, an auditor will typically want to see the scan or advisory that identified the gap, the ticket that tracked remediation with timestamps for detection, approval, and closure, the change record showing what was deployed and to which assets, and confirmation that the fix actually closed the finding rather than merely closing the ticket. That last point is where many programs quietly fail: a ticket marked “resolved” because a patch command returned a success code is not the same as verification that the vulnerable version is gone. Platforms that automate this phase, such as SITEY, re-test the specific finding against the live asset instead of trusting the patch command’s exit status, which produces a closure record with its own evidence rather than an assumption.
Retain evidence for at least as long as your compliance framework’s audit cycle, typically twelve to twenty-four months, and make sure the retention period is written into the policy itself, since “how long do you keep patch records” is a standard interview question. If your process already separates the fix step from the confirmation step, documenting that split under a distinct retest and closure stage gives auditors a clean place to sample evidence without digging through ticket comments.
Finally, map each policy clause to the specific control it satisfies in the frameworks you are certifying against. A short table at the end of the policy, or a separate reference document, that ties “Section 4: Severity Tiers” to “ISO 27001 A.8.8” and “PCI DSS 6.3.3” turns the auditor’s job from interpretation into confirmation, which is the fastest path through a review. Some teams maintain this cross-reference inside their compliance mapping so that a control change updates the linked policy language in one place instead of several.
A one-page policy skeleton you can adapt
The following structure fits on a single page and covers everything above. Fill each section with your organization’s specifics rather than generic language, since auditors can tell the difference between a policy that was written once and copied, and one that reflects an actual running process.
- Purpose and scope. One paragraph stating the policy’s objective and the asset classes it governs, with named exclusions and their compensating controls.
- Roles and responsibilities. A table of roles (not names) mapped to responsibilities: identification, approval, deployment, verification, exception approval.
- Severity classification. Your tier table with CVSS bands, remediation SLAs, and the clock-start definition.
- Testing and approval workflow. The decision table for which changes require staging, who approves standard versus emergency patches, and the emergency change cap.
- Maintenance windows. Standard cadence and the out-of-band trigger for critical findings.
- Exceptions and risk acceptance. Justification requirements, compensating controls, expiration, and approval ceiling by severity.
- Evidence and retention. What is recorded per cycle, where it is stored, retention period, and the framework control mapping.
- Review cadence. How often the policy itself is reviewed and by whom, typically annually or after a material infrastructure change.
Once this skeleton is filled in, the remaining work is operational discipline: keeping the SLA clock honest, keeping the exception log current, and keeping evidence tied to the ticket rather than scattered across email. A policy this specific is harder to write than a generic template, but it is also the version an auditor can actually verify in an afternoon instead of pushing back with follow-up questions for a month.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.