IRM IT Knowledge Topic - Access To Programs Data

IT Knowledge Topic
Access to Programs and Data
August 2020
For Internal Use Only
Disclaimer
This document is for reference information only. The use of this material is optional. It does not modify the
audit methodology or guidance set out in the relevant manual.
If there is a mandatory/specified approach (or document) for your local member firm, then please use that.
If you are unsure of your member firm’s policy for use of this document it is recommended you contact
your relevant Risk or Methodology team, including Department of Professional Practice resources.
This document may not cover all risks or considerations related to the specified topic. These materials are
provided for consideration and should be assessed for use, if appropriate, on an engagement-specific basis.
Wherever possible, audit work is documented directly in eAudIT/KPMG Clara workflow.
This document should not be put on file.
This document is a resource for engagement teams to use as they plan their information technology (IT)
audit work in relation to Access to Programs and Data (APD) at the entity they are auditing. This document
should not be retained in the audit workpapers.
NOTE: This document is one of a series of IT Knowledge documents. To understand fully all the
considerations covered in this document, teams may wish to refer to other IT Knowledge documents.
*Note on applicability: The new audit methodology set out in the KPMG Audit Execution Guide (KAEG)
introduces a number of significant changes to our methodology. One significant change that impacts on
IRM work is that to link automated controls to general IT controls (GITCs), engagement teams identify the
layers of technology that impact each relevant automated control, the risks arising from IT (RAFITs) within
each layer, and the GITC(s) that address each RAFIT. This approach is supported in the new audit tool that
replaces eAudIT: KPMG Clara workflow (KCw).
This document is drafted to be used by teams applying both KPMG Audit Methodology (KAM) and KAEG,
as far as possible terminology used is methodology independent, but where necessary the terminology of
RAFITs and Layers of technology is used. These are implicit in the KAM audit approach and explicit in KAEG.
For more information on KAEG and KCw, see the following site https://intra.ema.kpmg.com/sites/AUDIT/
KPMG_Clara_workflow/Pages/Guidance.aspx.
There is further guidance on certain terminology differences in KAM Alert 20-00.
© 2020 KPMG International Cooperative (“KPMG International”), a Swiss entity. Member firms of the KPMG network of independent firms are affiliated with KPMG International. KPMG
International provides no client services. No member firm has any authority to obligate or bind KPMG International or any other member firm vis-à-vis third parties, nor does KPMG International
have any such authority to obligate or bind any member firm. All rights reserved. NDP111567A-1F
1 of 12
Contents
1) Overview
2) General considerations
3) Example controls testing considerations
1) Overview
When audit teams test automated controls or information at a point in time, they also typically seek to
determine whether these controls operate consistently throughout the year. This consistency of operation
can be threatened by risks arising from IT, and this threat is typically addressed by identifying and testing
relevant GITCs categorised into the following IT processes:
— Access to Programs and Data
— Program Change
— Program Development
— Computer Operations.
This IT Knowledge document specifically focuses on some of the common control considerations related to
Access to Programs and Data.
Layers of technology
The layers of technology are the IT elements that make up the IT systems the entity uses. There are four
types of layers of technology:
— Applications
— Databases
— Operating systems
— Networks.
In most systems, there is at least one of each layer. When we identify risks arising from IT, we start by
considering which layer of technology the application control sits in, and then if there are other layers that
could contain a RAFIT.
Often automated controls will sit in an application layer (such as SAP), and they will be affected by risks in
the database layer. Less often, the operating system will be relevant and it is rare that risks in the network
layer will be relevant.
What are “Access to Programs and Data” (APD) controls?
An effective and successful control environment of an IT organization is highly dependent on how well
access to the IT systems is managed. APD controls allow organizations to restrict an individual user’s access
to certain parts of a system and data.
Ensuring that all users have sufficient access to perform their current roles, but without anyone having
excessive, inappropriate, or out-of-date access privileges, can be a challenge for many organizations.
Typically, therefore, many organizations—in addition to up-front preventative controls (which typically require
approval for the granting, modification, or removal of access)—may also have a detective or review control,
involving user attestation or recertification exercises. In essence, this typically involves requiring relevant line
managers (and/or system owners) to review lists of users on each system and confirm if it is still appropriate
for those users to have the levels of access they currently hold. These controls, if operated sufficiently
frequently and robustly, are effective at managing the risks around user access.
have any such authority to obligate or bind any member firm. All rights reserved. NDP111567A-1F 2 of 12
1) Overview (Continued)
As per KAM1: “Access to programs and data controls are controls established by management to reduce the
risk of unauthorized/inappropriate access to the relevant information systems related to financial reporting and
prevent individuals from perpetrating and concealing an error or irregularity.”
Some of the reasons businesses might want to enforce system access controls include preventing or
controlling access to:
— Specific transaction processing workflows or conflicting activities within workflows in order to assist in
maintaining segregation of duties
— Standing information (including historic transactions and exchange rates, for example)
— Privileged or sensitive data (including payroll data and contract terms, for example)
— System configurations (e.g., three-way match tolerances)
— Sensitive process areas (e.g., ability to start/run/cancel an interface).
(Some of these types of access and related controls are classified as Privileged Access or Segregation of Duties,
and are covered in a separate IT Knowledge document.)
For our audit, the risks that may be relevant are the risks that:
a. Identification and authentication mechanisms are not implemented to restrict logical access to IT systems and data
b. Logical access permissions are granted to users and accounts (including shared or generic accounts) that are
unauthorized or not commensurate with job responsibilities
c. Logical access permissions are not revoked in a timely manner
d. Logical access to users and accounts (including shared or generic accounts) that can perform privileged tasks
and functions within IT systems is unauthorized or not commensurate with job responsibilities
e. Physical access to facilities housing IT systems and/or electronic media is unauthorized or not commensurate
with job responsibilities.
Example APD controls may exist in the following areas:
a) Access authorization (provisioning), including contractors and third parties. Provision of access to one
or more systems, typically covering joiners (new hires) as well as changes to access for existing users whose
job role and requirements mean changes in access privileges are required.
b) Access revocation/removal/termination (deprovisioning). Prompt removal of access for a given user/
user account.
c) Access review (recertification). Checks performed to confirm that only appropriate people have access to a
given system or systems, and that the access privileges they have are sufficient (but no more than necessary)
to perform their duties.
d) Passwords. System-enforced configuration of passwords that ensures passwords cannot be easily guessed
or cracked, and that passwords are changed at a given frequency and not “reused” too soon.
e) Administrative/elevated/privileged access. Provision/monitoring/removal of access with more powerful
rights to perform changes to systems and other administrative functions. Please refer to the Privileged Access
and Segregation of Duties IT Knowledge document.
1 KAM International 32.1211 (ISA 315 Appendix 1.9)
International provides no client services. No member firm has any authority to obligate or bind KPMG International or any other member firm vis-à-vis third parties, nor does KPMG International 3 of 12
2) General Considerations
Example questions to build understanding of access and associated controls include:

