IT control owner

guide
IT general controls and IT application
controls, including common pitfalls
and leading practices

August 2025
Overview

This guide presumes the user understands the requirements of the Sarbanes-Oxley Act of 2002 for public companies
regarding internal controls over financial reporting (ICFR). The unique risks and controls over information technology
(IT) are important in the assessment of ICFR for both a company and its external auditors. This guide outlines the
considerations for different types of IT processes and controls and the documentation necessary to demonstrate the
design and operation of IT controls.

Contents and key points:

Contents Page

Overview 1

Section 1: IT risks and scoping for ICFR

Organizations should maintain an inventory of technology used, as well as a risk assessment of the
technology, to determine which of these are relevant to its ICFR. Organizations should develop IT
general controls (ITGCs) over the relevant technology to support:
2
▪ The continued operation of application controls and the automated portions of IT-dependent
manual (ITDM) controls (including the creation of complete and accurate reports) that address risks
of material misstatements in the business processes
▪ The integrity of data and information within the entity’s technology
Section 2: ITGCs that are review controls
When designing review controls, organizations should consider the risk the control is addressing to 3
determine the frequency, the control criteria and the assignment of appropriate reviewers.
Section 3: IT automated controls
IT application controls are automated procedures performed by the entity’s technology without input
from a person. These controls can relate to procedures used in the critical path of transactions, or 9
other financial data or to the execution of IT process procedures. Organizations need to consider risks
pertaining to IT application controls, such as the risk of changes to key configurations and data used in
the controls.
Section 4: Automated change management
Automated change management processes allow for faster development and implementation of 10
changes. However, they introduce their own collection of unique risks.
Section 5: Technology implementations and upgrades
Change inherently introduces risks, making it essential to have an effective system of ICFR to manage 11
risks during implementations.

Appendix 12

1 IT control owner guide

Section 1:
IT risks and scoping for ICFR

There are two overarching financial statement risks that arise from the entity’s use of IT:

Technology processes inaccurate/incomplete data Technology processes data inaccurately

For example: For example:
▪ As a result of insufficient controls over access to ▪ As a result of insufficient controls over changes to
modify data, prices were inappropriately or the revenue system, the invoice calculation was
erroneously changed. Therefore, the revenue inappropriately or erroneously changed to exclude
application may be performing the correct tax. Therefore, the entity’s application may be
calculation, but the prices it is using are incorrect. calculating sales prices by multiplying cost by
This means that the sales prices billed to customers quantity but not adding tax, so the amounts
and recorded as revenue are not correct. invoiced are not correct.

To identify technology relevant to management’s ICFR assertion:

5. Identify the relevant technology supporting

1. Identify significant financial critical transactions and controls
accounts

2. Process flow the business IT dependent manual

process Application controls
controls
(e.g., revenue — initiate, record, Manual
(e.g.,
process and report) controls
calculations,
interfaces) Information produced by
the entity
3. Identify technology used
within the business process

6. Identify IT risks and the required ITGCs

4. Determine the risks of (including at service organizations1):
material misstatement
Manage security settings, manage access,
manage change, IT operations, manage system
implementations

Technology (e.g., application, database, operating system, network, tool) is relevant to management’s ICFR assertion if it:
1. Supports the consistent operation of application controls in the significant classes of transactions, financial statement close
process or significant disclosure processes
2. Supports the production or creation of data and reports used in controls (e.g., report writers, data warehouses)
3. Supports the performance of ITGCs in the IT processes (e.g., identity and access management (IAM) tools, development
operations (DevOps) tools)
Refer to Appendix A: Considerations in the design of ITGCs for a diagram of the typical relationships between the components of an IT system.

1
When an entity uses a service organization’s IT services for technology used in the preparation of its financial statements, including transaction
processing, it is outsourcing the operation of part of its internal control environment to another organization. However, the outsourcing does not
relieve the entity of its responsibility for those controls. The design and operation of relevant controls at a service organization become part of the
entity’s system of ICFR. Outsourced activities that can be relevant to an entity’s ICFR may range from the full outsourcing of a business process,
such as payroll or invoice processing, to the use of technology provided by a service organization (e.g., the use of cloud service provider).

2 IT control owner guide

Section 2:
ITGCs that are review controls

Common types of review controls in ITGCs

▪ Point-in-time review controls (e.g., user access review)

▪ Activity review controls (e.g., change reviews, emergency access maintenance/firefighter usage)
The following includes considerations that apply to both point-in-time review controls as well as activity review
controls. Specific considerations for each control type are also included on subsequent pages.

Review execution and documentation

