Four Methods for Consulting and Early Involvement-Your Toolkit

Now that we've established that it's okay to actually speak to your fellow employees about internal controls even when you're not auditing them, let's talk about some of the best ways to do this. We will discuss four methods for promoting internal controls at the company outside your formal audits:

• Early involvement

• Informal audits

• Knowledge sharing

• Self-assessments

Early Involvement

We've already discussed this a bit. The most cost-effective way to create internal controls is to build them in up front. Any manufacturing firm will tell you that it's cheaper to build quality into a product than to try to add it after the fact. Internal controls are the same way. Once you've created a system, tested it, and implemented it, it is much more expensive to go back and change it than if you have done it right the first time. Also, as an auditor, you're much more likely to run into resistance after implementation. Everyone has moved on to other projects, and none of them are motivated to go back and make changes to a completed project. On the other hand, if you can provide the internal control requirements early in the process, they become just another part of the project scope to the implementers, and they don't mind it so much (provided that the control requirements are reasonable).

If we can agree that building in controls up front is our most efficient and cost-effective method, let's talk about how to accomplish this. Unfortunately, it's going to differ by company. However, every company should have some sort of project approval or review process (if your company doesn't, you've got an issue right there that needs to be addressed). Try to shoehorn yourself into this process. Does the project review group have a weekly or monthly meeting? Try to get yourself invited to it. Even better, does the company have a group of people or an organization that has to sign off at various stages of a project before it can be implemented? Ask to be part of the sign-off group. Be bold about it. Forget about all that "independent auditor" stuff and be willing to actually sign your name to something and take some ownership in the company. Just make it clear that your role is to provide input on the internal controls of the system or technology and nothing else. Sure, there's a chance that you might mess up and sign off even though there's an internal control weakness in the system, but this is a chance you have to take. This is a risk we all take. All the other approvers are putting their names on the line, and you need to be willing to do the same, unless you are satisfied with the ivory tower model of audit departments that minimizes their value.

You may run into some resistance as you try to take on this additional role. The IT groups may not want you at their meetings, and they may not want to have to deal with you during project implementation. This is especially true if you're working for an audit department that has a history of adversarial relationships and/or hasn't been successful at displaying its value in the past. They may see you as someone to be avoided, not someone to be invited to the table as a participant. It may take some time, and your first step may need to be to begin the process of developing good relationships. However, given that the relationship is such that the IT groups will consider your request, be sure to let them know that your motive isn't to slow anything down or stop anything, but instead that you are expressing a willingness to step up to the plate and help them out. Your tone shouldn't be that you think they need your approval but that you'd like to be part of the solution, not part of the problem. Let them know that you might be auditing them someday and that you want to help them build their system so that it will pass an audit when the time comes. Point out that the company pays you to be an expert on internal controls and that you would like to share that expertise with them during their project implementation so that you can help them to build the controls in up front.

Again, this may take time, and you may need to be persistent, but the end result is worth it.

Note 

Nowhere can you add more value to the company than by early involvement.

Early involvement is infinitely more cost-effective and efficient than after-the-fact audits. If you can work your way into being involved in projects before implementation, and if you can prove the value of your involvement, you will find yourself getting more requests than you ever imagined. It will be tempting to turn down some projects, saying that they're not important enough or don't have any internal control impact, but that would be a mistake. You don't want to chase away people who are looking to be educated on internal controls. If you are successful at your attempts to be invited to the table, you will need to dedicate appropriate resources to make it work.

So what does it really mean to be involved in projects early? Does it mean that you have to perform a full audit on each and every project? Not at all. This obviously would be impossible from a resource standpoint. Many auditors are confused by what they need to do when asked to provide input on a project. It seems like a daunting task, and it is important to simplify it. From a conceptual standpoint, it's no different from planning a traditional audit. When you're getting ready to execute an audit, what do you do? You spend time understanding the system, technology, or process that you'll be auditing. You then think through the risks involved with it and determine what sorts of controls you expect to see in order to mitigate those risks.

This is exactly what you do with early involvement. It's just like planning an audit. You need to spend time understanding the system, technology, or process being implemented. You need to think through the potential risks involved with it that might affect its security, integrity, or reliability. You then can provide input to the teams regarding what controls you would be looking for if you were auditing it after the fact. Basically, you're planning the audit and sharing the key points of your audit plan with the auditee as the system is being developed (Note: The chapters in Part II of this book will serve as an excellent guide in performing this planning). From your standpoint, you are sharing your audit plan. From their standpoint, you are giving them a set of internal control requirements. If this is all you can do, you've already provided an excellent service. However, if you're in a position to get the project team to confirm with you how it has implemented those control requirements so that you can ensure the controls appropriately mitigate the risks, then you've really arrived.

