The Stages of an Audit

Now that we understand the process of selecting what to audit, let's discuss the various stages for performing each of the audits in the audit plan. We will divide our audits into six major phases (Figure 2-3):

Figure 2-3: Audit process overview.

• Planning

• Fieldwork and documentation

• Issue discovery and validation

• Solution development

• Report drafting and issuance

• Issue tracking

Over the next few pages we will discuss how to perform each of these stages most effectively. However, as already mentioned twice in this chapter, we do not intend for this to be an Auditing 101 course, so we will not exhaust these topics. Instead, we will focus on key points that will then allow us to move on to the meat of our book.

Planning

Before beginning work on any audit, it is obviously important to determine what you plan to review (Figure 2-4). If this planning process is executed effectively, it will set the audit team up for success. Conversely, if it is performed poorly, then the audit team will be set up for failure, beginning work without a plan and without clear direction.

Figure 2-4: Audit process overview-planning stage.

The goal of the planning process is to determine the objectives and scope of the audit. You need to determine just what it is you're trying to accomplish with the review. As part of this process, you should develop a set of steps that need to be executed in order to accomplish the audit's objectives. This planning process will require careful research, thought, and consideration for each audit; however, following are some basic sources that should be referenced as part of each audit's planning process:

• Hand-off from the audit manager

• Preliminary survey

• Customer requests

• Standard checklists

• Research

Hand-off from the Audit Manager If the audit is in the audit plan, there must be some reason. The audit manager should relay to the audit team the information that led to the audit being scheduled. This might include comments from IT management and/or known concerns in the area. The factors that led to the audit being scheduled need to be encompassed in the audit plan. In addition, the audit manager should be able to provide the audit team with the key contacts for the audit.

Preliminary Survey The audit team should spend some time before each audit performing a preliminary survey of the area to be audited in order to understand just what it is they're getting into. This likely will include interviews with the audit customers to understand the function of the system or processes being reviewed, as well as review of any pertinent documentation. The goal is to obtain a basic background and understanding of the area to be reviewed. This will be needed to perform the preliminary assessment of risks in the area.

Customer Requests In Chapter 1 we discussed the importance of making the audit a collaborative, cooperative process. As part of accomplishing this goal, the audit customers should feel that they have some ownership in the audit. The audit team should not just come in and say, "This is what we're reviewing," and leave it at that. Instead, the team should ask the customers what areas they think should be reviewed and what areas they have concerns with. This input then should be meshed with the results of the auditors' objective risk assessment to determine the scope of the audit. Of course, there will be times when the auditors don't use the customers' input. For example, sometimes the audit customers will be concerned about areas that are more operational in nature and have no internal control impact. In those cases, it is perfectly legitimate for the audit team to scope those areas out, with an explanation to the customer as to why the audit team is not positioned to execute that request. It is also important not to allow the customer to steer the auditors away from reviewing important areas. The auditors still ultimately have to apply their judgment. However, obtaining the customers' input and incorporating it into the audit plan where possible will give the customers a feeling of ownership in the audit project and increase the chances of there being open and honest communication.

Standard Checklists Often there are already standard audit checklists for the area being reviewed. The checklists in Part II of this book can be an excellent starting point for many audits. In addition, the audit department might have its own checklists for systems and processes that are standard at the company. Having standard, repeat-able audit checklists for common areas can provide a very useful head start for many audits. However, those checklists still should be evaluated and altered as necessary for each specific audit. Having a standard checklist does not remove the requirement for the auditor to perform risk assessment prior to each audit.

Research Finally, the Internet, books, and training materials should be referenced and used as appropriate for each audit in order to obtain additional information about the area being audited.

Once these resources have been referenced, the auditor must perform an assessment of the risks in the area being reviewed in order to identify the steps that must be accomplished during the audit. This concept is illustrated in the "Internal Controls" section earlier in this chapter. As mentioned there, the auditor must understand the business purpose of what he or she is auditing, think through the risks to that purpose being accomplished, and then identify any existing internal controls that mitigate those risks. If it's a process being reviewed, then the auditor needs to lay out that process end to end and think about where it could break down. If it's a system or technology being reviewed, then the auditor needs to think through the risks to that system or technology functioning as intended.

