IRM IT Knowledge Topic - Access To Programs Data
IRM IT Knowledge Topic - Access To Programs Data
August 2020
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.
© 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 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.
© 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 3 of 12
have any such authority to obligate or bind any member firm. All rights reserved. NDP111567A-1F
2) General Considerations
© 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 4 of 12
have any such authority to obligate or bind any member firm. All rights reserved. NDP111567A-1F
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.
© 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 5 of 12
have any such authority to obligate or bind any member firm. All rights reserved. NDP111567A-1F
2) General Considerations (Continued)
— 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).
© 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 6 of 12
have any such authority to obligate or bind any member firm. All rights reservedNDP111567A-1F
2) General Considerations (Continued)
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.
© 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 7 of 12
have any such authority to obligate or bind any member firm. All rights reserved. NDP111567A-1F
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.
© 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 8 of 12
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.
© 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 9 of 12
General
3) Example
Considerations
controls testing considerations (Continued)
© 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 10 of 12
General
3) Example
Considerations
controls testing considerations (Continued)
© 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 11 of 12
General
3) Example
Considerations
controls testing considerations (Continued)
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.
Inquire, inspect, and/or observe to obtain evidence
to determine whether:
— Physical access rights were approved;
— Approval occurred before access was granted;
— The access granted matches the access requested/
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.)
Additional considerations:
— 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?
© 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 12 of 12