— How is access managed within the entity and the individual system components?
— Are the User Access Management processes and controls for end users the same as for privileged users or
are they different?
— Do users have unique, named accounts or do they use shared/generic accounts?
— Are there nonpersonal (generic or shared) accounts?
— Are audit logs enabled for user accounts and if so, how are the logs secured/managed/reviewed? (The mere
existence of logs does not mean there is a review control.)
— Can we get complete user logs to perform our own testing of access in the period (logs of user accounts
added/amended/deleted during the period and logs of activities performed by users during the period)?
– What control does management have over the accuracy and completeness of the logs and do we consider
testing those controls?
— Do users with privileged accounts use a different account for their nonprivileged activities and if so, how are
both those accounts managed?
— Are there automated tools/systems used to manage access controls (e.g., ticketing systems for requesting and
approving action relating to new/modified/redundant access; other tools used in user access reviews; etc.)?
– If so, how is the completeness and accuracy of the information flowing into the tools/systems managed?
– Do we need to consider testing relevant GITCs over such tools?
– Are there automated controls (such as workflow for approvals) or reports generated by the tools that are
relevant to the audit?
— Based on the scope, is physical access to information systems/servers/datacenters relevant to financial
reporting?
– If yes, how does management restrict access to appropriate personnel?
– Are the servers hosted by third-party vendors? If yes, then what controls does management have to control
vendor access? Is there a SOC report that management relies on?
– Is physical access periodically reviewed?
Do user access administration procedures for employee, contractor, third-party, system/privileged, robotic, and
test user accounts vary or are they homogeneous? Similarly, do user access administration controls vary across
different layers of technology?
Some APD IT controls may be automated controls, in which case we consider the RAFITs related to them and
identify GITCs over these.
General consideration themes:
Policies:
— As part of D&I, we may read management’s policies in relation to the control objectives relevant for our audit:
– We remember, though, that policies alone do not mean that a control has been implemented and is
operating effectively.
2) General Considerations (Continued)
User listings:
Some specific considerations related to the reliability of the user access listings include:
— Are the user lists extracted from the appropriate systems that are used in the access controls (and/or as
information used in our audit testing)?
– For example, are all types of users included from the source system or do we need to get different users
from different systems (entity’s staff, contractors, third parties, all locations, Service Organizations [if not
adequately covered by effective controls in a SOC report], etc.)?
— Are HR lists (joiners/movers and transferees/leavers) used in controls (and/or as information used in our audit)
accurate and complete?
– Staff/HR listings may well not include people who are not employees, such as contractors, third parties, etc.
— If any groups/categories of users have been excluded from the listing, have we understood the rationale and
documented why this is appropriate?
– For example, if a certain category of user has read-only access, we may determine that this represents a
remote risk of material misstatement to the audit.
— For user listings, have we considered and documented:
– How the lists were extracted;
– From which system (and which environment of the system);
– By whom they were extracted;
– When they were extracted;
– What date ranges were covered by the extraction; and
– Any filters which may have been applied.
Joiners (new hires)/movers (changes)/leavers (terminations) considerations:
— Are the members of management tasked with approving access rights sufficiently knowledgeable to be able
to perform this aspect of the control effectively?
– Consider their knowledge of both the staff for whom the access is being requested, and the roles/privileges
within the system.
— Have all relevant attributes of the controls necessary for the joiners’ process to operate effectively been
identified and tested?
– For example, do the access rights granted to the new joiner actually match the privileges approved for
them, but nothing more?
— Is access always granted after approval or are there scenarios where access is granted and approval is
obtained retrospectively?
— When a user changes role or moves within an organization:
– Are new/additional access rights and privileges approved by an authorized individual?
– Are all previous access rights that may no longer be required in the new role removed prior to granting
new access?
— On termination of a leaver, is their access to all relevant systems suspended/disabled/revoked appropriately?
– In addition to system-specific access, consider the risks and implications of remote access and network
access, particularly if single-sign-on is in operation at the entity being audited.
— Are there specific testing considerations with employees who leave and then return to the organization? For
example, an employee (or contractor) leaves the organization and later returns, either as a contractor or as an
employee; or an employee leaves one part of the organization and joins another:
– These can lead to false positives when testing, where a “leaver” appears to have retained access to
systems after they are believed to have left the organization.
– Consider checking the initial list of leavers “exceptions” against an accurate and complete list of new
hires (and obtaining commensurate access approval records) before following up with management and
concluding on whether any further testing is required.
Service organization considerations:
— Are there users within a service organization who have access to systems relevant to financial reporting for
the entity being audited?
– If so, are these users covered by controls in a SOC report or does the entity manage the service
organization’s user access to the system?
– Are there other unique considerations with respect to how their access is managed?
User access reviews:
User access review/recertification controls (being Management Review Controls) involve judgment, and our
testing should be designed and tailored to reflect this. Potential relevant considerations include:
— How will we evaluate the accuracy and completeness of the list being reviewed with respect to users across
all functions, departments, locations, etc.?
— Is there a defined timeline for the completion of review and are there escalation procedures when the review
is not completed within the defined timeline?
— How does management remediate inappropriate access issues noted during the review cycle?
– If inappropriate access is flagged, then how does management assess the impact of the inappropriate
access and what activities were performed by that user account?
— Who is authorized to perform the access reviews and how are all reviews coordinated across the different
individuals performing the review (in cases where there are more)?
— Do management and the control operators understand the actual rights and privileges attached to the role?
DB, OS, and network layers:
— Does the organization have different processes for removing redundant end-user and/or generic user accounts
across a range of databases/servers, e.g., linked to Windows AD group memberships or other replicated
authentication groups?
Preventative versus detective controls:
There may be circumstances where the engagement team determines it is appropriate to:
— Test preventative APD controls only and ignore detective controls;
— Test both preventative and detective APD controls;
— Ignore one or more relevant preventative APD controls and instead test one or more detective APD controls
addressing the same risk, or
— Ignore certain relevant APD controls completely and perform testing covering the full population—note that
deciding to ignore a relevant control and only perform additional procedures to support the continued
operation of controls is not an acceptable approach for an audit under PCAOB standards where we are
required to provide an ICOFR opinion (KAEG-I: ISA 330, The Auditor’s Responses to Assessed Risks – In
summary, perform additional procedures to obtain evidence that the deficient GITC did not affect during the
period the RAFIT[s] it was designed to address, and therefore did not affect the consistent effective operation
of the related automated control[s] and/or integrity of data within the IT system).
have any such authority to obligate or bind any member firm. All rights reservedNDP111567A-1F
The approach adopted may be based on prior-year experience and indications that known issues with
preventative controls have not been addressed by management. The four typical scenarios for testing detective
controls are:
1) Detective controls alone will provide sufficient evidence
2) Detective controls will provide sufficient evidence if tested in combination with preventative controls
3) Detective controls are not relevant as testing preventative controls provides sufficient evidence
4) Detective and preventative controls are tested as there is such high reliance/risk that we cannot conclude that
controls are effective (and relevant risks addressed) unless we test both preventative and detective controls.
User access reviews (sometimes known as user access recertifications) are a detective control and they
typically provide additional audit evidence that other APD controls are operating effectively or help to identify or
compensate for deficiencies. Where our testing has not identified failures in other user access administration
controls, engagement teams consider if sufficient evidence has been obtained, or if not, considers testing these
review controls to obtain sufficient evidence – or they restrict procedures to only documenting user access
reviews at a high level in the Understanding of IT.
For example, consider the scenario examples below:
— Example 1:
– Management’s preventative control over joiners has been tested to determine that new joiners are only
allocated the appropriate access rights and privileges that have been appropriately authorized for them.
– The same control is also used as the mechanism for making changes to access privileges when someone
changes role and needs different access.
– In both cases, the new joiner or the change in role is sent via a workflow in an HR system, which then
flows to the IT organization (once approved) to be actioned.
– Management also have a detective control in the form of an annual User Access Review.
– Other relevant APD controls are also tested and found to be effective.
» Our testing indicates that all relevant aspects of the preventative control are designed, implemented,
and operating effectively. Therefore, there is no need to test management’s detective control (User
Access Review). If the audit team wishes to make reference to it, perhaps to demonstrate the control-
consciousness of the entity, then they may document it at a high level as part of Understanding of IT. In
addition, we may decide not to test a detective control such as a User Access Review if it is an annual
control that does not occur close to year-end, as it may not be frequent enough to be reliable for audit
purposes, because incorrect access could have been provided for 11 months before this control will
detect it.
— Example 2:
– Last year’s audit testing indicated that management’s preventative control for timely removal of leavers’
accounts was not effective.
– This year’s Understanding of IT audit procedures indicate that management has not made any changes to
the way the preventative leavers’ control is designed or operated.
– Last year, having found the preventative leavers’ control was ineffective, the audit team tested
management’s detective control involving quarterly reviews of all leavers’ user accounts and identifying
outliers and performing appropriate procedures over these. This control was found to be effective.
» Therefore, the audit team determined that this year’s audit approach would ignore the preventative
control and focus on the detective control.
General
2) General
Considerations
Considerations (Continued)
— Example 3:
– Last year’s audit testing indicated that both management’s preventative and detective controls for removal
of leavers’ accounts were not effective.
– This year’s Understanding of IT audit procedures indicate that management has not made any changes to
the way either of the leavers’ controls are designed or operated.
» Therefore, the audit team determined that this year’s audit approach would ignore the leavers’ controls,
and would instead involve gaining evidence in relation to leavers’ accounts to determine if any were
accessed after the date on which the user left the organization, with appropriate additional procedures
being performed over outliers identified.
— Example 4:
– The engagement team’s assessment of either the reliance on APD controls is deemed to be very high, or
the risk if APD controls are not effective is deemed to be very high.
– Testing of preventative controls addresses concerns regarding timeliness of access (i.e., access is only
granted to appropriate users after approval and authorization etc.); whilst testing of detective controls
addresses the situation where any failure within preventative controls causes significant concerns due
to the nature or extent of inappropriate access potentially arising. (Note: detective controls such as user
access reviews may only operate once or twice a year, which could mean that reliance solely on the
detective control might potentially leave a “gap” of many months of the period being audited when users
could have had inappropriate access. Hence the combination of testing both detective and preventative
controls in this scenario.)
» The engagement team determines therefore that it is appropriate to test both preventative and detective
APD controls.
General
3) Example
Considerations
controls testing considerations
Note: Controls will vary based on the facts and circumstances of the particular audit engagement.
The information in this section is provided as example information only.
Example WCGW/RAFITs Illustrative controls Testing considerations