Completeness and accuracy of review content Reviewer assignments, understanding and
Review controls require evidence that demonstrates resources
when the reviewed content was compiled and that all Reviewers assigned to execute the review should be
intended records are included. Consider the following: familiar with the subject matter, informed of the review
▪ Does the report contain sufficiently detailed objectives and understand the implications of conclusions.
information to execute the review? Reports utilized Additionally, reviewers should have a role with the
in the control should be designed to capture all authority to request changes when required. Consider
relevant information required for a reviewer to make the following when assigning review responsibilities and
an informed decision. executing a review:
▪ Does retained documentation include system-derived ▪ How objective are the review criteria? Consider
dates showing when content was prepared? Include whether review instructions or criteria can be
dates in screenshots evidencing content creation. explicitly documented to avoid inconsistencies.
▪ Is the report created by running a program to select ▪ How intuitive is review content to understand?
a list of records from the technology? Programs Reviewers may require additional guidance or training
should be subject to change management controls to understand less intuitive or more technical subject
during setup or for any changes. Programs not matter.
subject to change management require validation by ▪ Is the volume of data reasonable for the number of
management each time they are utilized. assigned reviewers? Reviewers should reasonably be
▪ Does the system prompt a user for input during able to consider appropriateness of every record in
program execution that specifies selection criteria the population.
(e.g., parameters)? Retain evidence and document a ▪ Does the reviewer have the appropriate competence
review of the appropriateness of parameters entered and authority? Reviewers should not have conflicting
at run time. duties with performing the review, should have the
▪ Is any information removed or added by the appropriate understanding of the subject matter and
preparer after the content is generated? Document should be at the appropriate level to make decisions
any filtering or removal activities performed so the (e.g., reviewers should not review their own
procedure can be reperformed to reach the same technology changes or access permissions or
population. Retain evidence supporting the workflow configurations that route their own activities
completeness and accuracy of any supplemental for approval).
information being added. ▪ Are there aspects of the review that are automated?
Management should make sure the automations are
set up appropriately and changes are controlled
(e.g., routing to designated reviewers).

3 IT control owner guide

Conclusions and resulting actions

Evidence conclusions and resulting actions

Review outputs should include evidence that clearly demonstrates the procedures performed and outcomes reached
for the entire population. Consider:
▪ Was information divided among multiple reviewers?
Retain sufficient evidence of reviewer responses and verification that no information was lost in the separation of
the data into lists for reviewers.
▪ Were responses received in a timely manner?
Timeliness may vary in alignment with review frequency. Consider if alternative actions (e.g., removal of access)
can be taken in instances when responses are not provided.
▪ Did the reviewer consider each record assigned?
Stronger documentation includes record-by-record conclusions. Challenge whether summary-level conclusions
reasonably demonstrate the precision of the review and the reviewer’s judgments in the circumstances.
▪ Were corrective actions necessary?
Retain documentation that any actions required as a result of the review were completed timely. Follow-up actions
should follow established controls and documentation protocols where applicable.
▪ Was there risk exposure prior to correction?
When corrections are required in connection with the review (e.g., corrected changes, settings or access rights),
documentation should include an assessment of whether there was a risk to financial data prior to the correction. If
there was a risk, an evaluation of the nature and extent of procedures to address the effect of the exposure for the
period prior to the correction should be documented (e.g., “look-back” procedures).

4 IT control owner guide

User access review considerations

Point-in-time review controls are a type of detect and correct control in which system settings (including user
access rights) are re-evaluated periodically for ongoing appropriateness. The frequency at which a point-in-
time review control needs to be executed depends on several risk factors:

Lower frequency Risk factor Higher frequency

Yes Existence of other controls addressing the same risk No

Infrequent Historical frequency of access changes Frequent

Fewer Number of users who can make access changes More

Planned related projects, seasonality or downstream

No Yes
dependencies on control conclusions

Spotlight: User access reviews — common pitfalls

User access reviews are one of the most common point-in-time IT review controls and can prove especially challenging
given the volume of data and reviewers, as well as difficulty in conveying the meaning of user permissions in terms
intuitive to reviewers. The following are common pitfalls when designing and executing user access reviews:
▪ Documentation not retained to evidence extraction of user listings or subsequent modifications
▪ Save screenshots of the extraction of user listings that show record counts, parameters, and any applicable
ad hoc query or programming used to extract the data.
▪ If raw user listings are modified, document the steps performed so that modifications can be reperformed.
▪ Reliance on ad hoc queries, tools or programs not subject to in-scope change management controls
▪ All programs not subject to change management should be revalidated each time they are used. Reliance on
automation could include programs that automatically extract user and permissions listings, look up reporting
hierarchy and/or assign reviewers for each user, route tasks to reviewers to complete review activities, track
responses, or execute required changes.
▪ Reviewers who do not understand what permissions a user has or the implications to financial reporting
▪ Review content should have guidance regarding what the underlying permissions within roles permit a user to
do and any specific conflicts or sensitive functions to look for. This guidance should be revalidated and
updated on a periodic basis to maintain accuracy.
▪ Reviewers should be provided instructions on how to seek additional guidance if needed.
▪ Reviewers who are reviewing their own access

