ISACA Journal - 2012 Volume 2

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 using microcomputers. 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
this article?

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.