Not everyone should be an Internal Auditor

Sometimes Internal Auditors shouldn’t be Internal Auditors. Sometimes the role can be, no matter how much effort is expended to avoid this, confrontational or with the potential for conflict with the auditee (and others). This is particularly the case when there are strong personalities on the ‘other side’ of the audit process. I ran into exactly such a situation, as I’m sure have most of us. Remember, however, that just because someone is not appropriate for Internal Audit that does not mean that they may not have a lot to contribute to the business.

A number of years ago, I was engaged by a bank to perform a number of IT Audits. The bank had a full Internal Audit function but only three IT Auditors. The audit programme, however, included too many audits to be completed by the team that was available (for various reasons, only one of which was to too much work for the available resources).

After cutting my teeth on a couple of simple reviews, the Audit Director asked me to take a look at the implementation and use of the Project Management Methodology in a couple of the major projects that were in-flight at the time. These were significant projects, being run by and for different parts of the bank. Each had external project managers, and each seemed to be running to time, budget and promised deliverables. There were no particular reasons to worry about the projects.

Enter Bob (not his real name), a somewhat meek Internal Auditor, who chanced into IT Audit from a role as a bank branch auditor. I had worked with Bob before at another institution, and knew some of his strengths and weaknesses.  The Internal Audit Director said to me “I’d like Bob to work with you on this audit”. Really? Well, okay. “It will be good for him. He’ll learn something, and hopefully will become a better auditor.” He saw the horror in my face.

“I really need you to do this, but let me know how it goes”.

So the audit began. Each project provided all the requested information, and both were open allowing interviews with key project personnel and the projection managers. The project sponsors were comfortable the progress, and the user communities were looking forward to the new systems and processes, even though these were months away.

The projects were running smoothly, and the audit did not find any unreasonable budget to actual variations, or undue and unexpected slippages in estimated deliver dates, resource requirements, etc. Risks were documented (inadequately, but there was some consideration of risks). Of course, the primary purpose was to confirm the implementation and use of the corporate-mandated project management methodology.

While everything is going smoothly, a finding that process is not being followed can be a difficult finding to make and defend, especially when the processes will add effort and probably increase the resources and costs required to accomplish the project or set of tasks.

Add to that the personality trait of many good project managers – a straightforward manner and an air of confidence that can be used to ‘encourage’ focus on goals. They are confident, and they exude confidence, and that is one of the ways that they provide comfort to stakeholders, encourage teams, and deflect or reduce potential conflict or disagreement. This sometimes can manifest itself as arrogance and bullying.

And we faced two of these individuals. They had the backing of their respective General Managers, they were confident, they were delivering, and they really didn’t need Internal Audit second-guessing how they were going about achieving their missions.

I sent Bob to carry out some interviews, collect documentation, read it and summarise his thoughts. We talked through what he was seeing. We combined our work and work papers, and we arrived at our conclusions. We wrote up the draft report, and prepared for the exit-interviews with the two Project Managers. 

As the fieldwork progressed, Bob became more and more agitated, and at times seemed distracted. Finally, with the fieldwork completed and the draft report ready, we scheduled the exit interviews. Twice.

Then a third time, with each of the other two being cancelled and rescheduled.

Finally, the day arrived. I arrived in Internal Audit, and seeing Bob, said “Fantastic, today is the day. They’ve not cancelled or postponed. We’re ready.”

I looked closely at Bob. “Are you alright? You look tired.”

“I haven’t slept all week, I’ve been so worried about this meeting” was his response. Worried? Why? All our ducks were in a row, all the documentation was completed, the draft report was written, the findings reviewed, and the key points ready. All that was needed now was a conversation with the PMs, and to give them an opportunity to take the draft back with them and write up their comments, responses and action plans.

Focusing on the coming meeting, I put his comment away in the back of my mind, something for later.

We had our exit meeting. We outlined the audit, the fieldwork performed and the data and information reviewed. We presented our findings. The PMs read the Executive Summary, looked at each other, and after a few questions said “You’re right, we use our own methodologies. They are not the corporate-approved methodology. We will talk to our teams about how we will implement and use the standard methodology. We will need to train our people, and we might need some training also.”

