Lessons Learned from the Transition to COSO 2013

Protiviti has shared with us a useful Top 10 Lessons Learned from Implementing COSO 2013.

I especially like this section:

It is presumed that everyone understands that a top-down, risk-based approach remains applicable to Section 404 compliance, and the transition to the 2013 updated Framework does not affect this. While we don’t list this as a lesson, we could have, because some companies either forgot or neglected to apply this approach when setting the scope and objectives for using the Framework. As a result, they went overboard with their controls documentation and testing. We can’t stress enough that the COSO 2013 Framework did not change the essence of, and the need for, a top-down, risk-based approach in complying with SOX Section 404.

The report has a number of excellent pieces of advice. However, I wouldn’t be me if I didn’t have points of disagreement.

The first is on mapping. It is NOT necessary to map all your controls to the principles. If we take principle 10, for example, it states “The organization selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels”. Rather than map all your control activities to this principle (or to principle 11, which is the same – just for IT general controls), the organization needs to identify the control(s) it relies on for its assessment that the principles are present and functioning[1]. For principles 10 and 11, that will be the SOX scoping exercise. For the principle on fraud, the control that should be identified is the fraud risk assessment, not every control relied on to detect or prevent fraud.

Then there is the assertion that indirect controls are the same as entity-level controls. COSO (both 1992 and 2013) tell us, correctly, that activities in each of its components may operate at any level within the organization. For example, let’s say that an account analysis is prepared by Corporate Finance as part of the period-end close. This entity-level control may operate with sufficient precision to be relied upon to detect a material error or omission in that account. But the entity-level control is a direct control, not an indirect control. (A direct control can be relied upon to prevent or detect an error. An indirect control is one that serves to increase or decrease the likelihood that other, direct, controls will function effectively. Hiring, integrity, oversight by the board – these are indirect controls where a defect would increase the likelihood that affected direct controls would fail.)

Another example that helps us understand the difference is the hiring process (related to principle 4, in the Control Environment). The hiring process most often is at a lower level than the entity-level, often as deep as the activity level as that is where most hiring managers reside. Controls in the hiring process in this situation are activity level (or what I call ‘intermediate level’ controls, operating at a location or business unit rather than either the top or the bottom of the organization) and are indirect controls.

I could quibble with one or two more points, but I don’t want to detract from the report. I want, instead, to encourage you to read and discuss it.

What do you think?

What additional lessons have you learned?

[1] Full credit for this wording goes to the E&Y national office, who used it in a conversation I had with them about the firm’s training of its audit staff.

Advertisement