5 IT control owner guide

User access review documentation examples

Example — User access review identification of inappropriate users

Below is an example of documented results from a user access review (not inclusive of procedures performed over
the completeness and accuracy of the report used).
In this example, the control owner reviews all assigned users and any that require modification are documented in
the reviewer comments column.

User ID User name Role Permissions Reviewer comments

JSmith John Smith AP clerk AP processing Approve, no changes needed

JDoe Jane Doe Read-only Read Remove access, terminated

3/4/20XX

ABrown Andrew Brown Administrator Develop changes Remove access, terminated

System admin 3/8/20XX

BJohnson Bethany AR aging Aging bucket administration Remove access to aging bucket
Johnson AR processing administration

Example — Assessment of users requiring modification

Below is an example of an access assessment for users flagged to be modified or removed as a part of a user access
review (not inclusive of procedures performed over the completeness and accuracy of the report used).
In this example, the control owner evaluates whether the user had read only access or if their removal or last login
date was before their termination date (and, thus, no further risk needed to be evaluated). If the account was
accessed after termination, a further evaluation for the users is performed.

User ID User Access Is access Termination AD removal System last Was the access
name requiring read-only? date date login date/ used after it
removal or role last use became
modification date inappropriate?

JDoe Jane Read-only Yes

Doe

ABrown Andrew Administrator No 3/8/20XX 3/6/20XX

Brown
BJohnson Bethany AR aging No N/A — modified access, user Used until Yes
Johnson still employed removal

Example — Risk assessment of users requiring modification

Below is an example of a risk assessment for flagged users who leveraged their access up until the removal date.
The control owner evaluates whether the access was used inappropriately from the time the access was deemed no
longer appropriate until the date it was removed.

User ID User Access Risk assessment

name requiring
removal or
modification

BJohnson Bethany AR aging The access allowed the user to modify aging buckets. Logs of the user’s activity
Johnson were reviewed, and the user did not modify the aging buckets during the time the
access was held.

6 IT control owner guide

Activity review controls (e.g., change reviews,
emergency access maintenance/firefighter usage)

ITGCs designed to review activities performed within the IT environment may be necessary depending on the
sufficiency of other ITGCs in the environment, the risks relevant to the related IT and business processes supported,
and the extent of privileged access granted to the IT environment.

Understanding the environment to assess the need for activity review controls
The following are key areas of the IT environment to assess and determine whether activity review controls
may be required:
▪ Emergency access
▪ If short-term privileged access is provided to make changes directly in the production environment (e.g., direct
data changes, program changes, configuration changes), and this creates a segregation of duties conflict, an
activity review control should be performed to address the risk that unauthorized changes are made (see next
page for further emergency access considerations).
▪ Direct data changes
▪ If the IT environment permits direct access to perform data changes (other than database administrators) and
the type of data permitted to be changed could cause a material misstatement of the financial statements, an
activity review control should be performed to address the risk that unauthorized changes are made.
▪ Program and configuration changes
▪ If the IT environment does not systematically enforce segregation of duties in the change management process
(e.g., developer is systematically prevented from promoting their own change without independent approval),
or if the typical change process can be bypassed, a periodic review should be performed to address the risk that
unauthorized changes are made.
▪ Changes to key security settings
▪ The IT environment may necessitate a periodic review of changes to key security settings over time
(e.g., authentication settings).

7 IT control owner guide

Emergency access considerations

Entities typically require changes to the production environment (e.g., program code changes, data changes,
configuration changes) to go through a controlled process that includes segregation of access between developers and
implementers. However, under certain circumstances and for limited periods of time, it may be necessary for changes
to be made directly in the production environment or to production data by individuals who typically would not possess
elevated privileges. Such access is typically called “emergency access.” Granting emergency access increases the risk of
unintentional errors.

Emergency access control considerations