Done. 

Yes. It was that ‘easy’. The data was there, the documentation was there, and we did not attack their methodologies or pick holes in what they were doing. We were not auditing the effectiveness of their personal leadership, and we were not questioning the performance of the projects (although we did look at status reporting, steering committee reporting, budgets to actuals, etc). We had a specific scope and we audited to that scope, cognisant that other issues may come up.

What I didn’t expect was that the primary finding of serious concern was that one of the auditors was not able to perform the audit. Having worked with Bob in the past, it all came together then. He simply was not capable of assertive support of any position. His default in any potential conflict was not to address the issue, but to seek someone who could deal with it on his behalf.

When all was done and the report was issued, I stopped by the Audit Directors office. I told him what had happened, and said I was deeply worried about Bob, his mental state and his fitness to be and Internal Auditor. Furthermore, there was the very real potential that Bob would bring Internal Audit into ‘disrepute’ within the bank by not being adequately assertive or able, when pushed, to deal with highly assertive individuals. In the worst case, such an auditor might miss a critical control and technical issue, or fail to push for acceptance and resolution of a critical weakness, potentially endangering the bank itself. The IA Director knew we had worked together in the past, in fact, all three of us has been at another bank at the same time in the past. He “inherited” Bob when we took over IA in this bank. He knew what he had, but there was little he could do directly.

We talked, and eventually, I said “You have to get him out of Internal Audit. He will have a nervous breakdown, or worse. This is not the right job for him.” The IA Director agreed and asked for my suggestion. My view was that Bob had a solid knowledge of retail banking, adequate IT knowledge, and understood both the bank and the banking sector. Firing him would only compound Bob’s issues and would be wasting an otherwise perfectly decent person and skill-set. “Find him another job in the bank. For you and for him”.

Checking in with the IA Director a couple of years later, I asked what was the final outcome with Bob. The news was all good. Bob was encouraged to apply for, and was appointed to, a role in the Retail Product Development team, and was to all reports thriving. Conflict was not an issue, because he was supporting product developers who were, by nature, positive and had the support of the executives. His knowledge of the bank and banking products served him well.

Most of all, a ‘wrong fit’ was rectified, and IA was seen as a potential source of good quality people for the business, and not tarnished as the home of people who were not able to provide the challenge actually needed in healthy organisations.

What are the attributes of a good Internal Auditor? There is a long list. Near the top of any list must be confidence in the correctness of the principles that the auditor is espousing; of effective control, process effectiveness, risk identification and assessment, and confirmation by the auditee of the findings and potential impact. Meekness is not a desirable attribute.

  

In search of a seamless relationship between Operational Management, Risk Management and Internal Audit.

I continue to be amazed by the too frequent disconnect between Internal Audit, Risk Management, and Operational Management. The artificial, though regulator sanctified, “second line” and “third line” functions are too often used to justify two (complementary) functions seeking complete independence from each other, independence that can undermine the effective identification and management of risks.

Operational Management (OM) is responsible for delivering the objectives of the organisation, and specifically the objectives of their function(s). Risk Management (RM) provides support to OM by providing the framework for identifying and helping OM determine and implement the most appropriate management strategies to cover the risks to the accomplishment of the objectives. Internal Audit (IA), by focusing limited resources on the areas of highest risk, confirms that key controls are in place and that they are functioning effectively to ensure that risks to the achievement of objectives are managed within the risk appetite of the business.

Within that previous paragraph, there are a number of important words and concepts, too frequently considered separately, when they should be viewed as part of a seamless set of processes and responsibilities. Sadly too often the three are not seen as part of that seamless delivery, with the second two being detached from OM and from each other.

Operational Management is responsible for delivery of results, and as such is provided with resources (budget) that are almost always limited in relation to the provision of any “extras”. Managers face annual budget challenges, and not infrequently are asked to make “savings”. Sometimes this can (sacrilege) include reducing headcount or increasing the level of output expected without increasing resources. Frequently it is the control environment that suffers when this happens. 

