A business signs up for proactive IT support expecting the provider to handle prevention: patching before something breaks, monitoring before an issue becomes an outage, catching problems the business wouldn’t have noticed on its own. That’s a fair expectation, and it describes real work the provider does.
It’s also only half of what actually determines whether prevention works. The other half depends on the client doing things nobody told them were part of the deal, and when that half doesn’t happen, the business experiences the resulting failure as the provider dropping the ball.
Prevention needs information the provider doesn’t generate on its own
A provider can monitor a network continuously and still miss what it was never told to look for. Effective prevention depends on a flow of information that has to originate with the client, because the provider has no way to generate it independently.
- When an employee leaves, someone has to tell the provider so their access gets revoked. The provider doesn’t know an employee left unless someone says so.
- When the business opens a new location or adds a piece of equipment that connects to the network, someone has to flag it. The provider can’t monitor or patch a device it doesn’t know exists.
- When a scheduled maintenance window is proposed, someone on the client side has to actually make the system available for it, rather than pushing it back indefinitely because the timing is inconvenient.
None of this is technical work. It’s operational discipline on the client’s side, the kind of thing that doesn’t show up in a services proposal because it isn’t a line item. It’s assumed, and assumptions are exactly where this kind of relationship tends to break down.
Why this dependency stays invisible until something goes wrong
A services agreement describes what the provider does: monitoring, patching, response times, reporting. It’s much rarer to see it describe what the client needs to keep doing for that first list to actually function, because that half of the relationship is harder to specify and easier to assume will just happen.
That asymmetry shapes expectations. The client reads the proposal, sees a list of things the provider will handle, and reasonably concludes that prevention is the provider’s job in full. The provider, meanwhile, is operating on an implicit assumption that basic operational information, an employee leaving, a new device going live, will reach them in a timely way, because that’s how the relationship has to function in order to actually deliver prevention.
Neither side is being dishonest. The provider isn’t hiding a dependency it hopes the client won’t notice. It’s a gap in what gets made explicit, and it holds up fine as long as nothing happens to expose it.
Where the gap actually surfaces
The dependency stays invisible right up until a specific kind of failure happens, one where the cause traces back to information the client never passed along rather than to anything the provider missed on its own.
A former employee’s account gets used months after they left, because nobody told the provider they’d departed. A new piece of equipment at a second location never gets patched, because the provider didn’t know it existed until it showed up in an incident. A maintenance window that could have caught a vulnerability keeps getting pushed back by the client for operational convenience, until the vulnerability gets exploited instead.
In each case, the failure looks, from the client’s side, like proactive IT support failing to do its job. And in a narrow sense, something clearly did fail: a risk that should have been managed wasn’t. But the provider was never in a position to catch it, because the information required to catch it never reached them. The failure sits in the gap between the two halves of the relationship, not cleanly inside either one.
What changes when the dependency is made explicit
The fix here isn’t asking clients to somehow anticipate every piece of information a provider might need. It’s the provider naming the specific, recurring categories of information the relationship depends on, upfront, as part of the engagement rather than as something discovered after an incident.
That looks like a short, defined list rather than a vague request to “keep us in the loop”: offboarding notifications on a defined timeline, a simple process for flagging new locations or equipment, and an agreed standard for how maintenance windows get scheduled and honored. None of this is complicated. What makes it work is that it’s stated clearly enough that both sides know it’s part of the relationship, rather than something the client is expected to intuit.
Providers that do this well tend to build a lightweight check-in into the relationship, a monthly or quarterly review where the client is specifically asked about changes: new hires, departures, new equipment, upcoming moves. That single habit closes most of the gap, because it stops relying on the client to remember to report something and instead builds a moment where the question actually gets asked.
The relationship works both ways, or it doesn’t fully work
Prevention is a shared responsibility, even though only one side is paying for it and only one side is named in the contract. A provider can do everything within its control, monitor diligently, patch on schedule, respond quickly, and still be undermined by a gap in information it was never given the chance to close. Naming that dependency explicitly doesn’t shift blame onto the client. It gives both sides a fair shot at the outcome they’re actually trying to reach, instead of leaving one half of the relationship to chance and discovering the gap only after it’s already cost something.