DON'T SUMMARIZE JUST  PARAGRAPH OF WHAT YOU THOUGHT/LEARNED

 

CHAPTER 13 - 

The phrase "garbage in, garbage out" highlights the importance of input controls. If the data entered into a system are inaccurate, incomplete, or invalid, the output will be too. Consequently, only authorized personnel acting within their authority should prepare source documents. In addition, forms design, cancellation and storage of source documents, and automated data entry controls are needed to verify the validity of input data.

Forms Design

Source documents and other forms should be designed to minimize the chances for errors and omissions. Two particularly important forms design controls involve sequentially prenumbering source documents and using turnaround documents.

1. All source documents should be sequentially prenumbered. Prenumbering improves control by making it possible to verify that no documents are missing. (To understand this, consider the difficulty you would have in balancing your checking account if none of your checks were numbered.) When sequentially prenumbered source data documents are used, the system should be programmed to identify and report missing or duplicate source documents.
2. As explained in Chapter 2, companies use turnaround documents to eliminate the need for an external party to submit information that the organization already possesses, such as the customer's account number. Instead, that data is preprinted in machine-readable format on the turnaround document. An example is a utility bill that a special scanning device reads when the bill is returned with a payment. Turnaround documents improve accuracy by eliminating the potential for input errors when entering data manually.

Cancellation and Storage of Source Documents

Source documents that have been entered into the system should be canceled so they cannot be inadvertently or fraudulently reentered into the system. Paper documents should be defaced, for example, by stamping them "paid." Electronic documents can be similarly "canceled" by setting a flag field to indicate that the document has already been processed. Note: Cancellation does not mean disposal. Original source documents (or their electronic images) should be retained for as long as needed to satisfy legal and regulatory requirements and provide an audit trail.

Data Entry Controls

Source documents should be scanned for reasonableness and propriety before being entered into the system. However, this manual control must be supplemented with automated data entry controls, such as the following:

• A field check determines whether the characters in a field are of the proper type. For example, a check on a field that is supposed to contain only numeric values, such as a U.S. zip code, would indicate an error if it contained alphabetic characters.
• A sign check determines whether the data in a field have the appropriate arithmetic sign. For example, the quantity-ordered field should never be negative.
• A limit check tests a numerical amount against a fixed value. For example, the regular hours-worked field in weekly payroll input must be less than or equal to 40 hours. Similarly, the hourly wage field should be greater than or equal to the minimum wage.
• A range check tests whether a numerical amount falls between predetermined lower and upper limits. For example, a marketing promotion might be directed only to prospects with incomes between $50,000 and $99,999.
• A size check ensures that the input data will fit into the assigned field. For example, the value 458,976,253 will not fit in an eight-digit field. As discussed in Chapter 11, size checks are especially important for applications that directly accept end-user input, providing a way to prevent buffer overflow vulnerabilities.
• A completeness check (or test) verifies that all required data items have been entered. For example, sales transaction records should not be accepted for processing unless they include the customer's shipping and billing addresses.
• A validity check compares the ID code or account number in transaction data with similar data in the master file to verify that the account exists. For example, if product number 65432 is entered on a sales order, the computer must verify that there is indeed a product 65432 in the inventory database.
• A reasonableness test determines the correctness of the logical relationship between two data items. For example, overtime hours should be zero for someone who has not worked the maximum number of regular hours in a pay period.
• ID codes (such as part numbers) can contain a check digit that is computed from the other digits. For example, the system could assign each new inventory item a nine-digit number, then calculate a tenth digit from the original nine and append that calculated number to the original nine to form a 10-digit part number. Data entry devices can then be programmed to perform check digit verification, which involves recalculating the check digit to identify data entry errors. Continuing our example, check digit verification could be used to verify accuracy of an inventory item number by using the first nine digits to calculate what the tenth digit should be. If an error is made in entering any of the ten digits, the calculation made on the first nine digits will not match the tenth, or check digit. Note that check digit verification only tests whether an ID code in a transaction record could exist and is designed to catch transposition errors (e.g., entering 35689 instead of 35869 as a part number). A validity check is the only way to verify that the ID code really does exist.

The preceding data entry tests are used for both batch processing and online real-time processing. Additional data input controls differ for the two processing methods.

