TL;DR: A remediation ticket should trace one chain: finding, affected device and software, owner, approved fix, deployment result, refreshed evidence, and closure decision. Close the ticket only when refreshed device evidence shows the vulnerable installation is gone. If verification is missing, leave the ticket pending or record an explicit exception.
The ticket says "patch deployed." The deployment shows success. Then a rescan flags the same device, and nobody can prove which record is right. A deployment is an action, and verification is evidence. This guide shows how to verify vulnerability remediation tickets, with a ticket schema and a closure rule that help you keep tickets and fixes in sync.
What evidence belongs in a remediation ticket?
Good remediation ticket evidence lets someone who didn't work the ticket see why it closed. Use this schema as a starting point:
Field | What to record |
|---|---|
Finding | CVE or finding ID, source scanner, and risk context |
Owner | Named owner and target date |
Device | Stable device ID, installed software and version, detection time |
Approved fix | Fix version and the change or deployment reference |
Device status | Pending, deployed, failed, offline, verified, or excepted |
Verification | Link to post-remediation evidence, with a timestamp |
Exception | Rationale, approver, compensating control, and review date |
In the Finding field, add risk context so the owner knows how urgent the fix is: exploitation status, device exposure, and business impact. For findings that hit many devices, keep each device's status visible in the ticket using multiple rows or child records. Otherwise, "12 of 40 verified" could mistakenly get read as "closed," while the 28 still vulnerable stay buried.
How do you connect tickets to device actions?
Your vulnerability remediation workflow moves through validation, prioritization, deployment, failure handling, and verification, and tickets stall at the handoffs. PDQ's guide to reducing mean time to remediate covers those bottlenecks.
Pick a source of truth for each link in the chain:
Scanner: the finding and the affected installation.
Ticket system: the owner, target date, and closure decision.
Endpoint platform: deployment results and refreshed device state.
Store a stable device ID in all three, since hostnames change and collide. A scanner might flag a vulnerable browser on LAPTOP-04 while the endpoint platform knows that same machine by its serial number. Without a shared ID, someone matches them by name and hopes. If two records don't clearly describe the same device, mark the match unresolved instead of guessing.
Give stale or missing data an unresolved status too, and don’t treat it as fixed. Don't assume your scanner, ticket system, and endpoint platform sync with each other automatically. Confirm that data passes between them reliably.
PDQ's walkthrough on turning findings into targeted patches shows how to map findings to installations and devices.
When can a ticket be marked resolved?
Only when refreshed device evidence shows the vulnerable installation is gone should a ticket be resolved. An issued deployment isn't proof of device-level verification, and neither is a script that exited cleanly. Require:
A post-remediation inventory check or rescan, timestamped after the deployment
A version or installation record showing the vulnerable version is absent
A link to that evidence in the ticket
Check the timestamp, because evidence from before the deployment proves nothing. A screenshot of the deployment console isn't evidence either.
Track devices separately. Verified devices are done. Failed and offline devices stay open with a reason. Partial completion keeps the ticket open.
Reopen the ticket if a later scan finds the vulnerable version again, a new device enters scope, or the vendor widens the affected range.
Keep accepted risk distinct from remediation. An exception records a decision, not a fix, so label it "accepted," not "remediated." The same goes for mitigations like restricting access, which reduce exposure without removing the weakness. PDQ's explainer on vulnerability remediation covers these closure principles.
How does PDQ support verification?
PDQ provides device and vulnerability context for managed endpoints. The Vulnerabilities page lists each finding's impacted devices with a status of Vulnerable, Ignored, or Resolved, and a device's Vulnerabilities tab shows its vulnerable software. You can deploy a PDQ package to specific devices and review the results; PDQ automatically triggers a rescan after deployment, giving you refreshed evidence to link in the ticket once the scan completes.
PDQ’s integrations can connect your ticketing and automation tools with device data and deployment actions. Depending on the integration, you can trigger deployments, review deployment results, or retrieve device vulnerability data. Confirm what each integration does in your environment first. PDQ doesn't close your tickets for you, so the closure decision stays with you.
Final thoughts
A closed ticket should mean one thing: refreshed evidence shows the vulnerable installation is gone from every in-scope device, or an owner accepted the risk in writing. Start small. Add the device status and verification fields to your next ticket template, then make the closure rule a required step.
Try PDQ free for 14 days to see device-level vulnerability status and deployment results in one place.
