Chapter 9

Application Systems:
Risks and Controls

LEARNING OBJECTIVES
1. Discuss common risks associated with application systems.
2. Discuss common risks associated with end-user development application systems.
3. Discuss risks to systems exchanging business information and describe common standards
for their audit assessments.
4. Describe Web applications, including best secure coding practices and common risks.
5. Explain application controls and how they are used to safeguard the input, processing, and
output of information.
6. Discuss the IT auditor’s involvement in an examination of application systems.

Application systems provide automated functions to effectively support the business process.
Applications also introduce risks to organizations in the form of increased costs, loss of data
integrity, weaknesses in confidentiality, lack of availability, and poor performance, among others.
Further, once implemented, applications may be periodically modified to either correct errors or
just implement upgrades and enhancements (maintenance). Such maintenance will need to be
consistent with business or IT strategies; otherwise, it may cause performance issues and inefficient
use of resources.
This chapter discusses common risks to various types of application systems and provide
examples of such potential risks. It also touches upon relevant application controls that can be
implemented by organizations in order to mitigate the risks discussed. Lastly, involvement of the
IT auditor when examining applications is discussed.

Application System Risks

Application systems include concentrated data in a format that can be easily accessed. Such con-
centration of data increases the risks by placing greater reliance on a single piece of data or on a

241
242 ◾ Information Technology Control and Audit

single computer file or on a database table. If the data entered are erroneous, the impact of error
would be significant as applications rely on such piece of data. Similarly, the higher the number
of applications that use the concentrated data, the greater the impact when that data become
unavailable due to hardware or software problems. A good example to further the discussion of
application systems is an Enterprise Resource Planning (ERP) system.
ERP systems provide standard business functionality in an integrated IT environment system
(e.g., procurement, inventory, accounting, and human resources). ERP systems allow multiple
functions to access a common database—reducing storage costs and increasing consistency and
accuracy of data from a single source. In fact, having a single database improves the quality and
timeliness of financial information. However, processing errors can quickly impact multiple func-
tions as the information is shared but sourced from the same database. According to the June 2016
edition of Apps Run the World, a technology market-research company devoted to the applica-
tions space, the worldwide market of ERP applications will reach $84.1 billion by 2020 versus
$82.1 billion in 2015. Some of the primary ERP suppliers today include SAP, FIS Global, Oracle,
Fiserv, Intuit, Inc., Cerner Corporation, Microsoft, Ericsson, Infor, and McKesson.
Despite the many advantages of ERP systems, they are not without risks. ERP systems are not
much ­different than purchased or packaged application systems, and may therefore require exten-
sive ­modifications to new or existing business processes. ERP modifications (i.e., software releases)
require considerable programming to retrofit all of the organization-specific code. Because pack-
aged systems are generic by nature, organizations may need to modify their business operations to
match the ­vendor’s method of processing, for instance. Changes in business operations may not fit
well into the organization’s culture or other processes, and may also be costly due to training. In
addition, some integration may be required for functionality that is not part of the ERP, but pro-
vides integral information to the ERP functions. Moreover, as ERP systems are offered by a single
vendor, risks associated with having a single supplier apply (e.g., depending on a single supplier for
maintenance and support, specific hardware or software requirements, etc.).
Another risk with ERP systems is the specialized nature of the resources required to customize
and implement. In most organizations, these specialized resources must be procured from high-
priced consulting firms. To decrease the dependency on high-priced consultants, organizations
need to invest in educating their own staff to take over responsibility for maintaining the ERP
system. As these resources are in high-demand, the challenge is to keep these resources once they
are fully trained.
ERP systems can be quite complex with the underlying database, application modules, and
interfaces with third-party and legacy applications. The complexity of ERP systems may actually
cost more than the multiple application environments it was intended to replace.
Application systems like ERP systems are frequently exposed to many types of risks. Additional
­common risks associated with application systems include:

◾◾ Weak information security

◾◾ Unauthorized access to programs or data
◾◾ Unauthorized remote access
◾◾ Inaccurate information
◾◾ Erroneous or falsified data input
◾◾ Incomplete, duplicate, and untimely processing
◾◾ Communications system failure
◾◾ Inaccurate or incomplete output
◾◾ Insufficient documentation
 Application Systems: Risks and Controls ◾ 243

Weak Information Security

Information security should be a concern of IT, users, and management. However, it has not
been a consistent top priority for many organizations. Past surveys and reports have shown that
organizations are more concerned with budgets and staff shortages than information security.
Respondents to such surveys still continue to identify obstacles to reducing information security
risks, such as lack of human resources, funds, management awareness, and tools and solutions.
Meanwhile, advanced technology and increased end-user access to critical and sensitive informa-
tion continue to proliferate information security risks.

Unauthorized Access to Programs or Data

Application systems should be built with various levels of authorization for transaction submis-
sion and approval. Once an application goes into production, programmers should no longer
have access to programs and data. If programmers are provided access, such access should be a
­“read-only” access for the purpose of understanding issues reported by the user.
Similarly, users’ access should be limited to a “need-to-know” basis. This means that the infor-
mation made available to a user, whether it is “read-only” or with open access for modification,
should be in accordance with the user’s job functions and responsibilities. For example, a payroll
clerk needs access to the payroll system, but not to the billing system.

Unauthorized Remote Access

More and more users are demanding remote access to organizations’ computer resources. Remote
access allows users within an organization to access its network and computer resources from
locations outside the organization’s premises. Remote access, if unauthorized, does represent a
risk because client devices (used for the remote access) tend to have weaker protection than stan-
dard or organization-based client devices. These devices may not necessarily be managed by the
­organization and, hence, not be defined under the firewalls and antivirus rules, for example.
Remote access communications may be carried over untrusted networks, subjecting the
­communication to unauthorized monitoring, loss, or manipulation. In other words, if users within
(or outside) the organization’s network were to gain unauthorized access:

◾◾ sensitive and confidential information may be at risk and negatively impacted; and
◾◾ computer viruses can be introduced affecting company files, performance of computer
systems, or just slowing down the network and its resources.

To combat unauthorized remote access, at a minimum, user IDs and passwords should use
­encryption when transmitted over public lines. Furthermore, confidential data that are trans-
mitted over public lines should also be encrypted. The encryption security solution depends on
the sensitivity of the data being transmitted. Lastly, user access reviews should be periodically
performed by IS security personnel, and approved by management, to ensure the remote access
granted is accurate and consistent with job tasks and responsibilities.

Inaccurate Information
Accurate information must be ensured whether the end user is accessing data from an applica-
tion, a departmental database, or information on the cloud. End users may be asked to generate
244 ◾ Information Technology Control and Audit

reports for analysis and reporting without fully understanding the downloaded information.
Departmental data repositories (e.g., databases, data clouds, etc.) may have redundant infor-
mation with different timeframes. The result is waste of time in reconciling these repositories to
determine which data are accurate. Another major area of concern is that management may fail
to use information properly due to failures in identifying significant information; interpreting
meaning and value of the acquired information; and/or communicating critical information to the
responsible manager or chief decision maker on a timely basis.