Additional Batch Processing Data Entry Controls

1. • Batch processing works more efficiently if the transactions are sorted so that the accounts affected are in the same sequence as records are stored in the master file. For example, accurate batch processing of sales transactions to update customer account balances requires that the sales transactions file first be sorted by customer account number. A sequence check tests whether a transaction file is in the proper numerical or alphabetical sequence.
2. • An error log that identifies data input errors (date, cause, problem) facilitates timely review and resubmission of transactions that cannot be processed.
3. • Batch totals calculate numeric values for a batch of input records. Batch totals are used to ensure that all records in a batch are processed correctly. The following are three commonly used batch totals:
   1. 1. A financial total sums a field that contains monetary values, such as the total dollar amount of all sales for a batch of sales transactions.
   2. 2. A hash total sums a nonfinancial numeric field, such as the total of the quantity-ordered field in a batch of sales transactions. Unlike financial totals, hash totals have no inherent meaning. For example, it is possible to sum up the invoice numbers in a batch of sales transactions but the result is meaningless; its only purpose is to serve as an input control.
   3. 3. A record count is the number of records in a batch.

Additional Online Data Entry Controls

• Prompting, in which the system requests each input data item and waits for an acceptable response, ensures that all necessary data are entered (i.e., prompting is an online completeness check).
• Closed-loop verification checks the accuracy of input data by using it to retrieve and display other related information. For example, if a clerk enters an account number, the system could retrieve and display the account name so that the clerk could verify that the correct account number had been entered.
• A transaction log includes a detailed record of all transactions, including a unique transaction identifier, the date and time of entry, and who entered the transaction. If an online file is damaged, the transaction log can be used to reconstruct the file. If a malfunction temporarily shuts down the system, the transaction log can be used to ensure that transactions are not lost or entered twice.

Controls are also needed to ensure data is processed correctly. Important processing controls include the following:

• Data matching. In certain cases, two or more items of data must be matched before an action can take place. For example, before paying a vendor, the system should verify that information on the vendor invoice matches information on both the purchase order and the receiving report.
• File labels. File labels need to be checked to ensure that the correct and most current files are being updated. Both external labels that are readable by humans and internal labels that are written in machine-readable form on the data recording media should be used. Two important types of internal labels are header and trailer records. The header record is located at the beginning of each file and contains the file name, expiration date, and other identification data. The trailer record is located at the end of the file; in transaction files it contains the batch totals calculated during input. Programs should be designed to read the header record prior to processing, to ensure that the correct file is being updated. Programs should also be designed to read the information in the trailer record after processing, to verify that all input records have been correctly processed.
• Recalculation of batch totals. Batch totals should be recomputed as each transaction record is processed, by comparing a running total calculated during processing to the corresponding batch total calculated during input and stored in the trailer record. Any discrepancies indicate a processing error. Often, the nature of the discrepancy provides a clue about the type of error that occurred. For example, if the recomputed record count is smaller than the original, one or more transaction records were not processed. Conversely, if the recomputed record count is larger than the original, either additional unauthorized transactions were processed, or some transaction records were processed twice. If a financial or hash total discrepancy is evenly divisible by 9, the likely cause is a transposition error, in which two adjacent digits were inadvertently reversed (e.g., 46 instead of 64). Transposition errors may appear to be trivial but can have enormous financial consequences. For example, consider the effect of mis recording the interest rate on a loan as 6.4% instead of 4.6%.
• Cross-footing and zero-balance tests. Often totals can be calculated in multiple ways. For example, in spreadsheets a grand total can be computed either by summing a column of row totals or by summing a row of column totals. These two methods should produce the same result. A cross-footing balance test compares the results produced by each method to verify accuracy. A zero-balance test applies this same logic to verify the accuracy of processing that involves control accounts. For example, the payroll clearing account is debited for the total gross pay of all employees in a particular time period. It is then credited for the amount of all labor costs allocated to various expense categories. The payroll clearing account should have a zero balance after both sets of entries have been made; a nonzero balance indicates a processing error.
• Write-protection mechanisms. These protect against overwriting or erasing of data files stored on magnetic media. Write-protection mechanisms have long been used to protect master files from accidentally being damaged. Technological innovations also necessitate the use of write-protection mechanisms to protect the integrity of transaction data. For example, radio frequency identification (RFID) tags used to track inventory need to be write-protected so that unscrupulous customers cannot change the price of merchandise.
• Concurrent update controls. Errors can occur when two or more users attempt to update the same record simultaneously. Concurrent update controls prevent such errors by locking out one user until the system has finished processing the transaction entered by the other.