Risk Management can help OM to identify and consider the risks that they face, and can assist OM in identifying the controls that would be needed to manage the risks to the level acceptable within the business’s risk appetite. It remains, however, OM’s responsibility to implement the controls and to ensure the controls are functioning. RM can, and should, provide ongoing monitoring at an observation level of the risks and controls across the business.

(There is, of course, also the critical role that RM plays in the identification and mitigation of Emerging Risks and External Risks, but for our purposes here, we are looking only at the internal relationships and management of risks.)

RM confirms with OM that the control environment is functioning, as confirmed by OM and reviewed selectively by RM. The assessment of the current status of any risk is the responsibility of OM who own the risk and who is responsible for managing the risk. RM can suggest alternative views on the effectiveness of the management or the risks, both to OM and to senior management and the Board, but ultimately OM is responsible for the risks and controls. Furthermore, OM is responsible for determining how the provided resources will be applied for the achievement of objectives.

In this the assessment of the effectiveness of the control environment if firstly the responsibility of OM, and unless there is a fundamental disagreement with RM, it is OM's prerogative as to how resources should be applied. This includes the development and implementation of controls. While RM (and IA) can recommend, as it is OM that ultimately carries the responsibility, it is OM's decision. Escalation is appropriate only when there is a fundamental disagreement between RM (and IA) and OM.

Of course, it is appropriate that the Board be provided with additional comfort that the control environment is effective. Sadly the conflicting priorities of OM can lead to misreporting or inaccurate reporting of the effectiveness of the control environment. Likewise, limited RM resources can provide a general level of comfort that risks are identified, and that controls appropriate to the risk appetite have been implemented. 

This means that, while RM can and does support the implementation and operation of a framework for identifying and managing risks, it may be outside RM's resources to perform "deep-dives" into all areas of risk.

I am reminded of a bank that told their regulator that they treated all customers as "high risk" customers for due diligence purposed. The regulator's response was that if all customers were "high risk", then no customers were, and the real "high risk" customers would slip past the due diligence process. The bank was required to segment its customers and implement a higher level of due diligence than they had been performing.

IA’s role is to fill the gaps and to provide additional assurance that key controls in high-risk areas are functioning as per asserted by OM and that such controls are functioning with the risk appetite. So, IA’s role is the provision a “deep-dive” assessments of high-risk areas, to ensure that the key risks have been identified, that appropriate responses have been considered and agreed, and that controls have been put in place that brings management of the risks within risk appetite.

To summarise then:

1. OM is responsible for delivering business objectives,
2. OM applies limited resources to accomplish this,
3. RM assists OM in identifying and assessing risks to the accomplishment of objectives,
4. OM provides RM (and others) with regular reporting to confirm that objectives will be achieved within the acceptable risk appetite,
5. RM confirms that risk across the enterprise is being managed within risk appetite, as reported by OM and as reviewed by RM,
6. IA provides detailed “deep dive” assessments of the effectiveness of controls in the highest risk areas of the business, or where there may be limited confidence that risks are being managed within risk appetite,
7. OM, RM and IA jointly provide assurance to the Board that there can be a reasonable expectation that business objectives will be accomplished with risk appetite.

A quick word about risk appetite: the risk appetite of the enterprise is set by the Board (with the assistance of senior management and RM) and it is the responsibility of OM to deliver objectives within that risk appetite. 

This means that RM should continuously confirm that OM understands the risk appetite as it applies to their areas and objectives, and should confirm that there is an effective control environment commensurate with the level of risk and the enterprise’s risk appetite. OM does not set the risk appetite; neither does RM or IA.

Being practical, this influences the reporting to the Board on risk and the effectiveness of the system of internal controls. Some practical suggestions that come from this:

1. All IA findings should include discussion of the risks that have been identified,
2. There is an IA finding only if the control environment is failing (or is expected to fail) to manage identified risks within risk appetite,
3. All actions agreed by OM should be reflected against the risks as recorded and managed through the risk register,
4. All IA findings and actions should be recorded against their associated risks, or new risks should be added to the risk register where there is no corresponding risk,
5. OM and RM then need to update their review processes to ensure that the identified risk and mitigation is actually functioning.
6. Where IA has requested confirmation of the implementation of new or updated controls, this should be provided.
7. Annual review and approval of the updated risk appetite should then drive a review by OM and RM of the risk and control environment and will inform the IA review cycle by potentially changing the perceived highest risk areas.