Erroneous or Falsified Data Input

Erroneous data input is when inaccurate data are inputted in the application system unintention-
ally due to human error. Preventative measures include built-in application controls, such as check
digits and double entry. Falsified data input, on the other hand, is when inaccurate data are input-
ted to the application system intentionally to defraud the organization or its stakeholders. In this
case, preventative measures may include safeguarding access to programs and data through user
authentication and authorization mechanisms.

Incomplete, Duplicate, and Untimely Processing

Incomplete processing occurs when transactions or files are not processed due to errors. It may
occur in batch processing when a file is not present, or during online processing when a request
or trigger fails to kick off a transaction. Duplicate transaction processing includes executing trans-
actions more than once. It can occur during batch processing if files are executed multiple times,
or during online processing when a transaction trigger kicks off a transaction more than once.
Duplicate processing may also occur when a job abnormally terminates (abends), but some of the
records that have been processed are not reset. Untimely processing includes delayed processing
due to production problems or missing a time cutoff. For example, financial processes must occur
at month-end closing to ensure that the detailed transactions processed in one application system
match the transaction posting to the general ledger. In addition, when an online system post
transactions to a batch system, there is usually a cutoff time where processing ends on day one and
begins for day two.

Communications System Failure

Today, application systems within IT environments are responsible for many critical services,
including communication services (e.g., e-mail, intranets, Internet, instant messaging, etc.).
Because of this increasing reliance on IT communication services, the potential failure of these
services presents an increasing source of risk to organizations. Information that is routed from
one location to another over communication lines is vulnerable to accidental failures, intentional
interception, and/or modification by unauthorized parties.

Inaccurate or Incomplete Output

If not adequately safeguarded, output reports may contain errors after processing (compromising
their integrity) and also be distributed improperly. Output controls should be in place, for exam-
ple, to verify that the data are accurate and complete (i.e., properly recorded), and that report dis-
tribution and retention procedures are effective. Examples of output controls involve performing
 Application Systems: Risks and Controls ◾ 245

reviews, reconciliations, and verifying for data transmission. Additionally, access to reports should
be based on a “need-to-know” basis in order to maintain confidentiality.

Insufficient Documentation
End users typically focus on solving a business need and may not recognize the importance of
documentation. Any application system that is used by multiple users or has long-term benefits
must be documented, particularly if the original developer or programmer is no longer avail-
able. Documentation provides programmers with enough information to understand how the
application works, and assists in solving problems to ensure effective and efficient analysis of pro-
gram changes and troubleshooting. Documentation should be updated as the application system
is modified.
Documentation further ensures maintainability of the system and its components and
­minimizes the likelihood of errors. Documentation should be based on a defined standard and
consist of descriptions of procedures, instructions to personnel, flowcharts, data flow diagrams,
display or report layouts, and other materials that describe the application system.

End-User Development Application Risks

End-user development (EUD) (also known as end-user computing) generally involves the use of
department-developed applications, such as spreadsheets and databases, which are frequently used
as tools in performing daily work. These spreadsheets and databases are essentially an extension of
the IT environment and output generated from them may be used in making business decisions
impacting the company. As a result, the use of EUD has extended the scope of audits outside the
central IS environment. The level of risk and the required controls to be implemented depend on
the criticality of the EUD application. For example, an EUD application that consolidates data
from several departments that will later be an input into the financial reporting system is a prime
target for an audit.
EUD application risks are not easily identified because of lack of awareness and the absence
of adequate resources. For instance, personal computers or PCs, notebooks, laptops, and mobile
devices hosting relevant department-developed spreadsheets and/or databases may be perceived as
personal productivity tools, and thus be largely ignored by the organization. Similarly, many orga-
nizations have limited or no formal procedures related to EUD. The control or review of reports
produced by EUD applications may be limited or nonexistent. The associated risk is that manage-
ment may be relying on end-user-developed reports and information to the same degree as those
developed under traditional centralized IS environment. Management should consider the levels
of risk associated with EUD applications and establish appropriate levels of controls. Common
risks associated with EUD application systems include:

◾◾ Higher organizational costs

◾◾ Incompatible systems
◾◾ Redundant systems
◾◾ Ineffective implementations
◾◾ Absence of segregation of duties
◾◾ Incomplete system analysis
◾◾ Unauthorized access to data or programs
246 ◾ Information Technology Control and Audit

◾◾ Copyright violations
◾◾ Lack of back-up and recovery options
◾◾ Destruction of information by computer viruses

Higher Organizational Costs

EUD may at first appear to be relatively inexpensive compared to traditional IT development.
However, a number of hidden costs are associated with EUD that organizations should consider.
In addition to operation costs, costs may increase due to lack of training and technical support. Lack
of end-user training and their inexperience may also result in the purchase of inappropriate hard-
ware and the implementation of software solutions that are incompatible with the ­organization’s
systems architecture. End users may also increase organizational costs by creating inefficient or
redundant applications.

Incompatible Systems
End-user-designed application systems that are developed in isolation may not be compatible with
existing or future organizational IT architectures. Traditional IT systems development verifies
compatibility with existing hardware and related software applications. The absence of hardware
and software standards can result in the inability to share data with other applications in the
organization.

Redundant Systems
In addition to developing incompatible systems, end users may be developing redundant applica-
tions or databases because of the lack of communication between departments. Because of this
lack of communication, end-user departments may create a new database or application that
another department may have already created. A more efficient implementation process has end-
user departments coordinating their systems development projects with IT and meeting with
other end-user departments to discuss their proposed projects.

Ineffective Implementations
End users typically use fourth-generation programming languages, such as database or Internet
Web development tools to develop applications. In these cases, the end user is usually self-taught.
However, they lack formal training in structured applications development, do not realize the
importance of documentation, and tend to omit necessary control measures that are required for
effective implementations. In addition, there is no segregation of duties. Because of insufficient
analysis, documentation, and testing, end-user developed systems may not meet management’s
expectations.

Absence of Segregation of Duties

Traditional application systems development is separated by function, and tested and completed by
trained experts in each area. In many EUD projects, one individual is responsible for all phases, such
as analyzing, designing, constructing, testing, and implementing the development life cycle. There
are inherent risks, such as overlooking errors, when having the same person creating and testing
 Application Systems: Risks and Controls ◾ 247

a program. It is more likely that an independent review will catch errors made by the ­end-user
developer, and such a review helps to ensure the integrity of the newly designed application system.

Incomplete System Analysis

End-user departments eliminate many of the steps established by central IT departments. For
example, the analysis phase of development may be incomplete and not all facets of a problem
appropriately identified. In addition, with incomplete specifications, the completed system may
not meet objectives nor solve the business problem. End users must define their objectives for a
particular application before they decide to purchase existing software, have IT develop the appli-
cation, or use their limited expertise to develop the application. Incomplete specifications will
likely prompt system deficiencies.

Unauthorized Access to Data or Programs

