ServiceNow Vulnerability Response Governance Model

Vulnerability response governance is the set of forums and decision rights that decide how vulnerabilities are triaged and how patches pass through change control. It covers triage criteria, patching windows, patch compliance ownership, exceptions, metrics and vendor communication.

Establishing Governance Forums for Vulnerability Management

Vulnerability response requires decision forums at different levels: a Vulnerability Triage Board meets weekly to assess incoming vulnerabilities and decide on priority and remediation timeline; a Change Advisory Board reviews patching plans; a Security Steering Committee sets vulnerability policy and risk tolerance.

Define membership for each forum: Triage includes security engineers, system owners, and the vulnerability manager; CAB includes infrastructure owners, application teams, and change management; Steering includes heads of security, compliance, and operations.

Define decision authority: does Triage approve remediation timelines, or does CAB? Can a system owner skip patching a non-critical vulnerability if it is too risky to patch? How is risk tolerance decided: by the security team alone, or with business input?

Vulnerability Triage Standards and Criteria

Establish clear criteria for vulnerability prioritisation: severity (CVSS score), exploitability (is it actively exploited), asset value (does it affect critical systems), compensating controls (is the vulnerability mitigated by other controls), and business context (time-sensitive events that increase risk).

Document decision rules that map CVSS bands (critical, high, medium, low) to patching deadlines your policy sets. Set each deadline against the business impact on the affected system. A low score may not require patching if compensating controls exist.

Review these standards quarterly with security, operations, and business stakeholders. As the threat landscape changes, adjust your standards. If new exploits emerge for low-severity vulnerabilities, raise their priority.

Change Control for Vulnerability Patches

Patches are changes. Use your change management process: standard changes for routine patches that have been tested and approved, normal changes for patches that affect critical systems or have known risks. Define what triggers a standard change (patch from a trusted vendor, tested in staging, no known conflicts) and what requires a normal change (new vendor, complex dependencies, high-risk asset).

Include rollback criteria in every patch change: if a patch breaks functionality or causes performance degradation, who decides to roll back, and how quickly can it be executed? Document the rollback procedure in advance.

Patching Windows and Scheduling

Define patching windows: when are patches applied? Some organisations patch monthly on a specific date; others patch weekly; some maintain rolling patching schedules. Choose based on your risk tolerance and operational capacity.

Communicate patching windows to business stakeholders well in advance. Include maintenance windows for testing and validation. If a critical vulnerability emerges outside the planned window, trigger an emergency patching process with compressed timelines and reduced approval requirements.

Ownership and Accountability for Patch Compliance

Assign patch ownership: by system (the system owner is responsible for their systems), by infrastructure layer (the database team owns database patches, the application team owns app patches), or by criticality (a dedicated team owns critical patches, application teams own others).

Hold owners accountable: track compliance metrics (percentage of systems patched within SLA), and escalate non-compliance. If a system remains unpatched beyond the SLA, the owner must provide a documented reason (technical risk, business impact, customer requirement) or execute a remediation plan.

Exceptions and Exemptions

Some systems may have legitimate reasons not to patch: a vendor system that is out of support, a legacy application that will be retired soon, a third-party service where patching is the vendor’s responsibility. Document these exceptions and review them quarterly.

When an exception is granted, require a compensating control: if a system cannot be patched, increase monitoring, restrict access, or isolate the system from the network. Track the compensating control and ensure it is effective.

Vulnerability Metrics and Reporting

Track: number of vulnerabilities by severity, time to patch by severity, compliance percentage (systems patched within SLA), exceptions granted, and compensating controls in place. Report monthly to the Steering Committee.

Analyse trends: are high-severity vulnerabilities decreasing, or are they increasing? Is the time to patch improving, or getting worse? Are there systemic issues (a particular system or team consistently non-compliant)?

Vendor Communication and Disclosure

Establish communication with software vendors: subscribe to security advisories, participate in vendor vulnerability disclosure programs, and request advance notice of patches. This helps you prepare for large or risky patches.

If you discover a vulnerability in a vendor product, follow responsible disclosure: report to the vendor privately, give them time to patch, and delay public disclosure until the patch is available.

Writing the charter that decides who is allowed to say no to a patch

Forums and their membership are the easy part of a vulnerability governance model. The harder part is deciding what each body is allowed to decide, how far its authority reaches, and what happens when two bodies reach different answers. A charter that leaves those questions open turns every contested patch into a meeting, and the flaw stays open while people argue about whose call it is. This section covers the parts of a charter that carry the decisions, and it is written for the security leader who has to put the document in front of the steering committee for approval.

A delegation table that sets authority and its limits

The most useful single table in the charter is a delegation matrix. It names the decision, the body or role that holds the authority, the ceiling beyond which the authority does not reach, and the route an unresolved case takes next. Keep the ceilings in terms of business impact and exposure, not only severity scores, because a severity score alone does not show whether a system is one people depend on.

Resolving disagreement between security and operations

The disagreement most charters fail to anticipate is the one where security wants a patch applied and the operations owner says the system cannot take it. Neither side is wrong in the abstract. The charter should set out a sequence rather than leave the case to whoever shouts loudest. A workable sequence starts with the service owner stating the operational risk in writing, moves to a joint review by the vulnerability manager and the operations lead within an agreed short period, and ends with the steering committee recording the decision and its reason. The record matters as much as the outcome, because it is the evidence that a deferral was a considered choice.

What the steering committee should not decide

A steering committee that tries to approve individual patches will be overwhelmed within a few cycles and will start approving without reading. Its job is to set policy, approve the response windows and the ceilings in the delegation matrix, review the trend data, and deal with the cases that the lower bodies cannot resolve. Individual patch approvals belong to the change process. Holding that boundary firmly is one of the simplest ways to make the committee’s time count.

Writing a terms of reference that someone will follow

1. State the purpose of the body in one paragraph, in terms of the decisions it owns and the ones it does not.
2. List the standing members and their deputies, and say what happens if a required member is absent.
3. Set the quorum and the rule for when a decision can be taken by written consent between meetings.
4. Define the decision log: where it is kept, what each entry must record, and who checks it after each meeting.
5. Set the review cadence for the charter itself, and the trigger that forces an early review, such as a major incident.

When a lighter governance model is enough

A team with a small estate and few people responsible for vulnerabilities does not need three standing bodies. A single regular review, a written delegation table, and a periodic note to the business owner can carry the same decisions with far less overhead. The risk is informality drifting into unrecorded decisions, so the lighter model still needs the decision log. Governance is measured by whether the decisions are recorded and defensible, not by the number of meetings.

Who should hold the authority to defer a patch on a system that cannot be patched?

The service owner should hold it, because they carry the business consequence, with the security lead countersigning. The deferral should carry a compensating control and a revisit date, and it should never be open ended.

Should the steering committee review every exception?

No. It should review exceptions that run past their revisit date, exceptions on critical services, and any exception that is being renewed a second time. Routine deferrals with controls in place can stay with the delegated holder.

How do we keep the decision log from becoming a formality?

Ask someone outside the committee to check a sample of entries against the minutes each quarter. Entries that cannot be traced to a stated reason are the first signal that the log is being filled in after the fact.

What changes the ceilings in the delegation table?

A change to the business impact of a service, a new regulatory obligation, or an incident that shows a ceiling was set too high. Each change should be recorded with its reason and approved by the steering committee.

The post on risk management accountability is a useful companion when the question is who owns the decision rather than how it is recorded.

Related guides: ServiceNow Security, Risk & Governance and ServiceNow Vulnerability Response Automation Opportunities.