Managing Estates You Do Not Own

Internal IT monitors machines its own organisation owns, configured to its own standard, used by colleagues subject to its own policies. A service provider has none of that.

The recommendations in “Managing Estates You Do Not Own” become sustainable only when the recurring work has visible owners and enough capacity. A team assessing the workflow note can use time and project records to see where operational effort accumulates, without treating activity data as a substitute for technical evidence or direct discussion with technicians.

For an independent operational benchmark, compare the local practice with NIST Cybersecurity Framework; the important test is whether the control remains proportionate, documented and recoverable when the usual technician is unavailable.

What you do not control

What is installed. Clients buy software without telling you, and it breaks things.

Who has local administrator rights, which is frequently everybody, which is frequently non-negotiable.

When machines are on. A laptop that is off during the patch window is unpatched, and you cannot make it on.

Hardware age and specification, which the client controls through a budget you do not see.

And whether a user will accept an interruption, which determines what you can do during working hours.

What you are accountable for anyway

Uptime, under a contract that may not distinguish between your failure and the client's.

Patch compliance, reported to the client and sometimes to their insurer or auditor.

Response times.

The mismatch between control and accountability is the structural problem of this business, and the contract is where it should be resolved rather than in the tooling.

The things to establish per client

Who can approve a reboot, and in what window.

Which machines are out of scope and why.

What happens to a machine that is never on during the patch window.

Who to contact when a user refuses an action.

Four answers, written down at onboarding, and their absence produces most of the friction later.

Multi-tenancy as a practical matter

One console, many clients, and a mistake in a global setting reaches all of them.

Which means change control inside your own platform is a client-facing concern rather than an internal tidiness one.

Its own note covers scripts and the blast radius they have.

The documentation problem

Each client's estate has quirks: the application that must not be patched, the server that cannot reboot, the user who works nights.

That knowledge lives in technicians' heads and leaves with them.

Writing it per client is the single highest-return habit in this business, and it has its own note.

What this means for expectations

Promise what you control.

A contract that promises patch compliance without a reboot policy is promising something the client can prevent.

Say that at the point of sale, which is uncomfortable and cheaper than saying it after the first report.

What to check

For your largest client, do you know who can approve a reboot?

How many machines in your estates are never on during the patch window?

Does any contract promise something the client can block?

And where does per-client knowledge live?

The point

The machines belong to somebody else, and the mismatch between what you control and what you are accountable for is the structural problem of this business..

Underlying all of this

Everything in this collection reduces to four habits: tune until every alert is read, verify rather than assume at every stage from ring one to script execution, treat the console as the privileged system it is, and know what each client costs you. None needs a better platform, and a provider doing all four runs a quieter service than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the appearance of control substituting for control. An unread alert queue looks like monitoring. A compliance percentage that excludes pending reboots looks like protection. A script that reports success looks like automation. In each case the provider believes a risk is handled and it is not, which is worse than knowing it is open.