1

SOX GENERAL CONTROLS,

APPLICATION CONTROLS
AND SPREADSHEET
CONTROLS
 2

Introduction
•  The primer information
technology general controls
webinar primer provided an
overview of components of
this process
•  This webinar will speak
directly to the importance of
general controls (GC),
application controls (AC)
and spreadsheet controls as
they relate to Sarbanes-
Oxley
 3

Introduction
•  In the initial years of SOX
compliance, many felt that a
MW could not result from a
failure of any type of IT control
•  The world had changed
•  IT is no longer simply a back
office function
•  IT is of strategic importance to
ICFR
•  It must be adequately evaluated
from both a GC and AC level
 4

Agenda
•  Information technology and SOX
•  Identifying controls to evaluate
•  IT Control Framework
•  Approach to IT Evaluation
•  IT Entity controls
•  Application vs. General Controls
•  Information Technology General Controls
•  ITGC Specific to FR
•  Application controls
 5

Agenda
•  IT Baselining
•  Updating Baselining for IT
•  Spreadsheet processes
•  Documentation and testing
 6

IT AND SOX
 7

IT and SOX
•  PCAOB and SEC guidance
states technology controls
should only be part of SOX
404 to the extent specific
financial risks are addressed
•  Approach can significantly
reduces the scope of IT
controls required in the
assessment
•  Scoping decision is part of
the entity's top-down risk
assessment
 8

IT and SOX
•  Statements on Auditing
Standards 109 discusses IT
risks and control objectives
pertinent to a financial audit
•  Why should IT control be
evaluated…...
•  Business processes continue
to become more dependent
on technology
 9

IT and SOX
•  To determine how IT processes
relate to SOX, assessors must
understand how the FR process
works
•  Then identify the areas where IT
plays a critical role
•  IT controls can have a direct or
indirect impact on the FR
process
•  Assessors can utilize the same
framework for identifying
relevant IT controls as used for
other controls
 10

Sarbanes-Oxley Sequence
Define priority accounts to be reviewed;
Accoun&ng iden5fy significant accts./disclosures/
RA
relevant asser5ons

Document
Document transac5ons flows that
Processes materially impact FS

Use FS asser5ons to source

What are the risks Source Risks “what could go wrong”
Document controls at source of
What are the controls Document risk (preven5ve)or downstream
Controls
Who owns the controls in process (detec5ve)

Assess effec5veness
Is design of controls sufficient Assess
Design of control design
to address poten&al of MM

Validate
Test effec&veness of controls. Opera&ons
How are controls performing

Report
 11

IDENTIFYING TECHNOLOGY
CONTROLS TO EVALUATE
 12

IT and SOX
•  SOX is concerned about controls
that directly relate to FS assertions
•  Application controls that ensure
completeness of transactions can
be directly related to FS
assertions
•  Access controls that exist within
the applications are important
but do not directly align to a FS
assertion
•  What type of IT controls should be
considered…..
 13

IT SOX Controls
•  Specific application (transaction
processing) controls that
directly mitigate FR risks
•  GC which support assertions
that financial programs function
as intended and ensure key
financial reports are reliable
•  Controls which ensure problems
with processing of financial
information are identified and
corrected
 14

IT CONTROL FRAMEWORK
 15

COBIT
•  Several frameworks are designed for
use with IT-related controls
•  COBIT (Control Objectives for
Information and Related
Technologies) is an IT governance
framework that provides governance
(entity-level) and detailed (activity-
level) objectives
•  COBIT provides a comprehensive
understanding of the IT environment
•  It may be referenced and considered as
part of the work on IT risks and
controls
 16

COBIT
•  The COBIT framework provides
guidance on the achievement of
the broader spectrum of internal
control around the IT environment
•  Section 404 must focus primarily
on the achievement of the
assertions that are inherent in
reliable financial reporting
 17

COBIT
•  To fully document the
technology controls using
COBIT would create
documentation far in excess of
SOX 404 compliance
 18

APPROACH TO EVALUATING
IT FOR SOX
 19

Approach
•  Understand IT organization and
structure
•  Evaluate IT entity level controls
•  Evaluate IT process level controls
•  Application controls
•  General controls
•  Spreadsheet controls
 20

Approach
•  IT controls should be
considered for the systems
that support critical financial
business processes after the
top down risk assessment is
completed
•  ITGC should be evaluated for
any process or location that
support key FR applications
 21

IT Approach
•  Key is to complete evaluation as
soon as possible after the top
down risk assessment
•  This will help the assessment
team understand the strengths and
weakness of the IT systems that
impact other financial related
controls
 22

IT Approach
•  Document key applications
related to the critical
business processes linked to
the priority FR elements
•  Next, identify the related
technology components and
general IT controls that
provide assurance of
processing and data integrity
for the key applications
 23

