To get in touch please send us an email via the contact form

The dangers of a sulking contractor or employee

08 Apr 2015

The dangers of a sulking contractor or employee

Posted by with - in Databases, Networks, Security

As ICT (Information Communication Technology) professionals clients put their trust in us to do a good job. Most of us work hard for our clients and seek to give them the best value for money. Some, as we know, bring the profession into disrepute and its not just from shoddy work. Within thirty seconds a petulant employee or contractor can cost you thousands, but how do you protect yourself?

In my years working in ICT I recognise that you have good times with clients and you have bad times with clients. Build a strong relationship and you have them for a long time. Sadly though that doesn’t always work out as personnel changes and changes in circumstances within a client company can mean that, through no fault of your own, your relationship ends. Then of course there is the time the client outgrows your ability to support them.

I have learnt many things about people and seen much unprofessional behaviour over my years as an ICT consultant and I have often warned clients about the dangers of placing too much trust in one solution or one area. I also find myself having to advise clients to consider the possibility of a failed relationship and the damaged that can ensue should a former employee or contractor decide to wreak havoc or vengeance. Not a message the client wants to hear because after all they trust us and so do not want to believe such things happen.

Let me relate one such tale which illustrates this point exactly. It emphasises the need to have your own backups of all the data and content of the website at all times and not rely on the website contractor, designer, or other parties to maintain them for you.

Recently a company that I have done business with for a number of years, but don’t do contracted consultancy for (so they have not received security assessments or briefings from us) got themselves into quite some difficulty just because they didn’t renew the support contract with their web developer.

I was aware that the web developer had been causing trouble for some time. Not delivering and narrowing the options of the client unnecessarily. I supported them in finding an alternative developer and I suggested strongly to them that they allowed this developer to get in place before they sacked the existing one. For reasons of their own they didn’t do that, however they did ask my support in changing passwords and locking out the existing developer. They assured me that he had been fully paid and that has proven to be the case. They simply did not want to renew his support contract which was due as is of course their right and they had not yet concluded their deal with their new provider. The client was concerned that this developer would be unhappy about it and they proved to be very right.

In providing the initial advice to them, and at their request, I had researched the particular CMS that was in use and with the support of other ICT professionals that were familiar with, indeed expert in it, and know to me and trusted by me, I developed a strategy to transition to another developer to take over. However I wasn’t expecting the following outcome.

The developer had completely taken over the site by, over time, changing notify information, contact information and some ownership details. This meant that when I changed the cPanel (gateway) password he was automatically and immediately notified by the service provider and he by his own admission logged in giving him access. According to the ISP he also changed the passwords by means of a lost password request and while he was at it he was deleting critical configuration files, logs and the contents of system files and CMS users from the database causing a cascade delete of data and so a lot of the website content was gone. In short, the website no longer worked any more!

When you get these situations you have to ask “What could I have done differently?” Not much against someone who was so determined. Changing the notify information would have tipped him off in the same way and he could easily lock me out by changing the master password that the client gave me. In any case it is not so easy or quick to do and it was not visible and had to be changed by the ISP, so I could not have been aware of it. Taking a complete back up of the system in advance would also have alerted him and although I had some backups and some information I by no means had it all and would have required the website to have been taken down for some time as it is relatively huge.

The developer gave himself away that he had been on the site by admitting that he had removed his google analytics and some fonts so his presence there is without doubt. He also gave himself away by his other comments to the client including an almost preemptive list of things that we now had to do, followed by a “see I told you so” taunt email or txt when it had been done, some at 9.45 pm. Each intervention by text to the client declared with certainty what needed to be done with unerring accuracy. Something he could not have known once, with the help of the ISP, we had secured his inability to connect unless, of course, he had been guilty of the cause. However when he finally gave up the backup of the data he had spiked it with extra code meaning it didn’t work and had broken a routine that the client was currently relying on.

Needless to say that cunning plan” didn’t completely work as the site is up and running and the client and ourselves are licking our wounds from the three day war that we ended up in because of an unprofessional and petulant developer who had lost the client long before he chose to wreak revenge because he was no longer employed.

So here is my simple advice on how to avoid most of the above happening to you in the future:

Enter into a contract with your developer requiring him to deposit an up to date copy of the database into a site where he has write only access. Check that it is done regularly and have it tested to make sure it works occasionally. Check that they have done it often and pull them up if they don’t do it.

Keep the copies so that you have the latest working backup to hand and several from before. It’s not fool proof but I suspect that 90% plus of the issues we faced would have been circumventable with more ease if the client had done this. Slightly paranoid? Possibly but how important is your website these days? What is more how many of you have access to and a sound relationship with, a Professional company such as ourselves who are capable of responding to such events?

Comments are closed.