Access controls provide the first line of defense against unauthorized users who gain entrance to
an application system’s programs and data. The use of access controls, such as user IDs and pass-
words, are typically weak in user-developed systems. In some cases, user IDs and passwords may
not even be required, or they would be very simple and easily guessed. This oversight can subject
applications to accidental or deliberate changes or deletions that threaten the reliability of any
information generated. Systems require additional protection to prevent any unexpected changes.
To prevent any accidental changes, the user should be limited to execute only.

Copyright Violations
Organizations are responsible for controlling the computing environment to prevent software
piracy and copyright violations. However, some organizations may not specifically address soft-
ware piracy in training, in policy and procedures, or in the application of general internal controls.
Since software programs can easily be copied or installed on multiple computers, many organiza-
tions are in violation of copyright laws and are not even aware of the potential risks.
Organizations face a number of additional risks when they tolerate software piracy. Copied
software may be unreliable and carry viruses. Litigation involving copyright violations is highly
publicized, and the organization is at risk of losing potential goodwill. Furthermore, tolerating
software piracy encourages deterioration in business ethics that can seep into other areas of the
organization.
Organizations should inform end users of the copyright laws and the potential consequences
that result from violations of those laws. To prevent installation of unauthorized software, orga-
nizations may restrict user’s ability to install software by disabling administrative access to their
PCs. Additionally, when users are given access to a personal or desktop computer, they should
sign an acknowledgment that lists the installed software, the individual’s responsibilities, and any
disciplinary action for violations. Written procedures should clearly define user’s responsibility for
maintaining a software inventory, auditing compliance, and removing unlicensed software.

Lack of Back-Up and Recovery Options

Organizations that fail to maintain a copy of their data are really asking for trouble. Nowadays, it
is extremely easy to lose data and all but impossible to rebuild that data if backups had not been
248 ◾ Information Technology Control and Audit

performed. EUD applications are often stored in one’s PC and not properly backed-up. In case of
a disaster or virus attack, these applications (and their data) may not be recoverable because of the
lack of backups. It may therefore not be possible for the end user to recreate the application and its
data within a reasonable period of time.
The absence of a back-up and recovery strategy results in computer data loss. Unbacked up
data is constantly subject to risks, such as accidental deletion of files, viruses and damaging mal-
ware, hard drive failures, power failures or crashes, theft of computer, water damage, fire, and
many others.

Destruction of Information by Computer Viruses

Most end users are knowledgeable about computer virus attacks, but the effect of a virus remains
only a threat until they actually experience a loss. Based on the McAfee Labs Threats Report for
December 2016, the number of attacks approximates 650 million. For mobile devices, the number
for 2016 is also significant, almost approaching the 13.5 million mark. Further, in its 2017 Threats
Predictions report, McAfee Labs predicts the following, among others:

◾◾ Attackers will continue to look for opportunities to break traditional (non-mobile) computer
systems, and exploit vulnerabilities. Attackers are well able to exploit systems whose firm-
ware (permanent software programmed into a read-only memory) controls input and output
operations, as well as other firmware, such as solid-state drives, network cards, and Wi-Fi
devices. These types of exploits are probable to show in common malware attacks.
◾◾ Ransomware on mobile devices will continue its growth though attackers will likely com-
bine these mobile device locks with other forms of attack, such as credential theft, allowing
them to access such things as banks accounts and credit cards.

A virus is the common term used to describe self-reproducing programs, worms, moles, holes,
Trojan horses, and time bombs. In today’s environment, the threat is high because of the unlim-
ited number of sources from which a virus can be introduced. For example, viruses can be copied
from a disk or downloaded from an infected Web page. They spread to other files, those files in
turn spread to other files, and so on. The boot sector of a disk is one of the most susceptible to
virus infection because it is accessed every time that the computer is turned on, providing easy
replication of the virus. When a virus is activated, it copies code to the hard drive, and it can
spread to additional media by executing a common application such as a word processor or mail
program. The media that contain the virus will continue to infect other computers and spread the
virus throughout an organization.
Viruses can also spread among computers connected within a network (local, Internet, etc.).
They can spread when infected files or programs are downloaded from a public computer through
attachments to e-mails, hidden code within hyperlinks, and so on. Viruses can cause a variety of
problems such as:

◾◾ Destroying or altering data

◾◾ Destroying hardware
◾◾ Displaying unwanted messages
◾◾ Causing keyboards to lock and become inactive
◾◾ Slowing down a network by performing many tasks that are really just a continuous loop
with no end or resolution
 Application Systems: Risks and Controls ◾ 249

◾◾ Producing spamming
◾◾ Launching denial-of-service attacks

The risk to organizations is the time involved in removing the virus, rebuilding the affected
­systems, and reconstructing damaged data. Organizations should also be concerned about send-
ing virus-infected programs to other organizations. Viruses cause significant financial damage,
and recipients may file lawsuits against the instituting organization.

Risks to Systems Exchanging Electronic Business Information

Electronic Data Interchange (EDI) refers to the electronic exchange of business documents
between business (or trading) partners using a standardized format. EDI allows organizations to
electronically send and receive information in a standard format so that computers are able to read
and understand the documents being interchanged. A standard format describes the type, as well
as the design, style, or presentation (e.g., integer, decimal, mmddyy, etc.) of the information being
traded. Common examples of business information exchanged through EDI includes invoices and
purchase orders. Exhibit 9.1 describes risks associated with EDI or systems exchanging electronic
business information.

Exhibit 9.1 Risks to EDI or Systems Exchanging Electronic Business Information

Risk Description

Loss of business Inadvertent or deliberate corruption of EDI-related applications

continuity/going- could affect every EDI transaction entered into by an organization,
concern problem impacting customer satisfaction, supplier relations, and possibly
business continuity eventually.

Interdependence There is increased dependence on the systems of trading partners,

which is beyond the control of the organization.

Loss of confidentiality Sensitive information may be accidentally or deliberately divulged

of sensitive on the network or in the mailbox storage system to unauthorized
information parties, including competitors.

Increased exposure to Access to computer systems may provide an increased opportunity

fraud to change the computer records of both a single organization and
that of its trading partners by staff of the trading parties or by
third-party network staff. This could include the introduction of
unauthorized transactions by user organization or third-party
personnel.

Manipulation of A situation where amounts charged by or paid to suppliers are not

payment reviewed before transmission. Therefore, there is a risk that
payments could be made for goods not received, payment
amounts could be excessive, or duplicate payment could occur.

Loss of transactions Transactions could be lost as a result of processing disruptions at

third-party network sites or en route to the recipient organization,
which could cause losses and inaccurate financial reporting.
(Continued)
250 ◾ Information Technology Control and Audit

