Plain-English companion to Client VPS Patching — Managed Service
(design and rulings) and Patching & Maintenance on a Client VPS — How It Works
(what runs and when). This page is about the record: what the practice can see, what they can hand to an
inspector, and why it counts as evidence rather than as our word.
The reason patching a client's box is part of the managed service at all is not the patches — it is that the
practice has to be able to show somebody. An inspector or an auditor asks "how do you know this machine is
kept up to date?", and the answer cannot be a promise. So the rule from the start has been: the practice sees
when their box was patched, in their own dashboard, without having to ask us for it.
That leads to a design choice worth stating plainly: the record is written by the box itself, and it is
read-only to the client. They can show it; they cannot edit it. If we could edit it, it would be a claim. It
is written by the same kind of outbound report the nightly backup already sends us, which the dashboard already
displays per client today.
A "Maintenance & updates" card, in the same plain English as the rest of their infrastructure page. It
carries the sentence a practice manager actually wants:
44 updates applied on 12 October — 6 of them security fixes. Nothing outstanding. Next run: 1 November.
Under that, the same card shows whether a restart is waiting, whether anything is still outstanding, and when
the next run is due. It never shows a package name unless somebody asks for one.
A list of their box's runs, each row expandable. Plain summary on the surface; the package list — what
went from which version to which version, and which of them were security fixes — is there for the reader who
wants it.
A download. A spreadsheet file (CSV) of their runs to begin with, and a quarterly statement pack:
a printable statement plus a checksum, generated automatically on a schedule and held with their backups.
That last detail matters. If our own systems are degraded, the client's evidence should not be sitting only on
the machine that is degraded — so their pack lives with their data, not only in our application.
Only their box. A practice sees their own VPS and nothing else — never another practice's box, and never
our platform hosts. The card as it stands today has a bug here (it shows our platform hosts to every practice
admin); it is being fixed as part of this work, and the tests for it are written as isolation tests rather than
as a tidy-up, because at scale one filtering mistake would show one practice another practice's history.
A practice manager wants one sentence. An auditor may want the package list. Those are different readers, so
the answer is both, each in its own place: the card stays a sentence, the detail page and the exports carry the
list. Nobody has to read a version number to find out whether they are up to date.
Recommended defaults, changeable per client in the contract: we keep the run history for 24 months —
two annual audit cycles, so a client can answer for the period an inspector is most likely to ask about — and
their dashboard shows at least the last 12 months. Nothing is deleted to make the numbers look tidy.