Identification and Passwords Inquire, inspect, and/or observe to obtain evidence
authentication mechanisms and security to determine whether:
are not implemented to configurations are — Password configuration attributes for all relevant
restrict logical access to IT implemented to system userIDs, including privileged/generic
systems and data. restrict access to accounts, are sufficient and appropriate to achieve
authorised users only. the control objective of restricting access to
authorised users only, and preventing others from
(To obtain access to
gaining access.
programs and data, a
process of identification — There is a rationale for any deviation from expected
and authentication is configurations; consider the impact of each
implemented based deviation on the control’s effectiveness.
around a User ID and
Note: Where it is not possible to directly observe
safeguarded password
configuration settings, consider observing a typical
known only to the
user account changing a password using nonapproved
approved user account
attributes to determine whether the system prevents
owner.)
this.
Additional considerations:
Consideration of the effectiveness of authentication
controls (e.g., passwords) may include an assessment
of a number of factors such as password length,
password complexity, requirement to change
passwords at regular intervals, the inability to use
common words or previously used passwords, and the
use of userIDs shared by multiple users, etc.):
— Consider how any weak password setting(s)
identified might increase the overall risk of
inappropriate access, e.g., due to compromise
through brute force attack or password guessing
(note: these risks may be negated where user
accounts have been configured to become locked
after a specified number of failed attempts) with
reference to linked automated controls/IPE.
— Identify any related relevant GITCs, e.g., change
controls over changes to password configuration
settings.
General
3) Example
Considerations
controls testing considerations (Continued)
Example WCGW/RAFITs Illustrative Controls Testing Considerations