Is the auditor required actually to perform independent testing and validation to ensure that the controls are working as described? In other words, does the auditor really have to perform an audit of the system before implementation in order to be willing to sign off on it? This certainly would be nice and is probably a good idea for major enterprise application implementations and things of that magnitude, but it is not realistic from a resource standpoint to do this for every project that comes along. It is perfectly acceptable to make it clear to all that your sign-off is based on the assumption that the information that you've been given is accurate. If you audit the system later and it turns out that the controls weren't implemented as described, it's not a failure on your part.

It is also important to understand that not all of these early involvement opportunities will be time-consuming. Some projects have a significant internal control impact. For example, implementation of new tools that provide the ability for external business partners to access the internal network needs to be scrutinized heavily and will take some time. On the other hand, implementation of a new conference room scheduling system has almost no internal control impact and should be dispositioned by the auditor quickly. This does not mean that the auditor declines to get involved by saying that internal controls are not applicable to the system. What it does mean is that the auditor can provide some high-level guidance and be done with the project for all intents and purposes. There's a big difference image-wise between saying that a system doesn't matter to you and saying that you want to provide sign-off as usual but that you don't have many concerns. One is a negative message, and the other is positive.

Note 

Remember that for every project you're involved with, no matter how insignificant it is from an audit standpoint, you have a unique opportunity to educate your fellow employees on internal controls and their importance.

Informal Audits

One of the issues facing almost every department in almost every company is resource constraints. There's never enough time to do all the things you wish. For audit departments, there are always risks out there that we don't have time to address. There are always requests for audits that we can't fulfill. If our audits are to be thorough, we'll have time to audit only a handful of areas every year. In fact, if your audit scheduling process is purely risk-based (as opposed to having everything on a set rotation), there are some areas that will never make the cut. You'll likely never go to the audit committee and tell it that one of the top 15 risks that you need to review for the year is a tiny data center in a remote location supporting a small handful of people performing a less-than-critical business process. But does this mean that we should never work with those employees to help them understand the state of their internal controls? Does this mean that we should never understand what the risks at that site are? There has to be some way to perform reviews of such areas without turning them into unnecessarily large efforts. The informal audit is the mechanism to use.

In Chapter 2 we'll discuss potential processes for forming your audit plan. For now, let's take it as a given that you have some sort of risk evaluation process that helps you to form your audit plan each year. The problem is that there are two major gaps in what you'll be able to cover:

• As mentioned earlier, if the process is risk-based, there are some areas that you'll never get to.

