Most vulnerability management policies fail for one of two reasons. Either they are so vague that nobody can point to a line and say “this is what we broke,” or they are so packed with operational detail that the document is obsolete the week a scanner vendor changes. A policy that survives an audit and actually changes behavior sits between those two failure modes: firm enough to assign accountability, general enough to outlive a tool migration. Below is what belongs in each section, why auditors and engineers both reject the versions that skip it, and a structure you can copy directly.
Policy vs standard vs procedure: what belongs where
The single most common structural mistake is collapsing three documents into one. A policy states intent and authority: who is required to run vulnerability management, why, and under what governance body. A standard carries the numbers: CVSS thresholds, remediation SLAs, scan frequency. A procedure carries the steps: which tool triggers the scan, which queue a finding lands in, who clicks approve.
Keep them separate because they change at different speeds. A policy should survive years with only a signature-date update. A standard gets revisited when the threat landscape shifts, for example when CISA adds a new entry to the Known Exploited Vulnerabilities catalog and your organization decides that KEV membership now overrides CVSS score for SLA purposes. A procedure changes whenever you swap a scanner or reassign a team. If your SLA table lives inside the policy document, every SLA adjustment forces a full governance re-approval cycle, and teams quietly stop updating it. Put the mandate in the policy, the thresholds in a linked standard, and the click-by-click steps in a procedure or runbook that security engineering owns without board sign-off.
Purpose, scope and which assets are in and out
The purpose section should name the drivers in one paragraph: reducing exploitable exposure, and meeting the specific clauses that require it, such as ISO 27001 Annex A control 8.8, PCI DSS Requirement 11, SOC 2 CC7.1, GDPR Article 32, or, for organizations under Turkish jurisdiction, KVKK and BDDK information systems regulations. Naming the clause matters during an audit; “we do vulnerability management because it’s good practice” does not hold up as evidence of a control.
Scope is where policies lose enforceability fastest. Listing hostnames or IP ranges guarantees the document is wrong within a quarter. Instead, define asset classes: internet-facing web applications, internal production servers, cloud workloads and containers, network and security appliances, and any third-party or vendor-hosted system that processes regulated data. Then state explicit exclusions with a reason, for example acquired subsidiaries pending technical integration, or ephemeral development environments that never touch production data. Point the scope clause at your asset inventory as the source of truth rather than re-enumerating assets in the policy text, so scope updates automatically when the inventory changes instead of requiring a document revision.
A scope clause without an owner list is also incomplete. State who is responsible for keeping the inventory current, and what happens when an asset is discovered that nobody claims. An unowned asset should default into the security team’s queue for triage, not sit unassigned indefinitely.
Roles, decision rights and who may approve deviations
Four roles need to be distinct in the text, even in a small organization where one person holds two of them: the asset owner, accountable for the system and for funding or scheduling the fix; the security team, which discovers, validates severity, and tracks status; the vulnerability management lead or CISO, who holds escalation authority and approves exceptions above a defined severity; and the operations or patch team that executes the change.
The part most policies skip is decision rights: who can extend a remediation deadline, who can mark a finding as a false positive, and who can accept risk permanently rather than temporarily. Write these as thresholds, not names, since names turn over. For example: findings rated Medium or below can be deferred by the asset owner for one cycle; High findings require security team sign-off to defer; Critical findings can only be deferred by the CISO or a named delegate, in writing, with an expiration date.
These decision rights are only real if they are enforced technically, not just documented. If anyone with a login can close a critical finding, the RACI section is decorative. Tie approval authority to actual system roles, ideally through role-based access control that mirrors the policy’s decision-rights table field for field, so an engineer without exception authority literally cannot approve one in the tool that tracks the work.
Severity tiers mapped to remediation timelines
A severity table without SLAs is a scoring exercise, not a policy. Base tiers on CVSS but do not stop there: exploit availability, internet exposure, and KEV listing should be able to move a finding up a tier regardless of its base score. A CVSS 7.8 with a public proof-of-concept exploit and internet exposure is more urgent than an isolated CVSS 8.9 on a segmented internal host.
| Tier | Typical CVSS | Internet-facing SLA | Internal SLA |
|---|---|---|---|
| Critical | 9.0 to 10.0, or any KEV-listed CVE | 7 days | 14 days |
| High | 7.0 to 8.9 | 14 days | 30 days |
| Medium | 4.0 to 6.9 | 30 days | 90 days |
| Low | 0.1 to 3.9 | Next patch cycle | Backlog, reviewed quarterly |
State the clock start explicitly: does the SLA begin at detection, at validation, or at ticket assignment? Most audits expect detection, since assignment delay is itself a control gap you want visible. Also state what “remediated” means: a patch installed, or a patch installed and confirmed by a retest. Platforms that automate this last phase, such as SITEY, re-test the specific finding against the same scanner signature that raised it rather than trusting a patch job’s exit code, which closes a gap auditors frequently flag: tickets marked resolved that were never actually verified against the vulnerable service.
Exception and risk acceptance clauses that stay enforceable
Exception clauses are where policies quietly lose their teeth. An exception that never expires is a permanent exemption with extra paperwork. To stay enforceable, every risk acceptance record needs, at minimum: the specific finding or CVE it covers, a named approver whose authority matches the severity threshold defined in the roles section, a required compensating control, an expiration date, and a re-approval requirement rather than automatic renewal.
Set a hard ceiling on exception duration by severity, for example 30 days for Critical, 90 days for High, and 180 days for Medium, after which the exception lapses automatically and the finding reopens unless someone actively renews it with updated justification. Require a compensating control statement for anything above Medium, such as a WAF rule blocking the specific attack pattern, network segmentation isolating the host, or an active monitoring alert on the affected service, and require that the control be verified as still in place at renewal time, not assumed. Build in an automatic reopen trigger: if the underlying CVE gets added to the KEV catalog after the exception was granted, the exception should void immediately regardless of its stated expiration.
Route every exception request through a recorded workflow with a ticket ID, business justification, approver identity and timestamp, and the review date, so the audit trail exists without anyone assembling it after the fact from email threads. This is exactly the gap that structured approval gates close in tooling: the request, the approver, the compensating control, and the expiration all live as fields on one record instead of scattered across chat and spreadsheets.
Review cadence, enforcement and a section-by-section outline to copy
Set the policy’s own review cadence explicitly: annually at minimum, and immediately after a material trigger such as a significant incident, a new regulatory obligation, or a merger that changes the asset base. The standard document with SLA numbers should be reviewed more often, quarterly is reasonable, since threat intelligence and exploit prevalence shift faster than governance calendars.
Enforcement needs consequences that are written down, not implied. Define what happens when an SLA is missed: automatic escalation to the asset owner’s manager at the SLA deadline, a second escalation to the CISO at 150 percent of the SLA, and inclusion in a monthly exposure report reviewed by leadership. Tie these escalations to whatever ticketing or vulnerability management system tracks the work so the escalation fires on the deadline rather than whenever someone remembers to check. If your compliance program spans multiple frameworks, a single control implementation should generate evidence for all of them at once rather than separate spreadsheets per auditor; this is the practical reason mapping controls to frameworks like ISO 27001, PCI DSS, SOC 2, and GDPR in one place saves far more audit time than it costs to set up.
Here is a section order that covers what auditors and engineers both expect, usable as a table of contents for a first draft:
- Purpose and regulatory drivers
- Scope: in-scope asset classes, explicit exclusions, and the inventory system of record
- Roles and decision rights, including who may approve exceptions at each severity
- Definitions: severity tiers, CVSS mapping, KEV and exploit-availability overrides
- Remediation SLAs by severity and exposure, with an explicit clock-start and closure definition
- Exception and risk acceptance process, including expiration and compensating control requirements
- Enforcement and escalation for missed SLAs
- Metrics and reporting cadence to leadership
- Policy review cycle and version history
Each of these sections should be short enough that a new hire can read the whole policy in ten minutes and know exactly what is expected of their role. If a section requires a paragraph to explain a number, that number probably belongs in the linked standard instead. Automation changes what enforcement actually looks like day to day: an eight-phase pipeline that moves a finding from discovery through validation, scoring, assignment, remediation planning, patching, and retest means the policy’s SLA clock is measured against real, tracked state rather than a spreadsheet somebody updates on Fridays, which is the difference between a policy that reads well and one that changes outcomes.
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.