Exhibit 9.1 (Continued) Risks to EDI or Systems Exchanging Electronic Business Information
Risk Description
Errors in information Errors in the processing and communications systems, such as
and communication incorrect message repair, can result in the transmission of
systems incorrect trading information or inaccurate reporting to
management.
Loss of audit trail EDI eliminates the need for hard copy. There will be less paper for
the auditors to check. The EDI user may not provide adequate or
appropriate audit evidence, either on hard copy or on electronic
media. The third-party vendor may not hold audit trails for a
significant length of time, or audit trails could be lost when
messages are passed across multiple networks.
Concentration of There will be increased reliance on computer controls where they
control replace manual controls, and they may not be sufficiently timely.
The use of EDI with its greater reliance on computer systems
concentrates control in the hands of fewer staff, increases reliance
on key people, and increases risk.
Application failure Application or EDI component failures could have a significant
negative impact on partner organizations within the respective
business cycles, especially for Just-In-Time inventory management,
production, and payment systems. In addition, there is a
possibility of error propagation across other systems due to
integration with other business applications.
Potential legal liability A situation where liability is not clearly defined in trading partner
agreements, legal liability may arise due to errors outside the
control of an organization or by its own employees. There is still
considerable uncertainty about the legal status of EDI documents
or the inability to enforce contracts in unforeseen circumstances.
Overcharging by Third-party suppliers may accidentally or deliberately overcharge
third-party service an organization using their services.
providers
Manipulation of The information available to the proprietors of third-party
organization networks may enable them or competitors to take unfair
advantage of an organization.
Not achieving Happens where the anticipated cost savings from the investment in
anticipated cost EDI are not realized for some reason by an organization.
savings
Source: Adapted from Senft, S., Gallegos, F., and Davis, A. 2012. Information Technology Control
and Audit. Boca Raton: CRC Press/Taylor & Francis.

Implications arising from these risks include:

◾◾ Potential LOSS of transaction audit trail, thereby making it difficult or impossible to recon-
cile, reconstruct, and review records. This could possibly be a breach of legislation and result
in prosecution and fines.
 Application Systems: Risks and Controls ◾ 251

◾◾ Increased exposure to ransom, blackmail, or fraud through potential disruption of services

or increased opportunities to alter computer records in an organization and its trading
­partners’ IS.
◾◾ Disruption of cash flows when payment transactions are generated in error or diverted or
manipulated.
◾◾ Loss of profitability occurring through increased interest charges or orders going to a
­competitor due to lack of receipt of EDI messages.
◾◾ Damage to reputation through loss of major customers, especially if EDI problems are
widely publicized.

Standards for EDI Audit Assessments

Auditors, management, developers, and security consultants must need to be aware of the busi-
ness risks associated with EDI systems. Some well-known standards that provide a basis for EDI
audit assessments include: the Accredited Standards Committee (ASC) X12 group of standards sup-
ported by North America’s American National Standards Institute (ANSI) and the Electronic
Data Interchange for Administration, Commerce and Transport (EDIFACT) international standards
supported by the United Nations’ Economic Commission for Europe.

◾◾ ASC X12 standards facilitate the electronic interchange of business transactions, such as
placing and processing orders, shipping, receiving, invoicing, and payment. Specifically,
ASC X12 standards identify the data being used in the transaction, the order in which such
data must appear, whether data are mandatory or optional, when data can be repeated, and
how loops, if applicable, are structured and used.
◾◾ EDIFACT standards provide a set of common international standards for the electronic
transmission of commercial data. EDIFACT international standards deal with the elec-
tronic interchange of structured data, such as the trade in of goods and services between
independent computerized information systems.

Other common major standards for EDI assessments include:

◾◾ Tradacoms standard, which is predominant in the United Kingdom retail sector. The
­standard is currently referred to as GS1 UK.
◾◾ The Organization for Data Exchange by Tele Transmission (ODETTE) standards, which
represent the interests of the automotive industry in Europe. ODETTE creates stan-
dards, develops best practices, and provides services which support logistics management,
e-­business communications, and engineering data exchange throughout the European
­automotive industry.
◾◾ The Verband der Automobilindustrie (VDA) standards and best practices are also applicable
for the European automotive industry. VDA standards particularly focus on serving the
needs of German automotive companies.
◾◾ Health Level-7 (HL7) international standards relate to the electronic exchange of clinical
and administrative data among healthcare providers. HL7 standards have been adopted by
other standard issuing bodies like ANSI and International Organization for Standardization.
◾◾ GS1 EDI global standards guide the electronic communication and automation of business
transactions that typically takes place across the entire supply chain. These standards apply
to retailers, manufacturers, material suppliers, and logistic service providers, for example.
252 ◾ Information Technology Control and Audit

Web Application Risks

PC Magazine defines a Web application as “an application in which all or some parts of the soft-
ware are downloaded from the Web each time it is run.”* Use of Web applications has become a
key strategy for direction for many companies. Some companies simply use Web applications for
marketing purposes, but most use them to replace traditional client-server applications. Other
characteristics of Web applications include the use of a Web browser on the client side that is
usually platform independent, and requires less computing power. Some other benefits of Web
applications include reduced time to market, increased user satisfaction, and reduced expenses
related to maintenance and supports.
From a development point of view, a Web application should be designed to perform the spe-
cific tasks agreed upon and documented as part of the functional requirements. When developing
Web applications, teams must understand that client-side controls like input validation, hidden
fields, and interface controls, for example, are not fully dependable for security purposes. Attackers
may easily bypass these client-side controls and gain access to analyze or manipulate application
traffic, submit requests, etc. Well-known practices referred to when developing Web application
systems or applications include the Top 10 Secure Coding Practices, issued in March 2011 by
the United States Computer Emergency Readiness Team (US-CERT). Other common practices
include the secure coding principles described in the Open Web Application Security Project
(OWASP) Secure Coding Guidelines. While the following OWASP secure coding principles spe-
cifically reference Web applications, these principles may also apply to non-Web applications.

◾◾ Input validation
◾◾ Output encoding
◾◾ Authentication and password management
◾◾ Session management
◾◾ Access control
◾◾ Cryptographic practices
◾◾ Error handling and logging
◾◾ Data protection
◾◾ Communication security
◾◾ System configuration
◾◾ Database security
◾◾ File management
◾◾ Memory management
◾◾ General coding practices

OWASP offers a practical checklist† that focuses on implementing secure coding practices and
principles. The checklist is designed to serve as a secure coding kick-start tool to help development
teams understand (and comply with) secure coding practices.
Risks attributable to Web applications, as stated on the 2017 OWASP Top 10 Most Critical
Web Application Security Risks,‡ include:

* www.pcmag.com/encyclopedia/term/54272/web-application.
† www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf.
‡ www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#tab=OWASP_Top_10_for_2017_Release_
Candidate.
 Application Systems: Risks and Controls ◾ 253

◾◾ Injection
◾◾ Broken authentication and session management
◾◾ Cross-site scripting
◾◾ Broken access control
◾◾ Security misconfiguration
◾◾ Sensitive data exposure
◾◾ Insufficient attack protection
◾◾ Cross-site request forgery
◾◾ Using components with known vulnerabilities
◾◾ Under protected application program interfaces