IT Approach
•  Once those components and
ITGC are identified, the
associated documentation and
evaluation work is linked to the
associated business processes (as
well as to the related
applications)
 24

IT Risk Factors
•  If factors indicate lower risk,
the control being evaluated
might be suited for
benchmarking.
•  If factors indicate increased
risk, the control evaluated is
less suited for benchmarking
•  Factors are:
 25

IT Risk Factors
•  Extent to which the application is
stable (few changes from period to
period)
•  Availability and reliability of a
report of the programs placed in
production. (may be used as
evidence that controls within the
program have not changed)
•  Overall access control related to the
program
 26

TECHNOLOGY ENTITY
CONTROLS
 27

IT Entity Controls
•  Assessors must consider the
overall strengths/weaknesses in
the CE surrounding IT
•  Technology ELCs include:
•  Policies for developing and
modifying accounting systems
•  Defined responsibilities for
implementing, documenting,
testing, and approving changes
to financial computer
programs
 28

IT Entity Controls
•  Control over system conversions
•  Management approvals for access
to specific applications
•  SOD within IT
•  Procedures to prevent unauthorized
access to, or destruction of,
documents, records (computer
programs and data files)
•  Physical security over IT assets
 29

IT Entity Controls
•  Dedicated security officer function
that monitors IT processing activities
•  Reports to the board and audit
committee on the current state of IT
security
•  Systems to monitor/respond to
business interruptions due to
incidents stemming from malicious
intrusions
•  Logging of security violations and
other incidents
 30

IT Entity Controls
•  Consider outsourced providers and
requirements for SOC reports
•  SOC reports may provide a certain
level of assurance
•  Management is responsible to
ensure SOC reports cover required
controls
 31

IT Entity Controls
•  Cloud based applications -
management may not have the
option to configure controls
•  If not configurable, management
should understand the impact of
the existing controls and how they
impact the flow of transactions
•  Manual controls, user access
levels and security administration
should be considered for any risk
exposure
 32

IT Entity Controls
•  Strong ELC control is one where IT
upper management and the
application and data owners, fully
understand, communicate and
monitor the overall CE
•  Documented policies for internal
controls within the IT environment
•  Monitoring processes for various IT
processes
 33

APPLICATION VS. GENERAL

CONTROLS
 34

AC vs. GC
•  The variance between AC and GC
can be confusing
•  Application controls - controls that
pertain to the scope of individual
processes or application systems
(specific to a given application)
•  General controls - controls that
apply to all systems components,
processes, and data present in an
organization or systems
environment
 35

Application vs. General

General
Applica5on Controls -
Controls – Controls
Reside in around the
applica&ons environment
and relate to that supports
transac&ons the applica&on

Edit checks Manage Change

Authoriza&ons Logical Access
Valida&ons IT Opera&ons
Calcula&ons
 36

AC vs. GC
•  Confusion can exist on when
some informa&on technology
controls are classified as
applica&on controls vs.
general controls
•  One example is controls that
involve segrega&on of du&es
over access to informa&on
technology
 37

AC vs. GC
•  SOD Transaction level (AC)
•  Request/approve accurate,
timely/complete recording
of transactions
•  Prepare accurate, timely,
complete recording of
transactions
•  Move programs in/out of
production
•  Monitor accurate, timely
and complete recording of
transactions
 38

AC vs. GC
•  SOD System change
management level (GC)
•  Request/approve
program development or
change
•  Program the
development or change
•  Move programs in and
out of production
•  Monitor program
development and
changes
 39

GENERAL CONTROLS
 40

ITG
•  ITGC represent the foundation of
the IT control structure.
•  They help ensure the reliability of
data generated by IT systems and
support the assertion that systems
operate as intended and that output
is reliable.
•  ITGC are controls pervasive to all
applications
•  ITGC usually include the following
types of controls:
 41

ITGC Categories
•  Control environment – IT policies and
procedures
•  Change management –to ensure changes
to business systems are authorized
•  Source code/document version control –
to protect the integrity of program code
•  Software development life cycle
(SDLC) – to ensure IT projects are
effectively managed
 42

ITGC
•  Logical access–to manage access
based on business needs
•  Incident management –to address
operational processing errors
•  Problem management –to
identify and address the root
cause of incidents
•  Technical support procedures –
help employees perform more
efficiently
 43

ITGC
•  Hardware/software
configuration, installation,
testing
•  Disaster recovery back-up/
recovery procedures
•  Physical security
 44

ITGC SPECIFIC TO FR
 45

General Controls
•  Controls pervasive to all
applications
•  Data center/network operations
•  Systems software acquisition and
maintenance
•  Program change
•  Access security
•  Application system acquisition
development, and maintenance
 46

