Controls testing is key to SOX 404 compliance. Every year, the financial auditor is faced with a question "Which Controls should be tested for SOX Compliance?". Controls testing should be performed to ensure the auditor's conclusion whether controls address the risk of material mis-statement. To take a simple example, management assertion for completeness may include that accounts within the Accounts Receivable area are complete and accurate. The financial auditor will then develop the SOX testing plan to verify if the account receivable processes support the above assertion.

In SOX testing, the financial statement auditor must keep in mind that

- there may be more than one control that addresses the risk of mistatement to a relevant assertion; and

- On the other hand, one control may address the risk of mistatement for more than one financial statement assertion.

So how should the external financial auditor determine, which controls to test? The decision to include a particular control for testing should be based on which controls individually or in combination address the assessed risk of mis-statements for a given financial statement assertion. The way the controls are labeled has nothing to do with whether they should be selected for testing.

With AS5, auditors need to take a risk based approach to testing controls. In a scenario where there are entity level controls, transaction level controls as well as specific control activities, it is not neccesary to test all of these. The external auditor needs to have a good explanation on the risk assessment used for selecting controls to test. Under AS5, it is not neccesary to test all controls relevant to an assertion or test outdated controls.

Related SOX Posts:

- Entity Level Controls for SOX Compliance
- SOX Project Management 
- SOX Journal Entry Testing Approach
- Control Self Assessment for Sarbanes Oxley

SAP BW turns data stored in SAP R/3 into more reportable knowledge. SAP BW is not about creating or updating data, but it is about turning the data into information for decision making. As with SAP R/3 where security is controlled via authorizations, in SAP BW implementation as well, security is a key aspect of BW model implementation. SAP BW Security is not focused on transaction codes or actions that can be executed by users, but is more focused on the data itself. To put this in a structure, SAP BW security focuses on the key areas within BW which are:

- Info Areas
- Info Provides including BW Infocubes
- BW Queries

It is clear on the above that SAP BW Security is focused on what data can be accessed by the user, The main use of BW is to analyze information and summarize this information in an Infocube. This data is not updated by the end user. The data to be analyzed is accessed by the user in the InfoProvider by using a reporting tool such as BEx Analyzer. InfoProviders in BW are a classification of objects that can provide data to a BW query such as Infocubles or ODS objects. The Infocube contains data the summarized data that can then be analyzed by the user. Results of the query are based on the data in the InfoCube / ODS Object. BW Transaction code RRMX is one of the key transaction codes to analyze data.

So how does a company differentiate between its security strategy for SAP BW as against tackling security within SAP R/3. In ECC 6.0 security is detailed around company codes, document types, sales organizations, purchasing organizations, plants, business areas and so on. Authorization restrictions are relevant at the transaction code level as well as at authorization object level to prevent users from creating, changing, or viewing data with the ACTVT field.

However, one has to take a different approach for BW security as compared to R/3. To take an example, in BW it is key to look at lets say which company codes can a user access. A BW query can provide a restrictive view if the user has access to only a select set of company
codes. The user may only be able to make decisions for that particular company code only. When a user executes a query, and they have access to only one company code 1000, the query will return data for that company code only. This may be valid in a scenario, where there are
multiple company codes per geography and data across each should not be shared. It is important that the security strategy be planned at the onset of the BW implementation. This has a major impact on how BW report, queries will work in the future and how these may be secured. Even in BW, report and queries can be secured at the company code level, purchasing organisation level etc, but a thorough consideration must be given as to how this will fit in with the overall security strategy for the company in their system landscape.

Related Posts on SAP BW

BW Certification Exam Questions
SAP BW Application Consultant
SAP BW Reporting Agent Configuration