These steps will lead to a more seamless integration of OM, RM and IA, and will improve both relationships at the operational level, and provider greater confidence to the Board that the control environment if well established, operating and being effectively monitored. 

IT Audit - sometimes you need to escalate

A common facet of contracts is a true-up clause that pushes a disagreement on price or capacity into the future, with actual usage or consumption to be calculated at a future date or time. Think of the classic French Bistro (in the outback of France, no in a London or New York suburb), and the bottle of house red that is automatically delivered to your table. Or the bottle of whiskey in the officers mess in the Indian Raj, with the line drawn on the bottle. When the meal is finished, or the drinking is done, a new line is drawn, and you are charged for the difference - the amount consumed.

There is no contract that requires you to consume the entire bottle(s), or a guarantee that you will only drink three-quarters. The contract is settled at a later time. The core of this contract is that all can clearly see what was consumed, and there can be little dispute as the actual quantities and therefore the final bill.

I have seen computer systems contracts with just that type of resolution built into the contract. 

Many years ago, I was asked to look at a contract that had such a true-up clause in it. The computer vendor had estimated that a certain level of computing power (mainframes) would be required, while the client estimated a lower amount would be required. In the days before on-demand cloud infrastructure, computing power came in "boxes" of defined "MIPS"(Millions of Instructions per Second - a quaint concept to us today). You got the whole box, or no box. The vendor believed that a certain number of "boxes" would be needed, while the client thought otherwise.

The system was of too much importance however, to allow for the implementation of inadequate computing power, and so both partied agreed to install enough to ensure smooth functioning. The vendor was adamant that their estimates were right, so insisted that the total amount of processing power be installed.

Through the negotiations, a final difference of $18 million was arrived at, out of a total contract value of approximately $80 million. The parties agreed then, as is not uncommon, to split the difference three ways.

1. The client agreed to pay $6 million.
2. The vendor agreed to discount $6 million.
3. The parties agreed to review system usage at the end a year, and split the remaining $6 million based on the actual usage.

Makes perfect sense, if the actual usage can be measured and recorded, and if monitoring and system optimisation are in place on the client side. Like the line on the bottle, the utilisation level could be measured and a line drawn across the capacity of the systems.

Unfortunately, the client failed to put in place the monitoring. As a former mainframe systems capacity planner, I knew what monitoring would be required, and I knew exactly how the vendor would demonstrate that the application actually did require the full amount of computing capacity that was originally estimated. I had, in fact, worked for that vendor.

As the IT Auditor, I recommended that the monitoring should be put in place, and provided guidance on what and how to perform that monitoring. I also recommended that such monitoring should be performed on an ongoing basis, so that management could track how much of the $6 million they would "owe" at any given month-end, so that system optimisation could be performed. 

Nothing happened.

Again, in three months, I recommended that the monitoring be put in place. Again nothing was done. All the while the clock was ticking down to the performance date, and it was looking like the $6 million would be owed to the vendor.

Having received no response from the CIO, and in fact, having been told by the CIO that Internal Audit really didn't know what it was talking about, that Internal Audit knew nothing about IT, and that IT auditors were a particularly incompetent bunch, we felt there was no option but to escalate. A one-page memo was prepared and sent to the CEO (the same CEO who sent a two-page memo to all managers telling them that all correspondence to him should be in one-page memo form) outlining quickly the situation, and the (lack of) response from the CIO.

The result: After an independent review of IS's work lasting all of one day, the CIO was fired, and new negotiations were opened with the vendor, and a pre-emptive agreement was reached that saw the client pay the vendor $3 million. The vendor forgave the other $3 million.

Ultimately all agreed that they would not be able to draw a line on the bottle that each party would agree to, so it would have been almost impossible to agree exactly how much had been consumed.

But failure to implement basic monitoring and management cost the company $3 million that they should not have needed to pay.