Exposure-based prioritisation
Findings ranked by reachability, exploit availability and asset criticality, so the list your team works from is short enough to finish this month.
Security & Compliance
Vulnerability & Patch Management
A patching cadence you can keep, aimed at the vulnerabilities that are actually being exploited.
The work
What this actually does
Raw CVE counts tell you very little. A host with two hundred medium findings and no exposed service is usually a lower priority than one internet-facing appliance with a single flaw that has a working exploit. We start by building an exposure picture from your asset inventory, network reach and threat intelligence, then patch against that.
The mechanics differ by estate. Virtual machines get rolling patch windows with drain and health checks; container hosts get replaced rather than patched in place; language dependencies get version bumps through the same pipeline as the code. We automate what is safe to automate and keep a human approval on the changes that can take a service down.
If any of these sound familiar
- The vulnerability report has twelve thousand rows and no priorities
- Patch windows get cancelled whenever a release is close
- Rebooting a host still needs a person watching it at midnight
- Nobody knows which servers missed last quarter's patches
Scope
What's included
Every engagement on this page covers the following, sized to your setup rather than delivered as a fixed package. If something here is not relevant to you, it comes off the scope and off the price.
Automated patch pipelines
Scheduled jobs that apply OS and package updates through Ansible or your existing automation, with pre-checks, health gates and an automatic stop on failure.
Rolling patching without downtime
Hosts drained, patched and returned to the load balancer one at a time, with capacity checks so the remaining nodes can carry the traffic.
Immutable image rebuilds
Where hosts should not be patched in place, we rebuild from a fresh base with the same configuration and replace the node instead.
Patch status reporting
Which assets are current, which are overdue and which are deliberately excluded, refreshed after every run and readable by people outside the platform team.
Stateful service windows
Databases and stateful clusters get planned maintenance windows with replica failover first, since those are the patches that cannot be automated away.
What changes
What teams typically see
7 daysCritical patch target
95%Assets within patch window
0Manual reboots overnight
Handover
What you keep
Everything produced during the engagement is yours: the repositories, the accounts, the documentation. There is no proprietary layer and nothing to unlicense if you take the work in-house.
- Risk-ranked patch list refreshed from live exposure data
- Automation playbooks for each operating system family
- Maintenance calendar agreed with service owners
- Patch compliance dashboard by environment and owner
- Exception register with compensating controls recorded
Tooling
Tools we use here
A starting point, not a requirement. We work in whatever you already run wherever it does the job.
Ansible
AWS
Microsoft Azure
Google Cloud
Kubernetes
Terraform
Prometheus
Docker
How it runs
From first call to handover
The same four steps on every engagement. You see each one before it starts and can stop at any of them.
- 01
Build the exposure picture
We combine your asset list, network exposure and known exploited vulnerability feeds to rank what genuinely needs attention first, rather than sorting by score alone.
- 02
Define the patch cadence
Severity bands get a target window each, agreed with the teams who own the services, so everyone knows what happens and when without asking.
- 03
Automate the routine cases
Playbooks and pipeline jobs handle the predictable work, with health checks that halt a rollout when an instance fails to come back cleanly.
- 04
Report and tighten
Monthly reporting shows what slipped and why, and the cadence is adjusted when a target is consistently missed rather than quietly ignored.
Questions
Asked before we start
How fast do we have to patch critical issues?
There is no universal answer, and anyone quoting one number is guessing. For internet-facing systems we typically work to days, for internal services weeks. What matters is that the target is written down, measured and achievable with the staff you have.
Can you patch everything automatically?
No. Databases, appliances and anything without redundancy need a human decision and often a window. We automate the rest, and the parts that cannot be automated get recorded as exceptions with an owner rather than quietly left out.
What about vulnerabilities with no patch available?
Those are the hardest, and a scanner will keep flagging them. We handle them with compensating controls such as network restrictions, feature disablement or extra monitoring, and set a review date so the decision is revisited when a fix ships.
Does this replace our existing vulnerability scanner?
No, it usually consumes it. Keep the scanner you have for discovery and asset coverage, and let this work deal with prioritisation, scheduling and the evidence trail. Where a scanner misses whole platforms, we will say so and suggest something better.
Security & Compliance
Often needed alongside this
Security & Compliance
Container & Image Scanning
Block images with known critical CVEs before they ever reach a registry your production cluster can pull from.
- Trivy, Grype and Snyk in the build pipeline
- SBOM generation and provenance attestation
- Registry admission policies that block bad images
Infrastructure & Cloud
Configuration Management
Servers and appliances configured from code, so rebuilding a box is boring and identical every time.
- Ansible, Chef and Puppet role design
- Idempotent playbooks and hardened baselines
- Patching and compliance drift reports
Security & Compliance
Compliance Readiness
Continuous evidence collection instead of a quarterly fire drill — audit trails generated by your pipeline.
- SOC 2, ISO 27001, HIPAA and PCI DSS readiness
- Automated control evidence and reporting
- Change management and segregation-of-duties trails
Worth a conversation about Vulnerability & Patch Management?
Bring the specific problem. We will tell you honestly whether this is the service that fixes it, and what it would take.