Output Controls

Careful checking of system output provides additional control over processing integrity. Important output controls include the following:

• User review of output. Users should carefully examine system output to verify that it is reasonable and complete, and that they are the intended recipients.
• Reconciliation procedures. Periodically, all transactions and other system updates should be reconciled to control reports, file status/update reports, or other control mechanisms. In addition, general ledger accounts should be reconciled to subsidiary account totals on a regular basis. For example, the balance of the inventory control account in the general ledger should equal the sum of the item balances in the inventory database. The same is true for the accounts receivable, capital assets, and accounts payable control accounts.
• External data reconciliation. Database totals should periodically be reconciled with data maintained outside the system. For example, the number of employee records in the payroll file can be compared with the total number of employees in the human resources database to detect attempts to add fictitious employees to the payroll database. Similarly, inventory on hand should be physically counted and compared to the quantity on hand recorded in the database. The results of the physical count should be used to update the recorded amounts and significant discrepancies should be investigated.
• Data transmission controls. Organizations also need to implement controls designed to minimize the risk of data transmission errors. Whenever the receiving device detects a data transmission error, it requests the sending device to retransmit that data. Generally, this happens automatically, and the user is unaware that it has occurred. For example, the Transmission Control Protocol (TCP) discussed in Chapter 11 assigns a sequence number to each packet and uses that information to verify that all packets have been received and to reassemble them in the correct order. Two other common data transmission controls are checksums and parity bits.
• Checksums. When data are transmitted, the sending device can calculate a hash of the file, called a checksum. The receiving device performs the same calculation and sends the result to the sending device. If the two hashes agree, the transmission is presumed to be accurate. Otherwise, the file is resent.
• Parity bits. Computers represent characters as a set of binary digits called bits. Each bit has two possible values: 0 or 1. Many computers use a seven-bit coding scheme, which is more than enough to represent the 26 letters in the English alphabet (both upper- and lowercase), the numbers 0 through 9, and a variety of special symbols ($, %, &, etc.). A parity bit is an extra digit added to the beginning of every character that can be used to check transmission accuracy. Two basic schemes are referred to as even parity and odd parity. In even parity, the parity bit is set so that each character has an even number of bits with the value 1; in odd parity, the parity bit is set so that an odd number of bits in the character have the value 1. For example, the digits 5 and 7 can be represented by the seven-bit patterns 0000101 and 0000111, respectively. An even parity system would set the parity bit for 5 to 0, so that it would be transmitted as 00000101 (because the binary code for 5 already has two bits with the value 1). The parity bit for 7 would be set to 1 so that it would be transmitted as 10000111 (because the binary code for 7 has 3 bits with the value 1). The receiving device performs parity checking, which entails verifying that the proper number of bits are set to the value 1 in each character received.
• Blockchain. As explained in Chapter 12, blockchains provide a way to ensure that validated transactions and documents are not altered. Integrity is assured by hashing the contents of each block and then storing multiple copies of the entire chain on different devices.

Processing Integrity Controls in Spreadsheets

Most organizations have thousands of spreadsheets that are used to support decision-making. Yet, because end users almost always develop spreadsheets, they seldom contain adequate application controls. Therefore, it is not surprising that many organizations have experienced serious problems caused by spreadsheet errors. For example, an August 17, 2007, article in CIO Magazine¹⁰ describes how spreadsheet errors caused companies to lose money, issue erroneous dividend payout announcements, and misreport financial results.

Careful testing of spreadsheets before use could have prevented these kinds of costly mistakes. Although most spreadsheet software contains built-in "audit" features that can easily detect common errors, spreadsheets intended to support important decisions need more thorough testing to detect subtle errors. It is especially important to check for hardwiring, where formulas contain specific numeric values (e.g., 

). Best practice is to use reference cells (e.g., store the sales tax rate in cell A8) and then write formulas that include the reference cell (e.g., change the previous example to

). The problem with hardwiring is that the spreadsheet initially produces correct answers, but when the hardwired variable (e.g., the sales tax rate in the preceding example) changes, the formula may not be corrected in every cell that includes that hardwired value. In contrast, following the recommended best practice and storing the sales tax value in a clearly labeled cell means that when the sales tax rate changes, only that one cell needs to be updated. This best practice also ensures that the updated sales tax rate is used in every formula that involves calculating sales taxes.

