© 2015 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member firms affiliated with KPMG

© 2015 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative (“KPMG International”), a Swiss entity. All rights reserved. Printed in the U.S.A. FOR INTERNAL USE ONLY.

Information Technology Controls in the Audit

Baltimore Chapter -Association of Government Accountants

November 18, 2015

© 2015 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative (“KPMG International”), a Swiss entity. All rights reserved. Printed in the U.S.A. FOR INTERNAL USE ONLY. 2

Considering IT Risks R

ea

ss

es

s a

nd

Re

sp

on

d

Overall Understanding• Understand entity and its environment• Understand overall risks at the financial statement level

ELCs• Design and Implementation of entity level controls

Significant accounts, disclosures, and assertions• Identify significant accounts, disclosures, and assertions that present a

reasonable possibility of material misstatement

WCGWs, HLCs and PLCs• Identify WCGWs and identify/test the relevant HLCs, then PLCs

GITCs• Identify and test GITCs that support relevant application controls


Entity-Level Controls – Deeper Dive – Debrief

Control Environment

Risk Assessment

Information and Communication

Monitoring Activities

Control Activities

Entity-Level Controls (ELCs)

Higher-Level Controls (HLCs)

Process-Level Controls (PLCs)

Controls that do not specifically relate to an assertion (indirect)

Controls that specifically relate to an assertion (direct)

GITCs

13


Overall approach

Apply top-down, risk-based approach− Indicators of risks include major changes in an

IT environment− Define risks with the appropriate degree of

specificity and calibrate response accordingly− Consider the overall IT environment

(applications, databases, operating systems, networks, etc.)

− IT controls may impact entity-level, higher-level, and process-level controls

Continual reassessment of risks and recalibration of response is imperative

Use professional standards


Objective of a Walkthrough – AS 5.34

Why do we perform walkthroughs?

Understand flow of

transactions

Verify points where

misstatements could arise

Identify controls to address

misstatements

Identify controls to prevent/

detect misappropriation

of assets

fraud


WCGWs and Controls

66

Don’t forget about HLCs (includes IT)

Be specific when documenting WCGWs

(includes IT)

Identify controls that address WCGWs

(includes IT)

Testing automated vs. manual ≈ more

effective and efficient

Identify all WCGWs in the process

Check control descriptions

Trace flow – not controls!


IT Diagram

7

Application Database Operating System Network Location


Understanding Processes and Controls Conducted by Service Organization

8

During walkthrough at user entity, inquire about service organization activity that is relevant to the user entity’s financial statements and ICOFR

Identify WCGWs and controls at user entity and, if applicable, expected control objectives at service organization

Consider ROMM at user entity Consider availability of evidence at user

entity

If needed information is not at the user entity, Obtain SOC 1 Type 2 Report; Visit service organization; and/or Request another auditor perform

procedures

Examples of outsourced services: IT (e.g., software development, data processing, data backup) and accounting/finance/business processing (e.g., payroll, tax, benefit

claims processing, transfer agent, fund administration, custody, and record keeping).

Include in Walkthrough

at User Entity

Availabilityof Evidence at

User Entity

Type 2 Report /

Visit/Request Procedures


Review of SOC Reports

9

Expected control

objectives

User entity FS

assertions

Control objectives

in SOC report

Type of tests

performed by service

auditor

Exceptions in report

User auditor

response

WCGWs

End-user controls


Cloud Computing

10

“Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers,

storage, applications, and services) that can be rapidly provisioned and released with minimal management effort

or service provider interaction.” NIST SP 800-145

Subset of service organizations− Third party control of hardware, software and processes but in

non‑traditional manner, for example: On-demand payroll system provided by a cloud provider Allows for access to functionality of system over Internet but does not

include details such as location of the data center or other specifics about the technology infrastructure

Risks depend on the nature of the services provided


How Do We Test IT Controls?

11


Information Produced by the Entity (IPE)

12

IPE must be evaluated to determine whether it is sufficiently reliable prior to being used in our risk assessment or audit procedures. We consider:− Precision and detail− Completeness− Accuracy

If automated or manual controls over the C&A of IPE do not exist, or are not effective, we cannot use the IPE as the basis of the related process-level control.

For IPE that is used in a substantive procedure, we can test controls over the C&A or we can perform substantive tests (often in combination with the substantive audit procedure itself).


A/R Allowance Review – IPE Relevant Data Elements

13

Relevant Data Elements: Invoice date Invoiced amounts Invoice by customer

number Aging of the amounts Assessment of high and

low risk customers

Sales Process

System configuration of A/R aging report


IPE Reminders

14

Understand and Properly Identify IPE− IPE includes general ledger reports such as trial balances, as well

as data external to the financial systems. − All relevant data elements should be identified. − We should understand how each data element was initiated,

processed, and ultimately reported as IPE. Apply Appropriate Testing Method for C&A

− C&A cannot be substantively tested if it is being used as the basis for a control

Consider End-user Computing− If end-user reports are used in the financial reporting process, they

must be tested− End-user reports produced by activities that are not subject to the

entity’s GITCs are considered to be prepared manually.


Evaluating Design and Implementation

15

Consider the following when designing procedures to evaluate D&I

The objective of the control How the control is performed and documented The nature of the control Whether the control addresses a fraud risk How frequently the control is applied The knowledge, experience and skills of the person performing the