The result of the preceding exercise, as mentioned, should be a determination of the scope of the audit, including specifically determining and communicating what is out of scope and compiling a list of steps to be performed in order to accomplish that scope.

Toward the end of the planning process, it is important to hold some sort of kick-off meeting with the audit customers so that you can communicate what is in and out of scope for the audit project and also receive their final input. During this meeting, you should continue to be open to the customers' input and flexible regarding making changes to the audit scope. Again, if the customers feel ownership in the audit, they are much more likely to be open when working with the auditors. The kick-off meeting is also a great time to solicit primary points of contact for each audit step and to determine a schedule and methodology (e.g., meetings, e-mails) for keeping the customers informed as to the audit's status.

Once the kick-off meeting is completed, the audit's steps should be split up among the audit team members, and the next stage of the audit can begin.

Fieldwork and Documentation

The bulk of the audit occurs during this phase. This is the point in the process where the audit steps created during the preceding stage are executed by the audit team. During this stage, the team is acquiring data and performing interviews that will help team members to analyze the potential risks and determine which risks have not been mitigated appropriately (Figure 2-5).

Figure 2-5: Audit process overview-fieldwork and documentation stage.

Part II of this book provides detailed guidance for performing fieldwork for standard topics and technologies. In addition, Chapter 15 provides detailed guidance on performing risk analysis. Therefore, we will not spend much time on this topic here. However, it is important to understand the value of healthy skepticism. Wherever possible, the auditors should look for ways to independently validate the information given to them and the effectiveness of the control environment. There are times when this is not possible, and the audit team will need to take the information given to it at face value. However, the auditor always should be putting thought into how he or she can test things. For example, if the audit customer describes a process for approving new user account requests, the auditor should attempt to pull a sample of recently added users to see if they did indeed receive the proper approval. This will provide much more compelling evidence that a process is being followed than an interview.

It is also worth taking a moment to point out the importance of workpaper documentation. During fieldwork, it is critical for the auditors to do an adequate job of documenting their work so that the conclusions can be substantiated. The goal should be to document the work in sufficient detail that a reasonably informed person can understand what was done and arrive at the same conclusions as the auditor. The auditor basically should be telling a story, saying, "Here's what I did, here's what I found, here's my conclusion, and here's why I reached that conclusion." If a process was reviewed, the process should be described, and the key control points within that process should be highlighted. If a system or technology was reviewed, the specific settings and data reviewed should be described (along with how that information was obtained) and interpreted.

The documentation process seems tedious, but it is important. First, it is needed to meet the standards of the profession. Second, it is very possible that in the future the findings of the audit may be questioned or challenged, and the auditor who performed the work may have left the company or department by that time (or have just forgotten the details of what he or she did). It will be critical to have some documentation explaining what was done and substantiating the conclusions. Third, if the audit is performed again someday, retaining detailed documentation will allow the next audit team to learn from the experience of the previous audit team, thereby allowing for continuous improvement and efficiency.

One final note on fieldwork: During the planning phase, you will develop checklists as to what you plan to review during the audit. Do not fall into the trap of allowing those checklists to cause audit team members to turn off their judgment. The team needs to remain flexible during the audit and be prepared to explore avenues that were not considered during the planning. Team members always need to keep in mind the overall objective of the audit and not just become automatons following a canned script. It is also critical that each team member understand the purpose behind the audit steps he or she has been assigned. The steps assigned to each team member should be a guideline for accomplishing that purpose, and each auditor needs to remain creative in how this is done. If the step is performed, but it didn't really address the risk being investigated, then the auditor has failed.

Note 

The end purpose of the audit is not to execute the audit steps but instead to evaluate the state of internal controls in the area being reviewed.

Issue Discovery and Validation