The OWASP secure coding principles and practices checklist is one effective way to minimize
risks and ensure that the organization develops successful Web applications. However, auditors,
management, developers, and security consultants must consider the levels of risks associated with
all types of applications in order to design and implement appropriate application controls.

Application Controls
There are two broad groupings of computer controls that assist in mitigating the application
risks discussed above, and are essential to ensure the continued proper operation of application
systems. They are: General Computer Controls and Application Controls. General computer
controls (“general controls” or “ITGC”) include examining policies and procedures that relate
to many applications and supports the effective functioning of application controls. General
controls cover the IT infrastructure and support services, including all systems and applica-
tions. General controls commonly include controls over (1) information systems operations;
(2) information security; and (3) change control management (i.e., system software acquisition,
change and maintenance, program change, and application system acquisition, development, and
maintenance).
Application controls examine procedures specific and unique to the application. Application
controls are also referred as “automated controls.” They are concerned with the accuracy, com-
pleteness, validity, and authorization of the data captured, entered, processed, stored, transmit-
ted, and reported. Examples of application controls include validating data input, checking the
mathematical accuracy of records, and performing numerical sequence checks, among others.
Application controls are likely to be effective when general controls are effective. Exhibit 1.3 from
Chapter 1 illustrates general and application controls, and how they should be in place in order
to mitigate risks and safeguard applications. Notice in the exhibit that the application system is
constantly surrounded by risks. Risks are represented in the exhibit by explosion symbols. These
risks could be in the form of unauthorized access, loss or theft or equipment and information,
system shutdown, etc. The general controls, shown in the hexagon symbols, also surround the
application and provide a “protective shield” against the risks. Lastly, there are the application or
automated controls which reside inside the application and provide first-hand protection over the
input, processing, and output of the information.
Application controls implemented at organizations may include, among others, system and/or
application configuration controls; security-related controls enforcing user access, roles, and seg-
regation of duties; and automated notification controls to alert users that a transaction or process
is awaiting their action. Application controls also check for mathematical calculations, balancing
254 ◾ Information Technology Control and Audit

totals between jobs, reasonableness against expected volumes or values, reconciliations between
systems, and the controlled distribution of output to ensure accuracy and completeness of transac-
tions. Application controls can be described as techniques used to control the input, processing,
and output of information in an application. They are broken down into three main categories:
input, processing, and output controls.

Input Controls
Input controls are meant to minimize risks associated with data input into application systems.
The “user interface” is the means by which the user interacts with the system. In most cases, this
is the computer screen, mouse, and keyboard. An effective interface for the users will help reduce
desk costs and improve accuracy and efficiency. Also, a user interface should provide a means for
the user to obtain context-sensitive help.
Defining input requirements ensures that the method of capturing the data is appropriate
for the type of data being input and how it is subsequently used. Performance problems and
accuracy issues can be introduced with inappropriate methods for capturing data. Input require-
ments should specify all valid sources for data as well as the method for validating the data. Input
controls prevent invalid transactions from being entered and prevent invalid data within valid
transactions. They specifically ensure the authenticity, accuracy, and completeness of data entered
into an application.

Authenticity
NIST defines authenticity as “the property of being genuine and being able to be verified and
trusted.”* Authenticity ensures that only authorized users have access to entering transactions.
During an application system development process, authorized users should be defined along with
their security levels for data access. This information can be used when designing input screens to
limit screens or fields to particular user groups. Controls can also be designed to enforce separa-
tion of duties. For example, a user may be able to enter a transaction, but a supervisor may need to
approve the transaction before it is submitted for processing.
Authentication must also be considered when automated applications interface with other
applications. Authentication, according to NIST, verifies “the identity of a user, process, or device
often as a prerequisite to allowing access to resources in an information system.”* Often, sched-
uled batch jobs operate under the authority with specified access privileges to the database. Risks
associated with these access accounts as well as the access privileges need to be reviewed. Generic
accounts should not be used. The batch jobs should be given minimal privileges and system-level
accounts should not be used.

Accuracy
Accuracy is ensured through edit checks that validate data entered before accepting the transac-
tion for processing. Accuracy ensures that the information entered into an application is consistent
and complies with policies and procedures. This is accomplished by designing input screens with
edits and validations that check the data being entered against predefined rules or values.

* http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.
 Application Systems: Risks and Controls ◾ 255

The accuracy of transactions processed can be ensured by having all inputted transactions go
through data validation checks, whether coming from an online screen, an interface from another
application, or generated by the system. Programs that automatically generate transactions (i.e.,
time triggered programs) should have built-in edits that validate transaction accuracy similar to
transactions entered by a user. It is also important to track transaction volume and frequency
against expected trends to ensure that transactions are triggered properly. Missing and duplicate
checks should also be programmed in case an error occurs in the triggering logic.
Edit and validation routines are generally unique to the application system being used,
although some general-purpose routines may be incorporated. Exhibit 9.2 lists common edit and
validation routine checks or controls when inputting data. Edit and validation routines are placed
in a system to aid in ensuring the completeness and accuracy of data. Therefore, overriding edit
routines should not be taken lightly. In most systems, the user is not provided this capability.
Overriding edit routines is allowed only to privileged user department managers or supervisors,
and from a master terminal. Overrides should be automatically logged by the application so that
these actions can be analyzed for appropriateness and correctness.

Completeness
Completeness confirms that all data necessary to meet current and future business needs are
­actually ready and available. Having complete data to work with assists management when making
business decisions impacting the organization. Complete data, in the form of financial statements,
vendor lists, customer receivable reports, loan reports, etc., reflect an accurate status of the orga-
nization and how it is coping with competitors and industry trends and patterns. Completeness
is ensured, for Instance, through error-handling procedures that provide logging, reporting, and
correction of errors.

Exhibit 9.2 Edit and Validation Controls When Inputting Data

Control Description

Field check Confirms that characters in a field are of a proper type.

Sign check Validates that the data in a field has the appropriate positive or negative
sign.

Limit or range Verifies that the numerical amount entered is within acceptable minimum
check and maximum values.

Size check Checks that the size of the data entered fits into the specific field.

Completeness Corroborates that all required and necessary data is entered.

check

Validity check Compares data from transaction file to that of master file to verify for
existence.

Reasonableness Checks for correctness of logical relationship between two data items.
check

Check digit Recalculates a check digit to verify data entry error has not been made.
verification
256 ◾ Information Technology Control and Audit

Processing Controls
Processing controls prevent, detect, and/or correct errors while data processing (batch or online)
takes place. These controls help ensure that the data are accurately and completely processed
through the application (e.g., no data are added, lost, or altered during processing, etc.).
Jobs scheduled within an application should be reviewed to ensure that changes being made are
appropriate and do not introduce risks. As an example, in an ERP application system, a Structure
Query Language program can be written to modify data directly against the database, avoiding
the controls within the application and operating against the database with system administrator
privileges. However, from the screen, this program can look like a report if the underlying code is
not evaluated.

Accuracy and Completeness

To ensure data accuracy and completeness (A&C), programs should be built with logic to prevent,
detect, and/or correct errors. Error handling procedures should include:

