IT key controls: 52-111 cancelled, but due diligence still important.

In response to the feature article "Changing with the rules," which appeared in the March 2006 issue of CMA Management, a member sent the following query:

Is there any literature regarding what depth Sarbanes-Oxley Act (SOX) compliance is required for the automated processing (IT) segment within various organizations?

I have been involved in internal control certification for Multilateral Instrument 52-111 compliance, and although there has been some advice from outside public accounting firms on the certification process, there seems to be no clear understanding of what depth an organization has to go into, from the IT point of view, to satisfy 52-111.

The question remains, does an organization have to certify the automated controls as financial data flows through interacting automated modules, in particular, ERP systems? If so, what does this mean? Does the organization have to confirm that these automated controls, such as "edits", "program logic", etc. are operating effectively?

There seems to be a lot of confusion on this, even among the professional bodies, and I would be interested in hearing how other organizations are addressing this problem.

Darren Jones, CMA, associate director of technology risk at Protiviti, responds:

With the cancellation of MI 52-111, and with the revised interpretation of 52-109, external auditors will not be delivering an attestation to documented and tested automated controls in Canadian firms not affected by the Sarbanes-Oxley Act. However, with the civil liability issue underscoring the disclosures required by 52-109, I would still emphasize the need to perform due diligence to ensure the efficacy of IT controls are validated.

As a useful reference point for this process, consider what is required by the Sarbanes-Oxley Act. In SOX, anything that is central to the financial reporting process would need to be certified--anything central to a key control.

Thus, it's necessary to identify the systems and IT environments associated with the critical business processes related to internal control over financial reporting. This means documenting and assessing risks and controls for application-level controls and procedures; IT supporting processes (IT general controls); and IT entity-level controls. It means documenting the key IT risks related to the following systems as well:

--Data validation and verification

--Complex or critical calculations

--Security over transactions as appropriate

--Key interfaces and master files

--Critical management and other reports

It is necessary to document the IT processes that support these key systems and related IT infrastructure components that could compromise data and processing integrity.

This means that, yes, an organization does have to certify the automated controls as financial data flows through interacting automated modules such as ERP systems. The organization does have to confirm that these automated controls, such as "edits", "program logic", etc. are operating effectively if they are of central importance to a key control. Even spreadsheets and databases, if used as something central to a key control, should be certified. Anywhere that a risk to financial data exists has to be accounted for. For ERPs, you have to ask, have controls been enabled? Is there an "override feature" for controls? If key computerized controls are documented, it becomes clear where general IT process and application and data owner process controls have an impact and where errors or omissions may occur if weak general controls exist.

The basic rule to remember is that inadequate documentation is a control deficiency. Management must demonstrate an understanding of the process flow and potential points of failure in any IT system supporting internal controls over financial reporting.