The Need for Job Rotation

Author: Bruce R Wilkins, CISA, CRISC, CISM, CGEIT, CISSP
Date Published: 29 June 2022

On the surface, job rotation may seem straightforward or even outright boring. But this business process can be interesting when you peel back the layers. Job rotation is more than simply moving employees’ job duties around: It is an essential part of maintaining enterprise security.

Job rotation is based on the security concept of separation of duties (SoD), which is founded on the tenets of need-to-know, privilege and access. How these functional concepts are implemented is considered the access control method. Security managers often make the mistake of attempting to enforce the SoD defined for a given product as the overarching enterprise model. Applications do not define business processes; they are supposed to compliment processes. So, whether one uses zero trust based on rules or attributes or manually assigns privilege, understanding the concept of SoD is critical to securing an organization’s information in accordance with management’s risk tolerance. 

When defining roles for a business process, SoD is often used as a tool to help avoid fraud. The rule of thumb is that a group of 1 or 2 people working together is small enough to conduct nefarious activities without getting caught. However, once 5 or more people become involved, someone will, ultimately, turn in 1 or more of the others to the applicable authority. Thus, it is best to partition business processes so that a single individual (or 2) cannot complete large or multiple portions of the business process.

Each group of roles that can complete a given business process may be considered a team. In large organizations, I have seen 20 to 30 teams doing the same business process. When referring to job rotation, there are multiple dimensions to consider: within the team, external to the team and management of the team. I conducted an investigation into a manager who obtained the passwords of each employee on a particular team (it was explained to the employee as a contingency safeguard) and could complete an invoicing process, from inputting the invoice to issuing checks. Therefore, one must not only consider the employees completing the business process, but also the overarching managers. (And yes, the mentioned manager had purchased tickets to a South American country prior to being arrested.) 

Once roles have been defined, it is critical to understand which data each role will be able to manipulate. It is challenging to be constantly informed of all roles and their associated levels of access and privilege. This is where an access control matrix (ACM) comes into play. The ACM includes Business Process/Roles down the rows and Objects (data, programs) across the columns. Inside each cell is the degree of access and privilege (i.e., Read, Write, Execute and Delete [RWED]). The access and privilege levels are populated into the cells while deconflicting over- or underprivileged situations for each given role within a business process. One must also deconflict among business processes to ensure that separation is maintained throughout the organization. In almost all cases, a functional manager will have an ACM that can be used to validate what one has created. Or, in some cases, if appropriate, the functional manager’s ACM can be used. ACMs are usually updated every time a new application is brought into the organization. 

It is worth noting that job rotation and SoD were security requirements long before business processes began to be automated. Manual processes still must consider these concepts today. I once investigated a gentleman who collected coins out of slot machines. There were 5 locations he visited to collect the coins. When he had emergency surgery, his job was performed by someone else. During his absence, a 20% increase in revenue was observed. It was decided that we would change nothing. The gentleman came back and over the course of approximately 1 week, revenue slowly dropped by 20%. Once we found out where he was counting and removing the coins, he was arrested mid-skim.

These examples relate to fiduciary responsibility. On the security side, it is also critical that security personnel be rotated. I have investigated database administrators who were altering data, computer forensic personnel who possessed pornography collections, and network managers who ordered network devices for their home. (Some of these examples are obvious purchasing issues, but I included them for completeness.) The mentioned behaviors were demonstrated by remote and in-office workers using enterprise-owned computers. Such types of behavior can be difficult to identify when it is people who hold trusted positions who decide to behave poorly. Although I have never investigated a case of a system manager, database administrator (DBA) or other trusted individual deleting enterprise data (e.g., intellectual property [IP], copyright agreements, legal agreements) at will, I am sure there are some readers who have. 

The important question is often asked: “When should I require employees to rotate jobs?” Typically, there is a selected timeframe for the standard rotation of a role within a given business process. However, one should consider the sensitivity of jobs as it relates to the health of the organization. Ever-changing situations might encourage one to rotate jobs ahead of schedule. Therefore, it is important to ensure that all personnel performing critical business processes take vacations and are encouraged to look for promotion on other teams and in different areas of the enterprise. In my experience, exit interviews with past employees who were penalized or recently terminated showed that the individual felt their role lacked opportunity. Practices such as promoting from within show employees that there is upward mobility and opportunity to grow within the corporation. This lessens the possibility that the employees will feel stuck in a dead-end position and provides another reason for the employee to have a positive attitude toward their work, making them less likely to participate in negative behavior. 

Bruce R. Wilkins, CISA, CRISC, CISM, CGEIT, CISSP

Is an independent consultant working in the science and technology and advanced concepts domains. He provides secure innovation in an ever-changing technological topology, ranging from medical and communications innovation to innovation of advanced military applications requiring a wide range of compliance and security engineering solutions.