It Auditing: Using Controls to Protect Information Assets [IT AUDITING -OS N/D]

All the other chapters in this part have dealt with how to audit specific technologies and processes that are already in place and operating in a production environment (e.g., operating systems, data centers, applications, etc.). However, before any system or process can be implemented, there has to be a project that is funded and staffed to develop or procure that system or process. If proper disciplines are not followed during that project, the chances that the project will fail to meet requirements and/or result in inefficient use of company assets are greatly increased.

Background

Proper project management disciplines are an essential element of the success of any company endeavor. These disciplines help to ensure that pertinent requirements are gathered and tested, project resources are used efficiently, and all elements of the system are tested properly. Without project management disciplines, it is far more likely that the system being developed won't work or won't do what your key stakeholders expect it to do. This leads to rework and extra costs to the company (and also sometimes leads to people losing their jobs). Good project management does not ensure success, but it improves the chances significantly. The intent of this chapter is not to provide a training course on the basics of project management or the software development life cycle (SDLC), but it is instead intended to provide a list of basic risks to review when auditing a systems project in order to ensure that the most essential project management disciplines are being followed.

High-Level Goals of a Project Audit

Project audits are performed for the purpose of identifying risks to the success of company projects. In this chapter we'll be specifically referring to IT projects (e.g., software and infrastructure development), but the concepts could apply to any sort of project. Some of the high-level goals of a project audit include ensuring that

• All appropriate stakeholders are involved in the development of requirements and testing of the system and that frequent and effective communication is provided to all stakeholders. Failure to gather customer requirements and to obtain ongoing customer involvement leads to software, systems, and processes being developed or procured that do not align with business needs.

• Project issues, budgets, milestones, etc. are recorded, baselined, and tracked. Without these mechanisms, projects are more likely to go overbudget and overschedule and to have unresolved issues.

• Effective testing takes place, encompassing all system requirements. Inadequate testing leads to unstable, low-quality systems and a failure to meet customer requirements.

• Appropriate documentation is developed and maintained. Incomplete or out-of-date technical and user documentation could increase cost and cycle time to maintain the software, increase support and training costs, and limit the system's usefulness to the customer.

• Adequate training is provided to end users on implementation. Inadequate training leads to systems, processes, and software that go unused or are used improperly.

Basic Approaches to Project Auditing

There are two basic approaches that can be taken with project auditing. The first approach is quick and short term, the in-and-out approach. The second approach takes a long-term view of the project and is considered a consistent approach.

There are challenges to the short-term approach, in which auditors pick a point in the project to perform their audit. The auditors then review the project as of that point in time and make a judgment based on what's happened and what's planned. There are two major downfalls with this approach:

• It is difficult for the auditors to have an impact on the phases that have already been completed. For example, the user acceptance testing phase is a poor time to find out that things were messed up during the project definition phase. The project either has to go back and perform a bunch of rework or just understand that things were messed up and move forward, hoping for the best. Either way, the auditors' input is not very timely.

• It is difficult to fully evaluate the phases that have not yet begun. The auditors might be able to review plans for user acceptance testing at the beginning of the project, but until those plans are fully developed and are being executed, it is difficult to evaluate their true effectiveness.

The longer-term, or consistent-involvement, approach allows auditors to perform some assessment activities during each major phase of the project. Each audit evaluates the processes within the current phase while also assessing and providing input on plans for future phases. This is a much more effective means of auditing projects and also leads to a much more collaborative approach with your audit customers. The only negatives are that it stretches the audit out over a long period of time and that it can be difficult to schedule. However, the positives far outweigh the negatives.

If the project spans an exceptionally long period of time, the auditors might consider one of two approaches:

• Release interim audit reports after each major project phase so that the information in the report doesn't become too stale.

• Meet with the project manager to go over issues on a regular basis (e.g., once every 2 weeks). At this meeting, the auditors can communicate new risks to the project discovered since the last meeting and also follow up on the status of previous issues to determine if remediation is complete. If, in the auditors' opinion, the project risk is increasing to an unsatisfactory level, or if issues are not being mitigated, the auditors can escalate to a higher level of management at their discretion. The auditors should reserve the right to issue a full-scale audit report at any time, but by trying to work with the project manager first, it is more likely that issues will be resolved without escalation and without the issuance of interim audit reports.

Seven Major Parts of a Project Audit

Project audits can be divided into seven major parts, each of which require disciplines and controls that we will evaluate during project audits:

1. Ongoing project management. This topic covers those mechanisms that should be used throughout the project, such as issue tracking, project documentation, and change management.

2. Project startup: requirements gathering and initial design. This topic covers the birth of a project, where the need for the project is established, requirements are gathered, and the initial design and feasibility studies are performed.

3. Detailed design and system development. This topic covers the "meat" of the project, where the code is written, the product is procured or implemented, the processes are developed, etc.

4. Testing. This is the part of the project where the system, software, or process is tested to ensure that it meets requirements.

5. Implementation. This part of the project involves, obviously, implementing or installing the system, software, or process into a production environment.

6. Training. This topic covers the activities for training end users on using the system, software, or process that has been developed and implemented.

7. Project wrap-up. This topic covers postimplementation activities.

The rest of this chapter will focus on key audit steps and tests to perform related to these seven categories.