Business Tech: Finding an Exit
Since Bennett is talking about hiring in this issue, I thought we should also cover the other way that the door swings. Fired is not the opposite of hired. It is one of the possible exits. People leave for better jobs. People are excessed, laid-off, and take sabbaticals. Leaving isn't always permanent. Leaving isn't always leaving. Sometimes we are seeing Sally out the door in Marketing so she can walk in the door for Sales in the same company.
When Sally moves from the Denver office to the Miami office, what should change? When she goes from Marketing to Sales, how does that affect her rights and privileges in the organization?
Those are good starting questions, but IT doesn't stop there. We should also think about communication: Who should be notified? Should Security be reminded to change her badge color? Should the HR department be reminded to determine who her new boss is? Should Sales be tasked with officially assigning her a territory?
Yes, we do need to do the obvious IT things, like move or replace her computer (and phone and tablet and so on), change her network storage access, update her sharing privileges, and update the corporate directory. We still need to go beyond that and use our tools to streamline the entire process. Hopefully, your HR software has much or all of that built-in. If not, why not?
Bigger and Better
When Andrew leaves us for a new opportunity, we have to address half the issues that we looked at with Sally. We are shutting things down, but not adding alternatives. Now we have challenges like retention of data. How long do we need Andrew's ID to persist? Do we use it as a datapoint? We have obligations like COBRA, where HR still needs to track some information about Andrew. And what if Andrew returns?
That last one is often a gaping security hole. Watch the issue unfold: Andrew leaves. We disable his password(s), mark his account(s) inactive, and leave his ID out there because performance reports, sales data, and all sorts of other metrics refer to individual employees. Everything is good. We don't need to modify his permissions because the account is inactive and the passwords are dead.
Six months later, Andrew calls up and asks for his job back. Bigger and better wasn't either of those things. His boss doesn't have an opening, but another team does. We put Andrew back to life and give him his new permissions. The problem is that we never voided his old permissions. It seems obvious when we look at it like this, but I've seen it happen before. Sally's change is immediate; we do all the steps. Andrew's changes are in stages. He ends up with all his old rights and all his new ones. As the British say, "Mind the gap."
Square Peg Meets Round Hole
When Joe's department reorganizes, Joe loses his job. He isn't bad. We aren't dissatisfied; we just aren't doing the sort of jobs that Joe did for us. This is, from an IT standpoint, a situation much like Andrew's. Joe is leaving. Joe might be asked back, or ask to come back, when things change again. However, Joe may also present a different situation. We might keep Joe as a consultant.
The reorganization does not magically end every project and tie all the open issues up with a neat bow. So, Joe might be Schrödinger-ed, working for us but not working for us. If your system is HR-based, this can often be more difficult because in nearly every respect, Joe isn't an HR entity. He's a vendor. But, and this is a big but, he does need many things which an employee needs. He has to have an ID, password(s), and access to systems. At the same time, he doesn't need a paycheck, health insurance, invitations to the company retreat, and so forth.
The same thing may apply to layoffs.
Gimme a Break
Sabbaticals are normal in certain industries. Close variants, like maternity leave, family leave, or FMLA (Family Medical Leave Act), would also fall into this category. You should — SHOULD, SHOULD, SHOULD — have a policy of deactivating accounts when people will be out for extended periods. This is not the same as Joe's situation because some things will be handled differently.
A perfect example is e-mail. When Ronnie leaves for six months, we probably need to auto-forward her e-mail, perhaps copying her on it, perhaps not. While we will suspend her computer access, we might elect to let her continue to have access to e-mail and voice-mail. And these answers are likely to change on a case-by-case basis. Ronnie's sabbatical from teaching might be substantially different than Nick's FMLA from janitorial services.
Some exits are firings. When Matt is caught raiding the corporate accounts, we have to treat that exit differently than the more friendly sort. In the extreme case, like the one we are discussing here, there may be legal action. Or the legal issue might be on the other side. If someone is fired unjustly — or sees it as unjust — there may be unexpected legal actions. Therefore, we should have procedures and software in place to treat all firings as potentially actionable.
All means all. The previous examples are not guaranteed to be litigation-free either. Sally might see her move as a form of harassment. Joe may feel that he was targeted. Whether they are right or wrong, we need to take the same steps.
The normal things need to be done. Deactivate, disable passwords, remove permissions, and so on. But everything needs to be documented first. What did they previously have access to? What e-mails did they send? For larger businesses, a forensic accountant can be an excellent resource for helping to shape these policies and procedures.
Some final thoughts: I don't just have my own passwords. For example, I might have VPN passwords, access codes for the front door, the credit card number for the departmental account. Don't micro-focus on the individual's accounts. Look at all the ways we grant them rights and make sure that the changes ripple out as far as they need to go.
Remember, the software is an agent of policy. We need to make sure that our systems do the right steps in the right order. And we can't underestimate the value of documenting access.