The work that is invisible until the day it is not.

Patch by exploitability, not by score alone.

A modern application carries hundreds of transitive dependencies. Reviewing every advisory against every one of them by hand is not a plan, and treating the severity score as the sole ranking produces a queue nobody can finish: there are always more critical findings than there is time.

The prioritisation that works is risk based. A vulnerability that is known to be exploited in the wild outranks a theoretically severe one that is not, regardless of the score attached to it. The catalogue of known exploited vulnerabilities maintained by the United States Cybersecurity and Infrastructure Security Agency exists for exactly this purpose, and is a standing input to the weekly review.

Exposure is the second axis. The same library carries a different risk in a service reachable from the public internet than in a batch job on an internal network. Both get patched; they do not get patched in the same week.

• Composition analysis runs in the pipeline, not as an annual exercise
• Advisories reviewed weekly against the dependency inventory
• Known exploited vulnerabilities take precedence over score alone
• Internet facing exposure raises priority
• A patch service level per severity, agreed in writing
• Every applied patch recorded against the system it changed

Certificates and domains, renewed before expiry.

Certificate expiry is the purest example of avoidable downtime. The date is known at the moment of issue. The outage it causes is total, immediate and affects every user at once. It happens anyway, to large organisations, several times a year.

Automated renewal is the first control and monitoring is the second, because automation fails silently. Every certificate and every domain a HaveStack system depends on is on a renewal calendar with an alert well ahead of the date, and the alert goes to a person rather than a shared mailbox nobody owns.

Alerting to a named contact.

A dashboard tells you something is wrong when you are looking at it. Most failures do not wait for office hours. The useful question about any monitoring setup is not what it measures but who it wakes.

Uptime and error rates are alerted to a named individual on the client side and to the practice, with a defined escalation if the first contact does not respond. Thresholds are set against agreed objectives rather than against whatever the tool defaults to, so that an alert means something is outside the commitment rather than merely unusual.

Capacity against measured load, not guessed load.

Provisioning decided at launch reflects what the team expected. Six months in there is real data: peak concurrency, request distribution, the shape of month end. Reviewing against measurement rather than against the original estimate is how a system stops being either fragile or wasteful.

Capacity is reviewed monthly against observed load, with headroom expressed as a multiple of measured peak rather than as a feeling. Public facing services carry a stated peak they have been proven against, and the proof is a load test, not an opinion.

Logs retained for the period the contract sets.

Log retention is treated as an infrastructure cost decision and it is actually a contractual and sometimes regulatory one. The moment a client needs to establish what happened, in a dispute or an audit or a security review, the only relevant question is whether the record still exists.

The retention period is agreed in writing, applied to application, access and audit logs separately where they differ, and the storage is provisioned for it. Logs are not discarded to save space without a written change.

Written down, or it does not happen.

Maintenance that is not written down is a favour, and a favour stops the moment somebody is busy. These are the clauses that make the practice above enforceable.

Terms used here.

CVE

Common Vulnerabilities and Exposures. The public identifier that lets a single flaw be referenced across tools, advisories and patch notes.

CVSS

A severity score for a vulnerability considered in isolation. Useful as an input, misleading as the only ranking.

KEV

The Known Exploited Vulnerabilities catalogue, listing flaws with confirmed exploitation in the wild. A stronger prioritisation signal than severity.

SCA

Software composition analysis. Tooling that inventories third party components and matches them against known advisories.

Headroom

Provisioned capacity expressed as a multiple of measured peak load rather than of an original estimate.

References.

Published guidance this page draws on. HaveStack does not claim authorship of the practice described; it claims to follow it.

1. 01
   Known Exploited Vulnerabilities catalogue and directives. CISA.
2. 02
   What is patch management: process, policy and benefits. Palo Alto Networks.
3. 03
   CVE patching: process, best practices and tools. TuxCare.
4. 04
   Patch management lifecycle: CVE, CVSS and rollout rings. Hexnode.

The rest of what stays under management.