During the course of executing fieldwork, the auditors will be developing a list of potential concerns (Figure 2-6). This is obviously one of the more important phases of the audit, and the auditor must take care to scrub the list of potential issues so that he or she can be sure that all the issues are valid and relevant. In the spirit of making the audit a collaborative experience with the audit customers, potential audit issues should be discussed as soon as possible. Nobody enjoys having the auditors wait until the audit is over and then show a laundry list of issues. Not only is it unpleasant for your customers, but it also can be unpleasant for you because you may find that not all your information is accurate and not all your issues are valid. Instead of making a federal case out of each potential issue, take the tactic of approaching the customer and saying, "Hey, I think I uncovered something of concern. Can I discuss it with you to be sure I have my facts straight and am understanding the risk properly?" This allows the customer to work with you in validating the issue and also helps the customer take ownership of the issue.

Figure 2-6: Audit process overview-issue discovery and validation stage.

In addition to validating that you have your facts straight, it is also important to validate that the risk presented by the issue is of enough significance to be worth reporting and addressing. Don't raise issues for the sake of raising issues. Instead, raise issues that are presenting significant risk to the company. Consider mitigating controls and understand the whole picture before determining whether you have an issue worthy of being reported. Except in businesses that are highly regulated, take the same approach with compliance with internal policies. While it is obviously important for IT auditors to review systems for compliance with the company's internal IT security policies, the approach still should be risk-based. There are times when a system is technically in violation of policy, but that violation represents no real risk owing either to mitigating controls or to the nature of that particular system. In such cases, what is the value of raising an issue? Likewise, there should be many cases where the auditors raise a concern that has nothing to do with policy but instead has to do with risks to the specific environment being reviewed. Do not allow your audit team to become the policy compliance team. You should instead consider policies as well as all other relevant factors in evaluating the true risks to the environment being reviewed.

Note 

If you work with your customers throughout the audit to validate issues and come to agreement on the risks those issues represent, then the conclusion of the audit will go much more smoothly and quickly. Instead of debating all the issues at the end, you can just focus on addressing the issues that you've been discussing throughout the audit and on which you've already agreed.

Solution Development

Once you have identified the potential issues in the area you're auditing and have validated the facts and risks, it is time to work with your customers to develop an action plan for addressing each issue (Figure 2-7). Obviously, just raising the issues does your company no good unless those issues are actually addressed. Three common approaches are used for developing and assigning action items for addressing audit issues:

Figure 2-7: Audit process overview-solution development stage.

• The recommendation approach

• The management-response approach

• The solution approach

The Recommendation Approach

Under this very common approach, the auditors raise issues and provide recommendations for addressing them. They then ask the customers whether they agree to the recommendations and, if so, when they'll get them done. The following is a very common scenario for this approach. Perhaps the audit team discovers that there is no process in place to ensure that users have the latest security patches on their PCs prior to connecting to the network. They present the issue to the customers, along with a recommendation that says something like, "We recommend that a process for ensuring that users have the latest security patches on their PCs be in place prior to their being allowed to connect to the network" or something equally brilliant and useful. The auditors then ask the customers when they can have it done. The customers throw out a date to get the auditors off their backs, generally without really thinking through what they're signing up for. The auditors go away happy because their recommendation was accepted, and they have a due date. Who cares that the customers have no ownership in the action plan and that they'll probably blow the due date? We'll worry about that in a few months when the point is due, right?

This example obviously is a bit exaggerated, but unfortunately, it is not all that far from the truth. The recommendation approach can work if handled very well by a knowledgeable audit team. However, it generally results in the customers feeling a lack of ownership in the action plan because they're just doing what the auditors told them to do. In addition, the customers being audited are bound to have more detailed knowledge of the area being audited than the auditors, meaning that they're in the best position to develop a solution to the problem. By sticking a recommendation in front of them and asking if they accept it, they are much less likely to think through the problem and develop a workable and realistic action plan. There is instead a tendency to "accept" the recommendation to get the auditors out of the way, only to discover the inevitable roadblocks and complexities down the line when the audit point is almost due and the auditors are following up. This leads inevitably to the audit point going overdue and/or being extended. It is not an efficient process.

If this is the approach used by your company, it is important to do it the right way and engage the customers in brainstorming how to fix the problem prior to documenting your recommendation. Then the recommendation just becomes documentation of what has already been agreed to by all involved parties. This doesn't mean that the auditors can't bring ideas to the table. They can, and they should. However, the customers ultimately need to feel ownership of the action plan.