Logical access permissions New user access Evaluate:
are granted to users and is reviewed The completeness of the system-generated lists of
accounts (including shared and approved user accounts created during the period under review
or generic accounts) that by appropriate used for testing. (Note: We will be selecting and
are unauthorized or not individuals authorised testing items from the list that will provide evidence
commensurate with job by management. over the accuracy of the list, so we only need to test
responsibilities. completeness.)
Inquire, inspect, and/or observe to obtain evidence
to determine whether:
— Access rights were approved;
— Approval occurred before access rights were
granted; and
— The access granted matches the access requested/
approved.
(The above is based on testing a sample of new
accounts across the total population obtained from
systems supporting relevant automated controls that
follow the homogenous process.)
User access Evaluate:
modification is The completeness of the system-generated lists of
reviewed and accounts modified during the period under review for
approved by each in-scope system.
management. Inquire, inspect, and/or observe to obtain evidence
— Access rights/changes were approved;
— Changes were approved before being made;
approved; and
— Redundant access was removed.
(The above is based on testing a sample of modified
accounts across the total population obtained from
systems supporting relevant automated controls that
follow the homogenous process.)
The process for modifying user access rights is often
the same as the process for granting access. If this
is the case and we intend to test modifications as
one control alongside joiners, then the considerations
for doing so are clearly documented in the audit
file. Consider performing additional walkthroughs to
provide further justification for this approach. In this
scenario, we will have one population of all additions
and modifications and we test one sample (of the
appropriate size, as per guidance) from that listing.
have any such authority to obligate or bind any member firm. All rights reserved.NDP111567A-1F 10 of 12
General
3) Example
Considerations

