Foundation for internal control

Getting on top of access and authorization risks.

The most important and basic foundation to be laid for internal controls starts with assessing who are the persons who have authorization to do business transactions and what kind of responsibilities and reach they have within the organization. Very often we find that people are given too much responsibilities to conduct processes that the oversight of what they transact does not get enough attention.

“Maker-checker (or Maker and Checker, or 4-Eyes) is one of the central principles of authorization in the information systems of financial organizations. The principle of maker and checker means that for each transaction, there must be at least two individuals necessary for its completion. While one individual may create a transaction, the other individual should be involved in confirmation/authorization of the same. Here the segregation of duties plays an important role. In this way, strict control is kept over system software and data, keeping in mind functional division of labor between all classes of employees.”

(Source: //en.wikipedia.org/wiki/Maker-checker )

Many types of risks stem from neglecting this very important control. Typically called “segregation of duties” (SOD in short), this is the first check done by internal or external auditors. Across the world, many existing and proposed regulations (such as Sarbanes Oxley, Japanese SOX (JSOX), etc.) as well as standards brought about by IIA/ ISACA strive to bring to the fore this issue of SOD risk as the main focus for the agenda of auditors and management alike.

Segregation of Duties (SOD) is a basic internal control that can help you ensure that no single individual has the authority to execute combinations of two or more transactions that can typically become situations that can be “conflict of interest”, giving rise to potential business risks. Typical examples such as the same person issuing a purchase order and approving himself, receiving collections and adjusting against receivables, access to personnel master data with sensitive information and administering payroll, authorization to change programs in the software and also access to production systems, ability to change bill of materials and also issue production orders for manufacture, etc.

One may wonder – is this possible in a lean and mean organization? Almost all transactions are done by a few persons and how can I establish controls? Does this mean that I have to over-staff my business operations just to ensure a “no-SOD risk” scenario? Well, to be honest, there can never be a “no-SOD risk” scenario in such cases – but good practice demands that the organization is aware of the existing risks and takes suitable steps for supervisory controls or mitigation through reports or other procedures.

Irrespective of the industry or size of the organization, it is considered good practice to be aware of and sensitive to how authorization policies are enforced and ensure that roles and responsibilities do not permit excessive powers that could be unintentionally or intentionally misused.

However, large organizations with a huge user population, will find this a challenge because the user management (such as creation, modification, blocking, deleting, etc.) is generally the responsibility of the IT department. Complex IT landscapes makes it all the more challenging for them to ensure the spotting of SOD risks, because they deal with only the technical requirement for user life cycle management. Many IT departments / CIOs / CTOs are more worried about SLAs for ensuring quick productivity for granting access and they may have little or no time for understanding the SOD risk domain (sometimes spanning across multiple applications).

It is often the lack of shared responsibility between IT and the other departments such as finance or internal audit that this falls between two stools – and if some untoward risk occurs and a financial aberration, information loss or physical loss of assets happens – then the blame game starts on who is responsible for the event.

Let us look at the key points for this program to be successful.

1. Executive sponsorship – the tone at the top decides the importance for bringing in needed steps to bring in this internal control. That means, business teams have to understand and collaborate with the technical IT team to map the risk domain with the user life cycle management. Answering questions like “What if these two business tasks are given to the same person? What is the impact and potential risk? How critical is this risk (to help ranking priorities)”.

2. Defining respective groups and responsibilities – Business teams such as finance or internal audit must own up responsibility for defining SOD risks in understandable terms and the technical IT team should own up administering user management tasks to reflect the authorization policies with SOD enforced.

3. Technical definitions mapped to ‘business roles’ – We all know that business teams focus on operations and transactions and the technicalities behind how these transactions are referred to internally by the systems are not known to them. For example, “create purchase order” is a business task, “execute transaction XYZ01” is a technical command in a software. This is where the business and technical teams need to sit together and map technical definition of roles with understandable business terminology.

4. Develop risk matrix / matrices – Once the various business transactions are understood by all the teams, it becomes important to visualize what potential conflicts could arise if there is a combination of business transactions and this is where the “risk” is identified. The risk statement may state that when an employee has excessive authorization in, say accounts payable- like creating master data for vendors, initiate purchases and make payments to the vendor, it could result in a potential fraud situation. Every industry, functional area of every business has its own unique set of risk statements and has to be carefully evaluated. It is not uncommon for large global organizations to have multiple risk matrices for different business units, differing business models and varied locations. Knowledge of the particular industry, business unit and location is important to perform a customized analysis of the risk matrices that is suitable for each business model.

5. Understand current situation – Analysis of current user authorizations and their roles is the first step to identifying current status of SOD and the potential impact on various business processes. Some companies employ consulting firms who bring in their own software to run the analysis which is then perused by the company for prospective correction of SOD. However this approach is only a temporary approach, since manual efforts may not be suitable for a continuing analysis and preventative authorization mechanism. Alternatively, many organizations opt for specialized software for access governance that when connected to your software systems, has the intelligence to surface the potential SOD risks. Organizations that have a long term vision of the user access governance will opt for this approach, since cleaning up SOD risks is not a one-time activity. It needs constant monitoring due to user life cycle changes like addition of new users, new tasks, promotions, transfers, off-boarding from company, etc.

6. Remediating SOD risks – Once the analysis report is studied, you may want to take corrective action like removing unwanted authorizations from users who have critical SOD risks. This is referred to as “remediation”. This activity also includes removing unwanted authorizations contained in role definitions.

7. Mitigating SOD risks – Mitigation implies accepting the SOD risk by putting in supervisory or compensating controls to lessen the severity of the risk. Typically organizations that have lean and mean staffing, or are spread into remote locations with limited resources benefit by putting in mitigating controls that have additional checks and balances over transactions. Example of a typical SOD violation – an accounting department staff has several authorizations such as recording journal entries, adjusting receivables and writing off bad debts – you may want to put in supervisory controls such as a daily report going for a sign-off to his / her manager for journal entries, approval work-flow for writing off bad debts that could be applied as mitigating controls.

8. Get to know SOD risks when provisioning users and roles in the system – it would be best practice to pro-actively get to know SOD risks even before you grant users access and authorizations into your systems. The risk matrix that you have finalized will provide you the intelligence to compare what is requested or asked for as authorizations by each user or groups. Unless you have a very small business operation, comparing each and every authorization request against the risk matrix kept in a spreadsheet is cumbersome, time consuming and may result in missing out certain risks. There are options available in the marketplace for software that not only provide best practice risk matrices for various processes but also help in automating the whole process – starting from access request, approval by manager who gets visibility into any SOD risks, applying mitigating controls, work-flow messages to the technical team to do the final provisioning into the business applications. Obviously, the latter approach of automating the user provisioning is superior because it eliminates manual checking, comparison and provisioning that could lead to costly human errors.

9. Continuous and preventative checks on SOD risks – If you are a small organization with limited employees, you may want to go the manual way of checking for SOD risks periodically (say every quarter) either with the help of internal staff or external consultants. On the other hand, a large organization with huge number of employees, contractor or other external people accessing their systems, would do well to opt for a technology solution that helps them identify SOD risks automatically and help in provisioning / de-provisioning users in a seamless way.

10. Say NO to common log-in user accounts and shared passwords – it becomes a challenge and defeats the very purpose of identifying the users who have SOD risks when you have a group of users sharing a common user ID / account. In such a case, if there is a generic or shared account it become impossible to pin point with certainty who was the individual who used that shared account. As for sharing passwords between colleagues and friends, this is a problem of organizational culture and discipline has to be inculcated through corporate training programs.

11. Periodic reviews on SOD risks and mitigation controls – Encourage and bring about periodic reviews of user access rights and their roles by management and internal audit so that you are always on top of risks before they become loss events. Ensure that mitigation is given after serious consideration of each and every case and not as a matter of routine, because the context of the authorization request may vary based on business unit, location, criticality, etc.

12. Take steps for tracking emergency authorizations – There will always be situations in organizations that require some persons to do additional duties or tasks in emergency situations or due to the absence of some colleagues. This would entail granting temporary access rights that may result in segregation of duties risks. It is necessary to get log reports of what transactions were performed in the system during this period of excessive authorization and check whether any critical information was altered knowingly or unknowingly.

In summary, while technology and software solutions would help a lot to bring in this important internal control, it is the will and vision behind this program by a collaborative team that would ensure sustainable success in the long term.