The Management-Response Approach

With the recommendation approach, the auditors develop a recommendation and ask the customers if they'll do it. With the management-response approach, the auditors develop a list of issues and then throw them to the customers for their response and action plans. Sometimes the auditors send their recommendation for resolution along with the issue, and sometimes they just send the issue with no recommendation. Either way, the customers are supposed to send back their response, which is included in the audit report. This lends itself to very polite finger pointing and name calling. The auditor writes, in effect, 'There's a problem. We recommend that they fix it.' Management then writes back, in effect, "We think this is stupid, but we'll go ahead and implement a half-baked solution that we feel adds no value in order to get the auditors off our backs." Or even worse, management's response may be more like, "We think this is stupid and are going to do nothing about it. The auditors can go jump in a lake." In such cases, the auditors may include their counterresponse, saying something like, "Can you believe these people? They obviously don't care about controls. We're going to tell the CEO and get them in trouble."

Again, this is an exaggerated example but not far off the mark. The management-response approach does not lend itself to reaching consensus but instead allows the auditors basically to wash their hands of the responsibility of getting buy-in on the issues and their resolutions. Instead of developing a mutually agreed-on solution, they just say what they want and then allow the audit customers to say what they want, with the auditors then getting the last word in the report.

If this is the approach used by your company, try to get it changed. If you can't, try to work around the system. Prior to sending the issues and your recommendations to the customers, work out a solution with them with which you all feel comfortable. Your recommendation then can reflect what you're already agreed on, allowing the management response to be something like, "We agree and will implement it by the end of the year." Just because you have a management-response approach doesn't prevent you from going ahead and collaborating with your customers on mutually acceptable solutions.

The Solution Approach

Under this approach, the auditors work with the customers to develop a solution. This solution represents a mutually developed and agreed-on action plan for addressing the issues raised during the audit. It is a combination of the two preceding approaches, bringing in the best of each. As with the recommendation approach, the auditors are providing ideas for resolution based on their control knowledge. As with the management-response approach, the customers are providing ideas for resolutions based on their real-life operational knowledge. The result is a solution that the customers "own" and that is satisfying to the auditors. Because they have ownership of the issues, the customers are much more likely actually to follow through.

Under this approach, the audit report subtly reflects the shift in ownership. With the recommendation approach, the auditors might write something like, "We recommend that audit logs be enabled" or "Audit logs should be enabled." These statements emphasize the auditors' wishes and often are interpreted by customers as heavy handed and bossy (and often clueless). With the solution approach, the auditors instead would write, "The support team will enable audit logs." This statement is a crisp, clean statement of the customers' intentions and reflects something they have developed and agreed to with the auditors' help.

With this approach, it is important that the development of the solution be truly collaborative. Although the auditors should try to allow the customers to develop some initial ideas, they should have some potential solutions ready in their "back pockets" in case the customers are not coming up with acceptable answers. In addition, the auditors should have some sort of idea as to the minimum amount of mitigation with which they will be comfortable. They need to be prepared to let the customers know if the solutions proposed do not meet the minimum risk mitigation needs.

Guidance on Solution Development

Regardless of the approach used, it will be important to establish who is responsible for executing the action plans and the due dates by which they will be completed. This provides accountability and a basis for the auditors' follow-up. As these action plans are addressed, the auditors should be flexible regarding how finalized the action plan must be in the audit report. There are some issues that lend themselves to very straightforward solutions, such as changing a system setting or locking down file permissions. In these instances, you would expect the customers to be able to say exactly when the solution will be implemented. However, there are other issues that require very complex solutions and will involve engaging multiple organizations and developing complex processes or acquiring new technology. In these instances, it is not realistic to expect the audit customers to know exactly what they will do and when they will do at the time of report issuance. Instead, there needs to be an evaluation period in which the alternatives are examined and a detailed timeline is developed. Instead of pushing the customers to provide information when it is not realistic to expect them to do so, set an interim date. Establish a date by which they will have chosen a solution and developed a timeline. Once that date is reached, if they have indeed developed a detailed action plan, establish a new due date based on that plan.

