Home > Risk > User access risk and SOX compliance

User access risk and SOX compliance

December 12, 2016 Leave a comment Go to comments

When you take a top-down, risk-based approach to the assessment of internal control over financial reporting (for Sarbanes-Oxley, “SOX”, compliance purposes), it is quite possible to make a significant reduction in the number of key controls included in scope.

The only controls that need to be included in the scope for SOX are those that are relied upon to either prevent or detect a material misstatement of the financial statements. We call those “key controls”.

In my best-selling book, Management’s Guide to Sarbanes-Oxley Section 404: Maximizing Value Within Your Organization, I suggest this definition:

A key control is a control that, if it fails, means there is at least a reasonable likelihood that a material error in the financial statements would not be prevented or detected on a timely basis.  

In other words, a key control is one that is required to provide reasonable assurance that material errors will be prevented or timely detected.

The top-down, risk-based approach (which US regulators require external auditors to follow and encourage management to adopt) focuses the attention on key controls.

Organizations have a great many controls designed to address their various business risks. The top-down, risk-based approach enables management to exclude from the SOX scope controls that may be necessary for other business reasons (e.g., to protect valuable intellectual property) but are not key controls for SOX.

It is also possible to limit the number of controls, or “rules”, relied upon for user access risk for SOX.

By “user access”, I am talking about access to computer systems not only by business users (such as those in accounts payable, manufacturing operations, or cash management) but by people in IT charged with maintaining the systems in question.

I have led training classes for SOX program managers for quite a few years. A recurring theme is that the organizations they represent may have hundreds of access controls (“rules”) in their SOX scope.

They don’t need them all, not for SOX. They are not all SOX key controls.

Some history may be required to explain what I mean.

Many if not most organizations designed the IT portion of their SOX scope, including access controls, separately from the business process and risk side. They did not take a top-down, risk-based approach to identify what might go wrong in IT processes and activities that would lead to a material error or omission in the financial statements filed with the SEC. Instead, they relied on some combination of:

  • Checklists from consultants and others that listed access that should be limited, especially combinations of access that might represent a segregation of duties problem
  • Their experience of what constituted best practice in limiting user access
  • “Rules” included by vendors in their access control software – typically these can number about 140

But very often these rules may be necessary to run the business but highly unlikely to result in a material error or omission in the financial statements.

Examples of rules I have seen that are not critical for SOX, not key controls that need to be included in scope, are:

  • Rules about who can authorize a purchase requisition or order. Even if an unauthorized individual orders millions of dollars of materials or services, the financial statements may be correct: they will accurately record the expense and the level of cash
  • Rules about the ability of HR personnel to access payroll records. While it is possible that fictitious employees are set up and paid, it is highly unlikely that would ever be material to the financials – and the expense, though improper, has been incurred

The question to ask for all access rules is “if this happened, if this access was granted, is there at least a reasonable possibility (given all other key controls) that an undetected material error would be introduced into the financial statements?”

But there is a need for some level of access control rules. Examples include rules where:

  • A key control limits who can perform an activity, such as the approval of a journal entry
  • Access needs to be limited to certain powerful system commands, such as “root” access, that would enable an individual to bypass controls

At my last companies, we applied a top-down, risk-based approach and were able to reduce the number of access control rules in scope for SOX from more than 100 to less than 20.

But, managing user access can be a challenge.

When I ran the internal audit function at Maxtor, a $4bn manufacturer of disk drives, I also led the SOX compliance work on behalf of management.

When it came to access controls, our top-down and risk-based approach allowed us to reduce the number of rules in scope very significantly.

But we still had a problem!

We used software to identify violations of the SOX user access rules.

  • The first time we ran the software, we had more exceptions than employees! Management agreed to take prompt action and we came back after a few weeks.
  • We reran the software and the number of exceptions was down from the thousands to a couple of hundred. Some were repeat exceptions that management had missed, but an equal number were new ones! Management again agreed to act quickly and we returned in about two months.
  • Again we ran the software. This time, there were no repeat exceptions. But there were over a hundred new ones. We told management that time was running out to correct the situation before year-end.
  • We ran the software with hope and trepidation. Fortunately, there were less than ten exceptions and we were able to identify some mitigating controls, to the extent that we did not have a material weakness for SOX.
  • Around year-end, our external auditors ran their software to test these key controls. I went to my knees in prayer. Thankfully, their scans came out clean.

The right software can help you manage access risk. In fact, I am not sure that the typical organization can manage it acceptably without software. That will be the subject of a second blog post on this topic of user access.

For more on this issue, please refer to Management’s Guide to Sarbanes-Oxley Section 404: Maximizing Value Within Your Organization.

  1. John
    December 16, 2016 at 12:48 AM

    Norman, your commentary on SOX are those that are relied upon to either prevent or detect a material misstatement of the financial statements is quite correct. BUT because these controls ‘often’ are points to facilitate other SOD, Authority Limits etc we see a very comprehensive Identity & Access Management matrix. This leads to an out of scope SOX regime and dare I say, laziness in strict or in-scope SOX reporting. This is the issue surely?

    • Norman Marks
      December 16, 2016 at 7:31 AM

      John, SOX is not the only reason for controls. We need SOD controls in place to address other business risks, including fraud that does not rise to the level of being material. Is that what you mean? If so, I agree.

  2. John
    December 16, 2016 at 7:41 AM

    Absolutely, the matrix SoX, controls et al are required for many reasons, but the mitigation must not be a)confused, b)constant review, c)change of risk, etc so we are in agreement their but for ‘SOX’ we must not cloud/confuse objectives with these OTHER reasons – thats what I’m saying & that is often the ‘grey scoping’ to which I refer. I’m sure you agree with that?

    • Norman Marks
      December 16, 2016 at 7:46 AM

      The SOX work must be separated from any audit or other work on other business risks, so that the external auditors can focus on the controls required for SOX. But management needs to execute flawlessly all the controls required for business risks.

  3. marcushabib
    December 19, 2016 at 3:07 AM

    I think the concept of key control is vague, and not easy to identify /define as opposed to key risk. Because there might be heaps of key controls that are taken for grantedand not identified as so. For eg. One would say that the door lock is key control that prevents from theft, however would not consider the door itself where the lock is installed as key control!

  1. December 17, 2016 at 1:20 PM

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.