Tommie W. Singleton, Ph.D.,
CISA, CgeI T, CITP, CPA, is
an associate professor of
information systems (IS) at
Columbus State University
(Columbus, Georgia, USA).
Prior to obtaining his
doctorate in accountancy from
the University of Mississippi
(USA) in 1995, Singleton was
president of a small, value-added dealer of accounting
Singleton is also a scholar-in-residence for IT audit
and forensic accounting at
Carr Riggs & Ingram, a large
regional public accounting
firm in the southeastern US. In
1999, the Alabama Society of
CPAs awarded Singleton the
1998–1999 Innovative User of
Technology Award. His articles
on fraud, IT/IS, I T auditing and
IT governance have appeared
in numerous publications.
Testing Controls Associated With Data Transfers
Do you have something
to say about
Visit the Journal
pages of the ISACA
web site ( www.isaca.
org/journal), find the
article, and choose
the Comments tab to
share your thoughts.
Go directly to the article:
There are several IT-related functions that
inherently have a rather high degree of risk. Some
of those include custom application development,
logical access (especially where the Internet is
involved) and data transfers. The latter has been
growing in volume and risk recently.
In the last few years, there are more and more
occasions in which entities find it necessary or
beneficial to transfer data from one repository
to another, or to a tool for analysis. There are a
number of reasons why this has become fairly
common. Business analytics (i.e., business
intelligence) generally requires data to be
transferred from online transaction processing
(OLTP) systems to the analytic tool (e.g., data
mining, data warehouse, even a spreadsheet). Then
there are a number of occasions in which data are
transferred internally from different accounting
systems to a downstream general ledger or financial
reporting system. Sometimes that system is also a
spreadsheet. With systems such as electronic data
interchange (EDI), there is a need to transmit/
transfer data to an external entity (e.g., vendor).
The same might be true for government agencies
and other parties. Add to that the increased use of
data transfers in the banking industry (e.g., ACH,
wire transfers, electronic funds transfer [EFT]) and
credit card payments for online transactions.
According to experts, most companies do
not have a centralized methodology for tracking
and managing data transfers, which puts them
at risk for both data security/error problems and
the lack of documentation and audit trails for
relevant government regulations.
Gartner describes the risk this way: “FTP
[File Transfer Protocol] alone is not a viable
option to give organizations the insight, security,
performance, and ultimately, the risk mitigation
necessary to responsibly conduct business.” 1
The most popular term for this IT issue
is managed file transfer (MFT). Tech Target
defines MFT as “a type of software used to
provide secure internal, external, and ad hoc
data transfers through a network.” 2
This article addresses some of the IT audit
issues associated with data transfers.
DATA TrAnSFer TyPeS
Generally, data transfers can be categorized into
three types: system-to-system, partner-to-partner
and person-to-person. 3
System-to-system is a transfer of data between
two systems. That transfer could be internal
and involve computers of the entity, or it could
be between the entity and some external party.
The previous example of transferring data into a
downstream financial reporting system is fairly
common these days. For instance, if the entity is
using SAP, Oracle or even Microsoft Dynamics,
and has chosen to download the data into a
spreadsheet for year-end or fiscal-year journal
entries, generation of a trial balance, and possibly
other financial reporting process functions, then
that is a system-to-system transfer, even though one
of the systems is a spreadsheet. System-to-system
transfers can be systematic/regular, occasional or
ad hoc. For instance, transfers from OLTP to a
data warehouse system tend to be regular, whereas
financial reporting transfers tend to be occasional.
A partner-to-partner transfer was described in
the introduction regarding EDI. In this case,
two partners are continuously transferring
accounting data back and forth across agreed-upon systems. These transfers are generally done
on a regular basis.
A person-to-person transfer is the type that
probably goes unnoticed and unmanaged most
often. It could be as simple as attaching a data file
to an e-mail and sending from one person in the
entity to another via the corporate e-mail system.
Person-to-person transfers tend to be ad hoc and,
thus, are more difficult to observe, manage, secure
and control than the other types of data transfers.
An added complexity is the fact that most
ad hoc transfers, be they system-to-system or
person-to-person, tend to need a user interface
that is simple to use to minimize transfer risks.
Suffice it to say that transfers using e-mail as
the medium are a risky (i.e., horrible) option.
But the idea that restricting the size of e-mail
attachments will somehow reduce this risk is
not sound logic. Users will either “zip” the
data or use an online service (e.g., drop.io) to
accomplish the same purpose, and work around
that imposed restriction.
10 ISACA JOURNAL VOLUME 2, 2012