SECURITY ADMINISTRATION
 47

Security Administration
•  In security administration area,
primary goals are establishing and
maintaining the overall IT
environment computer security
•  Administration is comprehensive in
focus, and includes processes
within applications, databases,
platforms and networks
 48

Security Administration
•  Impact on FS Assertions
•  Limiting access to critical
systems (transactions,
applications, databases,
platforms and networks)
•  Limiting the ability to
execute, approve and view
transactions to those with a
valid business purpose
 49

Controls
•  Examine how how security
administration is managed
•  Understand where access to
critical data and applications
is managed
•  Evaluate how the process
around administrative users is
managed
•  Examine access to automated
job schedulers and the
controls in place to ensure
data processing occurs timely
and without exceptions
 50

CHANGE MANAGEMENT
 51

Change Management
•  Application change management is
important to ICFR
•  The integrity of application changes
directly impacts the accuracy,
consistency and completeness of
transaction processing
 52

Change Management
•  Impact on FS Assertions
•  Changes impact completeness,
accuracy, consistency of
applications processing transactions
•  Changes can impact the appropriate
SOD
•  Access to information assets may be
made available to unauthorized
individuals through the change-
control process
 53

Controls
•  Change process should cover all
aspects of the change cycle:
initiation, monitoring, testing, and
approval as well as migration of
the approved change into
production
•  Change process must be secured
so personnel in the function
cannot make inappropriate
changes
 54

Controls
•  Change process must be
comprehensive and consider all
possible implications of the
changes, such as systems
interfaces, data and error-
checking routines, application
security changes, management
reporting, etc.
 55

BACK-UP AND RECOVERY

 56

Back-up and Recovery

•  Data may need to be recovered.
•  The company must have the ability
to restore or restart the processing
while sustaining operations and not
losing data integrity
•  Some believe Section 404 requires a
full business continuity and DR plan
in to meet the “going concern”
assumption of FR
 57

Back-up and Recovery

•  Impact on the FS Assertions
•  Ability to completely/accurately
report transactions and FR data
•  Access to assets could be impacted
if inappropriate access is granted
through backed-up data
•  The company’s ability to meet its
obligations to file timely, and
accurate reports with the SEC could
be impacted if data recovery
procedures are not effective
 58

Controls
•  Adequate policies and periodic
mock recoveries for data
management
•  Attempt to duplicate conditions
that may occur when you
actually need to restore data
•  Ensures subsequent
processing following
restoration and recovery can
be relied upon
 59

SDLC
 60

Controls
•  Test access to data to evaluate
potential for alteration or
deletion through data miss-
management
•  Tests should include restoring
required folders, complete
with back-up folders and
critical financial applications
 61

SDLC
•  The systems development life
cycle as it applies to critical
financial systems should have
strong controls beyond simple
change management
procedures
 62

FS Assertions
•  Impact on the FS Assertions
•  Ability to completely/
accurately report
transactions and FR data
•  Access to assets could be
impacted if inappropriate
access is granted through
backed-up data
•  Ability to meet obligations
to file timely, and accurate
reports with the SEC could
be impacted if data recovery
procedures are not effective
 63

Controls
•  Approval of management for
project initiation
•  Documented and continuously
updated project plan
•  AC providing reasonable
protection from errors/malicious
activities
•  Final sign-offs the business and
IT management prior to
installation/implementation
•  Identified issues have been
appropriately addressed
 64

SOD
 65

IT SOD
•  Similar to financial processes, IT
processes critical to FR should
ensure adequate SOD
•  Inadequate SOD over financial
applications can impact several
FS assertions
•  The ability to identify the need for
SOD within IT will be closely tied
to the company size and
sophistication within IT
 66

APPLICATION CONTROLS
 67

What is an Application?
•  It is a computer-based system
which processes data for a specific
business purpose. Examples:
•  General Ledger
•  Fixed Assets
•  Inventory Control
•  Sales
•  Manufacturing Resource
Planning (MRP)
•  Human Resources
•  Payroll
 68

Application Controls
•  AC pertain to the scope of
individual processes or application
systems
•  They are automated controls that
affect the processing of individual
transactions
•  AC are controls over the input,
processing, and output functions
 69

Application Controls
•  Application or program controls
are fully automated and designed
to ensure the complete and
accurate processing of data, from
input through output.
•  These controls vary based on the
business purpose of the specific
application
 70

AC Categories
•  Categories of IT application
controls include:
•  Completeness checks - all
records were processed from
initiation to completion
•  Validity checks - only valid
data is input or processed.
•  Identification - all users are
uniquely and irrefutably
identified
 71

AC Categories
•  Authentication - provide an
authentication method in the
application system.
•  Authorization - only
approved business users have
access
•  Input controls - data integrity
into the application system
•  Forensic controls - data is
scientifically correct and
mathematically correct based
on inputs and outputs
 72