Approving requests for emergency access Reviewing activities performed with emergency
(prevent control) access (detect and correct control)
The design of emergency access controls should Emergency access activity reviews determine what the
consider the process used to authorize the use of individual did with the assigned emergency access and
emergency accounts and access and should consider whether the activity was appropriate. The design of
the following: these controls should consider the following:
▪ What are the circumstances for which granting ▪ Ascertain whether logging of emergency access
such access is appropriate? activity is enabled for the relevant technology. Can
▪ What is the process to obtain the access? the IDs used for emergency access turn the logging
function off? If so, the control is not designed
▪ Are the access rights granted the same or do
effectively unless there are additional mitigating
they vary depending on the issue causing the
controls.
request?
▪ Determine the reviewer(s) — the individual or group
▪ Whose approval is required?
of individuals — who have the appropriate
▪ Does the emergency access require a formal qualifications to perform a precise review.
“trouble ticket” to be approved before granting
▪ Reviewers should understand the purpose for
access?
which the emergency access was granted as well
▪ What information is used to determine whether as understand the nature of the actions taken by
to provide approval? The request should include the individual with emergency access. This
a reason as to why emergency access is needed allows the reviewer to assess whether the
and an expectation of what is being modified. actions taken were appropriate.
▪ If access rights are elevated via a “self- ▪ Processes should be in place to address the risk
elevation” process, is there a process to of an individual reviewing their own activities.
periodically review and validate that the
▪ Determine an appropriate frequency of the review
additional privileges granted via self-elevation
considering factors such as the frequency and
remain appropriate?
volume of emergency activity and the potential
▪ Is the individual assigned a different ID with the effect of inappropriate changes not identified and
rights or are the rights added to the individual’s corrected timely.
existing ID?
▪ Establish the actions required by a reviewer if they
▪ How is the duration of access determined and how identify an item they do not understand or do not
is the duration enforced? think is appropriate, as well as the corrective
actions taken when potential inappropriate
activities have occurred.
▪ Determine what evidence needs to be retained to
support adherence to the design attributes of the
review.

Entities may provide temporary elevated (but non-emergency) access to perform a specific task that the user only
performs occasionally. Controls should be in place for capturing and assessing the temporary access based on the
relative risk related to the access granted (e.g., elevated access to programs or data require high oversight, while
elevated access that allows changing a job schedule might require less analysis and support).

8 IT control owner guide

Section 3:
IT automated controls (application controls)

Application controls are automated procedures performed by the entity’s technology without input from a
person (e.g., edit checks, calculations, interfaces, approval routing). They can relate to procedures used in
transaction processing or in the execution of IT process procedures.
Application controls help verify that transactions are authorized, recorded, and processed completely and
accurately. Application controls can also help verify that IT processes are performed appropriately.

How automated controls are evaluated

To properly understand the design of the automated control, at least one of the following is performed by
the individual evaluating the control, depending on the circumstances of the control and the scenarios
created by the automation:

01 Inspecting system documentation 02 Inspecting the program code 03 Inspecting configuration

related to the automated portion that operates the control screens when the control is
of the control configurable

Controls can operate in different ways, or have alternatives, depending on the circumstances. There are various
ways such controls can be designed, typically programmed or configured. Entities should understand how
the alternatives have been enabled to determine whether multiple processing alternatives exist.

See below for characteristics of programmed and configured controls.

Programmed controls Configured controls

▪ Alternatives are hard-coded into system ▪ Alternatives are created using screens that are
functionality. included as part of the IT system.
▪ Such alternatives are typically seen in in-house ▪ These are typically seen in vendor-supplied
programmed technology or when the entity can technology. The vendor provides one or more
supplement configurations with custom-coded screens for user entities to complete that let the
actions (e.g., SAP). entities alter how a control operates.

Automation will consistently operate as programmed. However, if the data used by the program to
determine the action to perform is inaccurate, the control will not produce the intended result. For the
automated portion of a control to operate effectively, entities should have controls in place to make sure
the code and/or configurations used in the control remain as intended and the data used in the control is
input, and remains, complete and accurate.

9 IT control owner guide

Section 4:
Automated change management (e.g., DevOps tools)

Companies are increasingly using automation and collaboration platforms to facilitate the development, testing,
approval and migration of changes to IT system programs. Along with the implementation of automation, many
companies are reducing the need to maintain distinct IT groups between the application developers and system
administrators responsible for migrating changes to production. Common continuous integration/continuous
deployment (CI/CD) tools provide opportunities to enhance control activities, but CI/CD tools bring their own collection
of unique risks and do not negate the necessity to maintain production environment controls.

When utilizing automated change management processes:

1
Consider whether automated control points in CI/CD platforms can be bypassed or temporarily disabled
Code repositories are often configured to require reviews of all proposed code changes. Consider how
controls would prevent or detect a developer approving their own code, disabling the review requirement,
or making unnecessary or unauthorized changes in addition to corrections if proposals are not approved.

2
Demonstrate that changes are in line with business needs
Methodologies like Agile software development life cycle (SDLC) de-emphasize documentation retention.
Automation in IT can reduce opportunities for business involvement and validation. Documentation
retained by the entity should be able to clearly demonstrate that changes were necessary and authorized,
and that business owners affirmed that each change met the requested requirements.

