You are on page 1of 39

Sarbanes Oxley:

Documentation Best Practices in a SAP R/3 Environment


Jim Chergey, Deloitte Johanna Jones, Deloitte

What Well Cover


Introduction to best practices related to SOX documentation in a SAP R/3 environment Control objectives, risks, and control activities Documentation of business processes and general computer controls Testing of controls Wrap-up

What Well Cover


Introduction to best practices related to SOX documentation in a SAP R/3 environment Control objectives, risks, and control activities Documentation of business processes and general computer controls Testing of controls Wrap-up

SOX Documentation Requirements


Documentation requirements represent a significant element of the Sarbanes-Oxley Act
Primary types of documentation include:
Documentation of business processes and computer controls Evidence of control activities Documentation of test results

SOX Documentation Requirements


Final PCAOB standards require the external auditor to express an opinion regarding whether managements assessment is fairly stated and whether management maintained effective ICFR
Management must create and maintain documentation to support their Section 302 assertion (control design and control Requires a tremendous level of effort to compile and maintain Many organizations plan to utilize a document repository tool to manage/organize the documentation

Inappropriate documentation could result in a significant or material deficiency, or a qualified/negative opinion

Standard SAP Documentation


Documentation available in SAP
Logs (audit, transport, table, system, security) Change documents Reports

Not all features are configured by default

In addition, not all information will be relevant for SOX

Skill Level Required to Audit SAP


Takes several years to become a skilled SAP auditor
Basis Infrastructure Business Processes

Resources with appropriate knowledge may be scarce for SOX readiness assistance SAP Knowledge + Controls Expertise +

Business Process Expertise +


General Computer Controls Expertise

What Well Cover


Introduction to best practices related to SOX documentation in a SAP R/3 environment Control objectives, risks, and control activities Documentation of business processes and general computer controls Testing of controls Wrap-up

COSO Documentation Flow

Entity

Process

Control Objective

Risk

Control Activity

Control Objectives
Control objectives describe management goals/directives Objectives typically relate to:
Financial goals (completeness, existence/occurrence, rights/obligations, valuation/allocation, presentation/disclosure)
Operational goals (efficiency, accuracy, public image) Regulatory/legal goals (regulatory compliance, legal compliance)

Financial goals most relevant for SOX compliance

Risks
Need to be addressed at several layers:
Organization risks Entity risks Process/IT risks Absolute risk - before consideration of current controls (e.g., Accounts Payable is inherently risky) Residual risk - remaining risk when all controls are considered (should be at an acceptable/appropriate level)

Risk assessment component of COSO is different than risks associated with control objectives and activities

Control Activities
Control activities are unique to an organizations industry, technologies, size, business processes, etc. Control activities are mapped to control objectives
Controls activities should include a balance of preventative and detective controls

Generic Control Objectives


Generic control objectives
Generic control objectives may not be applicable or material to an organization
Not all business processes will be relevant/material Enabling technologies and support activities differ among organizations

Typically generic control objectives are not customized

Generic Control Activities


Generic control activities
Generic control activities should be customized based upon the organizations business processes, technologies and actual practices

SAP controls will not fit neatly into the CobiT generic control objectives
It is critical that these controls be included, however

SAP-Specific Controls
The SAP application has specific controls needs unique to the application that need to be identified, documented and tested
Example: Change control activities
System change option (SE06)

Client maintenance settings (SCC4)

Utilize SAP resources to assist in identifying these key controls


SAP Security Guide (http://service.sap.com/securityguide) Authorizations Made Easy System Administration Made Easy SAP Security Website (http://service.sap.com/security)

CobiT Control Objective


Lets look at a generic CobiT objective and fit SAPspecific control activities to that objective
Manage operations: Management has established and documented standard procedures for IT operations, including managing, monitoring and responding to security, availability and processing integrity events.

Customized SAP Control Activities


SAP Activity: Access to background processing transactions (SM36 and SM37) is restricted. SAP Activity: Administrative personnel utilize CCMS tools to proactively monitor job processing activities to identify processing errors and/or issues. SAP Activity: Specific SAP background user IDs have been created to run regularly scheduled jobs. These IDs are controlled appropriately.

Controls in Legacy Environments vs. the SAP Environment


If a similar control exists in multiple environments, be sure to customize the control activities and specify the environment in which the control applies
Example: Password history controls
Users may not utilize their last 10 passwords (AS/400) Users may not utilize their last 5 passwords (SAP)

What Well Cover


Introduction to best practices related to SOX documentation in a SAP R/3 environment Control objectives, risks, and control activities Documentation of business processes and general computer controls Testing of controls Wrap-up

Integrating IT Controls
IT-enabled business process controls should be embedded in the business process documentation
For example, do not create a separate document for Accounts Payable IT controls

Control objectives can be achieved through a combination of manual and systematic controls

Integrating IT Controls
Types of IT controls include:
Configured (IMG settings) System-enabled (change records) Security (design and administration of security) Reports (open sales order report) IT Procedures/Policies (user administration procedures)

Need to work with business process owners and IT business analysts to understand and document the complete controls structure

Manual Journal Entry Controls


MANUAL Manual journal entries are reviewed and approved before entry. Journal entries entered into the SAP system are reviewed regularly to ensure they were properly approved and accurately entered. IT (SYSTEMATIC) SAP automatically prevents entries where the total debits/credits are out of balance. Access to manually enter journal entries is restricted to appropriate personnel. Posting period controls are configured to ensure journal entries are posted to appropriate periods.

General Computer Controls Documentation


Documentation structure may differ from business processes
Process flows not relevant for many areas, such as system monitoring Process flows may be useful for some IT processes, such as change control and user administration

Narratives can be utilized to explain current practices

What Well Cover


Introduction to best practices related to SOX documentation in a SAP R/3 environment Control objectives, risks, and control activities Documentation of business processes and general computer controls Testing of controls Wrap-up

Testing Basics
Testing is primarily performed to evaluate the operating effectiveness of control activities Testing documentation should consist of: Testing procedures performed to ensure that control activities are functioning properly Documentation of exceptions Testing is different than Understanding Conversations with control owners does not qualify as testing Key Controls Only key controls need to be testedeven if all controls were documented

Sample Sizes
Appropriate testing sample sizes should be determined based upon:
Frequency of the control (annually, quarterly, monthly, weekly, daily, multiple times per day, programmed) Type of testing (corroborative inquiry vs. attribute sampling) Frequency of testing of the control activity (quarterly vs. annually)

Additional samples may be necessary if exceptions are found Sample size guidance should be provided by external auditor

Types of Testing
Corroborative inquiry Consists of interviews with control owner(s) to verify that the control is working as documented and corroboration via:
Observation Independent viewing of a control process or physical control Examination/inspection of evidential matter Hardcopy or online Reperformance Independent performance of a control

Types of Testing
Attribute sampling Utilized when a sample of documentation will be the primary test of the control; measures a characteristic of a control (present or not present) Additional reliance placed on testing if it is performed in a manner consistent with sample sizes/approach of the external auditors Other reliance factors:
Type of controls (control environment vs. routine transactions) Competence of tester Objectivity (independence) of tester

Documentation of Testing
Indicate who was interviewed
Include names and titles

Document content of interview Describe testing procedures performed


Examined, inspected, observed, reperformed

Note exceptions Refer to supporting workpapers and effectiveness gap documentation Provide signoff and date

Testing Documentation Example


Interviewed Joe Smith, Business Systems Analyst, and Jane Clark, Staff Accountant. Both stated that Company ABC uses transaction code AS01 to create an asset master record. Ran report RSUSR002 with the following query settings:
S_TCODE = AS01 A_S_GSBER, Company code = * (any) A_B_ANLKL, Activity = 01 (create) A_A_VIEW, Asset view = * (any) A_S_KOSTL, Cost center = * (any)

Refer to workpaper <4330.03.01 Access to AS01>. Examined the report with Joe and Jane and noted that there were 40 active and 2 inactive users with this access. Identified 6 active users that should not have this access. Exceptions Noted: Access to this transaction appears excessive. See control effectiveness gap at workpaper <2140 Asset Management Effectiveness Gaps> - Issue 20. Work Performed by Mike Auditor on 6/30/2004.

Documentation Repositories
Documentation repositories will likely need to be created/installed to track the documentation needed by management to support their Section 302 assertion Solutions vary from complex network directory structures to robust tools Document-related consideration items when evaluating solutions:
Are documents loaded or hyperlinked? What documentation can be stored? Where is the documentation stored (application database or external server)? How is data archived? How is version control maintained?

Management of Internal Controls (MIC)


SAPs tool for helping customers manage the SOX documentation requirement
General release planned for 3rd quarter 2004

Auditability of Controls
Documentation proving that controls are performed over time needs to be retained for audit purposes (i.e., the control must be audit-able) The amount of documentation should be reasonable but the control owner must be able to provide evidence of the control
May require additional signoff and filing procedures May require additional network storage

Auditors will request samples of documentation over a period of time, not just a walkthrough of the control procedure Retention of controls documentation similar to financial audit documentation retention requirements

Example Monitoring
Control: A daily checklist is used when monitoring the SAP system. The checklist is completed twice each day (morning and afternoon). Test: Auditor will select 10 days to examine evidence of the control. Documentation Requirements: Expectation that, at a minimum, completed checklists for each date will be available. The checklists should be initialed and dated by the control owner.

What Well Cover


Introduction to best practices related to SOX documentation in a SAP R/3 environment Control objectives, risks, and control activities Documentation of business processes and general computer controls Testing of controls Wrap-up

Review
Documentation requirements represent a significant element of SOX
Appropriate skills necessary to audit

Develop customized control activities and map to generic control objectives


Include SAP-specific controls

IT-enabled business process controls should be embedded in the business process documentation General computer control documentation structure may differ from business processes Document tests of controls
Testing is different than Understanding

Retain documentation

Resources Many are Available


The R/3 Security Guide Volumes I III
Free at the SAP Service Marketplace (SAPnet) Available at: http://service.sap.com/securityguide

Authorizations Made Easy Guide


Available at: http://www.tech.saplabs.com/guidebooks/default.asp

System Administration Made Easy Guide


Available at: http://www.tech.saplabs.com/guidebooks/default.asp

Security, Audit and Control Features: SAP R/3


Available at: http://www.isaca.org

SAP Security Website


http://service.sap.com/security

Deloitte
Available at: www.deloitte.com Navigate to Services Risk Consulting

Questions???

How to Contact Us: jchergey@deloitte.com jojones@deloitte.com

Session Code: 908

You might also like