Internal Controls

As I touched on in Segregation of Duties, controls are the foundation for any risk or governance framework. Internal controls reside in every facet of the organization, visible and invisible, but what exactly are they? They are any action taken by management, the board, and other parties to provide reasonable assurance that business objectives will be achieved and that undesired events will be prevented or detected and corrected. Essentially, they are insurance policies for stakeholders against foreseeable risk.

The first type of internal control is a preventative control – something that prevents the occurrence of errors (both intentional and unintentional).  Most programs have a back-end database that is critical. Most of these databases are (ior should be) restricted to access by only authorized individuals. These access controls prevent unauthorized users from entering the environment and making changes. Another example is (usually) built into the off-boarding process: when a user is no longer an employee of the organization, all credentials for the individual are to be removed. This prevents the individual from using the credentials to access information that they would not need to access due to their status as a non-employee. In these examples, there is something in place (a system or process) that prevents objectives from being missed due to problems that may be caused by incorrect access level restrictions.

The second type of internal control is a detective control – something that detects the occurrence of errors. One common example of a detective control is the review process. If an error is made by a data entry clerk (intentionally or unintentionally), when the reviewer for the process reviews the data (prior to approval), the error will be detected. These can be detected by comparing the data to what is expected, historical data, or the information that is returned from the data. If these errors can be detected prior to being approved and used in other processes within the organization, the risk that objectives will be missed is reduced. It should also be noted that in this case, segregation of duties was paramount and may be considered to be a preventative control.

The third type of internal control is a corrective control – something that can correct an error that has been detected. An easy to understand example of a corrective control would be the restoration of a database after an error is detected. Perhaps a user made an error or some data became corrupted – this would (hopefully) be detected by a detective control. Once detected, one corrective action could be to restore the database with an earlier version prior to the error. A more complicated version might be data validation – this may include both detective and corrective controls. If a batch is received by a system, the system can check to see if the batch is what is expected, either by the type or by reconciliation. If the data cannot be reconciled to the source data, an error is detected and the transaction is denied or returned (corrective).

By understanding these three control types, we can better evaluate processes or systems for risk.

 

Segregation of Duties

I cut my teeth in financial auditing. I obtained an accounting degree and went out into the world, my entire college career in the era after the passing of the Sarbanes-Oxley Act of 2002. This means internal controls have been the focus of my career for quite a while. One of the most fundamental controls is segregation of duties.

The fundamental idea behind SOD is that no single employee (or group of employees in the same position) should be capable, deliberately or not, of making a significant error (or fraud) and also concealing it. The three main components of this, in terms of assets or liabilities, are custody, approval and recording.

A simple example of duties that need to be separated for an asset would be handling cash, recording the amount of cash received and approving the receipt or the record of receipt.

A simple example of duties that need to be separated for a liability would be receiving an invoice, entering an invoice into the tracking system and reviewing or approving the invoice for entry or payment.

Now, as my career has evolved, I’ve needed to translate this concept in my brain from financial activities to the information technology world. Say, for example, we’re talking about auditing an ERP system that contains one or more financial components. Say the accounting component has the general ledger (GL) functions in it. It’s easy to translate this into controls in regards to the IT system – it’s parallel to the financial world – separate the receipt of an asset/liability, the ability to enter it into the system and the approval of the record.

Applying the financial SOD to the operation of a financial system is pretty straight forward. However, applying the concept of SOD to the implementation and maintenance of a (financial) system is a bit more abstract. The concern here differs from the concern over financial activities (by users) to the implementation and maintenance of the system as well as data access and intellectual property. This, to me, is where it gets tricky. The standard operating procedure should use the principle of least privilege. But does this encompass the majority of IT SOD?

If we take a look at a system, we understand there are multiple units that comprise its structure, including, but not limited to, source code, data management, configuration, security and infrastructure. Within each of these areas, we must separate the duties of access, modification and authorization. This will apply across functions as well.

Ex: The DBA role has access to the data, directly. As such, all changes to the database should be reviewed and approved by a different role prior to implementation. The SOD here is not as strictly defined as above – one user can access and change data, but the changes can’t be implemented until another user reviews and approves it.

We can also look at this from another angle – rather than the role we can focus on the asset.

The server configuration is managed to ensure the business can meet the SLAs. Access to server-side configuration applications is managed by the security team – only users that have approval from the relevant department are granted security clearance for this function. The access should have evidence of approval prior to implementation and only the security officer can make the changes. These changes are reviewed during an audit of system changes by a different employee. However, security doesn’t have access to the application – they don’t need it. The security roles also have controls in place to ensure that the security team doesn’t grant itself access to the application. Only the infrastructure team has access to the application, but cannot grant itself this access. Changes to the application configuration must be reviewed and approved by the cross-functional change management team. The change management team might rely on the compliance officer to determine if the changes meet best practice and have adequate documentation, but they may not have expertise in the subject matter to determine what changes should be made; they will rely on the change request to make a business case.

As we can see, this simple action flows across multiple teams and individuals and has multiple checkpoints in the process where authorization can be denied. In principle, these checks and balances seem relatively simple to implement. However, in practice, this is anything but simple. First, the requirements for process flow documentation need to be met; if the process isn’t adequately documented, there is no assurance that all duties have been identified. Next, we must rely on the SMEs in each area to identify and report that the documentation is adequate. We also must ensure that the number of employees available to perform all of these actions is great enough to properly separate the duties. Reliance on the system controls within the tools that are being utilized is paramount as well. Finally, these processes must be compared to other processes that run across teams and systems to determine any possible conflicts therein.

As evidenced, unlike financial SOD theory, IT SOD practice is more fluid and requires more technical skill to identify, assess and implement.