3
Maintain production environment controls
Controls should be in place to prevent or detect and correct changes to the production environment
that bypass or override the established process (e.g., making changes directly to the application
rather than through the tool).

As with any tool utilized to facilitate activities relevant to

ICFR, automated change management tools should be
subjected to a risk assessment and have ITGCs in place.
These ITGCs may be to maintain the appropriateness of
access to the tools, make sure changes to the tools
themselves are tested and approved, and validate that any
scheduled processes are executed successfully.

“
Technology innovation creates both opportunities and risks. It can enable the
development of new business markets and models, generate efficiencies through
automation, and enable entities to do things that were previously hard to imagine. It
may increase complexity, which makes identifying and managing risks more difficult.
- COSO 2013 Framework, Chapter 4

10 IT control owner guide

Section 5:
Technology implementations and upgrades

A pre-implementation assessment involves:

Technology implementations • Considering the effects of the implementation on the
introduce risk. Management is business and internal control (entity level, business
and IT process)
responsible for monitoring the
effect of the new system and related • Providing transparency into current and future state
complex business processes and identifying
risks, including any effect on ICFR. opportunities for process automation and/or
improvement
Entities implement new systems for various reasons, • Understanding the effects on the flow of data (input,
such as to leverage new technologies, increase modification, transfer and output) between IT systems
automation or to adopt new accounting standards. • Understanding the data conversion and validation
System implementations are not limited to systems that procedures for completeness and accuracy
process financial transactions. They may also include
tools like IAM and DevOps tools, as well as robotic • Identifying opportunities to optimize IT system
processing applications (RPAs), artificial intelligence (AI) integration, reporting and continuous control
and generative AI (GenAI) used in business and IT monitoring
processes. Implementations are not only entirely new • Identifying and evaluating new risks and controls prior
software deployments but also include new modules, to go-live
upgrades and significant changes to existing systems.

Identifying potential control issues early allows the

entity to address them before go-live to reduce the risk
of a significant deficiency or material weakness and
costly remediation in production.

Because a system implementation can create new IT and Governance

business process risks, it is essential for an entity to and SDLC
inform its auditors early in the process. Establishing
Business application
An entity should consider engaging a service provider, process security design
controls and
such as its independent auditor, to perform a pre- established segregation of
implementation assessment to evaluate the ICFR duties
considerations. Successful
technology
implementation

“
IT general Data
controls conversion and
established migration
validation
The technology general controls included in
a development methodology will vary Interface
depending on the risks of the technology validation

initiative. A large or complex development

initiative will generally have greater risks
than a small or simple initiative. The extent
and rigor of the controls over the initiative Refer to Appendix B: Typical controls related to technology
should be sized accordingly. implementations for risks to consider, example controls
and documentation that should be retained to demonstrate
- COSO 2013 Framework, Chapter 7 the entity’s ICFR during a system implementation.

11 IT control owner guide

Appendix A: Considerations in
the design of ITGCs
An IT environment consists of computers running operating system software. Computers run the programs that
comprise the IT application and the databases that hold the data collected and used by IT applications. Network
software connects computers and facilitates the use of the IT application, as well as the data collected and processed.

In the diagram below, the yellow arrows show access paths for users and administrators. The gray arrows show the
flow of transaction information.

Network software

Operating system

System
administrator Application
IT application User
screens
(programs)
and output

Network software
Operating system
Network software

Operating system

Database

Database
administrator
Data Other technology
warehouse and sources of
data
Network
administrator Operating system

Network software

When the data is directly or indirectly used in the business processes or financial statement close process, the
database is a relevant component of the IT environment. Data warehouses may be used to consolidate information
from various sources. If data warehouses are the source of data and information used in the operation of controls,
the data warehouse is relevant.
The operating system is likely relevant when the IT application security is integrated with the operating system
(i.e., logging into the operating system also acts as logging in to an IT application).
When the network is the authentication point for the relevant technology (i.e., single sign-on), it is considered relevant.
In addition to the “typical” IT applications (e.g., enterprise resource planning applications), IT systems may include
interface programs, stored procedures (i.e., program code stored in the database), programs kicked off by job
schedulers and report programs created using report writing software.
Tools used in IT processes may also be a relevant component of the IT environment when they are used to perform
ITGC activities (e.g., IAM tools that perform automated approval routing and provisioning).

12 IT control owner guide