Minimizing Risk of System Downtime

Organizations can undertake a variety of actions to minimize the risk of system downtime. COBIT 2019 management practice DSS01.05 identifies the need for preventive maintenance, such as cleaning disk drives and properly storing magnetic and optical media, to reduce the risk of hardware and software failure. The use of redundant components provides fault tolerance, which is the ability of a system to continue functioning in the event that a particular component fails. For example, many organizations use redundant arrays of independent drives (RAID) instead of just one disk drive. With RAID, data is written to multiple disk drives simultaneously. Thus, if one disk drive fails, the data can be readily accessed from another.

404

COBIT 2019 management practices DSS01.04 and DSS01.05 address the importance of locating and designing the data centers housing mission-critical servers and databases so as to minimize the risks associated with natural and human-caused disasters. Common design features include the following:

• Raised floors provide protection from damage caused by flooding.
• Fire detection and suppression devices reduce the likelihood of fire damage.
• Adequate air-conditioning systems reduce the likelihood of damage to computer equipment due to overheating or humidity.
• Cables with special plugs that cannot be easily removed reduce the risk of system damage due to accidental unplugging of the device.
• Surge-protection devices provide protection against temporary power fluctuations that might otherwise cause computers and other network equipment to crash.
• An uninterruptible power supply (UPS) system provides protection in the event of a prolonged power outage, using battery power to enable the system to operate long enough to back up critical data and safely shut down. (However, it is important to regularly inspect and test the batteries in a UPS to ensure that it will function when needed.)
• Physical access controls reduce the risk of theft or damage.

Training can also reduce the risk of system downtime. Well-trained operators are less likely to make mistakes and will know how to recover, with minimal damage, from errors they do commit. That is why COBIT 2019 management practice DSS01 stresses the importance of defining and documenting operational procedures and ensuring that IT staff understand their responsibilities.

System downtime can also occur because of computer malware (e.g., ransomware can make applications and data inaccessible). Therefore, it is important to install, run, and keep current antivirus and anti-spyware programs. These programs should be automatically invoked not only to scan Mail, but also any removable computer media (CDs, DVDs, USB drives, etc.) that are brought into the organization. A patch management system provides additional protection by ensuring that vulnerabilities that can be exploited by malware are fixed in a timely manner.

 

Recovery and Resumption of Normal Operations

The preventive controls discussed in the preceding section can minimize, but not entirely eliminate, the risk of system downtime. Hardware malfunctions, software problems, or human error can cause data to become inaccessible. For example, RAID devices can experience catastrophic failures, rendering all the drives useless. That's why senior management needs to answer two fundamental questions:

1. How much data are we willing to recreate from source documents (if they exist) or potentially lose (if no source documents exist)?
2. How long can we function without our information system?

Figure 13-1 shows the relationship between these two questions. When a problem occurs, data about everything that has happened since the last backup is lost unless it can be reentered into the system. Thus, management's answer to the first question determines the organization's recovery point objective (RPO), which represents the maximum amount of data that the organization is willing to have to reenter or potentially lose. The RPO is inversely related to the frequency of backups: the smaller the desired RPO, the more frequently backups need to be made. The answer to the second question determines the organization's recovery time objective (RTO), which is the maximum tolerable time to restore an information system after a disaster. Thus, the RTO represents the length of time that the organization is willing to attempt to function without its information system

Data Backup Procedures

Data backup procedures are designed to deal with situations where information is not accessible because the relevant files or databases have become corrupted as a result of hardware failure, software problems, or human error, but the information system itself is still functioning. Several different backup procedures exist. A full backup is an exact copy of the entire database. Full backups are time-consuming, so most organizations only do full backups weekly and supplement them with daily partial backups. Figure 13-2 compares the two types of daily partial backups:

