Oracle Gold Partner
Enterprise Architecture Compliance - After a string of corporate failures (see Enron, Worldcom…), the US Legislature passed the most sweeping financial reporting rules and regulations ever enacted, the Sarbanes-Oxley (SOX) Act, July 2002.
In summary, the intention of the Act is to help restore public trust in US business and corporate
reporting. SOX requires public organizations (market capitalization of $75 M +) to more actively
report their current financial status.
Sarbanes & Oxley content
The main Sarbanes & Oxley themes are:
Increase oversight (101-109)
Auditor conflicts of interest (201-209)
Whistleblower protection (301)
Disclosures accountability (302)
Management assessment of controls (404)
Acceleration of disclosures (408-409)
The two main sections of Sarbanes & Oxley
The two main section of Sarbanes & Oxley are “Disclosures accountability” Section 302 and “Management assessment of controls” Section 404.
 
Section 302 is about certification of financial reports by the CFO and CEO. They must certify the following assertion :
Based on my knowledge, it doesn’t contain any untrue statement or omissions
I have set up and maintained internal controls
I evaluate their effectiveness
 
 
Section 404 is about the assessment of internal controls
The obligation to add in the annual report an assessment of the effectiveness of their internal controls for financial reporting
The obligation for an external auditor to attest and report on the reliability of the management assessment.
 
 

Sarbanes-Oxley compliance calls for Enterprise Architecture  
With the Sarbanes-Oxley Act, companies will be required to document their financial reporting processes and related internal controls.
 

Process documentation
Organizations must document their main financial reporting processes. Given the potential complexity of this process, this requirement calls for the use of a powerful business process modeling tool.
This tool must allow multiple users to design and maintain the model, communicate the model to interested parties inside and outside the organization, and maintain this model in a repository for future review.

Risk analysis and documentation
Management implicitly makes various assertions in representing that the financial statements are fairly presented in conformity with generally accepted accounting principles. These assertions are for instance:
Existence or occurrence – assets and liabilities exist at a given date and recorded transactions occurred during a given period.
Completeness – all transactions and events that should be included in the financial statements are so included.
For each significant account assertion, management must wonder for each process what can go wrong
This tool must allow to define risk family (a nomenclature of risks), characterize risk (likelihood, impact)

Control documentation
We must then consider Controls over each significant process that Address risks identified for the each assertion. The tool must make it possible to associate each risk with the corresponding, preventive or curative actions which could be automatic.
Most Business Processes are either partially or wholly enabled by IT. So it is important to document IT controls.

 
 
IT controls need to be considered at 2 levels:
Controls over the IT environment (General Controls : security, program change …)
Controls over individual applications (Application Controls : embedded software program or routine to process transactions)
 
Assessing the controls efficiency:
Periodic evaluation of controls
Implementation of improvement recommendation