• PCAOB Inspectors Find IT Auditors on the Struggle Bus

    By | December 20, 2016

    In case you missed the news earlier this month, all of the PCAOB reports are out for the Big 4's 2015 cycle of inspections. What schadenfreude awaits us? Let’s take a look.

    Big picture — regarding overall deficiency rate — PwC is the winner this year. Even if PwC is only slightly ahead, the firm had 22% of the audits selected for inspection crop up with deficiencies compared to Deloitte (24%), EY (29%) and KPMG (38%). However, let’s refrain from patting PwC on the back because a big chunk of failures were serious enough for restatements. Although KPMG came in last again this year, we can still give the firm the “most improved” award from their abysmal showing last year.

    In recent history, the deficiency rates are neck and neck. The ranking from one year to another is somewhat arbitrary. After all, PCAOB examiners inspect only a sample of about 50 audits from each of these firms. I’m sure in some years a particular firm gets lucky and starts to pull ahead.

    It’s the meat and potatoes of the reports that prove more meaningful and, I’ll dare to say, more fun?

    Personally, I like to see how the IT audit teams stack up when it comes to deficiencies related to IT general controls (“ITGCs”). In sum, let’s just say there’s room for improvement.

    For example, PwC, EY, and KPMG all had deficiencies related to their IT control testing. Surprisingly, Deloitte walked away relatively unscathed in this match up. Nice job, Deloitte, we’ll give you some props for that. But, again, maybe you just got lucky.

    Although, this year Deloitte did have some issues with the accuracy and completeness of system generated reports, which fits in the IT testing bucket. We can all agree even if the report looks pretty, it may not be accurate or worthy of our precious billable time. It’s a good idea for someone to double-check if it’s legit. But hey, everyone struggles with that one, and it’s been a PCAOB favorite to call out for a while.

    As for the rest of them — it’s an interesting mix of issues:


    PwC screwed up testing compensating controls after determining an ITGC change management control was crap for Issuer J. Based on the report’s finding, I imagine that this is what happened (with a little poetic license, of course):

    1. Auditors decided the control that was in place to stop someone from tinkering with source code that processes revenue transactions (read: the computer’s instructions to handle revenue) didn’t meet muster. Exception noted.

    2. After the finding had surfaced, the IT audit staff was beaming with pride for finding such a juicy exception, the audit manager wanted to wring their necks, and the client felt sick.

    3. The auditors circled the wagons and scrambled to think of other controls — doing as little additional testing as possible — that supported the idea that even though someone at the company “could” change the code without going through the formal change process, it was unlikely that anyone did.

    4. Of the six compensating controls they came up with, four were so random that the PCAOB didn’t see how they even addressed the risk of unauthorized changes.

    5. The one pointed back to the original change management control (which was not working, remember). I’m sure they were hoping no one would notice the circular logic.

    6. The last one was just a nice idea. No one actually did any testing to verify that the control worked.

    The auditors also made the leap of faith that ITGCs would be clean and didn’t adjust sampling to beef up the application control testing. According to the report:

    The Firm tested an application control at an interim date using a sample of one item for each relevant scenario; this approach was based on an assumption that ITGCs were operating effectively, which was not supported due to the deficiencies in the testing of ITGCs that are described above. As a result, the Firm's testing of this control was insufficient.

    Come on, that’s just lazy.


    EY had a doozy called out for Issuer A. Apparently, EY failed to test ITGCs altogether for a handful of a client’s critical systems. In other words, the auditors blindly trusted these systems to spit out the numbers for revenue transactions. Sure, the client was complex, with multiple locations and lots of different systems for recording revenue, but it's not an excuse. I feel like that’s even more of a reason to do a good job.

    In addition to blindly trusting some of the client’s system, these same auditors of Issuer A blindly trusted internal audit too. Inspectors found that the team just attached the internal audit workpapers with deficiencies identified without any further testing to figure out what the deficiencies meant in the grand scheme of things. Another case of sheer laziness.

    Oh, and as an aside, EY also fell victim to the same finding that Deloitte ran into this year when they failed to test for the accuracy and completeness of reports.


    KPMG had two issuers with big ITGC findings. The first one, Issuer B, is a nasty audit deficiency. KPMG found a bunch of control deficiencies and then didn’t do enough additional work to make the risk go away. Instead, the firm basically ignored them (with bogus compensating controls) and issued a report without a significant deficiency or material weakness. The PCAOB said:

    Specifically, for each control either (1) the Firm failed to identify that the compensating control was not designed to prevent or detect unauthorized changes to these applications and data, as the compensating control was focused on the approval of planned changes to the systems' code or (2) the compensating control was also affected by the ITGC deficiencies.

    Another case of circular logic, it seems. See, PwC, you’re not alone.

    The next finding, this time for Issuer G, is related to administrator access, so it’s exciting. After all, I did say that companies better tighten up their access or they will hate themselves later. In this case, the client gave access to an application willy-nilly, and it resulted in a significant fraud risk. KPMG didn’t catch that some personnel got a little too much power and could manipulate data if they wanted to:

    The Firm failed to sufficiently test ITGCs over user access to the issuer's. Specifically, the Firm failed to evaluate the appropriateness of the access of certain personnel who had administrator-level access both to ALL applications and to databases supporting the ALL calculation, even though the Firm had identified this access when testing user-access controls.

    I’ll anxiously await the next cycle of inspections. Maybe we’ll see some improvement, maybe not. Let’s hope for under 20%? Can we dare to dream? In the meantime, auditors better dig deep with the ITGC testing, or at least try not to forget about them this year (coughEYcough).

    Image: Someecards

    • I got bored reading after the end of the EY paragraph. Why? Account transaction testing, unless the client presents it to you on a plate (after I hasten to add, you have picked the sample), is painful and takes an awful lot of time and effort, so I’m not surprised corners were cut. Anyway, you are supposed to rely on the work of IA if it’s any good.

      • Megan Lewczyk

        I agree that you can rely on IA if they are “any good” but you still can’t blow off reading the IA workpapers to see if there were any exceptions or other issues noted that may impact your testing (e.g., sample sizes) in other areas. I didn’t say the added work wasn’t painful to do…

        • To be honest Megan, I couldn’t care less. This is someone else’s problem, someone else’s cock up, someone’s else’s neck on the line. The only neck I care about is my own and if I am working with another Auditor, his or her’s insofar they are covering my arse as well, so when the ship goes go down, we can safely say it wasn’t our fault, nothing to do with me or us, etc.

    • “KPMG found a bunch of control deficiencies and then didn’t do enough additional work to make the risk go away”.

      Loose choice of words; presumably you mean audit risk as well as detection risk?

      But reading this article (albeit a quick read), the PCAOB seems to be blurring the line between systems audit and statutory audit. Sure, you may find that an employee has access to do naughty things on the accounting system but doesn’t necessarily mean that they’ve done so and the financial statements have material errors. This is all bread and butter stuff; the main issues seem to be poor training and over reliance on inexperienced junior staff to complete tasks.

      • Megan Lewczyk

        Actually, more specific. I was thinking the risk of unauthorized changes (discussed in the block quote). Of course, if the compensating controls couldn’t mitigate this specific change management (ITGC) risk, it would trickle up into the audit risk model. The overall control risk would be higher and I assume the audit team would need to do more substantive testing on revenue and accounts receivable to make up for it.

        • I was probably reading this article through an external audit lens rather than an advisory piece, so forgive me. After due consideration, I’m going to leave it there and you wish you and your husband a Happy Holiday and all the best for 2017.

          • Megan Lewczyk

            Haha! In public practice, I worked on the advisory and attestation side of the house — so yes, it’s written from a different perspective.

            • Megan Lewczyk

              Toning down the harshness, Audit Monkey? That’s a surprise. Well played. Happy holidays, too.

            • Well a quick Google search reveals you are involved with STEM Education so have contributed to your community and your husband is currently servicing or was in the USAF. No bigger commitment than serving your country and that deserves respect. Thank you for your best wishes.

            • Megan Lewczyk

              I appreciate that. 🙂

        • exEY

          In the past I’ve encountered similar issues, just like your example, where there was an ITGC issue around Chg Mgmt resulting from segregation of duty conflicts (e.g., some, but not all, data changes facilitated at the database level were not being logged) and your perspective intrigued me.

          Isn’t Audit Risk typically determined at the financial statement level for the organization as a whole? If you have 30 in-scope systems and one of these systems has a control design gap around the detection of unauthorized changes, does this really have a material impact to the overall Audit Risk? Or are you applying the Audit Risk equation to the individual system in your example?

          It seems each audit team and firm manage the risk of unauthorized changes, especially at the database level, differently. Some take an “absolute” assurance approach (e.g., database-level changes, not facilitated via the front-end, must be tracked and reviewed) or an “reasonableness” assurance approach (e.g., database-level access is restricted to authorized individuals and non-system account changes are monitored/reviewed).
          Personally, I’m in the camp all master/configuration/transactional data changes facilitated through the back-end database should be monitored or the control fails. However, I’ve found this is an unpopular approach because audit teams / management would be required to perform significant substantive procedures.

          What’s your view and how do you typically manage these scenarios? It seems nearly all the Big4 firms are struggling with this one.

    • Big4Veteran

      “I’m sure in some years a particular firm gets lucky…”

      This would describe every year that a client doesn’t blow up.

      P.S. Damn, this article was long. Who has to attention span to read this shit?

      • What do you expect from a Consultant in Advisory? You are paying for volume and volume is what you will get.

    • Adam Hill

      Maybe off subject a bit, but let me float an idea.

      If the auditor was allowed to perform a balance sheet audit, coupled with reasonableness testing for the income statement, what is the exposure outside of possible income statement classification?

      I got out before I received an answer that was adequate (right, wrong or indifferent).

      Point being that if you are locked down on the BOY and EOY balance sheets, everything else flows through the income statement or oci.