Note 

When developing solutions, the auditor should keep in mind that it is not always practical for 100 percent of the risk to be mitigated. There are many occasions where mitigating 100 percent of the risk would be cost-prohibitive, but 80 percent of the risk may be mitigated for a reasonable cost. This is the Pareto concept, where the first 80 percent of the risk can be addressed for 20 percent of the cost. If the auditor digs his or her heels in and insists on a 100 percent solution, he or she will lose credibility, damage relationships, and cause the customers to do nothing. Having 80 percent of the risk addressed is better than having 0 percent of the risk addressed. The auditor must remember that he or she is an employee of the company and should be pushing for solutions that are reasonable and cost-beneficial. Of course, the auditor must be objective and ensure that the unmitigated risk is not unreasonable. However, auditors who always insist on 100 percent solutions become auditors who are avoided and who are viewed as having no business sense.

As discussed previously, the auditors should work diligently to reach agreement with the customers on the issues and solutions from the audit. If this is done well, there should be very few instances where agreement cannot be reached. However, inevitably there will be times where you just don't see eye to eye and cannot reach consensus. These cases should be few and far between, but they do happen. In addition, there are times when the customers agree with you but do not feel that they have the resources to address the issue. So how do you approach these instances? Do you get in a yelling and screaming match? Do you threaten your customers, reminding them that you report to the audit committee and that you can get them in trouble for not addressing the issue? Absolutely not! There is no reason that these situations can't be handled respectfully and cooperatively.

Remember, the concept of audit requirements is a misnomer. The audit department is not a requirements-setting body and therefore should not be in the business of trying to force action. Instead, auditors are there to identify risks and to ensure that the appropriate level of management is made aware of those risks so that decisions can be made as to whether or not to mitigate them. It is always an option that a risk may be accepted. However, the auditor must use his or her judgment to determine what level of management needs to be informed of the risk. There are some audit issues that represent a small amount of risk. In such cases, if a lower-level manager indicates that he or she understands and accepts the risk, then the auditor can just document this and move on. There will be other instances where the risk is more severe, and the auditor feels that the CIO needs to be made aware of the risk. However, if the CIO understands the risk and decides to accept it, once again, the auditor has done his or her job, and no further action is necessary. Still other issues represent such a severe risk that the auditor will be comfortable only with sign-off by the CEO or even the audit committee.

Note 

There is always some level of management that can sign off on accepting the risk for any given issue. The auditors must use their judgment to determine what that level is.

Even in cases where you feel that you must go above someone's head to make the appropriate level of management aware of a given risk, there is no reason for this to be an adversarial event. You can calmly explain to your audit customers that you understand their reasons for declining to address the issue and that your job requires you to inform higher levels of management about the risk to ensure that they are also comfortable with accepting it. You can even invite them to participate in any meetings to discuss the risk and/or keep them copied on any e-mail traffic. This should not turn into a "he said/she said" match but instead can remain very open and respectful, with the auditors explaining the customers' viewpoint as well as their own during management communications. Escalating an issue often will result in a positive outcome for the customers, such as additional resources being allocated to allow for the issue to be addressed, so the escalation process does not have to be a contentious one. There even will be times when the customers want the auditors to escalate an issue in order to provide additional backing to address a known issue that perhaps has not received proper attention prior to the audit.

Report Drafting and Issuance

Once you've discovered the issues in the environment being audited, validated them with the customers, and developed solutions for addressing them, it is time to draft the audit report (Figure 2-8). The audit report is the vehicle by which you document the results of the audit. It serves two main functions:

Figure 2-8: Audit process overview-report drafting and issuance stage.

• For you and the audit customers, it serves as a record of the audit, its results, and the resulting action plans.

• For senior management and the audit committee, it serves as a "report card" on the area that was audited.

Essential Elements of an Audit Report

There are as many audit report formats as there are internal audit departments. However, following are the essential elements of an audit report:

• Statement of the audit scope

• Executive summary

