Segregation Of Duties

This is a subject that has come up a number of times lately and I think it needs to be addressed as there is apparently a lot of confusion about segregation of duties.

Let us first define segregation of duties.  When duties are properly segregated, no one individual is able to complete a task without the assistance of one or more individuals.  Segregation of duties grew out of the finance and accounting areas where it is important to have as many individuals involved as possible to minimize the likelihood of fraud.  This is the first important lesson of segregation of duties, it does not eliminate the possibility of fraud, it only minimizes the possibility.  If a group of individuals decide to work together to commit fraud, segregation of duties will not stop such activity.  However, the group will have to work together which is where the deterrent factor comes in as it is more difficult to hide a fraud with a group of people involved.

What people have been complaining about most when I talk to them about segregation of duties is that they will have to increase head count.  In today’s tight economy, increasing headcount is typically not an option and even in good times, increasing headcount is not always desirable.   While there are situations where headcount does have to increase to get proper segregation of duties, I would say that in 90%+ of cases that I have been involved with this is just not true.  In fact, in a number of cases, headcount actually got reduced.

As I stated earlier in the definition, what segregation of duties involves is making sure that processes that involve people are structured such that no one individual can complete the task.  In the PCI compliance realm, there are a number of areas requiring segregation of duties.  The majority of which are related to change control.  The reason change control needs segregation of duties is to minimize human error.  The idea is that, if more people are involved, the less likely that human error will be introduced and therefore security will be maintained.

So, in a change control environment with proper segregation of duties you have the following simplified process.

  • Person ‘A’ makes a change to something (program, device, etc.) based on the requirements specified in Change Request ‘1’.
  • Person ‘A’ conducts unit testing of the change to make sure that the change is operating as expected.
  • Person ‘B’ reviews the change and conducts integrated testing of the change to make sure that the change is operating as expected with the complete system.  Typically this testing is in an environment that replicates production.  If testing is not successful, ‘B’ documents the failure and sends the request back to ‘A’ for further work and testing.
  • If testing is successful, Person ’B’ meets with Manager ‘C’ and provides ‘C’ with the results of testing.  If testing was successful, ‘C’ approves the change to go into production and an implementation schedule is agreed to for the implementation of the change.  If ‘C’ believes that the change is not what was documented in Change Request ‘1’, then ‘C’ will reject the proposed change and send the request back to ‘A’ for further work.
  • If approved, Person ‘B’ moves the change from test to production.

As you can see in my simple example, there are only three people involved in the change process – two staff and a manager.  The staff could switch off the change initiator and change tester roles, but the manager is always going to be the approver.  In larger organizations, there may be more steps and more people involved in each step, but the idea is the same – minimize the potential of introducing human error into the process.  The idea being that, with more people involved in the review of the process and the results, the less likely that an error will occur.

Does human error still occur? You bet, all of the time.  Why?

  • Because the people involved are human and errors occur.
  • People do not have the experience to perform their role in the process.
  • People get lax in their role in the process.
  • The process is not followed to the letter.
  • Testing plans and testing as a whole are skipped or short cut.

In today’s hurry up environment, people expedite processes by not following all of the steps in the belief that it does not affect the outcome.  While not as critical as flying a plane, the commercial aviation industry has proven over the last 70 years that procedures have a major impact on minimizing human error.

However, if people are left in roles for too long, job stagnation can become a serious problem.  However, job stagnation can be simply addressed by rotating people’s responsibilities.  Such an approach not only keeps people fresh, but has the added benefit of cross training them for other tasks.  A lot of organizations I work with rotate their quality assurance people back to roles as change initiators or as production operations personnel to keep them fresh.

Hopefully I have pointed out that it does not take a mass of people to maintain segregation of duties.  It just requires a creative approach to ensuring that you have the most people possible to ensure that no one person is carrying the entire load or all of the responsibility.

4 Responses to “Segregation Of Duties”

  1. July 21, 2017 at 4:23 AM

    What if you are a smaller sized company and not a large enough staff compliment to allocate 4 people to this process? What we are currently doing and that works quit well in this case is we put more focus on our change control process with proper documentation, review and approval before anything enters production. But, the person that wrote the code or is implementing the change will in most cases be the same person to write the plan and required documentation and also at the end of the day the person doing the deployment. I know that this requirement is to keep me from writing code that would allow me to defraud or compromise a system, but surely if your other processes like code review and change control is solid this shouldn’t be an issue??

    • July 23, 2017 at 7:50 AM

      Regardless of PCI compliance, any QA testing and production deployment should be done by someone other than the person that did the development. It’s just a “best practice” for those obvious reason you point out. Just because it is working now, does not mean that it will always work and it is when that control breaks down that organizations get into trouble. That happens with all controls and why they are so important to stay in working order.

  2. 3 Mansion Wong
    March 29, 2011 at 4:51 PM

    In my recent PCI work in this subject area, I am told that PCI only concerns production and non-production environment. Hence, in your article, if Person “B” deploys the change to QA environment for testing, Person “B” should not be allowed to deploy the change to production environment. I see that in your example, proper segregation of duties require 4 people, one for development, one for QA, one for deployment, and one for approval. They all have their own roles and responsibilities. Definitely, there is an increase in headcount.

    Warm Regards,

    • March 30, 2011 at 8:12 PM

      Headcount does not have to increase, just the number of people involved in the change management and approval process. The developer hands off to the QA person for testing which is two individuals. There needs to be someone from management to approve the change going into production which makes three individuals. Then the QA person can push the change to production. While that is a total of three individuals, I would venture to say that every organization already has those three roles/individuals already. An increase in headcount only occurs when an organization was not properly controlling change control to begin with.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.


November 2009

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 2,386 other followers

%d bloggers like this: