IT Maintenance Agreement Legal Disclaimers

I am looking to engage clients in a maintenance agreement (managed IT) starting Jan 2019.  I'm curious if it's common to include ransomware attacks/resolution in the flat monthly maintenance agreement with the client.  Where are the boundaries with flat monthly maintenance agreement vs charging for add/removes/changes (projects) to the environment?  A recent 12 user ransomware attack encrypted 2 out of 5 server and 7 out of approximately 20 workstations.  This was easily 30 hours worth of recovery time.  I obviously would like to exclude these catastrophic events out of the maintenance agreement and provide best effort security as we continue to make improvements to secure these environments against future attacks.  Time, money, staff constraints on both sides limit these things from being expedited.  Anyway, any advice on the legalese disclaimer?  Any other liability that I should be concerned that is or isn't cover with a related legal statement here?  Does a business associate agreement protect the IT individual from these disasters?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

AlexProject Systems EngineerCommented:
Putting it bluntly, if you're responsible for the maintenance of the machines, you should have patched them up fully anyway, if someone is dumb enough to force ransomware onto a machine, they need to pay for it.

At the same time though, you should be educating the client and drafting emails for them to send in order to offset the majority of risk to the company.

snoopaloopAuthor Commented:
We had them patched, had plans to upgrade from 7 all to 10, and deploy Webroot during the holidays. Someone just most likely clicked on something before we completed these projects.  The reality is we took over a account in shambles and the finger is automatically pointed at us as soon we are in the drivers seat.  So like to have some disclaimers and gain some insight from others as I'm sure I'm not the only one in this type of predicament.
Lee W, MVPTechnology and Business Process AdvisorCommented:
No two MSPs are the same.

An MSP is basically an outsourced IT department.  With that in mind, if you're going to maintain the network and be expected to do so for a flat fee, then you need to have controls in place to prevent problems.  This means (among other things):
1. Restricting admin rights.  Most MSPs do not give the client admin rights or even an admin account.  As soon as you allow someone else to "admin" the systems, you put yourself in a position to clean up the mess they leave.  DON'T DO IT.  That said, strictly speaking, it's not my network, it's the client's.  So what I do is I give them keys to the castle in the form of a sealed envelope I can see whenever I'm there.  If that envelope is ever opened without my authorization, there's a charge. And a disclaimer that notes anything done to clean up the mess left behind is billed hourly.
2. BACKUPS.  Who cares if you get hit by ransomware?  You have backups right?  You are the pro and know how to setup and maintain backups so that they too aren't encrypted, right? So if the client is hit with ransomware, you restore backups.
3. You should be analyzing their work styles, needs, and applications to better understand the restrictions you can and can't put in place as security should be a MAJOR concern. And if your policies say they can't work because they are too restrictive, you need to ease up on the policies and increase rates.  Flexibility comes at a cost.  Want a CRM product?  Prepackaged ones cost hundreds of dollars per user... or you can get the flexibility of a custom written one for thousands.

Basically, you need to be reasonable in the sense that if you get hit by a bus, you can't leave the client in a position that could cause them serious problems... but otherwise, YOU are IT - not them.  If they don't like it, they can hire someone else.  This is how an MSP (should) work.  You run the IT.  But you are a partner and your goal is to keep them safe, do as little work as possible (because your policies and skills allow you to set things up in a way to minimize the time you need to spend servicing the client which ALSO means they are kept running in a stable, working manner so you're not spending time there.  This makes them happy, you happy, everyone happy.
OWASP Proactive Controls

Learn the most important control and control categories that every architect and developer should include in their projects.

I couldn't say it is common or uncommon because agreements can vary so much, but ransomware tends to get squeezed in with virus and malware protection. So if you look at it that way, then yes.

As far as the account being in shambles before coming in, that tends to be a risk of taking over an account from another company. To be fair, pricing should take that into account at the time of bidding.
David FavorLinux/LXD/WordPress/Hosting SavantCommented:
Here's how I handle this.

1) Provide a solid backup system, where data is stored remotely, to ensure backups are never encrypted with ransomware.

Tip: Locally made backups, aren't really backups, because they can be infected with various malware, including ransomware.

Tip: Local means the backup files can be seen by way of a disk access.

Tip: Remote means a login to some system is required to pull down a backup for a restore.

2) Make full backups + incremental backups at a frequency representing how often customer changes data.

Tip: Frequency best determined during a client onboarding interview. Some clients nightly will work. Other clients might require an hourly incremental backup to run.

3) Provide ground rules for what is + is not covered under your blanket contract.

4) Ground rule violations bill at an hourly rate to remediate, like clicking a *.exe file attachment, which infects a machine with a virus.

There is no way you can ever guess the crazy actions a client make take.

If you end up with an entire network of machines infected due to a bunch of people clicking + installing malware, then you best build in to fix this nonsense at an hourly rate, because someone will have to work by the hour to clean up this mess.

Hint: If you build your contract to cover a minimum number of hours/month/machine, then bill an hourly rate for overages, then you easily escape things like cleansing 100s of machines of malware + also have a built in billing mechanism for clients who will talk your ear off your head.

I tell clients up front, I bill like an attorney. If we're on the phone for an hour, expect to see a bill for an hour.

This inspires clients to have a clear agenda on calls + stay on point.
Where are the boundaries with flat monthly maintenance agreement vs charging for add/removes/changes (projects) to the environment?
That varies from place to place. Define where you feel the lines should reasonably be drawn.

I obviously would like to exclude these catastrophic events out of the maintenance agreement and provide best effort security as we continue to make improvements to secure these environments against future attacks.
I would recommend that you think long and hard about this.
  1. Improvement is a continuous and neverending process.
  2. There will always be a risk of catastrophic events, even after you've gotten things to where you want to. Where do you draw the line? What if your work ends the being the cause of being open to said events?
  3. New attack vectors pop up every day. The customer is counting on you to protect them from those things.

But also, if you try to exclude catastrophic events, you may find yourself losing out on potential business. If you had to put in loopholes, I might base it more around things that the customer opts not to do that are best practice (i.e. you have a customer that refuses to have a backup system). The sheer possibility of having to pay dearly if things happen might motivate them to actually accept those best practices.

Time, money, staff constraints on both sides limit these things from being expedited.  Anyway, any advice on the legalese disclaimer?
But these risks always exist. Would recommend you build these possibilities in your pricing, which may assist on the staffing end of things. Sometimes with a customer you're going to end up with a lot of pain up front while trying to get things in order, then over time it balances out and even turns into being extremely easy where the profit margins turn out wonderful.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
snoopaloopAuthor Commented:
Thank you!!! I appreciate all the input.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.