What I'm saying is that relying on crazy people to not go crazy is not a good data loss prevention strategy.
(In the end, putting someone in a situation where they'll do something bad is worse than being the person that does something bad. A good example is the Colgan Air crash from a few years ago. Anybody knows that when your plane is stalling you're supposed to push the control column forward and apply full engine power. The plane does the pushing the control column forward part automatically! But for some reason, the trained airline captain did the exact opposite, stalling the plane and killing everyone on board. Why? Because he got paid so little that he couldn't afford a hotel room to sleep in before his work that day, and had to commute across the country and then work a full shift. This is the airline's fault for impairing someone to the extent that he killed 50+ people by doing the exact opposite of what any trained pilot would do. $300 for a hotel room and everyone on that flight would still be alive today.
Similarly, when you fire someone that works with critical data, you need to make sure the guy's access is revoked. It's a precaution that needs to be taken, as this case shows. When necessary precautions are omitted, bad things happen. Planes crash, and important data goes away forever.)
What I'm saying is that relying on crazy people to not go crazy is not a good data loss prevention strategy.
Except companies that believe this are impossible to work for, there is so much process and policy to prevent anyone doing any harm that no-one can get any work done either. At the end of the day, you have to sort out all the trust issues before you give someone the root password, then you just have to trust them to get on with it.
"What I'm saying is that relying on crazy people to not go crazy is not a good data loss prevention strategy."
Upvoted for exactitude. Also, it's worth remembering that virtually no one hires already disgruntled employees. That's not to excuse anything that the truly disgruntled do to retaliate. But it does suggest that an abusive employer represents a risk to everyone relying on their 'teams'.
EDIT: I don't think the pilot was retaliating, by the way. What he was subject to is a different kind of abuse.
Separately, when two parties are in a fight, it's always worth remembering who started it. If blame needs to be shared, and it's unfair to share it evenly, the unprovoked aggressor deserves a special measure of approbation. Typically, this is the party with more power, not less, for the simple reason that it's a lot harder to abuse a lack of trust and authority.
I understand your point but the difference in the Colgan case is that the pilot made a tragic mistake, whereas the disgruntled employee deliberately wiped the show. Yes, his employer is careless for not revoking his permissions, but the question remains - how is this not his fault?
Because when the company has to man up, and tell the reason of the Fuck up to the stakeholders, the should not be pointing fingers to a person who was not even on their payroll.
It was someone's job to avoid this from happening, or they do not have people covering such cases... either way, someone other (person or the company as a whole) than the fired employee messed up for the business/customers and they are liable/answerable.
Because people fail... all the time. Good, Smart, Sincere people fail. (not in this particular case, though)
This is just how things are. We all have heard numerous stories of rm -r / or drop database or something similar. Hell, the whole widely accept idea of "bugs" in software industry is based on the fact that people WILL do something wrong. Not because they are bad people, want to do bad things, but to err is human.
So your process should not be designed around the idea of people doing the right things always.