Appendix A: Considerations in
the design of ITGCs
Control objective Data used in the control
▪ The control should be designed with specific actions ▪ Control attributes should be defined for the control
that are directly responsive to the identified risk. performer to verify the completeness and accuracy of
Nature and type of control the data used in the control.
▪ ITGCs are either prevent or detect and correct, and Documentation of the design of the control
may be manual, partially automated or fully ▪ Documentation of the design of the ITGC clearly
automated. define all attributes of the control. The documentation
▪ If manual: Identify performers who are objective, of design can be presented in several ways, including
do not have conflicting duties (e.g., not reviewing in policy manuals, process models, flowcharts,
changes they made), have sufficient authority and internal memoranda or a combination thereof. Clear
are competent to perform the control. documentation of the design provides evidence to
support the achievement of COSO Principle 11: The
▪ If automated: Identify the data necessary for the
organization selects and develops general control
control to operate effectively (e.g., configurations,
activities over technology to support the achievement
lookup tables, master data) and confirm there is a
of objectives.
process for maintaining the data.
Frequency
▪ Define the frequency in which the control is
performed in relation to the control objective,
considering the existence of other ITGCs in the IT
process.
“
In considering the nature and extent of
documentation needed, management
should also remember that the
Competence and authority of control performers
▪ Authority of a control performer relates to whether documentation … will likely be used by
the individual has the authorization and rank to make the external auditor as part of his or her
decisions, enforce the controls and take actions to audit evidence … Management may also
correct issues identified. Competence of a control document significant judgments, how
performer relates to whether the individual has the
such decisions were considered, and the
skills and sufficient knowledge of the relevant subject
matter to effectively perform the control (e.g., an final decisions reached.
individual must understand the programming - COSO 2013 Framework
language to peer review changes to programs).

Leading practices and ways to maximize efficiencies for IT

processes and ITGCs that support the relevant IT systems
Common IT control processes are beneficial for maintaining compliance, managing risks and enabling operational
efficiency. IT systems follow a common IT process when the control activities performed for each technology are
performed in substantially the same way under the same governance (i.e., subject to the same policies).
Performing a control rationalization exercise can help companies focus their efforts on areas of risk. Control
rationalizations involve taking inventory of all existing IT controls, identifying duplicate or overlapping controls, and
removing or consolidating controls that are not necessary to address IT risks. Companies can prioritize controls that
address key risks and focus fewer resources on non-key areas.
Having an IT compliance team to oversee the IT control environment helps make sure IT controls are properly
designed and remain effective over time. IT compliance teams help companies stay updated on evolving regulations
and makes sure IT controls align with current standards.

13 IT control owner guide

Appendix A: Considerations in
the design of ITGCs
IT processes often both prevent ITGCs as well as detect and correct ITGCs.

Prevent ITGCs operate in an IT process to prevent Benefits

issues with the systems that support the business
processes. The COSO 2013 Framework states that “a ▪ Prevents errors that are difficult to detect from
preventive control is designed to avoid an unintended occurring when processing an occurrence-based
event or result at the time of initial occurrence.” control
Insufficient prevent controls increase the risk of issues in ▪ Prevents errors from occurring early in the
supporting technologies and increases the need for process of occurrence-based controls
timely and sensitive detect and correct controls to
address such issues. ▪ May create efficiencies for control owners if
automation is involved in a portion of the control
(e.g., automated controls and ITDM controls)
Examples of prevent ITGCs:
▪ Change testing and approval Disadvantages
▪ New user approval ▪ Direct evidence to support the effective operation
▪ Access deprovisioning (e.g., terminations) of the control: may not be retained because
▪ Approval of requests for emergency (e.g., firefighter) prevent controls operate on a “real-time” basis
access ▪ May have gaps in the level of precision of the
▪ Approval of changes to job schedules control or achievement of certain control attributes
▪ Approval of changes to security settings and
passwords

Detect and correct ITGCs operate in an IT process to Benefits

detect IT issues with the technologies that support the
business process. Detect and correct controls monitor ▪ Able to detect errors, inappropriate changes or
the functioning of their processes and the operation of inappropriate access that occurred/exist and
relevant prevent controls. As stated in the COSO 2013 subsequently correct and perform an evaluation
Framework, “A detective control is designed to discover an over the inappropriate item to make sure it did not
unintended event or result after the initial processing has affect the environment
occurred but before the ultimate objective has concluded.” ▪ May be more efficient to demonstrate that ICFR
Insufficient detect and correct controls that are intended obligations have been met than prevent controls
to monitor the functioning of IT processes may not because detect and correct controls are performed
identify issues in the operation of prevent controls. less frequently and often are applied to groups of
items with evidence that is readily available
Examples of detect and correct ITGCs:
▪ Change monitoring Disadvantages
▪ Elevated access activity review ▪ May not be sufficiently timely to prevent errors in
▪ User access review the IT processes they support
▪ Role to permissions review ▪ Requires retention of evidence of follow-up
▪ Scheduled job monitoring
▪ Requires additional controls or control attributes to
address the data and reports used in the controls

