Operating systems, patch cycles, backup verification, restore testing and capacity headroom, on Windows, Linux and the virtualisation layer beneath them.
Backups are proven by restore, not by a green tick in a console.
Patching and backup failures happen overnight, which is when someone needs to be awake.
A backup that has never been restored is a hypothesis. We test on a schedule and report the timing.
Patch level per system, with every deferral recorded as accepted risk with an owner.
Capacity conversations happen a quarter early rather than at the point of failure.
System support is the least visible part of a managed service and the one that decides how bad your worst day is. It is also the first thing cut when budgets tighten.
Windows Server and enterprise Linux: builds, hardening baselines, configuration drift, services, and the incidents that follow a change.
Builds are standardised and documented, so a rebuilt server matches the one it replaced.
Servers that are the same on Friday as they were on Monday.
Monthly cycles by ring, emergency out-of-band patching, reboot coordination around your close and production calendars.
Every deferral is recorded as accepted risk with a named owner and a review date, rather than quietly skipped.
A patch position you can state on any given day.
Job configuration, retention aligned to your recovery objectives, offsite or immutable copies, and daily verification of outcomes.
Scheduled restore tests to a separate environment, timed and reported, so your recovery objective is a measurement.
A restore time you have observed rather than estimated.
Cluster health, resource contention, snapshot hygiene, host patching with live migration, and capacity across the estate.
Snapshot sprawl is treated as a defect, because it is the most common cause of a storage emergency nobody saw coming.
Hosts patched without a maintenance window nobody can find.
Baseline configuration, drift detection, local administrator control, service accounts and the evidence pack an auditor asks for.
Hardening is applied against a named standard, so compliance is a comparison rather than an opinion.
Evidence produced on request, not assembled in a scramble.
Growth trending by system and volume, memory and I/O headroom, plus hardware and operating system end-of-support tracking.
End-of-support dates are tracked against the estate, so migrations are planned rather than forced.
A dated forecast to the next capacity or upgrade decision.
Taking over systems
Cadence matters more than scope on this layer. The column that separates a real service from a nominal one is the last.
| Function | Scope | Cadence | Evidence produced |
|---|---|---|---|
| Patching | Operating systems, agents, firmware where in scope | Monthly by ring | Patch position statement and deferral register |
| Backup | Job health, retention, offsite or immutable copy | Daily verification | Verification log and exception list |
| Restore | Point-in-time restore to a separate environment | Scheduled test | Timed restore report against your objective |
| Configuration | Baselines, drift detection, hardening standard | Continuous, reviewed monthly | Drift report with corrections applied |
| Virtualisation | Cluster health, snapshots, host patching | Continuous, patched monthly | Host patch record and snapshot hygiene report |
| Capacity | Growth by system and volume, memory and I/O | Quarterly | Dated forecast to the next decision point |
Backup job success proves that a job ran. It does not prove the data is usable, that the retention matches what the business assumed, or that a restore fits inside the window someone promised the board.
So restores are tested on a schedule against a real target environment, and the report states how long it took. That number is your actual recovery time objective. Everything else is an aspiration.
Ask for a systems auditIndicative practice. Test frequency and scope are set per criticality tier after the audit.
Yes, to administer, and it should be individually named, logged and revocable rather than a shared account. Access through your own privileged access management tooling is the arrangement we prefer, because then every action we take lands in your audit trail rather than only in ours.
They exist in every estate. We support the operating system, state the exposure plainly where no patches are available, and set out the mitigations. What we will not do is imply that support from us removes the underlying risk of an unpatched platform.
Less than the alternative, and it is scheduled around your calendar rather than ours: rings, agreed windows, reboot coordination, and out-of-band handling for anything urgent. The estates that find patching disruptive are usually the ones patching rarely, which makes each cycle bigger and riskier.
Yes, and it is a sensible first engagement. Backup and restore is bounded, it is measurable within a month, and the first restore test usually tells you more about the estate than a full audit would.
You do. Build baselines, hardening standards, patch ring definitions, backup policies and run books are yours from the first month and at exit. Being replaceable is part of the design rather than a risk we manage.
Start with a systems audit. It needs read access rather than a contract, and it produces a ranked findings report and a first measured restore time.