• There are times when management requests an audit (once you've developed the right sort of relationship with them), but that audit just doesn't make the cut once you perform a risk ranking.

It is important that formal audits be performed in a disciplined and thorough manner. We will discuss the audit process in Chapter 2, but for now, let's just accept the fact that, to do them right, they need to be thoroughly documented and tested, including taking representative samples of data before making conclusions. Although all this is important and necessary, it is also time-consuming. But what if you had the flexibility to perform some audits in a more on-the-fly manner? If you've built a strong IT audit team, with good depth of knowledge and experience, you should be able to let them loose to perform a "quick and dirty" review of a system, site, or technology. Remove the constraints of documenting their work in detailed work papers. Forget about taking large representative samples. Let the auditors act as consultants. Give an auditor a couple of weeks to review the controls of the area, and tell him or her that all he or she needs to produce at the end of the project is a memo summarizing the results. You'll be amazed both at the quality of the results and the appreciation shown by the people you audited. You'll also be amazed at how much the auditors are able to accomplish in a short time when released from the shackles of the normal audit process (which are important for formal audits and, again, will be discussed in Chapter 2).

Of course, it's also important to put caveats on the work and the results. Make sure that the people you are informally auditing understand that this will not be as thorough as a formal audit, that you are not claiming that you will find all the issues, and that you are not testing statistical samples. Even though auditors like to shy away from the word consultant, you should make it clear that this is exactly what you are in this case. You are loaning them your control expertise. If you are of a particularly paranoid nature, you might even want to state these caveats in your final memo so that the review doesn't come back to haunt you later if more issues are found.

A common question with these sorts of informal reviews is whether the auditors are required to track the issues to completion. There is no right answer to this question, but in general, "No" is the best answer. This is an informal audit, and the issues have not been substantiated as thoroughly as in a formal audit. Therefore, you are on a little shakier ground when it comes to turning around and requiring that the issues you raised be fixed. Also, since this was an area that wasn't risky enough to make the formal audit plan, it's likely that the risks are relatively minor from a company perspective. Forcing and tracking their mitigation may be unnecessary overhead. Also, it may make others less likely to request your services in the future. If they invite you in as a consultant and then you turn around and beat them up and tell them they need to fix all the issues or be reported to the audit committee, they're highly unlikely to ask for your help again.

But what if you uncover a major issue that is creating a significant risk for the company? Clearly, in such a case, you have an obligation to make the appropriate level of management aware of the issue and ensure that the risks are mitigated. Therefore, a happy medium for these engagements is to tell the people you're auditing that you don't intend to track the issues coming out of the review but that if you find a major issue, you'll have to make an exception. Most people will be understanding and accepting of this obligation.

What does the audit process look like for an informal audit? It should be simple and straightforward, consisting of the following basic steps:

1. The audit department should agree on the timing and scope of the informal review with the people they will be auditing.

2. The auditor who will be performing the review should make a basic checklist of areas he or she plans to review during the project (the checklists throughout this book provide a good starting point).

3. The auditor executes those steps, keeping notes as needed but not creating work papers for review. The notes do not need to be kept once the audit is completed. Remember, speed is of the essence, and this is a consulting engagement, not a formal audit review. If you can't get comfortable with this, you'll bog yourself down with documentation and process, losing the flexibility to perform this sort of review effectively.

4. At the end of the project, the auditor compiles all concerns from his or her review.

5. The auditor has a debriefing meeting with the people he or she has been auditing to discuss the issues and consult on how serious the issues are and potential means for addressing them.

6. The auditor documents the final list of concerns, along with relevant thoughts on resolving them, in a memo. This memo does not need to include due dates and can include the caveats mentioned earlier (this is not a formal audit, we will not be tracking issues, etc.). The memo also should indicate the auditor's willingness to continue consulting with the team as it addresses these items.

7. The auditor issues the memo and archives it electronically for future reference.

This list of steps may seem overly simplistic, and this is intentional. You need to avoid overengineering the process. The idea is that you're the department with internal control expertise, and you're consulting with other departments in this regard. Send knowledgeable, experienced auditors in, and let them "do their thing." Informal consulting engagements are another tool in your toolkit that you can use to promote internal controls at your company. They are yet another way that you can add value to your company.

Note 

You have the internal control expertise, and you need to use it in every way imaginable. Informal audits are a way for you to do a lot quickly. They greatly increase your coverage of the company's risks and your ability to accomplish your mission of promoting internal controls.

Knowledge Sharing

As internal auditors, you have a unique blend of knowledge of the company and expertise in internal controls. As we have established, the true mission of an internal audit department is to help the company improve the state of its internal controls. In order to do this, it is vital that the internal audit department be creative in finding new ways to share its unique knowledge with the rest of the company. Of course, much of the knowledge sharing should occur as you perform audits, as you perform consulting reviews, and as you provide input as part of your early involvement activities. However, this still leaves some gaps. In this section we'll discuss how to close some of the remaining gaps.

One of the easiest communication vehicles should be the company's intranet. The internal audit department should have its own website. Unfortunately, for many companies, this website simply contains the audit department's organization chart, a description of its mission and processes, and its audit schedule. While these are certainly useful elements of the website, they don't realize the site's potential as a vehicle for communication. Listed below are three key opportunities for obtaining additional value from the audit department's website.

1 Control Guidelines

As you prepare for audits, one of the most frequent questions you'll receive is, "What do you people look for?" Wouldn't it be nice if you could just tell them to go to your website for the answer? Obviously, for some one-time audits, where you've never reviewed the area before and it will be years before you review it again, this wouldn't be practical. For common technologies and topics, though, it can be extremely helpful to provide control guidelines describing the sorts of things that you usually review during audits. The areas covered in Part II of this book are good candidates for this sort of thing. Why not let people know what sorts of things you look for when auditing Unix? Why not let them know the basic sorts of controls you look for when auditing an application? Not only will this help people prepare for your audits, but it also will provide excellent information for anyone else at the company who may be interested but whom you have no plans to audit. If you have checklists of things you look for in an audit, it's trivial to turn those checklists into control guidelines that can be used throughout the company. For example, perhaps you have a Unix test step that says, "Ensure that a shadow password file is used to prevent users from viewing the encrypted passwords." The control guideline could say, "A shadow password file should be used to prevent users from viewing the encrypted passwords." It is as easy as this. Turn your audit programs into control guidelines, stick them on your website, and you've helped reach your goal of open communication and promotion of controls.

Note 

Posting control guidelines on your website empowers groups expecting an audit. Some groups actually will spend time up front finding weaknesses and implementing appropriate controls. This effort benefits the company and the group being audited.

2 Common Issues, Best Practices, and Innovative Solutions

Auditors are in a unique position in that they are able to review the processes and technologies that exist all across the company, giving them the ability to note trends and to compare and contrast various organizations. Unfortunately, they rarely take time to consider how the results of an audit might be useful to other similar organizations at the company. Now, there are many audits where the results are not applicable to any other organization. On the other hand, in most companies, there are some functions that are performed by multiple decentralized organizations. For example, perhaps Unix administration is performed at each company site by the site IT folks. In such a case, the results of a Unix security audit at one site could be very useful if shared with the Unix administrators at all other sites. These results could help them to analyze their own controls to ensure that they don't have the same problems. This is a way that your one audit can have an impact on other organizations months or years before you actually get around to auditing them. It's usually not healthy to air an organization's "dirty laundry" unnecessarily, but results usually can be "sanitized" so that they do not directly indicate the organization that was audited. Even better, if an area such as Unix security is going to be audited at multiple sites, wait until you have three or four of the audits under your belt, and then compile the results to determine what issues are surfacing commonly. This can be the basis of a common issues communication sent to all personnel with similar responsibilities. This sort of message should be communicated both on the website and also as an e-mail that is sent to all relevant personnel. This provides both a push and a pull delivery mechanism for your message.

Use the auditor's company-wide perspective to compile best practices and innovative solutions from past audits. As you perform your audits, you sometimes will see that a group has implemented a control particularly well. Or you might find instances where a group has developed an innovative solution for an issue found commonly in other sites or groups. This information also should be compiled and shared via the website and e-mail. This will help others to improve their controls and resolve issues that they may have in their own environments.

3 Tools

Do you have audit tools that you use in performing your audits? Why not make those tools available to the rest of the company so that people can assess themselves if desired? For example, if you use a vulnerability scanning tool for reviewing the security of various devices at the company, consider making that tool available via your website, along with some basic "how to" documentation. Of course, licensing issues must be taken into consideration, but it's something worth investigating. Again, this is another way that you can promote internal controls, allowing people to assess themselves. If you're using open-source tools, consider providing links to the websites where those tools can be retrieved. It's all part of sharing your knowledge and expertise.

Note 

Sharing the tools auditors use with others enables groups to self-assess their controls. This is an excellent enabler, but it is important that you carefully package the tools inside strong policy stating who can use the tools, on what systems, at what times, and with whose permission. Other things to consider are controlled areas of the website open only to the IT organization and how to regulate the use of hacking tools such as password crackers and spoofing utilities. Inappropriate use of these tools can compromise personal information or violate the integrity of critical data.

Also, as mentioned in the immediately preceding section, you may know of instances where a group has developed an innovative solution to a common problem. If the solution involved developing a tool, ask the group if you can have a copy and post it on your website for others to use. For example, if a group has developed a script to enforce password aging in a Unix NIS (Network Information Service) environment, get a copy of it and place it on your website. In this way, other organizations running NIS can get it and improve their control environments too.

If you use the website for this purpose, it will be important to place a caveat on your site stating that you don't support the tools. You don't want to get in a position where people are calling you at all hours expecting you to help them debug the tools. Of course, you should be willing to help where you're able, but you don't want to set an expectation that turns you into a software support organization. Also, you should check with your IT security organization prior to making these tools available on your website to ensure that distribution and use outside the IT security and IT audit teams is not a violation of policy. Finally, you should include a disclaimer stating that there are no guarantees regarding the compatibility of the tools with any specific system and suggesting that they first be executed in a test environment. There is always the risk that a tool will interact oddly with "buggy" software, and you don't want to be held responsible should something unfortunate occur.

Self-Assessments

Another concept for promoting controls outside a formal audit is the self-assessment. Entire books have been written on this concept, and it is up to each audit department to determine whether it wants to formally implement a control self-assessment (CSA) model. We will not get into the details of this process here. However, conceptually, facilitating an organization in assessing itself is another potential tool for your toolkit. This could be as simple as walking through your control guidelines (described earlier in this chapter) and asking the organization whether or not it has implemented each control. This can lead to healthy dialogue around the purpose of each control and what level of mitigation is truly necessary. Earlier in this chapter we described the informal audit, which is something less than a formal audit but provides an organization with good input on the state of their internal controls. The self-assessment exercise is something less than an informal audit, in that it provides absolutely no independent validation of the controls in the environment, but it also can be a useful vehicle for promoting controls. Once again, a knowledgeable and experienced auditor is critical for making this tool work.

Consulting and Early-Involvement Toolkit-Final Thoughts

As can be seen, there are many methods of reviewing and promoting internal controls at a company besides formal audits. Of course, one of your barriers will be getting company management and the audit committee to approve use of your resources in this way. They may be resistant to using resources for anything except formal audits. Your best ammunition is to get the focus away from counting how many audit reports are issued and toward looking at how the department is helping to improve internal controls at the company. If you convince them to let you try it, even on a test basis, the results will speak for themselves.

Note 

If the audit department focuses solely on formal audits, it severely limits its coverage and ability to fulfill its mission successfully.