When you submit an enquiry via our website, we use the personal data you supply to respond to your query, including providing you with any requested information about our products and services. We may also email you several times after your enquiry in order to follow up on your interest and ensure that we have answered your it to your satisfaction. We will do this based on our legitimate interest in providing accurate information prior to a sale. Your enquiry is stored and processed as an email which is hosted by Microsoft within the European Economic Area (EEA). We keep enquiry emails for two years, after which they are securely archived and kept for seven years, when we delete them.
If you’re implementing an ISMS (information security management system) that conforms to the ISO27001 standard then you may have come across one of the controls in Annex A that talks about “Segregation of duties”. It appears as control A.6.1.2 in the 2013 version of the standard, and pops up again as control A.5.3 in the 2022 update. But what does this mean, and in what circumstances would this control be applicable? Let’s take a look.
The Oxford English Dictionary defines “segregation” as:
The action of segregating. The separation or isolation of a portion of a community or a body of persons from the rest.
But obviously in this case we’re talking about segregating duties, rather than people. A typical process may consist of a number of steps (or “duties”) that must be carried out to produce its output. So by segregating some of these duties we are dictating that they must be carried out by different people. Why? Because there may be a risk that a single person carrying out all of the steps (or even just the most important ones) could use this power for their own benefit, maybe fraudulently. Common examples where this has happened are often in the area of finance, where a hapless employee has been brought up in court accused of stealing money from their employer. They may have achieved this through an ability to perform too many steps in a finance process without adequate supervision; perhaps they have been able to create a new supplier (themselves), raise an invoice from that supplier and pay it without anyone else being involved. Suspicions are only raised when they turn up to work in that new Tesla everyone’s talking about.
Similarly to the finance example, there are processes within information security that carry elements of this type of risk. The 2022 version of ISO27002 is helpful in giving a list of seven examples where this could be the case. Let’s look at the first of these; change management.
A simple software change management process will usually involve a change request for some software being raised in the first instance, maybe due to a bug, or perhaps to introduce some new functionality. The change will be designed and then coded in development before being tested. It will then be promoted into live and become part of the application. If an unscrupulous developer wanted to introduce a backdoor into an application, or even transfer money in very small steps into their own bank account (depending on what the application does), then they would need to create the code, test it and put it into live without anyone noticing. If the change management process allows the same person to do all of these tasks then it introduces a significant insider risk.
To reduce this risk we would want the key duties in this process to be segregated and carried out by different people; one person writes the code, another tests it and a further person approves it and puts it live. The number of people involved will generally depend on the degree of risk (for example more for a big finance application), the resources available and the level to which the organization chooses to reduce the risk. Of course, the scenario we’re talking about could still happen if all of the people involved agree to be part of the deception, but it turns it from a single rogue actor situation into a less likely conspiracy one.
The principle of segregation of duties applies wherever there is a process or procedure that has the potential to be abused, or where the consequences of getting it wrong accidentally are serious. This may cover aspects of the administration of systems in particular, such as:
The point about accidental errors is an important one, as mistakes are far more common than fraud. The potential to wreak havoc via the mistaken deletion of cloud resources is increasing as we place more and more reliance on the cloud. Cloud service providers try to reduce errors by using additional controls such as requiring the administrator to type “Yes I definitely want to delete this” or similar text before carrying out the command, but a busy employee can still get it wrong if there is no one else to consult or approve the action.
The first step in applying this control is to identify those processes and procedures within your organization that carry an unacceptable risk of abuse or accidental action. For each of these, define the steps involved in carrying out the process and highlight those that must be done by a different person. For smaller organizations with few people this may involve checks and approvals at key stages rather than getting multiple people to do the work. But if this is the case, the process must be able to cater for a bad actor simply skipping the approval – ideally the system must prevent the process being completed unless the right approvals have been granted. It’s also important to back this control up with complementary ones such as activity monitoring and logging and regular reviews, to check that things are as they should be.
A.5.3 Segregation of Duties is an important control, and one which is more likely than not to be applicable in your organization. Your risk assessment should be highlighting those areas and assets of greatest significance and you should be always thinking at the back of your mind – “do we need to segregate here?”. Proper design of your processes won’t guarantee protection from this kind of insider threat, but it should make fraud and major accidents less likely by requiring more people to be involved.
Written by CertiKit’s CEO, Ken Holmes CISSP, CIPP/E. Ken is the primary author of CertiKit’s toolkit range, an ISO27001 Lead Auditor and has helped to implement, operate and audit ISO certifications over a varied 30-year career in the Information Technology industry.
CertiKit are a provider of ISO toolkits, consultancy and internal auditing services, and have helped more than 4000 organizations worldwide with their compliance.
For more guidance on implementing the ISO27001:2022 standard, we’ve put together a list of our best free resources including video guides, blogs and downloadable documents.