Vulnerability and patch management

Turn scanner output into a prioritized, owned remediation plan: what is genuinely exploitable here, who fixes it, in what order, and how it gets verified.

Isometric diagram of unranked vulnerability findings being reprioritised by real exposure, then verified as fixed, with the unscanned estate marked as the blind spot.
How vulnerability and patch management work is framed: scope, evidence and a safe way back.

What we review

  • Current coverage: Which systems are scanned, which are invisible to tooling, and what that blind spot contains.
  • Finding quality: Whether results are accurate, deduplicated and attributable to a real owner.
  • Prioritization basis: Whether severity reflects exploitability and exposure in this environment, not just vendor score.
  • Asset ownership: Who is accountable for remediating each class of system, and whether they know it.
  • Patch pipeline: How updates reach production today, including test, approval and rollback steps.
  • Maintenance windows: What can be patched without disruption, what requires downtime, and what has never been restarted.
  • Exception handling: How systems that cannot be patched are recorded, compensated for and reviewed.
  • Verification: Whether remediation is confirmed by evidence rather than by a closed ticket.

Deliverables

  • Coverage map: What is scanned, what is not, and which unscanned systems matter most.
  • Prioritized remediation plan: Findings ranked by real exposure and exploitability, with an owner and a sequence.
  • Patch pipeline assessment: How updates reach production, where the process breaks, and what to change.
  • Exception register: Systems that cannot be patched, why, what compensates, and when each is revisited.
  • Verification method: How each remediation is proven, so a closed ticket means a fixed system.
  • Operating rhythm: A realistic cadence your team can sustain, sized to the staff you actually have.

Engagement boundaries

  • This is an assessment and planning engagement, not an ongoing managed patching service.
  • HAI Consulting does not deploy patches to production on your behalf unless separately agreed and scheduled through your change process.
  • Vulnerability scanning identifies known issues; it does not prove an environment is free of compromise.
  • No exploitation or penetration testing is performed as part of this work.
  • A vulnerability management process reduces risk over time; it does not eliminate the possibility of a breach.
  • Scanner licensing, tooling costs and remediation labour remain your responsibility.
  • Findings depend on the accuracy of the inventory you provide; systems you do not disclose cannot be assessed.
  • This work does not certify compliance with any framework or standard.
  • Where a system cannot be patched, the engagement documents the risk and compensating controls rather than resolving it.

Questions before the work starts

We already have a scanner. What does this add?

A scanner produces findings; it does not produce decisions. This work establishes what is genuinely exploitable in your environment, who owns each remediation, in what order work should happen, and how completion is verified. Most organizations we see have data and no defensible plan.

Will you patch our systems for us?

Not as a default. This engagement assesses and plans. If you want changes implemented, that is scoped separately, runs through your approval process, and carries a tested rollback path.

How do you decide what to fix first?

Exposure and exploitability in your specific environment, not vendor severity alone. An internet-facing service with a known exploited vulnerability outranks a higher-scored issue on an isolated internal host.

What about systems we cannot patch?

They are recorded in an exception register with the reason, the compensating controls in place, and a date for review. Unpatched systems that nobody has written down are the ones that cause incidents.

Our last patching cycle caused an outage. How is this different?

That experience is the starting point, not something to work around. The engagement reviews how updates reach production and whether rollback has ever been tested, because teams that have been burned will avoid patching until that is addressed.

The platforms this work covers

Vulnerability and patch work covers the platforms your estate actually runs, including the ones scanners often miss.

  • Microsoft 365 and Entra ID
  • Microsoft Azure
  • Amazon Web Services
  • Cisco
  • Palo Alto Networks
  • Check Point
  • Fortinet FortiGate
  • F5
  • Cloudflare
  • On-premises and colocation data centre

Audits available

  • Patch posture audit: which systems are current, which are behind, and which are invisible to existing tooling.
  • Firewall and network device firmware review: supported versions, known issues, and upgrade paths with rollback.
  • Cloud workload patching review: image currency, rebuild cadence and drift in Azure and AWS estates.
  • Exception review: systems that cannot be patched, the compensating controls in place, and the review date for each.

Need a second set of eyes on a security or infrastructure decision?

Describe the environment, the risk and the outcome you need.

Contact HAI Consulting →