1. An incremental backup involves copying only the data items that have changed since the last partial backup. This produces a set of incremental backup files, each containing the results of one day's transactions. Restoration involves first loading the last full backup and then installing each subsequent incremental backup in the proper sequence.
2. A differential backup copies all changes made since the last full backup. Thus, each new differential backup file contains the cumulative effects of all activity since the last full backup. Consequently, except for the first day following a full backup, daily differential backups take longer than incremental backups. Restoration is simpler, however, because the last full backup needs to be supplemented with only the most recent differential backup, instead of a set of daily incremental backup files.

Deduplication is causing many organizations to eliminate making full backups and to continuously make incremental partial backups instead. Deduplication uses hashing to identify and backup only those portions of a file or database that have been updated since the last backup. The deduplication process works by dividing a file or database into uniform-sized chunks. Each chunk is hashed, and the chunk's hash value is compared to the hash values of all chunks in the hash file from the previous backup. Recall that identical hash values mean that two data sets are bit-for-bit identical. Thus, any data chunk with a hash file that matches a value in the hash file from the previous backup has not been changed. Consequently, it does not need to be backed up again. Instead, only those data chunks whose current hash values do not match any values in the hash file from the previous backup need to be backed up this time. Typically, only a small percentage of a database or file has been changed since the last backup; therefore, deduplication results in fast backups. The restore process then involves using the most current file of chunk hashes to identify the appropriate incremental backup files that need to be combined to recreate the complete file or database.

406

No matter which backup procedure is used, multiple backup copies should be created. One copy can be stored on-site, for use in the event of relatively minor problems, such as failure of a hard drive. In the event of a more serious problem, such as a fire or flood, any backup copies stored on-site will likely be destroyed or inaccessible. Therefore, a second backup copy needs to be stored off-site. These backup files can be transported to the remote storage site either physically (e.g., by courier) or electronically. In either case, the same security controls need to be applied to backup files as are used to protect the original copy of the information. This means that backup copies of sensitive data should be encrypted both in storage and during electronic transmission. Access to backup files also needs to be carefully controlled and monitored.

It is also important to periodically practice restoring a system from its backups. This verifies that the backup procedure is working correctly and that the backup media (tape or disk) can be successfully read by the hardware in use.

The purpose of backups is to enable restoration of data in the event that the original copy becomes inaccessible. Consequently, backups are retained for only a relatively short period of time. For example, many organizations maintain only several months of backups. Some information, however, must be stored much longer. An archive is a copy of a database, master file, or software retained indefinitely as a historical record, usually to satisfy legal and regulatory requirements. Archives are used to retrieve selected data, not to restore entire files or databases. Consequently, archive software includes indexing features to facilitate quick retrieval, but backup software does not. Therefore, retaining backups for years is not a viable alternative to creating true archives. As with backups, multiple copies of archives should be made and stored in different locations. Unlike backups, archives are seldom encrypted because their long retention times increase the risk of losing the decryption key. Consequently, physical and logical access controls are the primary means of protecting archive files.

What media should be used for backups and archives, tape or disk? Disk backup is faster, and so is the time required to retrieve the data. Tape, however, is cheaper, easier to transport, and more durable. In addition, because tapes are typically stored offline, they are less likely to be infected by ransomware. Consequently, many organizations use both media. Data are first backed up to disk, for speed, and then transferred to tape.

Special attention needs to be paid to backing up and archiving Mail because it has become an important repository of organizational behavior and information. Indeed, Mail often contains solutions to specific problems. Mail also frequently contains information relevant to lawsuits. It may be tempting for an organization to consider a policy of periodically deleting all Mail, to prevent a plaintiff's attorney from finding a "smoking gun" and to avoid the costs of finding the Mail requested by the other party. Most experts, however, advise against such policies because other parties are likely to possess copies of the Mail. Therefore, a policy of regularly deleting all Mail means that the organization will not be able to tell its side of the story; instead, the court (and jury) will only read the Mail presented by the other party to the dispute. There have also been cases where the courts have fined organizations millions of dollars for failing to produce requested Mail in a timely manner. Therefore, organizations need to back up and archive important mail while also periodically purging the large volume of routine, trivial Mail.

407

Disaster Recovery and Business Continuity Planning

Backups are designed to mitigate problems when one or more files or databases become corrupted because of hardware, software, or human error. Disaster recovery plans and business continuity plans are designed to mitigate more serious problems.