• List of issues, along with action plans for resolving them

Statement of the Audit Scope It is important to make it clear for the reader what was included in the audit and, if necessary, what was not included in the audit. If an area or topic was specifically scoped out of the audit, it is important to state as much in the report so that there are no misunderstandings.

Executive Summary In addition to listing all the detailed issues and action plans, you need to have an executive summary so that someone who does not have the time or inclination to read all the details can understand the overall state of controls in the environment. This summary should be written so that it can stand alone, even if it were removed from the rest of the report. It should not list or discuss every issue, only the most significant ones. It should not be a tedious listing of the results of each area reviewed. Instead, it should reflect what you would really want someone to know about the results of the audit, assuming that they read no other part of the report. It also should not just be a bunch of mealy-mouthed platitudes and vague statements. Don't just say, "The area generally was well controlled, but there are opportunities for improvement." What does this mean? Be bold, and actually state an opinion. Say

Strong controls were in place over account administration, but a number of control concerns were found related to software change controls. The most significant of these issues is the fact that developers have direct access to update production code. This means that these programmers can alter production code functionality without going through proper testing and approval. The development team has developed an action plan for addressing this concern, which will result in their access being removed from the production environment. Further details are found in the "Issues" section below.

This is obviously just an example, and most of your executive summary sections should be longer than this. The point is that you need to provide some actual information so that management can understand what it should be concerned about.

List of Issues and Action Plans This is the meat of the report because it provides details on all the significant issues uncovered during the audit and what is going to be done to fix them. Quality and clarity of writing are essential because each issue must be documented in such a way that multiple levels can understand it. It should be written so that the people who deal with the area day to day understand exactly what you're talking about, but it also needs to be written so that senior management can understand enough about it to grasp the risk and why it needs to be mitigated. Be sure to explain concepts in layperson's terms and to spell out the risk. For example, if you have a concern about the default umask setting on a server, you could write an issue that says

The default umask on the server is set to 000.

Although the Unix administrators will understand your concern immediately on reading it, this statement is completely meaningless to anyone else who reads it. Alternatively, you could write the issue this way:

File permissions on the server need improving.

The lay reader will understand this, but the Unix administrator could interpret this in many ways and needs more detail about exactly what aspect of file permissions you're referring to. Instead, you might write the issue like this:

The default umask on the server is set to 000. This means that, by default, when a new file is created, its file permissions are set such that anyone with access to the server will be able to read and write to the file. As this server contains critical financial data files, this could result in inappropriate access to data and/or unauthorized changes to the data.

All levels can understand this third example. The technical person understands exactly what system setting you're referring to, and the layperson can understand the business risk being addressed.

Note 

If you have certain systems or subject areas that you audit frequently, it may be useful to develop a database of standard wording for common issues. This database (which could be as simple as a spreadsheet) would contain standard wording for issues that are raised frequently during your audits. This prevents each audit team from spending time struggling with how to document the issue when writing the report and also provides consistency between your reports. For example, if you frequently audit Unix security at various company sites, it would be helpful to document standard wording for common issues such as, for example, the absence of password aging, easily guessed passwords, poor file security, etc. Of course, the audit team always should alter these as necessary to fit the circumstances of the specific audit, but the standard wording will provide an excellent starting point.

Many audit departments use a rating system in their audit reports. This rating system could provide a an overall rating for the audit, such as rating each audited area as "unsatisfactory," "needs improvement," or "adequate," or could provide a number rating, with, for example, a 1 being the worst and a 10 being the best. The rating system also could involve rating the severity of each specific audit issue. While your company's environment may require this sort of thing, it is best to avoid it if possible. Rating systems lead to lots of wasted time and energy spent on debating with the customers what the exact rating should be. Instead of spending energy on debating whether the report should be a 5 or a 6, spend that time reaching agreement on the need to do something and on developing an action plan. The end goal is to improve the controls in the environment. Debating over a rating does not contribute to this goal.

Following is a simplified example of an audit report, using the elements described in the preceding section.

Audit Scope

