Year 1 – 1988 – new auditor

Year 1 – 1988

My first audit position was in an organization employed over 100 auditors divided into business lines: finance, HR, operations, and IT. I was hired as a Senior IT auditor even though I had no internal audit experience and only (what I felt was) limited IT experience. On top of that, I was getting very little (read “no”) support from my supervisor.  To be fair, there were hundreds of application systems and new system development projects and only 3 IT auditors; so my supervisor was busy conducting his own IT audits. (BTW, I was called an EDP auditor at the time; but I am using the newer term.) After reading 6 feet (literally) of printed documentation on the company, audit, and audit procedures I was “ready” to start auditing.

Our IT environment was almost exclusively IBM mainframe computers and applications. There was a certain amount of distributed processing and a few mini-computers. At a previous job I had learned JCL, TSO/ISPF (both mainframe essentials) as well as a couple of applications such as Wilbur and S2K. I was definitely not a programmer – but I had taken several introductory programming courses (e.g. FORTRAN, COBOL, Pascal, XPL, and PL1) in university. I was more of an “intelligent end-user”. I knew enough about IT to talk to programmers and explain what I needed, but now I had to do more than just talk IT.

Back in the late 1980’s, internal audit was mainly about controls and control weaknesses. The notion of assessing risk did not exist. The objective of the audit was to identify and assess relevant controls and to provide assurance that the controls were working properly. At the time, this made sense – what were the critical controls and were they working – was the order of the day.

My first audit was to assess the controls around telecommunications – primarily telephones and faxes. After some initial reading of the policies and procedures, I contacted the group responsible for telecommunications and asked to see the monthly Call Detail reports that they used to verify the accuracy of the multi-million dollar per year telecommunication bill. I was shocked to learn that they have not even looked at the previous month’s report; and that the report was only available on paper. (Remember this was 1988, and it was my first audit – so technology was limited and I was more than a little naive about management’s monitoring practices)  In fact they had not opened any of the boxes containing the Call Detail reports for many months.

I searched for, found, and opened the box marked July 1988 (the most recent report). The box contained 500 pages of printed details of every phone call made on any phone line. The details included the originating phone number, phone number called, start date and time of the call, length of the call in minutes, and the cost. There were subtotals for each originating phone number and a total at the end of the report. By the way, the box I opened was only the first of six boxes for July 1988.

As I flipped through the report, trying to figure out what I was supposed to do, and regretting my decision to become an internal auditor, I noticed a record that had a call-duration of 999 minutes and over $1,000 in charges. The printed report was in columns and since most calls were under 10 minutes and less than $1.00, this call stood out visually from the rest. I quickly did the math and determined that the call was over 16.6 hours in length.   While I pondered why someone would be on the phone for more than 16 hours, I noticed that another phone call had been initiated from the same originating phone number a few minutes after the 16 hour call had been initiated.   It was not possible to have two concurrent calls on one phone line with the types of phones we had in our offices. I figured I was on to something so, with renewed interest in the task, I continued flipping through the 3,000 page July report – marking every instance of 999-minute calls by circling the amount and placing a piece of scotch tape on the edge of page and folding the tape back over on itself so that it protruded from the page by about a quarter inch (sticky notes did not exist yet; and neither did yellow highlighters). By the end of the day, I had identified 23 calls totalling $29K in charges. I asked the manager of the area about it and he had no idea why this would be happening, but he did give me the phone number of our account manager at the telecom company.   I called him and he said, “Sometimes the communication switch doesn’t close when a call is terminated so the billing system thinks the call is ongoing. The maximum duration in the billing program is 999 minutes and the charges are based on that.” He paused for a second and then added “How much of a refund do we owe you?” I realized that he was telling me that we had been charged for 999-minute calls when the actual calls were much shorter in duration. I told him that I had only reviewed one month of call details and he said, “Multiply the amount by 12 and send a memo asking for a full refund”.

I was feeling pretty good, my first audit and I had identified a control weakness in both our review of the telephone bill and the telecom’s switching system. On top of that, I recovered almost $350K. Not bad for essentially one day’s work. However, I was a little concerned about the recommendation. The manager knew he was supposed to review the Call Detail report, but he wasn’t. Simply recommending that management review the Call Detail report seemed too obvious and probably didn’t address the problem.

I asked the manager why he didn’t review the Call Detail reports every month and his reply was, “I don’t have time to sitting there all day flipping through the monthly report. Besides, now that you have identified a control issue with the telecom switch, we have negotiated a $30K reduction in the monthly bill to address the possible overcharges until the telecom company advises us that the problem has been fixed.” In the end, I was instructed by my audit manager to include the recommendation that management review the monthly Call Detail report to ensure the accuracy of the monthly telecom invoice. Management responded with “Agreed” but I knew that this would never happen.

Analysis: even though I did not have access to the telecomm data in electronic format – the following ACL commands would have easily detected and determined the amount of the overpayment: STATITISTICS, FILTER, and TOTAL.

Lessons-learned: The fact that management has access to the information and should be monitoring events does not mean that this is always the case. Being new to audit, I still thought that controls were generally implemented and effective – why wouldn’t they be when it made so much sense? However, I was beginning to learn that “operational expediency”, a failure to understand the risk or the need for controls, and many other factors erode controls. Over time, this erosion can, and does, make controls inadequate. (Note: One of these days I want to write an article on “entropy” and how this law affects even the most tightly controlled systems. Entropy is a constant force of nature to move to a more random – less controlled – state. It applies to everything, including business processes; and because of entropy, all controls will deteriorate over time.)

Another lesson: This was the first time that I wished that I had access to the information in electronic format. It was also the first time that I was not happy with what I was told to recommend (Do “A”). Unfortunately, it was not the last time for either of these.

In later years, when I was reviewing audit reports produced by my audit teams I would criticize them if they did this: Criteria: Management should do “A”; Observation – management was not doing “A”; Recommendation – do “A”. I firmly believe that if all you can recommend is that management do what they already know they are supposed to do (and are not doing) then you probably have not dug deep enough to discover the “cause” and are only dealing with the “symptom”. Recommendations that only address the symptoms are not effective and, as a result, audit does not add real value to the process.