Logical access permissions Redundant user Evaluate:
are not revoked in a timely access is removed on The completeness of the system-generated lists used
manner. a timely basis. for testing (users listings from in-scope systems;
complete list detailing all employees, contractors, third
parties, etc., who may no longer require access during
the period under review, including those occurring in the
period after our interim testing, e.g., a list from the HR
function of all terminated employees, contractors, etc.).
— For a sample of leavers, their access to all relevant
systems was revoked/disabled/suspended.
Note:
— Engagement teams may determine that it is
appropriate to use matching techniques to reconcile
the full listing of terminated individuals with current
system user lists.
— Where relevant to the planned audit reliance on
system-enforced segregation of duties/restricted
access controls, and/or where practical, teams
additionally design audit tests to confirm the
timeliness of the removal of redundant access; or
consider any compensating controls management
has in place to detect redundant access and/or
investigate any activity undertaken by the redundant
account(s).
Management may have detective controls in place
to proactively reconcile terminated employees/
contractors/etc. with user lists. Consider obtaining
evidence relating to the design/operation of such
controls in lieu of the ToE procedures listed.
Some users (particularly contractors) may leave and
rejoin an entity during the same year. This can result
in false positives, where “Leavers” retain access to
systems.
Consider checking the initial list of Leavers
“exceptions” against an accurate and complete list
of new hires before following up with management
and obtaining commensurate access approval
records. Validate any suspected false-positives with
management before concluding on whether further
evidence is required.
General
3) Example
Considerations