A disaster recovery plan (DRP) outlines the procedures to restore an organization's IT function in the event that its data center is destroyed. Organizations have three basic options for replacing their IT infrastructure, which includes not just computers, but also network components such as routers and switches, software, data, Internet access, printers, and supplies. The first option is to contract for use of a cold site, which is an empty building prewired for necessary telephone and Internet access. However, a cold site does not contain any computing equipment; instead, the organization has a contract with one or more vendors to provide all necessary equipment within a specified period of time.

A second option is to contract for use of a hot site, which is a facility not only prewired for telephone and Internet access but also contains all the computing and office equipment the organization needs to perform its essential business activities. The third option is real-time mirroring, which involves maintaining two copies of the database at two separate data centers at all times and updating both databases in real-time as each transaction occurs.

 

The different DRP options (cold site, hot site, or real-time mirroring) vary in cost, with cold sites being least expensive and real-time mirroring most expensive. However, the choice should not be driven by cost but should reflect management's decisions about tolerable RPO and RTO. For some organizations, both RPO and RTO must be as close to zero as possible. Airlines and financial institutions, for example, cannot operate without their information systems, nor can they afford to lose data about transactions because they have so many every minute. For such organizations, the goal is not recovery but resiliency (i.e., they must be able to continue functioning no matter what happens). Real-time mirroring provides maximum resiliency because both RPO and RTO are close to zero. Transactions are backed up in real time, and if something happens to one data center, the organization can immediately shift all processing to the other. Thus, real-time mirroring is the appropriate DRP choice when RPO, RTO, or both must be close to zero.

 

Some organizations can tolerate the potential loss of some data and have the ability to operate for a period of time without their AIS. If management has decided that it can tolerate RTO and RPO ranging from hours up to a full day, the choice of a hot site as a DRP strategy is warranted. Using a cold site for DRP is appropriate only if management can tolerate having both RTO and RPO greater than one day.

Organizations can choose to build their own hot site or cold site, or they can contract with a third party for the use of such facilities. Using a third-party site is less expensive, but it does carry the risk of not being available when needed. Most providers of hot and cold sites "oversell" their capacity under the assumption that at any one time only a few clients will need to use the facilities. Normally, that is a safe assumption. However, in the event of a major calamity, such as Hurricanes Katrina and Sandy, that affects every organization in a geographic area, it means that some organizations may not be able to use the services for which they contracted. (The ability to sue for failure to provide the services is not a compensating control because the organization may be out of business by the time the lawsuit is settled.). Click on the blue icons in the table below to learn more about cold site, hot site and real-time mirroring.

Jason's report assessed the effectiveness of Northwest Industries' controls designed to ensure processing integrity. To minimize data entry, and the opportunity for mistakes, Northwest Industries mailed turnaround documents to customers, which were returned with their payments. All data entry was done online, with extensive use of input validation routines to ensure the accuracy of the information entering the system. Managers reviewed output for reasonableness, and the accuracy of key components of financial reports was regularly cross-validated with independent sources. For example, inventory was counted quarterly, and the results of the physical counts were reconciled to the quantities stored in the system.

Jason was concerned about the effectiveness of controls designed to ensure systems availability, however. He noted that although Northwest Industries had developed a disaster recovery and business continuity plan, those plans had not been reviewed or updated for three years. Of even greater concern was the fact that many portions of the plan had never been tested. Jason's biggest concern, however, related to backup procedures. All files were backed up weekly, on Saturdays, onto DVDs, and incremental backups were made each night, but no one had ever practiced restoring the data. In addition, the backups were not encrypted, and the only copy was stored on-site in the main server room on a shelf by the door.

Jason concluded his report with specific recommendations to address the weaknesses he had found. He recommended that Northwest Industries immediately test its backup restoration procedures, encrypt its backup files, and store a second copy of all backups offsite. Jason also recommended testing the DRP and BCP plans. Jason felt confident that once those recommendations were implemented, management could be reasonably assured that Northwest Industries' information systems had satisfied the AICPA's Trust Services framework criteria and principles for systems reliability.
 
 

Answer rating: 100% (QA)

It appears youve shared an excerpt from a textbook or course material on the topic ... View the full answer