14 IT control owner guide

Appendix B: Typical controls related
to technology implementations
While risks vary depending on the specific implementation, below are risks to consider, example controls and
documentation that should be retained to demonstrate the entity’s ICFR.
Documentation to retain as
Risks to consider Example controls
evidence of ICFR
• Lack of executive sponsorship and The implementation is managed • Project plan that includes (as
business involvement throughout using a comprehensive project plan. applicable):
the implementation may result in • A timeline
failure to meet the business and • The people and skills needed
strategic objectives of the
• A security design plan
implementation.
• A data migration strategy
• Lack of review and formal
approval of key project activities • A testing strategy
may lead to functionality not • How issues will be captured
working properly and/or business and their resolution
requirements not being met. monitored
• Insufficient documentation to • A training plan
support the performance of key • How post-implementation
project activities may affect issues will be addressed
accountability, making it difficult to • The criteria for the go/no-go
investigate discrepancies or issues. decision, and who or what
• Lack of validation go-live criteria group will make the final
may result in transaction decision
processing issues, thus impairing • Sign-offs by individuals
financial processing. responsible for the various
• End users and IT support parts of the plan
personnel do not effectively use • Approvals and documented basis
or support the new IT system. for go-live decision
• Insufficient testing of the new • Key functions are tested in the • Testing plans, scripts and results
technology may result in the new technology. of testing
system not operating as • Reports are tested and • Evidence that issues identified
expected, leading to data compared, when appropriate, to were addressed and retested
integrity and processing issues. data and reports from the • Documented plan to address any
• Data transfer processes do not existing system. tests that were not satisfactorily
function correctly due to • Interfaces are tested, including completed at go-live, as well as
inadequate testing of interfaces. the job scheduling needed to evaluation of the effect of the
operate them. gaps on the operation of the
application and/or IT
environment
• Final approval of test results

Configurations and security settings • Key configurations and security • Documentation of the
that are not set properly may settings, including passwords, comparison of the password
undermine other controls. are set to appropriate values. characteristics, key security
settings and configurations to
• Default passwords to system IDs
policies or business requirements
delivered with software have
documents
been changed or the related
accounts have been disabled. • Evidence that default passwords
were changed or the accounts
were disabled

15 IT control owner guide

Appendix B: Typical controls related
to technology implementations
Documentation to retain as
Risks to consider Example controls
evidence of ICFR
Extraction, transformation and load Transformations to data performed • Testing plans, scripts and results
processes do not function correctly to accommodate the new data of testing of data transformation
due to an inadequate understanding structures are tested for accuracy • Verifications of the completeness
of the data in the source. and to determine that no data is lost and accuracy of live data post-
or added in the process. migration (e.g., reconciliations)
• Key stakeholder reviews and final
approval of data conversion
User access is inconsistent with, or • Roles created for the new IT • Documentation of the
in excess of, what is needed for the application include appropriate assignment of access rights to
user’s job responsibilities. access rights based on job roles per the security design plan
responsibilities and considering • Documentation of the
segregation of duties. assignment of access rights, or
• Access rights, or roles, to the roles, to specific individuals or
new technology and related tools tools per the security design plan
are assigned based on job • Documentation that the
responsibilities and considering privileged access was established
appropriate segregation of per the security design plan
duties. • Final approval of access security
• Privileged access to the new IT design implementation
application, database and related
tools are assigned based on job
responsibilities and considering
segregation of duties.

Elevated or privileged access during • Requests for elevated or privileged • Evidence that access added
the hypercare period may lead to access rights are approved. during the hypercare period was
inappropriate or unauthorized authorized by an appropriate
• The activities performed using
changes to the system’s production person prior to the access being
access rights granted during the
environment and data. provided
hypercare period are logged and
reviewed. • Reviews of logs of elevated or
privileged access activity during
the hypercare period

• Unauthorized access to • Controls to manage changes, • Documentation of the

technology or data may result in access and IT operations for the identification of control owners
improper or erroneous new technology are updated, or and operators for the ITGCs and
transactions or data loss. new controls are established and business controls in the new
relevant policies are updated. application
• Inappropriate or unauthorized
changes made to the production • Business process controls are • Updates to related IT and
environment may lead to updated, or new controls are business process policies
inaccurate processing. established and relevant policies
• Management has not are updated.
appropriately updated business
to adequately identify and
mitigate business risks.
• Documentation may not exist to
demonstrate the design and
operation of key controls.

16 IT control owner guide

Appendix B: Typical controls related
to technology implementations
Key reminders for technology implementations

Establish controls for the hypercare period

