Mack-the-Auditor Gets Audited! Part 1

Usually, I’m the one doing the auditing, but this time, I (Mack) was the one who was audited.

It was a great experience for me.

Well, sort of. No one likes being audited (ahem). But it gave me a fresh perspective of how others feel when I audit them.

This is the first of 3 posts; this post contains some background info on the project that was audited, and the second one discusses the audit and the results, and in the third post, I describe my perspective on the whole thing, and some takeaways.

Background on the Project

I won’t go into all the details, but before I arrived at this company I’m working @ right now, they wrote some ACL scripts to do an ongoing review of certain transactions (again, the details don’t matter).

This project used several data files. Some of the files we received automatically, but several we did not. This ACL project required the auditor to manually download several files and then run about 40 scripts in a particular order, one by one.

About 4 years ago, my job was to automate this from end to end, from obtaining the data, doing all the data cleaning and transformation, analyzing the data, and producing the results. The goal was that the project would initiate itself on a schedule, run without intervention, and send the auditor an email with a link to the results.

So I automated it. It took a lot longer than all of us expected, but most of that was due to the business/technical contacts who could not seem to write queries that pulled the right data. Each time I would get the data and validate it, I would find missing products, missing transactions, missing approvals, etc.

Eventually, my contacts got the data right.

The other problem was that the original scripts contained no comments, and the original auditor who helped with the scripts was no longer with the company.

The lack of comments was surprising as they had hired a professional consulting firm (to remain nameless, because they are known world-wide) to help write the scripts.

So I had to go through all the scripts and understand what they were supposed to do and verify that they were actually doing just that (some weren’t, but I fixed them).

To make a long story shorter, I finished the project, and it worked great. All the testing that I and the auditor who was responsible for running this project showed that it worked correctly.

As we wrapped up the project, I met with the CAE and recommended that the files that were automated before I arrived be re-validated. It had been a couple years since this was done, but the CAE said he didn’t see that a big risk. I disagreed, but that was that. Ace beats jack (or in this case, Ace beats Mack–couldn’t resist).

Audit Winds Blowing

About 2 years later, I was working at this company again on some other projects, when this ACL project came up again.

The CAE heard from one of his colleagues that regulators had fined a competitor because they had a process that was similar to the one I updated, but the competitor’s version didn’t work, and failed to catch a large fraud that the regulators were investigating.

The CAE wanted an outside opinion on whether our ACL fraud scripts really worked, so he hired a consulting firm (different from the original) to review the project. I was asked to work with the consulting firm as I knew the scripts better than anyone, even the auditor who was responsible for reviewing the results each month (which is interesting, given the time that had passed, the auditor hadn’t learned much or updated the scripts much since I automated them).

Scope of the Audit

The consulting firm was paid big money to do the following:

• Review all documentation.
• Review the process used to create, test, run, and update the scripts.
• Review all scripts in detail for errors.
• Recommend more efficient scripting and automation methods, if applicable.
• Run their own test files to validate that the scripts worked as described.

Read Part 2.

 

Advertisement