◾◾ Logging error activity

◾◾ Approval of error correction and resubmission
◾◾ Defined responsibility for suspense files
◾◾ Reports of unresolved errors
◾◾ Aging and prioritization of unresolved errors

A&C can also be achieved by balancing batch transactions going in with transactions going out of
a predecessor. Balancing steps should occur in major job processing points. The following control
points are examples of major job processing points:

◾◾ Input points. Programs that accept transactions from input processing (e.g., user interface, etc.)
◾◾ Major processing modules. Programs that modify the data (e.g., perform calculations, etc.)
◾◾ Branching points. Programs that split or merge data (e.g., a programs merging data from two
or more different input sources into one file; file is then used as data feed for the financial
reporting system, etc.)
◾◾ Output points. Result of data processing (e.g., financial or operational reports, printed
checks, output data file, etc.)

Designed properly, balancing totals for transaction count and amount can detect missing or
­duplicate transactions (see Exhibit 9.3, part A). Additionally, balancing and reconciliation should
occur between applications that share common data. This can be achieved by creating a reconcili-
ation report that lists data from all application systems involved, and reports on any differences
for a user group to review and follow upon any exceptions. Exhibit 9.3, part B is used to illus-
trate a sample reconciliation between the Billing, Payment, and Accounts Receivable systems.
Notice how the Accounts Receivable system confirms (or reconciles) all 17 records involved and,
most importantly, the balance of $400 pending after billings were sent out and collections (or
­payments) were received.
Balancing totals should also include a transaction (quantity) count, totals for all amount
fields for each type of transaction, and cross-foot totals for detail fields to total fields. Notice
in Exhibit 9.4 how the total number of quantity is verified, and how the total amount per part
 Application Systems: Risks and Controls ◾ 257

(a)

Billing system— Receivables system—

invoices out: invoices in:

Count = 10 Count = 10
Total = $1,250 Total = $1,250

(b)

Billing system— Payment system—

invoices out: payments in:

Record count = 10 Record count = 7

Record sum = $1,250 Record sum = $850

Accounts receivable
system
(reconciliation of
invoices and
payments):

Record count = 17
Record sum = $400

Exhibit 9.3 Batch balancing totals (A) and cross-application reconciliation (B).

results from cross-footing Quantity and Unit Price. In files where there are no meaningful totals,
hash totals can be created that add all of the figures in a column to verify that the same total is
accepted by the next process. For example, totaling part numbers does not provide any mean-
ing. However, this total can be used to verify that all the correct part numbers were received.
Transaction flows should be balanced on a daily basis and cumulatively to monthly jobs before the
register closes. Balancing totals should also consider both error transactions leaving and entering
the processing flow. In Exhibit 9.5, for example, 10 total transactions (with amount of $1,250)
minus 2 transactions written to an error file (with amount of $250) were processed in the Accounts
Receivable System. The reconciled/balanced total count and amount in the Accounts Receivable
System is now eight and $1,000, respectively.
Other common examples of processing controls include:

◾◾ Data matching. Matches two or more items before executing a particular command or action
(e.g., matching invoice to purchase order and receiving report before making the payment,
etc.).
◾◾ File labels. Ensure that the correct and most updated file is being used.
◾◾ Cross-footing. Compares two alternative ways of calculating the same total in order to verify
for accuracy (e.g., adding by rows and by columns in a spreadsheet, etc.).
258 ◾ Information Technology Control and Audit

Exhibit 9.4 Sample Balancing Totals

Order Quantity Part Number Unit Price Total

Part A 100 1288543 $1.20 $120.00

Part B 80 0982374 $0.60 $48.00

Part C 200 5436682 $0.45 $90.00

Total 380 $258.00

Source: Adapted from Senft, S., Gallegos, F., and Davis, A. 2012. Information Technology Control
and Audit. Boca Raton: CRC Press/Taylor & Francis.

Billing system— Error file—

invoices out: invoices:
Count = 10 Count = 2
Total = $1,250 Total = $250

Accounts receivable
system
(invoices in—errors):

Count = 8
Total = $1,000

Exhibit 9.5 Balancing totals with error transactions.

◾◾ Zero-balance tests. Check that a particular account (e.g., payroll clearing account, etc.)
­maintains a balance of zero. This test assists organizations in eliminating excess balances in
separate accounts and maintaining greater control over disbursements.
◾◾ Write-protection mechanisms. Safeguard against overwriting or erasing data.
◾◾ Concurrent update controls. Prevent errors of two or more users updating the same record at
the same time.

Output Controls
Output controls are designed to detect and correct errors after processing is completed, ensur-
ing the integrity of the output produced. In particular, output controls include: (1) procedures
to ­verify if the data are accurate and complete (i.e., properly recorded) and (2) procedures for
adequate report distribution and retention. If outputs are produced centrally, then conventional
controls, such as having a security officer and distributing logs may be appropriate. If output
 Application Systems: Risks and Controls ◾ 259

is distributed over a data communication network, control emphasis shifts to access controls
for individual workstations. To maintain confidentiality, access to reports should be based on a
“need-to-know” basis.

Accuracy and Completeness

Output should be verified against an independent source to verify its accuracy and complete-
ness. Three common types of output controls related to accuracy and completeness are user
reviews, reconciliations, and data transmission controls. User reviews ensure outputs (reports)
generated are secure, confidential, and private through performing balancing and completeness
checks; comparisons of key data fields; checks for missing information; and document recreation.
Reconciliations include procedures to reconcile control reports. For example, transaction totals
posted to the general ledger should be reconciled against the detailed balance due in the accounts
receivable subsidiary ledger. Another example includes external data reconciliations, such as
reconciliation of bank/cash accounts. As mentioned earlier, data that are common to two or more
applications should be reconciled to verify consistency. Data transmission controls are imple-
mented to protect the physical transfer of data over a point-to-point or point-to-multipoint com-
munication channel. An example here would be the implementation of encryption techniques
over transmitted data.

Distribution and Retention

Distribution of output should be clearly defined, and physical and logical access should be lim-
ited to authorized personnel. The need for output should be regularly reviewed as reports may be
requested at the time an application is developed, but may no longer be useful. Also, the same
information may be used for more than one system with different views, organization, and use.
For example, the marketing department may use sales information to pay commission and moni-
tor sales quotas, whereas the accounting department uses the same information to prepare finan-
cial statements and reports. These two systems should be reconciled to make sure that the amount
reported for paying sales staff is the same as the amount reported on the financial statements and
reports.
Because storage space (online or physical) is expensive, retention periods and storage require-
ments should be defined for programs, data, and reports. Critical information should be stored
securely (i.e., encrypted) and its destruction should be permanent and conducted in such a way as
to prevent unauthorized viewing. Organizations should consider any law and regulations that may
govern the duration of retention periods.

