6/13/2013
Sarbanes-Oxley
What does it mean for IT in the Working
World?
Bob Lennard,
Senior Manager, Procurement Systems and RSTS Asia
RadioShack
June 11, 2013
6/13/2013
2
Background
• Graduated from UNT in 1996, BBA in BCIS (Business Computing
Information Systems)
• Started at RadioShack January 1997 as Associate Developer
• ERP System (Oracle Retail) developer, Cost/Price Team 1999 – 2001
• ERP System Team Lead, 2001 – 2004
• Manager, Procurement Systems, 2005 – 2008
• Manager, Procurement Systems and RSTS Asia, 2008 - 2010
• Senior Manager, Procurement Systems and RSTS Asia, 2010 – Present
Contact Info:
Email: bob.lennard@radioshack.com
Twitter: @dfwrlfreunion (SIM-RLF Reunion Group Link)
Office: 817-415-6517
LinkedIn: www.linkedin.com/blennard
1
6/13/2013
6/13/2013
3
6/13/2013
4
What is Sarbanes-Oxley?
Source: EisnerAmper Website: www.eisneramper.com
IT Control Objectives
What does it mean for IT Management?
This requires knowledge of internal controls
across business units supported – not just IT
controls.
Understand what compliance means to your
organization – must meet requirements
internally and externally.
Compliance Planning is a regular exercise
Plan Reviews Occur on a Regular Basis
Evaluate where system controls are appropriate
Integrate IT controls/plans with those of
business partners
Understand Key Controls, General Controls,
and Mitigating Controls
IT COSO’s:
• Plan & Scope
• Perform Risk
Assessment
• Identify Significant
Accounts/Controls
• Document Control
Design
• Evaluate Control
Design
• Evaluate Operational
Effectiveness
• Determine Material
Weaknesses
• Document Results
• Build Sustainability
2
6/13/2013
6/13/2013
5
What does it mean to IT and my Job?
Impacts:
• Time
• Competing Efforts
• Priority Shifts
• Design of Future
Applications
6/13/2013
6
Plan and Scope
• What Systems?
• Which subsystems?
• Which business units?
• Which IT support team?
• Keywords: Financially
impacted and General
Computing Controls
No Planning Results in Significant Creep
3
6/13/2013
6/13/2013
7
Perform Risk Assessment
• What is the level of risk? What are the potential impacts of the risk?
• How does that weigh against other risks that must be addressed?
• Does the risk justify a control? Weighed against cost?
• Do you want to create a control for it?
• Can this be addressed manually?
• Are there mitigating controls that reduce your need to create a new control?
6/13/2013
8
Identify Significant Accounts/Controls
• Who/what is the community impacted? What financial area is impacted?
• What portion of your business? Percentage? Dollars?
• Are there controls in place in other areas that reduce your need for a control
here?
• Who will be your decision makers in the creation of controls?
• Who will be the business owner of this control? The IT owner?
4
6/13/2013
6/13/2013
9
6/13/2013
10
Document Control Design
• Decide on Control Type
• Design Implementation
Strategy
• Review Control with
Involved Team
• Revise Control as
Needed
• Create Final
Documentation
Evaluate Control Design
• Is control effective?
• How does end result
compare to documented
control?
• Are there any issues with
existing control?
• Does it provide standalone effectiveness? Or
is it dependent on
another control?
• Can it be improved?
5
6/13/2013
6/13/2013
11
Evaluate Operational Effectiveness
• Is it feasible to maintain?
• Can it even be done?
• How many hours of productivity are lost to the control?
• Is the control contrary to what the business wants to achieve?
• Does this control create any barriers to the overall success of the company?
• If there are barriers, how do you meet the need of the control while
revamping it to provide operational effectiveness?
6/13/2013
12
Determine Material Weaknesses
• Did this address the
issue you intended?
• Are there any “holes” in
your design that allow it
to be circumvented?
• Are there issues in the
process flow tied to this
control?
• Are there upstream
controls that are not
providing the
feed/information you
need?
• Are you providing the
correct data to the
downstream controls?
6
6/13/2013
6/13/2013
13
6/13/2013
14
Document Results
• Recurring Process
• Validate Results vs. Expectations as Documented in Narrative
• Not only results, but often times the related code and processes
• May need to present change tracking as well
• Company Portal/Cloud Based Options for Documenting
• May do more than once – internally and externally
Build Sustainability
• Identify Potential Improvements
• Evaluate against any system changes since last testing period
• Identify new systems that require new controls
• Review system narratives and control documentation periodically
• Work with internal and external audit teams to determine required changes
year over year
• Words of Caution:
• Auditors aren’t going to tell you what to do – just whether the control is
valid or not.
• Don’t overbuild your controls. You’ll be living with it years after
implementation!
7