Logical access to users and see Privileged see Privileged Access IT Knowledge document
accounts (including shared Access IT Knowledge
or generic accounts) that document
can perform privileged
tasks and functions within
IT systems is unauthorized
or not commensurate with
job responsibilities.
Physical access to facilities IT systems and If physical access controls are relevant for the audit,
housing IT systems and/ data relevant to then considerations include:
or electronic media is financial reporting are
Evaluate:
unauthorized or not protected by physical
The completeness of the system-generated list of
commensurate with job security measures.
people with access during the period under review, to
responsibilities.
be used for testing.
— Physical access rights were approved;
— Approval occurred before access was granted;
approved; and
— The access granted remains appropriate for the
individual’s current role.
(The above is based on testing a sample of access
existing in the period to relevant sites, across the
total population of sites that follow the homogenous
process.)
— Are sensitive IT facilities owned/managed/operated
by third parties? Are there existing SOC reports that
the engagement team can obtain and review to
evaluate the physical access controls?
— Testing of operating effectiveness may include
attempting to access certain locations (e.g., does your
visitor pass to enter the building also allow you to
“swipe” and gain access to sensitive IT-related areas?).
— If access is controlled with shared PIN codes or
passwords rather than individually allocated swipe
cards, then how often are the codes changed and
how is that process managed? Are the PIN codes or
passwords unique to each person with access, to
enable access logs to be maintained?

IRM IT Knowledge Topic - Access To Programs Data

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IRM IT Knowledge Topic - Access To Programs Data

Uploaded by

Copyright:

Available Formats

IT Knowledge Topic

Access to Programs and Data

For Internal Use Only

1 KAM International 32.1211 (ISA 315 Appendix 1.9)

Example questions to build understanding of access and associated controls include:

Example WCGW/RAFITs Illustrative controls Testing considerations

Example WCGW/RAFITs Illustrative Controls Testing Considerations

Example WCGW/RAFITs Illustrative Controls Testing Considerations

Example WCGW/RAFITs Illustrative Controls Testing Considerations

You might also like