IT Auditor’s Involvement
IT auditors can assist organizations by reviewing their application systems to ensure they comply
with the organization’s strategy and standards, as well as provide automated functions to effec-
tively support the business process. Applications will need to be risk assessed to determine the level
of audit involvement. The type of assessment will also vary depending on the risks of the particular
application. Applications introduce risks to organizations in the form of increased costs, loss of
data integrity, weaknesses in confidentiality, lack of availability, poor performance, and others.
These risks should be addressed with adequate selection and implementation of controls.
260 ◾ Information Technology Control and Audit

Auditing application systems requires specific knowledge about application risks and controls.
Understanding those allows the IT auditor to identify key areas that would benefit from indepen-
dent verification. Moreover, understanding application controls allows the IT auditor to evaluate
and recommend the ones that will ensure complete and accurate transaction processing.
As stated before, IT auditors can be involved as control consultants or independent review-
ers. The level of involvement is determined by completing a risk assessment. Results from the risk
assessment also prompt the amount of time necessary to allocate to the particular application,
required resources, etc. Preparation of an audit plan then follows. The plan describes the audit
objectives and procedures to be performed to ensure applications are adequately implemented,
and safeguard the information. IT auditors finally communicate findings identified throughout
the audit plus recommendations to management.

Risk Assessment
IT auditors may not have enough time to assess every particular application system in the organi-
zation. Involvement within a particular application will depend on the assessment of the applica-
tion risks. Application risks relate to application complexity and magnitude, inexperienced staff,
lack of end-user involvement, and lack of management commitment. The level of risk may be a
function of the need for timely information, complexity of the application, degree of reliance for
important decisions, length of time the application will be used, and the number of people who
will use it. The risk assessment defines which aspects of a particular application will be covered by
the audit. The scope of the audit may vary depending on the risks identified.

Audit Plan
The audit plan details the steps and procedures to fulfill the audit objectives. As in any audit, an
audit of application systems begins with a preliminary analysis of the control environment by
reviewing existing standards, policies, and procedures. During the audit, these standards, policies,
and procedures should be assessed for completeness and operational efficiency. The preliminary
analysis should identify the organization’s strategy and the responsibilities for managing and con-
trolling applications. Documenting an understanding of the application system is also a must at
this stage.
The audit plan will further document the necessary procedures to carry on the examination
to ensure that the application system is designed and implemented effectively, as well as operates
consistent with the organization policies and procedures. Procedures performed by IT auditors
should provide reasonable assurance that applications have been adequately designed and imple-
mented, and:

◾◾ Comply with standards, policies, and procedures

◾◾ Achieve efficient and economical operations
◾◾ Conform to legal requirements
◾◾ Include the necessary controls to protect against loss or serious errors
◾◾ Provide controls and audit trails needed for management, auditor, and for operational review
purposes

NIST’s Special Publication 800-53A, Revision 4, Assessing Security and Privacy Controls
in Federal Information Systems and Organizations (2014), provides all-inclusive assessment
 Application Systems: Risks and Controls ◾ 261

procedures for examining security and privacy controls in federal information systems and organi-
zations.* It is important to note that these procedures also apply to non-federal application systems.

Communication
The first area to communicate is the IT auditor’s scope of involvement. It is very important to
make sure that management’s expectations of the IT auditor’s role are understood and commu-
nicated to all participants. IT auditors must develop an open line of communication with both
management and users. If a good relationship between these groups does not exist, information
might be withheld from the IT auditor. Although the IT auditor should cultivate good working
relationships with all groups with design responsibilities, the IT auditor must remain independent.
Throughout the audit, the IT auditor will be making control recommendations resulting from
identified findings. Depending on the organization’s culture, these recommendations may need to
be handled informally with each application owner in charge of the deficient area or process, or
formally by presenting them to the steering committee. In either case, the IT auditor must always
consider the value of the control recommendation versus the cost of implementing the control.
Recommendations should be specific. They should identify the problem and not the symptom,
and allow for the proper controls to be implemented and tested. Findings, risks as a result of those
findings, and audit recommendations are usually documented in a formal letter (i.e., Management
Letter). Refer to Exhibit 3.9 from Chapter 3 for an example of the format of a Management Letter
from an IT audit.

Conclusion
Applications are critical for organizations in conducting their business. They represent a signifi-
cant investment for many organizations as they provide automated functions to effectively s­ upport
the business process. Applications also introduce risks to organizations. These risks should be
addressed with adequate selection and implementation of application controls.
EUD involves the use of department-developed applications, such as spreadsheets and
­databases, which are frequently used as tools in performing daily work. These spreadsheets and
databases are essentially an extension of the IT environment and output generated from them may
be used in making business decisions impacting the company. The level of risk and the required
controls to be implemented depend on the criticality of the EUD application.
Auditors, management, developers, and security consultants need to be aware of the busi-
ness risks associated with systems exchanging electronic business information. Such electronic
exchange of business documents between business (or trading) partners using a standardized
format is referred to as EDI. Common examples of business information exchanged through
EDI includes invoices and purchase orders, and risks like loss of business continuity, increased
dependence on systems, loss of confidentiality of sensitive information, and increased exposures to
frauds are some of many. Some standards that provide a basis for EDI audit assessments include
ANSI’s ASC X12 (North America) and EDIFACT (International).
Use of Web applications has become key for direction for many companies. Companies may
use Web applications for marketing purposes, and others for replacing their traditional client–
server applications. Web applications include the use of a Web browser on the client side that is

* http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.
262 ◾ Information Technology Control and Audit

usually platform independent, and requires less computing power. Some benefits of Web applica-
tions include reduced time to market, increased user satisfaction, and reduced expenses related to
maintenance and supports. Web applications are also subject to risks similar to those traditional
applications systems are exposed to.
Owing to these risks, controls need to be implemented to ensure that applications continue to
meet the business needs in an effective and efficient manner. Application controls are specific and
unique to applications. They are concerned with the accuracy, completeness, validity, and autho-
rization of the data captured, entered, processed, stored, transmitted, and reported. Application
controls are broken down into input, processing, and output controls.
IT auditors can assist organizations by reviewing their application systems to ensure that they
comply with the organization’s strategy and standards, as well as provide automated functions to
effectively support the business process. Applications will need to be risk assessed to determine the
level of audit’s involvement. Results from the risk assessment also prompt the amount of time nec-
essary to allocate to the particular application, required resources, etc. Preparation of an audit plan
then follows describing the audit objectives and procedures to be performed. Lastly, IT auditors
communicate findings identified throughout the audit plus recommendations to management.

Review Questions
1. Explain why unauthorized remote access represents a risk to applications.
2. Explain how incomplete, duplicate, and untimely processing can negatively impact applications.
3. List seven common risks associated with EUD application systems.
4. How can EUD applications become incompatible systems?
5. In today’s environment, the threat of computer viruses is high because of the unlimited
number of sources from which they can be introduced. Computer viruses can be copied
from a disk, downloaded from an infected Web page, spread among computers connected
within a network, etc. Describe the risks or problems that may result from computer viruses.
6. Explain what EDI means. Describe potential implications resulting from risks related to
application systems exchanging electronic business information.
7. List and explain five secure coding principles and practices according to OWASP for Web
applications.
8. Application controls can be described as techniques used to control the input, processing,
and output of information in an application. What do input controls refer to? Briefly describe
what input controls ensure.
9. Application controls can be described as techniques used to control the input, processing,
and output of information in an application. What do processing controls refer to? Briefly
describe what processing controls ensure.
10. Application controls can be described as techniques used to control the input, process-
ing, and output of information in an application. What do output controls refer to? Briefly
describe what output controls ensure.

