Backups are invisible... until disaster hits

In business, assumptions are dangerous. And nowhere is this clearer than in IT projects, where the smallest misunderstanding can snowball into massive disputes.

Most projects don’t collapse because of bad code. They collapse because of bad communication and assumptions that nobody notices until it’s too late.

The Silent Killer: Assumptions

Here’s how it often plays out.

You assume the client will take care of backups. They assume you’re handling them. Nobody checks, nobody clarifies, and the project moves forward.

Six months later, their system crashes. Suddenly, their team is calling you in a panic: “Can you restore the data?”

And even if backups were never part of your scope, even if your contract never mentioned them, the blame rarely falls where it belongs.

It won’t land on their internal IT team or the employee who skipped the process. It lands squarely on you - the external vendor.

Why This Happens

The truth is, clients rarely read technical scopes with the same care that you do. They don’t live in the fine print. They live in the outcomes.

So when disaster strikes, they look for accountability, not clauses in a contract.

And if your agreement doesn’t explicitly say who handles backups, how often they’re done, and where they’re stored, silence becomes consent. You end up being responsible for something you never agreed to.

The Fix

The good news is that avoiding this mess doesn’t require massive 50-page contracts. It requires clarity and proactive communication.

1/ Define who handles backups. Spell it out in plain language: is it the client or the vendor? No gray areas.

2/ Document the frequency and retention periods. Daily, weekly, thirty days of history - whatever it is, make it unambiguous.

3/ Charge separately if you manage them. Backups are not freebies. They require infrastructure, monitoring, and accountability. Treat them like the valuable service they are.

This way, when disaster hits, there’s no confusion. Everyone knows exactly where the responsibility lies.

Final Thoughts

IT projects don’t fail because of bad code. They fail because of bad assumptions.

If you expect the client to handle something, don’t assume. Write it. Communicate it. Get it agreed to before the project starts.

And in IT, the most expensive mistakes rarely come from complex technical work. They come from simple oversights - the things nobody thought to clarify.

“I thought you were handling it” is not an acceptable answer when data is lost or systems go down. The best time to protect yourself is before the disaster, not after it.

Assumptions might feel harmless in the moment, but in reality, they’re silent liabilities.

And the smartest IT vendors know that a few extra sentences in a contract today can save them from lawsuits, disputes, and broken relationships tomorrow.