control – for manual controls or manual controls with an automated component only

The related IT application, if any The relevant general IT controls Whether the control addresses user considerations for a service

organization. Whether the control is designed at the appropriate level of precision


Tests of Operating Effectiveness (TOEs) for Automated Controls

16

Operating effectiveness for an automated control includes the following elements:− How the controls were applied at relevant times during the period

under audit− The consistency with which they were applied,− By whom or by what means they were applied, and− Sufficient understanding of important attributes.

Consider the impact of other types of controls, particularly GITCs Consider the persuasiveness of the audit evidence needed Consider nature, timing and extent of tests of controls

TOEs are required in an Integrated Audit!


Evaluating Control Exceptions

17

What is a deficiency? An internal control deficiency exists when a control does

not allow management to prevent, or detect and correct misstatements on a timely basis.

A deficiency can be in design or in operation, such as:− A control is missing− A control is not properly designed to meet the control

objective− A properly designed control does not operate as designed, or− When the person performing the control does not possess

the necessary authority or competence to perform the control effectively


Severity of the Deficiency – Magnitude & Likelihood

Severity

Magnitude Likelihood


GITC-Related Findings

19

Failure to appropriately evaluate the impact and/or severity of control deficiencies

Failure to test appropriate GITCs or inappropriate reliance on application controls when deficiencies were identified in supporting GITCs

Failure to evaluate GITC deficiencies with other control deficiencies

Failure to consider the impact of ineffective GITCs on IPE and other relevant application controls


Segregation of Duties (SoD)

20

System access controls are the configuration controls to manage SoD in an automated environment

No single individual has control over two or more conflicting phases of a transaction or operation

SoD is tested as a part of application controls and GITCs

Assigning different people responsibility for authorizing transactions, recording transactions, and maintaining custody of assets is intended to reduce the

opportunities for any one person to be in a position to both perpetrate and conceal errors or fraud in the normal course of his or her duties.

We may identify SoD as a control activity in our walkthroughs


Linking Application Controls to GITCs

21

Do we understand the link between the automated

controls and the GITCs we plan to test? Is our test work over

the GITCs appropriate?

We first link specific application controls to the relevant GITCs that support their

ongoing effectiveness

The only GITCs to be considered for testing are those that support the effective operation of application

controls of interest

Use walkthrough to help with the linking. Involve IRM specialists.

Identify GITCs that cover all layers of the application control (network, OS,

database, application), and support the actual operation of the app control.


Linking Application Controls to GITCs – Impact of GITC Deficiencies

22

If we identify a deficiency in a GITC, have we evaluated the

impact on each related application control?

We test each relevant GITC and conclude on its operating effectiveness

If we find a deficiency in a GITC, we obtain an understanding of the impact

on relevant application controls

Linking provides a clear understanding of a GITC deficiency’s impact given its

link back to affected application controls

We first link specific application controls to the relevant GITCs that support their

ongoing effectiveness


System Implementation Risks and Associated GITCs

23

System changes introduce IT risks in the year of change Certain GITCs are designed to mitigate these risks:

− Program development GITCs address: Development or acquisition of new programs or infrastructure Major changes to existing IS

− Program change GITCs address: Limiting the number of personnel who have access to migrate changes

to the production environment to help control the process

− Access to programs and data GITCs address: Security roles and segregation of duties over system testing and

migrating changes to the production environment


Considerations Regarding Nature, Timing and Extent of Control Tests

24

Factor Considerations

Nature of Testing

In the order of from when more audit evidence is needed to when less audit evidence is needed: Reperformance or recalculation Observation of the entity’s operations Inspection of relevant documentation Inquiries (in combination with other procedures)

Timing of Testing

When more persuasive audit evidence is needed: Move timing of procedure closer to “as of” date Test controls over a greater period of time throughout the year Perform tests at unannounced or unpredictable times

Extent of Testing

The extent of evidence may be increased by: Select larger sample sizes Increase the number of performances of the audit procedure Increase the number of selected operations of the control to be tested


Identifying and Evaluating IT Control Deficiencies – Debrief

25

The audit is iterative, by nature − General IT control deficiencies have an impact on the

testing of application controls Discuss exceptions with the process/control owners for

confirmation that a deficiency exists (AU-C-265.A1-A2) Assess severity and communicate deficiencies as they’re

identified Avoid heavy reliance on manual controls as

compensating controls when communicating deficiencies to management

Consider IRM involvement when determining the impact of GITC deficiencies on relevant application controls and IPE


Reminders for Aggregating Deficiencies

26

Conclusions are judgment based; assess

qualitative and quantitative data.

Inquiry alone is insufficient (look for

disconfirming evidence)

Review work performed by IA and the service org report(s) to determine if

there are deficiencies you need to consider.

Communicate deficiencies to

management on a timely basis.

Aggregate not only process level controls,

but also GITCs and ELCs.

Participate in risk and audit quality assessment

(RAQA) Completion meeting

You are NOT done after evaluating deficiencies. Evaluate the need to modify risk assessment and, thus, the nature,

timing, and extent of substantive audit procedures

Document. Document. Document!


What Questions Do You Have?

27


For Further Information

28

For Further InformationJohnny E. Ramsey, CPA, CGFM, CGMA, CISA

Senior Manager, KPMG LLP

202-533-3292 [email protected]

mailto:[email protected]

Documents

© 2015 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member firms affiliated with KPMG