A managed IT contract usually lists activities. Monitoring. Patching. Backups. Help desk. Each one is a thing that will be done on a schedule, and each is genuinely useful. The gap that catches people is that an activity being performed is not the same as the outcome being achieved, and contracts are written in the first language rather than the second.
We spent this week auditing our own systems and found three things worth putting next to that distinction, because all three would sit comfortably inside a contract that was being honored to the letter.
Three findings, and the clause that would have covered them
A monitoring check on our mail domain had failed every day for four months. Monitoring was in place. It ran on schedule. It produced output. The thing it monitored was healthy the whole time and the check was asking the wrong question, so its output was worthless — and "monitoring is in place" was true throughout.
A backup had been running nightly and reporting success for months, and had never been restored from. Backups were in place. They completed. Nobody had established that anything could be recovered. "Nightly backups" was true throughout.
A certificate renewal would have stopped working sixty days later, silently, because two individually correct pieces of automation interacted badly. Certificate management was in place and had worked for a year. "Certificates are managed" was true throughout.
Activities are easy to specify, outcomes are not
This is not usually anybody acting in bad faith. Activities can be written down, priced, scheduled and evidenced. "We monitor your mail authentication" is a sentence a provider can commit to and a client can verify. "Your mail authentication is correct" is a claim about the world that requires someone to keep checking whether the check itself still means anything, and that work is unbounded and hard to price.
So the industry writes contracts in activities, which is reasonable. The consequence is that the difference between a service that produces outcomes and one that produces activity is invisible at signing time, and often for a year or two afterwards. It becomes visible on the day a restore is needed, or an auditor asks, or a certificate expires.
Questions worth asking before signing
These are the ones we would want asked of us, and they are more useful than any feature list because the answers are checkable later.
When did you last restore from my backups, and what did you restore? Not whether backups run. Whether anyone has taken something out. A provider who does this will have a date and a description; one who does not will explain why it is not usually necessary.
Which of your checks have never once produced a warning? A check that has been quiet since installation is either watching something perfect or is not watching. Both look identical from outside, and the answer tells you whether anybody has asked.
What is explicitly not covered, in writing? Every contract has exclusions and the reasonable ones are easy to state — new projects, hardware purchases, after-hours incident response, work caused by software you bought without telling anyone. The answer matters less than whether it exists as a list. A provider who cannot produce one has not thought about the boundary, which means you will discover it during an invoice dispute.
If we part ways, what do I leave with? Documentation, diagrams, credentials, the runbooks. Ask what the handover contains and how long it takes. A relationship you cannot leave is not a service arrangement, and the answer to this question is a reliable proxy for how the rest of it will go.
What we changed on our own side
It would be poor form to write this without saying what the audit changed here. Every monitor we write now ships with a test that makes it fail, so a check that cannot go red on demand is treated as unfinished rather than passing. Backups are verified by restoring from them on a schedule, not by reading the job's exit code. And where we could not enumerate the ways something might break, we added a check on the outcome instead — is any certificate running short — which does not care why.
None of that is exotic and none of it required new software. It required deciding that the question is not whether the activity happened.
If you are evaluating providers, the useful move is not comparing feature lists, which will look similar. It is asking each one the four questions above and noticing which answers are specific. Specificity is the whole signal: a date, a document, a list. Anyone can say monitoring is included.
Working on something where this kind of thinking matters? Get in touch.