Define scope, ownership and authority
Identify covered systems, business owners and teams authorised to change them. Include relevant cloud, remote and external services. Define how assets enter scope and how retirement is recorded without erasing useful evidence. Ownership needs to reflect the service and change responsibility, not merely the location of the device.
Assign assessment, prioritisation, remediation, verification and acceptance responsibilities. Agree escalation and testing boundaries. Operational technology needs explicit approval and suitable methods. Owning the scanner does not grant permission to test every connected system, especially those operated under supplier agreements.
Establish dependable assessment
Choose methods for each asset group, including authenticated scanning where appropriate. Set schedules by exposure, criticality, change and obligations, not a universal interval. Add triggers for deployments, relevant exploitation information and remediation. Document safe windows and what to do if a job produces unexpected effects.
Define coverage quality before relying on charts. Track failed authentication, unreachable assets, duplicates and stale agents. Compare with independent inventory. Targeted or once-agent-installed does not mean assessed. Give gaps their own follow-up so detection counts do not hide the estate that remains unknown.
Build a risk-based work queue
Agree priority criteria and response targets with the teams delivering them. CVSS informs rather than dictates business order. Consider exposure, service importance and exploitation. Treat EPSS as an estimate and KEV as known exploitation, not proof of compromise. Keep those distinctions in the report.
Create work with evidence, affected assets, owner and remedy. Qualys VMDR may support assessment; Patch Management may support eligible deployment. Confirm entitlement and coverage. Neither bundled licensing nor automatic remediation of every finding should be assumed. Group changes around real patching and application-testing work.
Verify closure and govern exceptions
Check that deployment removed the condition, including any required restart. Use rescan or authorised targeted testing as appropriate; exploitation is not the default validation step. Establish how to resolve conflicting evidence and reopen issues. Retain enough detail that another engineer can understand the closure decision.
Make exceptions time-limited with owner, rationale and controls. Review freshness, authentication, overdue priority work and verified remediation. Use recurring failures to improve baselines and processes. A programme succeeds when the route from found to fixed is dependable, not when it maximises job counts.