Entities should confirm privileged access has been appropriately restricted prior to go-live. If privileged access is needed to support
hypercare activities after go-live, entities should confirm logging is enabled, activity is monitored and privileged access is revoked
once hypercare ends. Entities should consider reviewing access for default accounts, vendor accounts, and contractors and
consultants that are part of the implementation team.
Verify the completeness and accuracy of data and reports
The use of incomplete or inaccurate data files and reports during implementations could result in material errors in the financial
statements (e.g., if “bad” data is used in a process and not detected by the control, the resulting conclusion may be erroneous and
the cause of a potential material misstatement). Examples of data and reports used in the technology implementation are reports of
users and their roles assigned, reports of access rights within roles, logs of activity performed during hypercare period, and queries
of data before and after conversion/migration. Examples of evidence that should be retained by entities to demonstrate the control
activities performed to verify the completeness and accuracy of data and reports may include:
▪ Tick mark on a screenshot of the parameters used to generate a report
▪ Screenshot of query executed and records returned, and a note evidencing agreement of the records in the output
▪ Checklist that includes an instruction to review the criteria used in generating the report
Retain documentation of criteria used and conclusions reached
A sign-off “blessing”an entire file is generally inadequate documentation of a control owner’s review and approval. An entity should
document the criteria used, judgments made and conclusions reached.

As stated in the COSO framework, “Documentation also provides evidence of the conduct of internal control,
enables proper monitoring, and supports reporting on internal control effectiveness, particularly when
evaluated by other parties interacting with the entity, such as regulators, auditors, or customers.
Documentation also provides a means to retain organizational knowledge and mitigate the risk of having the
knowledge within the minds of a limited number of employees.”

If the system implementation involves outsourcing a business or IT processes to service organizations:

▪ Include in the contract with the service organization the right to audit or to influence the content of System and Organization
Controls (SOC) 1® reports. Also include the service organization’s responsibility for obtaining and providing to your entity and
your external auditor the SOC 1® reports of subservice organizations. Include provisions for the procedures to address control
issues and who will pay for supplemental procedures that may need to be performed at the service organization.
▪ Obtain the prior period SOC 1® report upon go-live and plan to obtain and evaluate future reports on a timely basis as well as the
SOC 1® reports of the subservice organizations. Identify any inadequately described controls or tests of those controls,
deviations and the service auditor procedures to audit remediation or other procedures performed by your entity to address the
deviations. Work with your external auditor, the service organization and the service auditor to set appropriate current-period
expectations for the information to be provided about control deviations and additional procedures to be performed by the
service organization and the service auditor if needed.
▪ Verify that your entity’s activities related to the service organization have effective controls, particularly those mapped to
complementary user entity controls (CUECs) in the SOC 1® report (an example of such activities is maintaining appropriate
access of the entity’s users to the service organization’s technology).
▪ Make a list of data and reports obtained from the service organization. Determine whether the prior period SOC 1® report
includes service auditor testing that address completeness and accuracy of these reports. If not, request the service organization
to perform procedures and have the service auditor include them in its testing or identify or implement additional entity controls
to address the completeness and accuracy of the reports.
▪ Consider the period covered by the SOC 1® report compared to your entity’s reporting period, and determine any additional
procedures needed. A typical procedure for period differences up to three months is to obtain a bridge letter from service
organization management and, when applicable, from subservice organization management.

17 IT control owner guide

EY | Building a better working world

EY is building a better working world by creating

new value for clients, people, society and the
planet, while building trust in capital markets.

Enabled by data, AI and advanced technology,

EY teams help clients shape the future with
confidence and develop answers for the most
pressing issues of today and tomorrow.

EY teams work across a full spectrum of

services in assurance, consulting, tax, strategy
and transactions. Fueled by sector insights,
a globally connected, multi-disciplinary network
and diverse ecosystem partners, EY teams can
provide services in more than 150 countries
and territories.

All in to shape the future with confidence.

EY refers to the global organization, and may refer to one or more, of

the member firms of Ernst & Young Global Limited, each of which is a
separate legal entity. Ernst & Young Global Limited, a UK company
limited by guarantee, does not provide services to clients. Information
about how EY collects and uses personal data and a description of the
rights individuals have under data protection legislation are available
via [Link]/privacy. EY member firms do not practice law where
prohibited by local laws. For more information about our organization,
please visit [Link].

Ernst & Young LLP is a client-serving member firm of

Ernst & Young Global Limited operating in the US.

© 2025 Ernst & Young LLP.

All Rights Reserved.

SCORE no. 27800-251US

2504-11618-CS
ED None

This material has been prepared for general informational purposes only and is
not intended to be relied upon as accounting, tax, legal or other professional
advice. Please refer to your advisors for specific advice.

[Link]

18 IT control owner guide