During this audit, we reviewed the internal controls within the corporate accounts receivable (AR) system. This included a review of controls within the application and its related database and operating system. Physical security of the AR system server was not included in the scope of the review because those controls were tested during a recent audit of the data center.

Executive Summary

Strong controls were in place over account administration, but a number of control concerns were found related to software change controls. The most significant of these issues is the fact that developers have direct access to production code. This means that these programmers can alter production code functionality without going through proper testing and approval. The development team has developed an action plan for addressing this concern, which will result in their access being removed from the production environment. Further details are found in the "Issues" section below.

Audit Issues

1. Developers have direct access to update production code.

   There are no technical or procedural controls to prevent application support personnel from making unauthorized changes to the system.

   Risk Without proper software change controls, changes could be made to the application, either unintentionally or maliciously, that have not been approved and/or that have not been tested properly. These code changes could result in inaccurate system processing, the ability of an employee to execute fraudulent transactions, or system unavailability.

   Solution The AR system team will implement a baseline tool for protecting the production code. The ability to check new code into this tool will be limited to the group's manager and a backup, neither of whom has responsibility for performing code changes. Once this tool is implemented, the team will document procedures requiring approval and testing prior to submitting new production code for check-in.

   Responsible: Clark Kent

   Completion Date: xx/xx/xx

2. The default umask on the server is set to 000.

   Risk This means that, by default, when a new file is created, its file permissions are set such that anyone with access to the server will be able to read and write to the file. Since this server contains critical financial data files, this could result in inappropriate access to data and/or unauthorized changes to the data.

   Solution Janet Richardson from the Unix infrastructure team will reset the default umask to 027 on the affected servers in the environment. Additionally, the Unix baseline documentation will be updated to include checking the default umask value prior to placing new systems into production.

   Responsible: Janet Richardson

   Completion Date: xx/xx/xx

Additional Elements of an Audit Report

In addition to the three basic sections just mentioned, there are other elements that you might consider adding to your reports.

Key Controls In addition to the issues you found, there undoubtedly were some good things that were already being done. There were likely some important controls already in place that you relied on during your assessment. If these controls were not in place or changed, it would change your overall assessment of the environment. Isn't it as important for your customers to know what they're doing right as it is for them to know what they need to improved? If you don't tell them that you considered a particular control to be important, then they could very well make a decision to stop performing that control. For example, if you relied on the fact that they disabled all unnecessary network services on their servers and that they regularly run Tripwire to detect changes in the environment, then state as much in the audit report. In this way, they'll know that they should not make changes to those controls.

Closed Items If your audit customers resolve issues during the course of the audit, give them credit for it. List the issues that have already been resolved in a separate section. This keeps closed items from clogging up the "Issues" section, gives your customers credit for being proactive, and yet also ensures that the audit report reflects a complete picture of the problems in place at the time of the review.

Minor Issues Sometimes you find minor issues during the project that do not represent a great risk. You have no interest in tracking their resolution because you really don't care whether the customers address them or not. Yet you would like to make the customers aware of your observations so that they can take action if they would like. These sorts of minor issues can be listed in their own section, where you make it clear that they are being communicated purely for informational purposes and that you won't be requiring action plans or tracking resolution.

Once you have drafted the report, you should let your customers review it and comment on it before it is issued. Be willing to make minor wording changes as long as they don't change the message of what you're saying. The goal should be for the customers to be comfortable with and in agreement with what's in the report.

Distributing the Audit Report

Finally, once the report has been drafted and reviewed by the customers, it is time to issue it. Most audit departments issue all audit reports to senior management (including the CIO, CFO, and CEO) and sometimes even to the audit committee. This certainly fits with the department's goal of providing senior management with independent assurance on the state of internal controls at the company. However, it can damage your goal of partnering with management to assess and improve the state of internal controls.

Note 

If people know that everything you find is going to be sent all the way up the management chain, they'll likely be much less willing to share information and will be doing all they can to minimize what's in the report.

Consider seeking permission from senior management to allow you to issue reports only to the lower-level management of the group being audited. Senior managers likely will be concerned that this will result in significant issues going unad-dressed without their knowledge. You can compensate for this concern with a few additions to the process:

