TL;DR: Vulnerability Response can manage exceptions in two ways: its own native process, or through the Policy and Compliance Management integration, which ties each exception to a policy or control objective. The second gives you governance traceability and compliance impact. It also costs you exception rules for auto-deferral and requires that impacted controls exist to be selected, which means entities and controls in IRM. Pick deliberately, scope the control side before go-live, and set expirations that revert the item to Open so the decision gets made again.Remediation is rarely as clean as the policy suggests. A vulnerability has a remediation target driven by severity, exploitability, asset criticality, or policy. Then you meet the system that cannot be patched inside that window. The application depends on an unsupported component. The production box has one maintenance window a quarter. Patching introduces more operational risk than temporarily carrying the vulnerability does.
An exception or deferral is frequently the right answer. The hard part is keeping the exception attached to the requirement that made it necessary.
When that link is missing, exceptions turn into isolated operational decisions. Someone approves, remediation defers, everyone moves on. Six months later, nobody can reconstruct why it was granted, which control requirement it touched, whether the compensating controls are still in place, or whether the justification still holds.
An exception starts with a requirement, not a ticket
Most exceptions exist because the organization set an expectation it currently cannot meet. Take a policy requiring critical vulnerabilities to be remediated inside a defined window. When a system owner asks for more time, they are not asking permission to leave a vulnerability open. They are asking the organization to accept a temporary deviation from a security requirement it wrote down.
That difference is the whole governance question. Managed only from the vulnerability record, you keep good information about the technical finding and the remediation decision. What you lose is the relationship between that decision and your policies and controls. Attach the exception to the requirement, and you can say not just which vulnerability is open, but which requirement the organization decided to stand down on.
The two ways ServiceNow does this
Here is where the article has to get specific, because the platform gives you a choice and the choice has consequences.
Vulnerability Response ships its own exception management process. Under Administration > Exception Management, you can instead elect to manage exceptions using GRC: Policy and Compliance. From Vulnerability Response v10.3 and Policy and Compliance Management v10.1, policy exceptions can be requested directly from Vulnerability Response using the GRC policy exception management capability, and two integration records are created automatically in the Integration Registry when Vulnerability Response is installed, one for a vulnerability group and one for a vulnerable item.
What the integration buys you is exactly the connection this article is about. You can request an exception against a specific policy or control objective, which surfaces the compliance impact of approving it; you can attach questionnaires and assessments to gather more information from the requester; and you can configure approvals to trigger automatically based on the risk rating, policy, or control objective involved.
The compliance manager assigns a risk rating and documents the risk description, analysis, and mitigation plan, so the governance record is built during the decision rather than reconstructed afterward.
What it costs you is worth knowing before you flip the switch. Requiring remediation teams to input a control to defer a fix requires a certain level of understanding not every organization has. And not every deferral request needs to be seen by the policy team; in fact, most won't be.
So even though deferrals and exceptions link to GRC, ensure approvals stay at the right level. The scoping trap is on the control side. Under the GRC process, selecting impacted controls is required when the exception reaches the Analyze state, and controls only exist where entities exist in IRM.
That is the question I would put on the table in the first design session: at what level do you maintain entities and controls? Generating an entity and a control for every CI in the CMDB is not a serious plan. Scoping entities to business services, application groupings, or environments usually is. Get that wrong and the process stalls at Analyze on every request.
Keep policy, control, and evidence distinct
Three things get used interchangeably when they shouldn’t be. A policy sets the expectation. A control turns that expectation into something implementable, assessable, and monitorable. Operational security records are evidence of what is happening in the environment.
A vulnerability exception sits across all three. The operational side reports the facts: the vulnerability exists, the normal remediation requirement cannot be met, and an exception is requested. The governance side asks different questions. Which policy requirement does this affect? Which control addresses that requirement? Who owns the resulting risk? What evidence supports the decision? When does it get reviewed?
Those questions are straightforward when the records relate to each other and painful when they live in separate systems.
Design from the control, not the approval chain
Most teams start an exception design at the approval workflow. Who approves, how many approvals, how long the exception runs. Those decisions are necessary, and they are second. The first question is what requirement is being excepted and why. If the organization cannot answer that cleanly, the process is missing its governance context before anyone builds a single flow.
For vulnerability management, the relevant control might address remediation timelines, patch management, configuration standards, or unsupported software, so different exception types connect to different controls. This is also why one generic security exception process gets hard to govern.
Two requests can look identical operationally while carrying very different policy implications. Mapping exceptions to controls preserves that difference. It is also the practical reason to define your reasons for requesting exceptions and, if you use them, policy categories for filtering, before users start submitting.
Compensating controls belong in the decision
An exception does not mean the organization decided to do nothing. A system that cannot be patched today can be segmented off part of the network. Access can be tightened. Monitoring can be added. A vulnerable service can be disabled or fronted by another technology.
Those measures change the risk of granting the exception, so they belong in the record and in the review. Connecting exceptions to the control framework lets a reviewer weigh both the control that cannot currently be satisfied and the compensating controls holding down exposure in the meantime. That is a materially better artifact than an approval noting that remediation has been postponed.
It also gives the next reviewer something concrete to reassess. If the compensating control changes, fails, or gets removed, the basis for the original approval no longer holds, and somebody should know that.
Expiration is the mechanism, not the intention
The most common failure in exception management is temporary decisions quietly becoming permanent. The exception gets approved for a good reason, the team moves on, the system stays in production, the vulnerability stays open, and the context behind the decision leaves with whoever changes jobs first.
The platform handles this if you let it. Once approved, the policy exception is active and defers the patching activity until it expires. On expiration, the exception ends automatically and the vulnerable item reverts from Deferred to Open.
That reversion is the point. The item comes back into the queue, and the decision gets made again with current information. Maybe it has been remediated and the exception closes. Maybe an upgrade path now exists, or the system is scheduled for retirement, or exploitation activity in the wild has changed the risk, or the business still needs the exception and will approve another defined period. Any of those is a fine outcome. Silence is not.
Set expiration windows from policy and risk tolerance rather than convenience and watch the volume of items reverting to Open. If nobody is working that queue, you do not have an exception process; you have a deferral habit.
Traceability is what auditors are testing
An auditor or risk committee looking at an open vulnerability will ask why it was not remediated according to policy. A mature process answers without anyone reassembling the story from email, spreadsheets, ticket comments, and memory.
You should be able to produce the original finding, the applicable requirement, the request, the justification, the approving authority, the compensating controls, the approved period, and the status. The reason the platform helps is that the operational security work and the governance records are not separate bodies of information by default.
One access detail that shows up in every implementation: the GRC business user or business user lite role is the minimum required to raise a policy exception from an upstream application. Remediation owners requesting exceptions need that role, and licensing conversations tend to surface late if nobody counts those users during design.
The relationship pays off at volume
One exception is easy to understand. The problem changes shape at several hundred or several thousand, where exception management becomes an analytical exercise as much as an approval process.
With exceptions tied to controls, you can look for patterns. One control generating a disproportionate share of exceptions. A business unit that always needs more time. A legacy technology accounting for a large slice of accepted risk. The same compensating control appearing repeatedly because the permanent fix has never been funded.
None of that is visible when exceptions are independent tickets. And a high volume against one control has two possible readings: the policy is unrealistic, or something structural is preventing compliance with it. Both are worth chasing, and the data tells you which conversation to have.
Connect the operational decision to the governance decision
Exceptions are permanent features of large environments. There will always be cases where immediate remediation is technically impossible, operationally impractical, or more disruptive than carrying the risk for a defined period.
So, the goal is not fewer exceptions. It is exceptions that are explicit, governed, and genuinely temporary.
The finding tells you what needs attention. The exception documents why the standard response cannot happen now. The policy and control framework identifies the requirement affected. The compensating controls describe how exposure is being managed in the interim. Together, those records show what the organization decided, which matters because approving an exception does not retire the risk, just who is managing it and how.
