Change the Locks

When I worked at Sherwin Williams, they had a policy: Any time a key holder left a store, you immediately changed the locks, even if the person was still working for the company. This may seem to be over-cautious, but it actually protected the company and the employee. In IT, I have continued to use the analogy of "change the locks" in many scenarios.

It's obvious this policy protects Sherwin Williams. After all, it protects them from any bad apples that might come back. It also protects the company in the case where someone else got hold of the employee's old key.

What's less obvious is that it protects the departing employee. The locks were often changed on the employee's last day. If, by chance, the store was robbed that very night, and there wasn't any sign of forced entry, then that employee was in the clear.

Without this clear and consistent policy, the company would have an unknown number of keys floating around for every store. Eventually, this might would cause a preventable security breach.

I think the parallels with IT are obvious. When an employee leaves, or changes roles, change the locks. In other words, remove any access or privileges they no longer need.

Unlike the physical world, the exact changes that need to be made may not be as obvious. Therefore, it is important to set up well thought out policies. Here are some things to look at:

  • Who decides what roles and permissions are necessary?
  • How is the change in authorization initiated? Can it be automated?
  • How do you know what resources people have access to?
  • How often do you review the roles and permissions?
  • Do you use a central authorization system and single sign on? Are there systems that are exceptions?
  • What qualifies as a change in role? Can you make use of a system like LDAP?
  • Do you have outsiders (contractors, clients, auditors...) that will need access?
  • What qualifies as leaving? Will people who retire, or are laid off, still need some access?
  • Do people occasionally need a higher level of access? How is that handled?

There are no right answers to these questions. The important thing is to have these discussions early, and often, before something goes wrong.