Exercises
1. A company allows orders to be placed directly through its Web site. Describe the three
most prominent application system risks that could contribute to unauthorized access to a
­customer’s order information. Identify controls to put in place to mitigate those risks.
 Application Systems: Risks and Controls ◾ 263

2. A payroll department has a time sheet application where employees enter their hours worked.
Describe the two most prominent application system risks and the controls that would help
mitigate those risks.
3. Departments within a company have their own technical support person who creates and
maintains the applications. Describe three risks associated with this practice. What controls
would you recommend to help minimize those risks?
4. Explain the significance of application controls and provide examples on how they are used
to safeguard the input, processing, and output of information.

CASE—EUD APPLICATIONS
INSTRUCTIONS: A company uses EUD applications, particularly, a spreadsheet to main-
tain its budget. The spreadsheet is used to solicit the budget from each of the company’s
departments. The budget department subsequently compiles the individual spreadsheets
into a master sheet, reviews and revises the budget based on its constraints, and then uses it
to load the budget values into the company’s finance system where the department can then
view its finalized budget.
TASK: List and describe at least seven prominent application risks associated with the use
of a spreadsheet system. You are also required to explain how each of the risks you list
may impact the spreadsheet system. Search beyond the chapter for specific examples, IT
literature, and/or any other valid external source to support your response. Submit a word
file with a cover page, responses to the task above, and a reference section at the end. The
submitted file should be between 5 and 7 pages long (double line spacing), including cover
page and references. Be ready to present your work to the class.

CASE—INPUT CONTROLS
INSTRUCTIONS: A company has a centralized accounting system. Each individual
department currently compiles its accounting paper transactions from its local accounting
system. To eliminate the paper and increase efficiency, the Audit Manager of the company
just asked you, IT auditor, to help him come up with a plan to implement an interface from
each individual department’s accounting system to the centralized accounting system.
TASK: Prepare a memo to the Audit Manager naming and describing the most critical
controls that you would recommend in this particular case. You are required to search
beyond the chapter (i.e., IT literature and/or any other valid external source) to support
your response. Include examples, as appropriate, to evidence your case point. Submit a word
file with a cover page, responses to the task above, and a reference section at the end. The
submitted file should be 5 pages long (double line spacing), including cover page and refer-
ences. Be ready to present your work to the class.

Further Reading
1. A survey of key concepts and issues for electronic recordkeeping. (2003). Electronic Data Interchange.
www.ctg.albany.edu/publications/reports/key_concepts?chapter=3&PrintVersion=2
264 ◾ Information Technology Control and Audit

2. Baker, S., Waterman, S., and Ivanov, G. (2010). In the Crossfire: Critical Infrastructure in the Age of
Cyber War, McAfee.
3. Berkeley Information Security and Policy. Secure coding practice guidelines. https://security.berkeley.
edu/secure-coding-practice-guidelines (accessed July 2017).
4. Federal Bureau of Investigation (FBI), Financial Crimes Report to the Public Fiscal Years 2007
through 2011, Department of Justice, United States. www.fbi.gov/stats-services/publications/
financial-crimes-report-2010-2011
5. Global Technology Audit Guide (GTAG) 8: Auditing Application Controls. The Institute of Internal
Auditors. https://na.theiia.org/standards-guidance/recommended-guidance/practice-guides/Pages/
GTAG8.aspx (accessed July 2017).
6. GS1 EDI. GS1. www.gs1.org/edi (accessed July 2017).
7. ISACA. (2017). COBIT and Application Controls: A Management Guide, www.isaca.org/knowledge-
center/research/researchdeliverables/pages/cobit-and-application-controls-a-management-guide.aspx
8. ISACA. (2017). Web Application Security: Business and Risk Considerations, www.isaca.org
9. Jones, D.C., Kalmi, P., and Kauhanen, A. (2011). Firm and employee effects of an enterprise informa-
tion system: Micro-econometric evidence. Int. J. Prod. Econ., 130(2), 159–168.
10. McAfee Labs 2017 threats predictions, report issued on November 2016. www.mcafee.com/au/
resources/reports/rp-threats-predictions-2017.pdf
11. McAfee Labs threats report––December 2016 www.mcafee.com/ca/resources/reports/rp-quarterly-
threats-dec-2016.pdf
12. Morella, R. (August 2015). Auditing web applications. IT audit strategies for web applications. ISACA
Geek Week. www.isaca.org/chapters3/Atlanta/AboutOurChapter/Documents/GW2015/081115-10AM-
WebAppSecurity.pdf
13. National Institute of Standards and Technology. Special Publication 800-53A, Revision 4, Assessing
security and privacy controls in federal information systems and organizations, December 2014.
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf
14. Odette. EDI basics. www.edibasics.com/edi-resources/document-standards/odette/ (accessed July
2017).
15. Otero, A. R. (2015). An information security control assessment methodology for organizations’
financial information. Int. J. Acc. Inform. Syst., 18(1), 26–45.
16. Otero, A. R. (2015). Impact of IT auditors’ involvement in financial audits. Int. J. Res. Bus. Technol.,
6(3), 841–849.
17. Otero, A. R., Tejay, G., Otero, L. D., and Ruiz, A. (2012). A fuzzy logic-based information security
control assessment for organizations, IEEE Conference on Open Systems. 21–24 Oct. 2012, Kuala
Lumpur, Malaysia.
18. Otero, A. R., Otero, C. E., and Qureshi, A. (2010). A multi-criteria evaluation of information security
controls using Boolean features. Int. J. Network Secur. Appl., 2(4), 1–11.
19. OWASP. (2013). OWASP top 10–2013: Top 10 most critical web application security risks. www.
owasp.org/index.php/Top_10_2013-Risk
20. OWASP. Secure coding practices—Quick reference guide. www.owasp.org/index.php/OWASP_
Secure_Coding_Practices_-_Quick_Reference_Guide (accessed June 2017).
21. Romney, M. B. and Steinbart, P. J. (2015). Accounting Information Systems, 13th Edition. Pearson
Education, Reading, UK.
22. Berkeley Information Security and Policy. Secure coding practice guidelines. https://security.berkeley.
edu/secure-coding-practice-guidelines (accessed June 2017).
23. Senft, S., Gallegos, F., and Davis, A. (2012). Information Technology Control and Audit, CRC Press/
Taylor & Francis: Boca Raton.
24. Tradacoms. EDI basics. www.edibasics.co.uk/edi-resources/document-standards/tradacoms/ (accessed
July 2017).