Application Controls
•  Purpose of AC
•  Ensure the input data is
complete, accurate and valid
•  Ensure the internal
processing produces the
expected results
•  Ensure the processing
accomplishes the desired
tasks
•  Ensure output reports are
protected from disclosure
 73

Classification
Type Descrip5on Example
Edit Limit risk of Required fields
Checks inappropriate input,
processing or output Specific data
of data due to field format on
format input
Valida&ons Limit risk of Three way
inappropriate input, match
processing, output
of data from Tolerance
confirma&on of test limits
Calcula&ons Ensure computa&on AR aging
is occurring
accurately Pricing
calcula&ons
 74

Classification
Type Descrip5on Example
Interfaces Limit risk of Transfer of
inappropriate input, data between
processing or output systems
of data being
exchanged between Error
applica&ons repor&ng
during batch
runs
Authoriza&ons Limit risk of Approval to
inappropriate input, post JE’s
processing, output of
key FD due to Two
unauthorized access approvals for
Includes: check runs
•  SOD
•  Authoriza&on
checks, limits and
hierarchies
 75

Edit vs. Validation

•  There is a difference between edit
and validation:
•  Edit check is to limit the risk of
inappropriate input, processing
or output of data due to field
format
•  Validation check is to limit the
risk of inappropriate input,
processing, or output of data
due to the confirmation of a
test
 76

IT BASELINING
 77

Information Technology
•  Per AS5, en&rely automated
applica&on controls are
generally not subject to
breakdowns due to human
failure.
•  Allows the auditor to use a
"benchmarking" strategy
•  Consistent/effec&ve func&oning
of the automated AC may be
dependent upon the related
files, tables, data, and
parameters
 78

IT Baselining
•  Baselining automated AC can be
effective for companies using
purchased software when the
possibility of program changes is
remote
•  Auditors use risk factors to
determine whether to use a
benchmarking strategy
 79

UPDATING BASELINE
 80

IT Baseline
•  Previously tested GC can be
relied on if the following have not
changed since establishing a
baseline:
•  GC over program changes
•  Access to programs/computer
operations are effective and
continue to be tested
•  The automated AC is verified
and has not changed since the
established
 81

Updating Baseline
•  After a period of time the baseline of
an automated AC should be
reestablished
•  To determine when to reestablish a
baseline, evaluate the following
factors:
 82

Updating Baseline
•  Effectiveness of IT CE, including
controls over:
•  Application and system
software acquisition and
maintenance
•  Access controls
•  Computer operations
•  Understanding of the nature of
changes on specific programs that
contain controls
 83

Updating Baseline
•  Nature and timing of other
related tests
•  Consequences of errors
associated with the AC
benchmarked
•  Whether the control is
sensitive to other business
factors that may have changed
 84

Updating Baseline
•  The nature and extent of the
evidence that should be
obtained to verify the control
has not changed may vary
depending on circumstances,
including the strength of the
company's program change
controls
 85

SPREADSHEETS
 86

Spreadsheets
•  PC spreadsheets often used to
provide critical data or
calculations related to FR.
•  Categorized as end-user
computing (EUC) tools that
have historically been absent
traditional IT controls
•  They can support complex
calculations and provide
significant flexibility
 87

Spreadsheets
•  With flexibility comes the risk
of errors, an increased potential
for fraud, and misuse for
critical spreadsheets
•  To remediate and control
spreadsheets, organizations
may implement controls such
as:
 88

Controls
•  Inventory and risk-rank
spreadsheets related to critical
financial risks
•  Typically relate to key
estimates and judgments
where sophisticated
calculations and assumptions
are involved
•  Spreadsheets used merely to
download and upload are less
of a concern
 89

Controls
•  Perform a risk based analysis for
spreadsheet logic errors
•  Ensure the spreadsheet
calculations are functioning as
intended
•  Ensure changes to key
calculations are properly
approved
 90

Controls
•  Activities that may support the
assessment of the key controls:
•  Identify IT systems involved in
the initiation, authorization,
processing, summarization and
reporting of financial data
•  Identifying key controls that
address specific financial risks
 91

Controls
•  Design and implement controls
designed to mitigate the
identified risks and monitoring
them for continued
effectiveness
•  Ensure IT controls are updated
and changed, as necessary, to
correspond with changes in
internal control or financial
reporting processes
•  Monitoring IT controls for
effective operation over time
 92

Summary
•  Information technology controls
must have an impact on ICFR
•  Inventory your systems
•  Understand the variance between
general controls and application
controls
•  Inventory spreadsheet process
that tie into FR
•  If baselining, ensure
consideration of elements that
may impact the adequate
functioning of the system as
baselined