• Send the executive summary section of each audit to senior management. This possibly could be compiled and sent on a quarterly basis. In this way, senior management stays in the loop on what's being audited and on the overall results without being sent every detailed issue and action plan.

• Assure senior managers that if any issue is not resolved in a timely manner, you will escalate it to them. In this way, they will be bothered only with the issues that are not being addressed.

• Assure senior managers that you will go ahead and let them know about any particularly material or pervasive issues. If you find these sorts of issues on an audit, you can consider going ahead and sending just those issues to senior management in an abbreviated audit report.

As you consider how to document and distribute your reports, keep in mind that your objective is to see the issues addressed, the risks mitigated, and the controls improved. Your objective is not to report things for the sake of reporting them or to show off all the things you did. Tailor your reporting process in such a way that it maximizes your chance of achieving your true objective.

Issue Tracking

It is common for auditors to feel like the audit is "done" once the audit report is issued. However, as we've discussed earlier in this book, issuing an audit report adds no value to the company unless it results in action being taken. The audit is not truly complete until the issues raised in the audit are resolved, either by being fixed (the preferred resolution) or by being accepted by the appropriate level of management (Figure 2-9). The audit department must develop a process whereby its members are able to track and follow up on issues until they are resolved. This likely will involve maintaining a database containing all audit points and their due dates, along with a mechanism for marking them as closed, overdue, etc.

Figure 2-9: Audit process overview-issue-tracking stage.

It is usually wise for the auditor who performed or led an audit to be responsible for following up on the points from that audit. That auditor is responsible for following up regularly with the responsible customers as the due date for each point approaches. The auditor shouldn't wait until the point is due or past due before contacting the customer but instead should be in regular contact regarding the status of the issue. This serves a number of purposes. First, it allows the auditor to consult with the customers as decisions are being made. Second, it allows the auditor to be alerted early if the solution being implemented isn't matching expectations. In this way, the auditor can try to redirect activities before things are finalized. Third, if the issue is not being worked, it allows the audit department to try to address the problem prior to the point becoming overdue.

If it turns out that an issue is not being addressed as agreed, the auditors are responsible for initiating escalation procedures where needed. In the preceding section on solution development, we discussed the concepts of escalation and risk acceptance and how they can best be executed. We will not repeat that material here except to provide a reminder that not every issue has to be escalated to the audit committee if it's not being worked. The auditors must determine how important the risk is and make a decision as to what level of management needs to be aware of that risk and make a decision about whether to mitigate it. This is the level of management that an issue should be escalated to if necessary. Every little issue does not need to be escalated to the audit committee because the risks associated with some issues just don't warrant it. You don't need to go tell the audit committee about a user having a bad password.

Escalation should be a last resort and should not be a mechanical process. Judgment should be retained during the issue-tracking process. If a point is overdue, the first step should be to spend time with the responsible customers understanding why. If they are working on the issue, but other priorities have gotten in the way, resulting in a delay, or if it has turned out that implementing the solution is more complicated than initially thought, there is no need to escalate the point. Instead, consider extending the due date while setting an expectation that you cannot extend it endlessly. Escalation should occur only in cases where work is truly not progressing on addressing the issue either because the customers are choosing to not take action or because the customers do not have the resources or authority to make it happen.

Note 

The escalation process should be a tool to enable the fulfillment of the audit department's goal of improving internal controls, not a mechanical process devoid of common sense.

Finally, a decision needs to be made regarding the validation of solutions put in place to address audit issues. How much emphasis needs to be placed on retesting the area to ensure that the new controls are working effectively? Although it would be nice to retest everything, it's probably not practical from a resource standpoint. In some cases it would require a complete reaudit of the area to truly validate the solution. The practical answer is usually to perform a "best effort" attempt to validate that the control was indeed implemented. If the solution was to modify a system setting, the auditor certainly can check the setting. If the solution was to create a disaster recovery plan, the auditor certainly can view the plan. However, there are other cases where the practical answer is to get the customer to explain and walk through the process or system that has been implemented without really testing its effectiveness. This is another area where judgment and common sense need to be applied.