The primary goal of auditing information systems is to determine whether IT processes support business requirements in the most effective and secure manner. As a starting point, the IS auditor should review the following:

Note

Strategic Planning

The goal of strategic planning is to ensure that the organization’s long-term (three- to five-year) and short-term (one-year) strategies are defined in writing and that there is a regular review process. The strategic plans make sure that the organization meets its goals and objectives and, if there is a proper review cycle, reflect the current direction of the organization and its business units. Although the strategic objectives are the responsibility of senior management, the planning process should include the senior managers, managers of the business units, and IT managers. An organization’s implementation of IT will be less likely to succeed if senior management is not committed to strategic planning. IT management then can align the IS strategy with the business strategy.

This sounds like a simple process, but a number of companies create both the business and IS strategy but do not have a process for regular review and update. Above all else, the IS strategy must support the business objectives of the organization. When performing an IS strategy audit, an IS auditor should review both short-term (one-year) and long-term (three- to five-year) IS strategies, interview appropriate corporate management personnel, and ensure that the external environment has been considered. The auditor should not focus on actual procedures during an audit of IS strategy.

Policies and procedures define the actual operational implementation of the strategic plan and, like the strategic plan, should have a formal process for creation, communication, and review. As stated earlier, policies and procedures are subject to change more often than the strategic plan as they guide operational activities. An IS auditor not only reviews the policies and procedures, but through interview and observation, the auditor also determines whether the procedures are being followed, aligns them with the strategic plan, and guides current operational activities. In addition to creating a formal process for review and update, the auditor should be able to identify specific ownership for these activities and how often they are performed. Undefined creation, review, and communication or ownership are indicators of the absence of a formal process.

Note

IS Steering Committee

The IS steering committee ensures that the IT department’s strategy and implementation of the strategy directly align with the business strategy as well as the corporate mission and objectives. The steering committee is composed of senior managers who assist in the selection, approval, prioritization, and ongoing review of major IT projects, planning, and budgets. The IS auditor looks for the existence of a formalized committee with a charter, procedures, and defined responsibilities. The IT steering committee maintains detailed meeting minutes as a part of its ongoing reporting to senior management. This reporting ensures that the board of directors and senior management are informed of major IT projects and the status of ongoing projects in a timely manner.

The term “major IT projects” is an important distinction to the IS auditor, evidence that the IT steering committee is getting involved in the day-to-day operations of the IT department. This is an indicator that the committee might not be following the charter or is unclear in its responsibilities. If the committee is providing guidance on day-to-day operations, it will have difficulty determining whether the projects and budgets are aligned with the business objectives, and its reporting to senior management will reflect operational issues instead of overall strategy. This type of review will not ensure alignment or the efficient and effective use of IT resources.

The absence of a formal, chartered IT steering committee could indicate that IT projects are not aligned with the organization’s strategy. With a lack of external controls (the IT steering committee), some projects might not support the mission of the organization, or projects might not come in on time or within budget.

Note

As an IS auditor, you can learn a significant amount about an organization by reviewing the strategic plan and organizational and lower-level policies. These documents can provide background on the business objectives and mission, as well as the line or operational policies supporting that mission. If you review strategy and policies before doing observation and conducting interviews, you might identify areas in which potential gaps exist, help define whether the organization has a clear process for policy development, and determine whether the organization is using a top-down or bottom-up approach to policy development.

Policy Development

Organizations follow different approaches in policy development. The top-down approach aligns organization-wide policies with the business strategy; department- and office-level policy then is created in accordance with strategy and organizational policy. The top-down approach works to ensure that all policies are aligned with the organizational strategy, but it generally requires more time to develop and implement and might not address immediate operation priorities of the organization.

Other organizations create policy using the bottom-up approach. They identify immediate areas of concern, compliance, or risk, and develop policy for those areas by performing a risk assessment. Although this approach is more time- and cost-effective, it creates the risk that policies might not align with organizational policies and strategy.

Note

A variety of policy types exist, and it is important that the organization and the auditor understand the distinction between policy types and their enforcement:

• Regulatory—. These policies are written to ensure that the organization is following standards set by a specific industry and are regulated by law. These types of policies are frequently used in financial institutions, healthcare facilities, public utilities, and the federal government.

• Advisory—. These policies strongly recommend certain types of behaviors, actions, or activities for the organization. These types of policies outline possible consequences for noncompliance and are enforced internally within the organization.

• Informative—. These policies are generally not enforceable and are considered “teaching” policies. These types of policies are used in most organizations.

In addition to different policy types, different subsets of the organization need to develop and comply with lower-level policies. Human resources policies at the policy level are those that most of us are familiar with; these policies pertain to training, travel, hiring, promotion, and termination. These policies are implemented organization-wide, regardless of function or authority level, and they guide the actions of employees. The policies should have a process for review as well as communication within the organization, and should address both the long- and short-term objectives of the organization. There are a variety of methods for communicating policy; these might take the form of awareness training, employee manuals, company newsletters, or legal banners. It is important that clear responsibilities are defined and programs are put in place to ensure that employees are aware of and understand the organization’s policies.

IT Policy

Although senior managers are responsible for the development, review, and communication of policy, a significant portion of policies pertains to information systems acquisition (hardware/software), compliance, security, network and operations, continuity of operations, and financial/accounting policies.

Table 2.1 lists some definitions of policy types that are used by organizations and that pertain to IT functions.

Table 2.1. Areas of Policy Development

Planning policies	Responsibility: Who is involved with planning? Timing: When does planning take place? Process: How should planning be conducted? Deliverables: What planning documents are produced? Priorities: What are the most and least critical planning issues?
Organizational policies	Structure: What is the organizational form of the IT function? Information architecture: Is the infrastructure aligned with the organization’s mission? Communication: Do all affected parties know the IT strategy and policies? Compliance: Are all external regulations and laws being addressed? Risk assessment: Are IT risks identified, measured, and controlled?
Hardware policy	Acquisition: How is hardware acquired from outside vendors? Standards: What are the hardware compatibility standards? Performance: How are computing capabilities tested? Configuration: Where should client/servers, personal computers, and similar technology be used? Service providers: Should third-party service bureaus be used, and when?
Network policy	Acquisition: How is network technology acquired from outside vendors? Standards: What are the network compatibility standards (LAN, Internet, intranet, and so on)? Performance: How much bandwidth is needed, and is the network fast enough? Configuration: What are the logical and physical configuration standards (server, firewalls, routers, and so on)? Adaptability: Does the network have the capability to support emerging business models?
Security policies	Testing/evaluation: How is security tested or evaluated? Access: Who can have access to what information and applications? Monitoring: Who monitors security, and how? Firewalls: Are firewalls effectively configured and utilized? Violations: What happens if an employee or external entity violates security?
Operations policy	Structure: How is the operations function structured? Responsibilities: Who is responsible for transaction processing? Input: How does data enter into the information system? Processing: What processing modes are used? Error handling: Who should correct erroneous input/processing items?
Contingency policy	Backup: What are the backup procedures? Recovery: What is the recovery process, and how is it tested? Disasters: Who is in charge, and what is the plan? Alternate sites: What types of sites are available for off-site processing?
Financial and accounting policies	Project management: Are IT projects prioritized, managed, and monitored? Revenue generation: Should services be sold inside or outside the organization? Technology investments: Are the investment returns being properly evaluated? Funding priorities: Where and how should resources be allocated most effectively? Budgets: Are budgets aligned with funding levels and priorities, and aligned with strategy?

Policies are high-level documents that align with the business strategy (both long and short term) and represent the corporate philosophy. The organization’s management is responsible for the formulation, documentation, communication, and control of policies. The development of these policies and their implementation show an organization’s commitment (due care and diligence) to the use, operation, and security of information systems.

IS auditors should look for both policies and procedures that apply to all phases of the system development life cycle (SDLC) and ensure that they align with the organization’s strategy. The SDLC encompasses the planning, analysis, design, implementation, integration/testing, acceptance, maintenance, and security of information systems. The SDLC is a formal model that represents the phased implementation of information systems. The definition of detailed tasks might change by organization, but Figure 2.1 outlines the high-level tasks of an SDLC.

Figure 2.1. SDLC diagram.

Procedures

Procedures are detailed documents that incorporate the intent of the parent policy and that document administrative and operational processes. In some cases, procedures provide step-by-step details for performing a function and writing in a clear and concise manner to allow easy understanding and implementation.

The procedures outline how to perform various business processes within the IT environment and the controls associated with them. The change in business process should drive policy and procedure changes, but this is not always the case. In today’s fast-moving business environment, it is not uncommon for business processes to frequently change because of procedures, compliance, or the influence of new technologies in the organization. An IS auditor must pay particular attention to the process for review and implementation of procedures because they are the most fluid documents in the organization. In addition, the auditor might find through direct observation or interviews that the defined procedures are not being followed. This is an indication that there is no defined process for review and update of the procedures, or that the people working in the operational environments are not properly trained on the procedures associated with their function.

The lack of procedures or adherence to procedures could be indicators of a larger issue: Necessary controls in the environment are being bypassed by ad-hoc procedures. In this case, the procedure, or lack thereof, makes it difficult for the auditor to identify controls and ensure that the process is efficient and secure.

Note

As stated earlier, reviewing the business strategy, the IT strategy, and associated policies and procedures before conducting interviews and observations should provide the auditor with a clear view of the organization’s objectives and mission and any potential gaps in policy or procedures. As a part of the interview and observation process, the auditor should observe personnel in the performance of their duties and assist in identifying the following:

All procedures should incorporate controls over the business process. As a part of the planning phase, the IS auditor should identify control objectives associated with each business process and ensure that the procedure is followed and that controls meet the control objectives. IT control objectives enable the IS auditor to more clearly understand the desired result or purpose of implementing specific control procedures. The IS auditor should check to see that the procedures are understood and executed correctly, determine whether control objectives are fulfilled, and should determine whether a review process is in place for change control. When auditing this area of IT, the auditor should look for areas of concern that could indicate potential problems. This can include the following:

During the IT audit process, the auditor should ensure that a process exists for strategy, policy and procedure development, communication, and review. This review process can be part of a change-control process (CCP). The CCP is implemented in organizations as a way to provide a formal review and change-management process for systems and associated documentation. The change-control board (CCB) similar to the IT steering committee, is a formal process, that is chartered by senior management. The CCB should accept requests for changes to systems and documentation, and should review and approve or deny recommended changes. The CCB also might be charged with the periodic review of strategy, policies, and procedures as part of its charter.

As an example of an ad-hoc procedure that is not aligned with a documented procedure, we can review the following example.

Imagine that the IS auditor is reviewing the back-up procedures for the organization’s servers. The documented procedure states that the backups are performed by the backup operator who is responsible for configuring the backups, labeling the tapes, managing off-site storage, and performing log review. The procedure further states that a backup job is scheduled to run every evening to back up the organization’s servers. The backup software should be configured to connect to the server, back up the data, verify that the data was backed up, log any anomalies, and move to the next server. While monitoring the process, the auditor finds that the data is being backed up and logged, and the backup software then connects the next server.

While questioning the backup operator, the IS auditor inquires about why the data backed up on the tape is not verified and then logged. The backup operator states that the procedure was created when the company had only five servers, which could be backed up and verified in about eight hours. With the addition of 10 servers, the backup procedure cannot back up and verify all the servers in the environment in the eight-hour backup window. The backup operator asked for additional equipment after the servers were installed but has not received it. The backup operator therefore changed the actual procedure to back up the servers without verifying, to ensure that all 15 servers could be backed up during the eight-hour backup window.

This scenario identifies a few areas of concern:

In this case, the difference between the actual documented procedure and the ad-hoc procedure on the surface appears small, but it can have far-reaching effects. This type of scenario could be an indicator of risk in the environment.

The IT department should have a clear process for developing IS strategy. This process should include the development, communication, and implementation of the strategy. If this process does not exist, the auditor will find indicators throughout the review of strategy, policy/procedures, and observations. The lack of an IS strategy or a strategy that is outdated or not communicated indicates that IT might not be aligned with the business strategy and that a change in business strategy might not be reflected in the IT department’s policy. An IS auditor should recognize key development risk indicators, including these:

The IT strategy should align with the business strategy, ensure efficient use of IT resources, and serve as the basis for IT policy and procedures. Although the development of IT strategy is an IT function, it should include stakeholders in the organization, as well as senior management. The participation of stakeholders (such as senior managers of business functions) helps ensure that the strategy meets the goals of the organization and business functions, and helps keep the strategy aligned when the business strategy changes. When performing an audit of IS strategic planning, it is unlikely that the IS auditor would assess specific security procedures. During an IS strategy review, overall goals and business plans would be reviewed to determine whether the organization’s plans are consistent with its goals.

The organizational structure and design of the information systems department should ensure efficient and effective use of IT resources. These resources should have clearly defined duties and the associated policies and procedures. The IT organization needs to ensure proper segregation of duties to reduce the risk of errors or misappropriations associated with the information systems or data.

Evaluating IS Organization and Structure

Both the organization and the IT department should create and maintain an organizational chart. This chart reflects a clearly defined structure and provides a clear definition of the IT department’s hierarchy, authority, and responsibility. The organizational chart, combined with job descriptions, provides the auditor with a clear definition of individual responsibilities and the reporting structure. A review of these documents helps the IS auditor ensure that there is proper segregation of duties based on job function and detailed tasks associated with the function. Per ISACA, segregation of duties avoids the possibility that a single person could be responsible for diverse and critical functions in such a way that errors or misappropriations could occur and not be detected in a timely manner during the normal course of business processes. During the development of the department’s hierarchy, IT management should consider the following:

• Segregation of incompatible duties

  • Segregation between operations and programming might not be possible in smaller environments.

  • Audit trails might be an acceptable compensating control.

• Vesting in different people

  • Authorizing transactions

  • Recording transactions

  • Maintaining custody of assets

• Accomplishing judicious choices with respect to...

  • Placing the IT function in the organization

  • Integrating programmed controls into computing infrastructures and applications (with IS auditors possibly included in the project team as control advocates and experts)

As stated in Chapter 1, “The Information Systems (IS) Audit Process,” each function within the organization should have a clear definition of the duties to perform that function. While performing operational tasks, certain functions act as controls across the IT organization and must be segregated accordingly. A clear example is the role of the security function within the IT organization. This function is responsible for the implementation and maintenance of security controls, to ensure the confidentiality, integrity, and availability of systems and information. As such, security personnel should not be involved in the day-to-day operational administration of information systems. To illustrate this point, consider the following scenario:

Generally, systems administrators are responsible for the operational maintenance of systems and, in most cases, are responsible for the creation, maintenance, and termination of user accounts for the systems. In a properly segregated environment, administrators would create user accounts and the associated profile information but would not assign access rights to systems or data. After the user account and profile information was created, the security administrator, with approval from the application owner(s), would enable access to the systems and data that the users required to perform their jobs.

Although the assignment of access rights is performed by the security administrator, the authorization of access to data is provided by application/data owners. This ensures an adequate segregation of duties between IS and end users. This segregation of duties ensures that no one function or individual can create user accounts and provide access to systems and data. As an example of the improper segregation of duties, consider the ramifications if either the systems administrator or the security administrator could both create accounts and assign access rights. A single person would then have the ability to create a fictitious user account and provide access to payroll information, private employee information, or the organization’s intellectual property.

Note

In smaller environments, it is often difficult to completely segregate incompatible duties. In these cases, the organization must use compensating controls such as audit trails and specific levels of approval before a task can be completed. IT functions such as systems development, computer operations, and security should be segregated by either function or the use of compensating controls. Keep in mind that functions within organizations can be combined. As an example, a quality-control administrator could be responsible for change control and problem management. Combining these duties does not create a situation in which errors or misappropriations could occur.

Table 2.2 shows example IT functions that should not be combined.

Table 2.2. Proper Segregation of Duties

	Systems Development	Computer Operations	Security Administration	Explanation
X = Functions should not be combined
Systems development		X	X	Applications development staff has access to systems, business applications, and other key software, and should not be allowed to process end-user information or maintain custody of corporate data and business applications (computer operations).
Computer operations	X			Computer operations staff are responsible for entering data, processing information, and disseminating output, and should not be involved in systems development or security administration because they might be able to bypass controls associated with data transactions.
Security administration	X	X		Security administrators are responsible for safeguarding resources, including ensuring that business software and applications are secure, and ensuring the safety of corporate information, communication, networks, and physical facilities.

Designing the ultimate structure of the IT function is often determined by cultural, political, and economic forces inherent in the organization. The design process should consider internal controls to reduce errors, misappropriation, or fraud. As an example, IT management should separate systems development, computer operations, and computer security. If these functions cannot be separated, compensating controls should be put in place. The IS auditor should ensure that systems developers and computer operators are segregated and that the IT function forms a separate security specialization, to maintain custody of software applications and corporate data.

Evaluating Use of Third-Party Services

Outsourcing is a contractual arrangement between the organization and a third party for information systems and associated development, processing, or hosting. This contract relinquishes control over part or all of the information processing to an external party. Organizations often use third-party resources as a way to offset IT costs within the organization or if a particular skill set is required that does not exist in the organization.

A variety of reasons exist for outsourcing. Organizations must ensure that IT processing resources achieve the same level of confidentiality, availability, and integrity that they would have if they were located within the organization. The organization’s management might decide to outsource functions to focus on core competencies, as a cost-savings measure, or to gain flexibility to the organization. Many organizations choose to outsource data processing to obtain necessary IT expertise from outside sources. This expertise might range from software to data entry monitoring or internal quality assurance processes, to reduce data errors. In data entry, key verification is one of the best controls for ensuring that data is entered correctly. The key verification processes ensure that after data has been keyed once (or recognized), it is keyed again by a second independent operator. As each keystroke is made, the system flags any differences, and these can be immediately verified and corrected. These types of processes might be best provided by a third party instead of being developed in-house.

These services can be provided by a third party:

• Data entry

• Application hosting

• Design and development of systems or applications

• Conversion of legacy system

• Help desk support

• Payroll processing

• Check processing

• Electronic bill payment

• Credit card operations

It is important to remember that third-party providers (service organizations) face the same threats to information security and controls that all organizations do. The service provider must manage security and risk well.

Some of the criteria for outsourcing, for example, is if the applications development backlog is greater than three years, if more than 50% of the programming costs is spent on system maintenance, or if duplicate information systems functions exist at two or more sites. In these instances, outsourcing the function can help consolidate duplicate functions or reduce development costs and increase delivery time. Organizations should be concerned with both the security (confidentiality and integrity) of their systems and their availability; they should use legally binding contracts to ensure that third-party service providers perform as expected. The contracts should articulate the roles and responsibilities of each party, services to be performed, service-level agreements, contract duration, services costs, dispute resolution, and dissolution agreements.

The contractual agreement generally includes a service-level agreement (SLA). The SLA outlines the level of service (uptime, downtime, and response time) for the outsourced information systems. The SLA usually outlines a guaranteed level of service, and this is used as a management tool to control the information resources maintained by the service provider. Outsourcing is a long-term strategy, and service-level providers face the same risks as organizations. The organization must ensure that proper contractual agreements provide the necessary level of assurance that the information systems will meet the expectations of the organization.

Note

Organizations can reduce the risk of outsourcing by doing the following:

• Having clearly defined, measurable shared goals and rewards

• Utilizing multiple vendors for redundancy

• Developing performance metrics

• Requiring external auditing of service providers’ facilities, practices, and systems

Organizations might request that third parties provide the results of a recent audit report or implement an SAS 70 audit. A Type I or Type II audit assures the organization of the existence and effectiveness of internal controls relative to the service provided. An SAS 70 Type I audit is a “walkthrough” that describes the service provider’s internal controls but does not perform detailed testing of these controls. A Type II provides detailed testing of the controls around the service provided.

The auditor’s report generally contains a report of the independent auditors, a description of the relevant policies and procedures, control objectives, and results of the service auditor’s tests or the operating effectiveness of the control objectives and any other client control considerations. IS auditors should look for third-party assurance of the service provider’s design, implementation, and management of controls. These reports often adhere to auditing standards by a reputable organization, such as SAS 70 (AICPA; United States), Section 5900 of the Handbook of Auditing (CICA; Canada), or FIT 1/94 (FIT; United Kingdom). If the third party does not have or will not allow a third-party audit, the organization should look elsewhere for services.

A typical service auditor report should contain the following information:

• Report of independent auditors

• Description of relevant policies and procedures (provided by client organizational management)

• Control objectives specified by the client organization’s management, along with the results of the service auditor’s tests of the operation effectiveness of the control objectives

• Client control considerations

  Per ISACA, the auditor should be aware of the following risks associated with outsourcing:

• Contract protection—A contract that adequately protects the company

• Audit rights—The right to audit vendor operations

• Continuity of operations—Continued service in the event of a disaster

• Integrity, confidentiality, and availability of organization-owned data

• Personnel—Lack of loyalty toward customers, or disgruntled customers/employees, over the outsource agreement

• Access control/security administration (vendor controlled)

• Violation reporting and follow-up (vendor controlled)

• Change control and testing (vendor controlled)

• Network controls (vendor controlled)

• Performance management (vendor controlled)

Most risk in outsourcing to third-party providers is the disruption of services through either natural or artificial occurrences, such as natural disasters or security breaches. When auditing a potential third-party service provider, an IS auditor often requests proof of each provider’s business continuity plan (BCP). Table 2.3 lists some examples of this risk and mitigation.

Table 2.3. Example of Risk-Mitigation Strategy

Risk	Risk Mitigation
Business disruption because a service provider fails to perform as expected	Legally binding contracts should exist between the company and service providers, articulating the roles and responsibilities of each party, services to be performed, service-level agreements, contract duration, service costs, dispute resolutions, dissolutions arrangements, and so on. Both the client and service organizations’ IT functions must agree on a backup and recovery plan. The plan should be periodically tested.
Security breach	The client organization’s IT function must work with the service provider to ensure the security and confidentiality of company information.

When auditing third-party service providers, the IS auditor should be concerned with ownership of program and files, a statement of due care and confidentiality, and the capability of continued service of the provider in the event of a disaster. These should be clearly stated in the contract between the third-party provider and the organization. The contract should have a regular review process to ensure that the third-party provider’s contractual obligations are aligned with the IT strategies, procedures, and organizational goals.

Note

Note

The development of an IT strategic plan leads to the development of corporate or department objectives and serves as the primary guideline for allocating resources. The strategic plan keeps the organization headed in a profitable direction, and long-term planning minimizes the risk that organizational resources will not support the company’s overall objectives. IT management is responsible for establishing sound project management and organizational policies. The combination of the IT strategic plan, sound project management, and organizational policies reduces business risks. The lack of these controls might lead to IT management that is crisis-oriented or firefighting.

IS auditors should look for evidence of a prescribed, documented IT planning process. The existence of an ongoing process indicates that the company is constantly and diligently seeking an optimal “fit” between the information technology infrastructure and the organization’s goals. Establishing a sound IT management methodology through sound project management, IT organizational hierarchy, and policies ensures that organizational goals are better fulfilled and that business risks are reduced.

IS Project-Management Strategies and Policies

The core principles of project management include the development of a detailed plan, the reporting of project activity against the plan, and the adjustment of the plan to enable corrective action. All project plans should be assigned to a project manager who is experienced in the area of implementation, who has skills associated with managing projects, and who has a good working relationship with the staff in planning and executing the project.

The following list outlines the five basic phases of the project life cycle. Although the scope and details of particular projects will differ, the phases remain the same:

• Phase I: Plan the project—. This phase includes setting the time, cost, and scope of the project. In a software project, the planning team and project manager determine the relative physical size of the software to be developed; this can be used as a guide for allocating and budgeting resources. The team can use function point analysis to measure the size of an information system based on the number and complexity of inputs and files that a user sees and interacts with.

  The project team identifies the resources required, including internal/external personnel, cost, and additional facilities or equipment, and identifies the particular outcome(s) of the project. The team then determines the work breakdown structure, which is the core of the project plan, and identifies specific tasks, the resources assigned to those tasks, and project milestones and dependencies.

• Phase II: Schedule the project—. This phase of the project breaks the project into logically grouped activities and creates a timetable for each activity. The team should create Gantt charts to show timelines, milestones, and dependencies. When this is complete, the team should perform critical path analysis on the project plan. The critical path analysis shows areas of risk due to resource constraints, project timelines, or priority against existing projects.

• Phase III: Monitor continuously—. The project teams should monitor the progress of the project against the baseline using planning benchmarks, milestones, and deliverables. It is important that deviations from the plan be addressed throughout the project, to ensure that the cost, time, and use of valuable resources do not exceed the expected value of the project in meeting the business objectives.

• Phase IV: Controlling the project—. The old adage that “No good plan survives contact with the enemy” is particularly applicable at this point in the project. The project will encounter a variety of constraints and changes throughout the project life cycle. The team might find that business processes have changed, that valuable resources are not available (both people and budget), or that the expected outcomes of particular tasks were not realized. To overcome these types of changes, the teams must be flexible and continually must adjust the plan to keep the project moving. These adjustments might decrease the scope of the project, extend or shorten timelines, or bring on additional resources. The skills of the project manager and the planning team, and adequate communication of the resources on the project are key to successfully overcoming obstacles during this phase.

• Phase V: Closing the project—. This phase includes user acceptance of the products and services, as well as written acceptance of all expected outcomes. The project manager should evaluate the project personnel and reassign remaining project resources. The project history should be chronicled and used to determine whether the original return on investment will be realized as the product goes into production.

As stated earlier, major projects should be submitted to and prioritized by the IS steering committee, to ensure that the project aligns with the business strategy and that resources are available for successful completion of the project. A project manager should be assigned and must have operational control of the project and all resources assigned to the project. These resources might come from within the IT department, from business units, or from external sources. The IS auditor might be included on the project team as a subject matter expert on controls or to provide independent objective review of the project.

A variety of factors can negatively impact a project, its timeline, or its cost. IS auditors also can look for some indicators when reviewing the project-planning process or individual projects.

Project-planning risk indicators include these:

• Management does not use a formal project-management methodology.

• Project leaders are not adequately experienced in planning or managing projects.

• Projects do not have senior-level executive support.

• Projects are taking longer to develop than planned.

• Projects are costing more than budgeted.

Project risk indicators include these:

• Project leaders have insufficient domain expertise.

• Project teams are unqualified to handle project size or complexity.

• Project team members are dissatisfied.

• Projects do not include input from all affected parties.

• Project recipients are dissatisfied with project outcomes.

• Projects have a high staff turnover rate.

• Projects are frequently aborted or suspended.

These are some of the possible risks during project planning and implementation. In reading the following scenario, you can see the actual outcome of risks that are not mitigated.

The IT department’s help desk is receiving an increasing number of trouble tickets regarding slow response time on an application server. The server OS is Windows NT. After a cursory review, the system administrators determine that the application server response time would improve drastically if it was upgraded to Windows 2000 server. The remainder of the IT architecture, including the servers that provide user login (authentication services) are currently running Windows NT. The entire server infrastructure is scheduled for a planned upgrade later in the year, but the systems administrators are confident that this upgrade will not affect the applications running on the problem server or the rest of the infrastructure. When the upgrade is completed, the administrators receive a higher number of trouble tickets due to login problems, intermittent outages of the applications on the upgraded server, and network connectivity issues.

Table 2.4illustrates both the risks involved with performing this upgrade and the lack of planning.

Table 2.4. System Upgrade Risks

System Component	Problem	Planning Solution	Risk Type
Hardware	The network connectivity problem is related to an incompatible network card and drivers.	A proper plan would have included interoperability testing as well as capacity testing; the incompatible card and drivers would have been discovered before being put into production.	Business risk: The critical applications needed to operate the business are not operating properly. Continuity risk: Lack of proper planning results in downtime for systems and applications. There was no plan to “roll back” the upgrade. Information risks: The information in the applications can be adversely affected because users cannot enter and update data.
Operating system	The Windows 2000 operating systems does not provide login (authentication) services to users in the old Windows NT infrastructure.	Proper planning and testing would have ensured that the correct resources were tested and reviewed authentication systems to ensure that they were compatible.	Business risk: Critical applications needed to operate the business are not operating properly. Continuity risk: Lack of proper planning results in downtime for systems and applications. There was no plan to “roll back” the upgrade.
Application	The application availability is intermittent.	Proper planning and testing would have ensured that the old applications were compatible with the new Windows 2000 operating system.	Business risk: Critical applications needed to operate the business are not operating properly. Continuity risk: Lack of proper planning results in downtime for systems and applications. There was no plan to “roll back” the upgrade.
Interoperability	Network connectivity is intermittent.	Proper planning and testing would have ensured that the communications protocols with Windows 2000 were compatible with the network infrastructure.	Business risk: Critical applications needed to operate the business are not operating properly. Continuity risk: Lack of proper planning results in downtime for systems and applications. There was no plan to “roll back” the upgrade.

A good project-planning process and regular review reduce overall risks to the business, information, and system. During the project-planning phase, the project-management team and IT management should determine the risk as it applies to expected outcomes and determine ways to mitigate the risk.

Note

Organizations continue to increase their dependency on information systems and invest heavily in the acquisition, development, and maintenance of those systems. These systems support mission-critical business functions and should maximize the organization’s return on investment. The combination of a solid governance framework and risk-management process creates a control infrastructure that reduces risk and ensures that IT infrastructure supports the business functions.

IS auditors should look for evidence of a structured approach to the management of systems and applications, and defined life-cycle phases and progression points. The presence of a structured approach provides advantages to the auditor:

The risks associated with improper planning are varied, but the lack of a planning and review process or organization structures are indicators of a lack of controls. The IS auditor must advise the project-management team and senior management of the deficiencies. As stated earlier, the IT department should have proper project-planning procedures that follow a standard system-development life cycle. This project-planning process, combined with change control, ensures proper control over the production IT infrastructure.

In Chapter 1, we defined the different types of risks, such as business risk, continuity risk, and so on. As a part of ongoing IT procedures, a formal risk-management process must be incorporated into the planning, acquisition, development, testing, and deployment of information systems. The IT organization and project managers should use proper risk-management techniques to assess risk, take steps to reduce risk to an acceptable level (mitigation), and maintain that level of risk.

The objectives of an effective risk-management program should enable the organization to realize its business objectives:

Proper risk management enables IT managers and senior leadership to balance the operational and economic costs of protective measures and to achieve gains in mission objectives by protecting the IT systems and data that support their organizations’ objectives.

To coordinate the planning, design, and implementation of changes that could affect the connected systems or data, such as upgrading hardware or software or adding services, the organization should develop a change-management process. The change process is usually facilitated by a chartered change control board (CCB). A CCB generally is charged with reviewing all changes in the environment and has the authority to accept, deny, postpone, or send back a change request for additional information. The CCB is in place to ensure that the implementation of changes does not disrupt the availability or integrity of data, introduce vulnerabilities, or allocate resources (personnel and money) to projects or changes that do not meet business objectives. The change-management process establishes an open line of communication among all affected parties and allows those parties to provide input that is instrumental in the implementation process as it unfolds.

Change management is an integral part of any production IT infrastructure; it not only approves change in the environment, but it also can schedule changes and monitor milestones of changes that are in progress. The CCB is usually composed of members from the information systems department, as well as senior managers from the business functions. The CCB usually includes an administrator who is responsible for receiving, documenting, and scheduling the review of change requests (CR). The CR should contain all the information necessary to allow the CCB to make an informed decision about the change. A CR typically contains this information:

The CRs generally are reviewed by subject matter experts (SMEs) before they are submitted to the CCB and include suggestions or concerns. The SME can be in the business or IT area and can include business managers, users, security personnel, application developers, or network and systems engineers. SMEs provide the board with enough information to make a decision on the request and to understand the impacts in the environment. A formal change-control process is generally applied to systems and application development, but it can apply to network, security, and documentation changes as well.

In a development environment, the CR identifies how the object code will move from development to a test library and how it will test security and control features. The CR also defines how the program will be introduced into the production environment, as well as data conversion, user training, and documentation.

The presence of a formal change-control process ensures that other governance and procedures (project planning, security, and so on) are formally involved in environment changes. In a development environment, it helps to ensure proper segregation of duties because programmers should not be able to make changes to production code and introduce the chance of fraud.

Per ISACA, quality assurance usually performs two distinct tasks:

An example of a standard quality-assurance model is the Software Capability Maturity Model (CMM) developed by Carnegie Melon’s Software Engineering Institute. The CMM model provides a framework for improving software life cycle processes and specific metrics to improve the software process. CMM has maturity levels that are designed with continuous process improvement in mind, to increase product and service quality through the implementation of best practices.

Note

Per the CMM model documentation, software process maturity is the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective. The more mature an organization’s software process is, the higher the productivity and quality of the software products produced are. As software process maturity increases, the organization institutionalizes its software process via policies, standards, and organizational structures. This institutionalization entails building an infrastructure and a corporate culture that supports the methods, practices, and procedures of the business so that they endure after those who originally defined them have gone. The CMM maturity levels are shown in Figure 2.2.

Figure 2.2. CMM maturity levels.

IT management can use assessment methods to provide a mechanism to determine whether the activities of the organization have deviated from the planned or expected levels. These methods include IS budgets, capacity and growth planning, industry standards/benchmarking, financial management practices, and goal accomplishment. Quality management is the means by which the IS department processes are controlled, measured, and improved. Management principles focus on areas such as people, change, processes, and security. Industry standards/benchmarking provide a means of determining the level of performance provided by similar information-processing facility environments.

Note

The International Organization for Standardization (ISO) has created the ISO 9000 series, which is implemented by 634,000 organizations in 152 countries. ISO 9000 has become an international reference for quality management requirements in business-to-business dealings. Per ISO, the ISO 9000 family is primarily concerned with “quality management” or what the organization does to fulfill the following:

ISO 9001/9002/9003 contains guidelines about design, development, production, installation servicing, and final inspection/testing.

Per ISO, ISO 9001:2000, “Quality Management Systems,” specifies requirements for a quality-management system. Adherence to these requirements demonstrates that the organization has the capability to consistently provide products that do the following:

All requirements of this international standard are generic and are intended to apply to all organizations, regardless of type, size, and product provided.

Note

ISO 9126 focuses on the end result of good software processes, such as the quality of the actual software product. ISO 9126 provides definitions of the characteristics and associated quality-evaluation process to be used when specifying the requirements for and evaluating the quality of software products throughout the software life cycle. The following are specific definitions associated with the ISO standards.

In conjunction with these standards, organizations can perform certification and accreditation activities. These activities are commonly performed within the U.S. federal government and are defined as follows:

Certification activities include testing systems and their controls to ensure that the systems meet the control objectives. When the certification is complete, any deficiencies are noted and forwarded to the appropriate authority for accreditation. During the accreditation process, the approving authority reviews the results of controls testing and determines the level of risk associated with the deficiencies. If the approving authority determines that the risk associated with the deficiencies is acceptable, the system is allowed to process in an operational environment with a plan to correct the deficiencies (remediation). If the level of risk is beyond an acceptable level, the deficiencies must be corrected before the system can go into operation.

The IS auditor must review quality assurance activities to ensure that quality assurance personnel are creating and reviewing prescribed quality processes. The auditor also must make sure that a standard quality-control process is in place for conducting tests or reviews, to verify and ensure that software and systems are free from defects and that they meet user expectations.

Note

The implementation of strong IS security management ensures the protection of information assets (processing resources and data) through effective policy, controls, standardized procedures, and control testing. As stated earlier, security management applies risk-management principles and techniques to assess IT assets, mitigate the risk to these assets, and monitor residual risks. These are the three tenets of information security:

These tenets are collectively known as the CIA triad. Security management should apply these tenets in the implementation and review of controls within the IT environment. In Chapter 1, you learned about a variety of risk types. Security management implements controls to reduce (mitigate) risk. The following are a list of control categories that reduce risk and help control the IT function:

Developing and implementing a function dedicated to security in the organization ensures that the risks associated with the business and information systems are mitigated through the use of risk-assessment techniques, policies and procedures, and an overall security strategy. The combination of these security controls ensures that the IT infrastructure is protected against both internal and external threats.

The security function must protect the IT infrastructure through the use of physical and logical controls. Physical security controls access to facilities, computers, and telecommunications equipment and other assets of the infrastructure. These controls ensure that only authorized users have access to facilities and that policies are in place so that visitors are logged and accompanied by authorized personnel. The physical facility should be configured so that during the normal course of business, visitors such as vending machine suppliers, workmen, and janitorial and repair personnel are monitored and have access only to the areas required to perform their function. Access to the facility can be controlled through the use of security guards, biometric devices (retina scanners, hand geometry, fingerprint scanners), keys and locks, and electronic card readers. All access points to the facility, including doors, windows, and access vents, should contain physical controls to monitor, detect, and control entry. In the case of windows and vents, the organization might deploy cameras, motion detectors, glass-break detectors, and alarms.

A monitoring system should be in place for the facility. This could include cameras, visitor logs, card entry logs, roving guards, and penetration alarms. It is important to remember that having these controls in place should include defining responsibility for regular review and monitoring. As an example, the visitor logs should be regularly reviewed to ensure that visitors are signing in and out of the facility. The logs associated with key cards should be reviewed to ensure that only authorized individuals have access to the facility and to look for anomalies associated with access (authorized individuals coming in during time frames that are not concurrent with their work hours or attempting to access areas of the facility for which they do not have access).

Physical security controls are most often defeated through the use of social engineering, whereby unauthorized persons gain access to the facility by posing as someone they are not (repairman, authorized vendors, and others). Social engineering is the use of physiological tricks on authorized users to gain access to the system. Unauthorized persons might use techniques such as “shoulder surfing,” looking over the shoulder of authorized users to identify key codes to access the building, or claiming to have “lost” badges or key cards and persuading an authorized user to help them gain access, or piggybacking behind an authorized user with a valid key card.

The IS auditor should regularly perform penetration tests into the facility. These tests might include breaking into access points through the use of persuasion or brute force, or gaining admission as a visitor and trying to access areas for which they are not authorized. The combination of regular review, monitoring, and testing of physical security controls can identify weaknesses and areas for improvement.

As a rule, logical security controls are more complex to implement and maintain, but they are an integral part of maintaining the confidentiality, availability, and integrity of the IT infrastructure. Logical access controls entail access to the information systems (workstations, servers, telecommunications, and data) of the organization. The most common form for logical access to the information systems is through a terminal or workstation. Logical controls ensure that authorized users have a login (ID) and password, and should apply the control of least privilege: Authorized users should have access to only the applications and data they need to perform their job function.

It is important that the security function in the organization not only implement these controls, but also have regular logging and monitoring of logical access to the systems and data. These policies and procedures should include segregation of duties, logging of access (both successful and unsuccessful), and transaction logs monitoring what systems or applications were accessed by whom and when. Proper segregation of duties ensures that those charged with the review of system and transaction logs do not have the ability to change those logs and that there are clear procedures for reporting any anomalies or incidents found in the logs. A variety of controls are included in logical controls; these are some of the controls that the IS auditor should look for:

In addition to internal user accounts, unauthorized users might gain access to applications and data from outside the organization. Unauthorized users could be existing vendors or suppliers who have access to internal systems, authorized internal users who access from remote locations, or unauthorized users (hackers) gaining access through the Internet. In most cases, organizations will have firewalls in place to protect external access through the Internet. The firewall settings (rules) should be the most restrictive possible and should deny all access except that explicitly required by the external users to perform their function. Firewall logs and access should be regularly reviewed and should have a system in place to notify administrators in the event of unauthorized access. The security function should define incident response and reporting procedures to remove access to critical applications and data in the event of external unauthorized access. These procedures can be as extreme as disconnecting the organization’s access to the Internet or can just include removing critical applications for Internet connectivity.

The IS auditor should perform regular review and scanning for known vulnerabilities, as well as attempts to exploit vulnerabilities that are discovered. Penetration testing ensures that the controls in place mitigate the risk in accordance with the system’s value or function. The purpose of performing a penetration test is to exploit one or more known vulnerabilities. The combination of regular monitoring, incident reporting, scanning, and penetration testing enables the organization to identify and correct weaknesses within the current security infrastructure.

An information system converts data into information through its collection and processing. The information systems should produce accurate, complete, timely, and reliable information. The organization must control the risks associated with the collection and processing of this data. The integrity of data in the organization is important because all data, with few exceptions, should be considered influential data. Influential data is used throughout the organization for decision making at all levels in the organization. One of the greatest concerns with regard to data is unauthorized access to the data. This might take place at the point of entry into the information system or through unauthorized manipulation or viewing of the data once in the information system. These threats are both internal and external, and they compromise the confidentiality and privacy of data. Organizations today store and use a large amount of data in their information systems, and they often do not have proper controls in place to protect data access or detect such access.

Table 2.5 lists some common examples of risks associated with data integrity.

We just identified unauthorized access and the manipulation of data and its effect on data integrity. Another effect on the data integrity is the introduction of errors in the data. These errors might be affected through improper system design, lack of procedures or training, or inadvertent misuse of data.

Proper procedures with regard to system development and testing reduce the introduction of errors in the data. During the system development life cycle, the IT organization should ensure that the requirements for the systems are complete, that the system requirements meet the business requirements of the organization, and that application-development procedures continually test against the requirements. The development of the system should include proper controls at the application level (access, validation, and so on) and the database level (proper data element design, validation, constraints, and error handling). Applications and their associated databases should have regular error-handling routines that ensure that the data entered in the systems meets the business rules as well as external guidelines (compliance). The normal process should include the input of data, a validation process, the creation of a suspense file for transactions that do not meet the validation criteria, and a review of the suspense file by authorized parties before making it part of the production data. This process should include proper segregation of duties, ensuring that those entering data have no part in authorizing, reviewing, or approving data.

The security function in the organization should be involved in all aspects of the system development life cycle, to ensure that proper controls are implemented. The security function should provide specific controls for the confidentiality, availability, and integrity of information systems, to mitigate risk in the organization.

We discuss business continuity planning (BCP) and disaster-recovery planning (DRP) in detail in Chapter 5, “Disaster Recovery and Business Continuity,” but it is important to provide definitions and a framework. Although BCP and DRP are commonly interchanged, they are distinctly different. Per ISACA, BCP is a process designed to reduce the organization’s business risk from an unexpected disruption of the critical functions or operations (manual or automated) necessary for the survival of the organization. This includes the human and material resources supporting the critical functions and operations, and assurance of the continuity of the minimum level of services necessary for critical operations.

DRP is generally the plan followed by IS to recover an IT processing facility or by business units to recover an operational facility. The IS recovery plan must be consistent with and must support the overall plan of the organization. Disasters are disruptions that cause critical information resources to be inoperative for a period of time, adversely impacting the business operations.

The proper implementation of BCP ensures that critical business functions can withstand a variety of emergencies. The primary responsibility of BCP lies with management; the goal is to minimize the effects of a disaster so that the organization can resume normal operations as soon as possible. BCP is, at best, an annual project and is effective only if it is continuously performed and tested. During BCP, the organization must define what qualifies as a disruptive event or disaster. When we think of disasters, we might think of fires, floods, tornadoes, or terrorist events. In fact, a disaster can include a variety of events that appear smaller in nature but that have a large effect on the organization’s continuity. As an example, Wall Street brokers would consider a telecommunications outage a disaster: It restricts their customers’ ability to reach them and their ability to perform trading functions. In other businesses, a telecommunications outage would be an annoyance but would not necessarily affect the continuity of the business.

The degree to which a BCP/DRP plan is successful depends on the support and leadership of senior management. Senior management needs to support the plan through development, implementation, and testing, to ensure that the plan will be successful in the event of a disaster. Senior management should establish a BCP policy that includes the commitment of the organization to its stakeholders, shareholders, employees, and partners. This policy should include what aspects of the operation will be included in the BCP/DRP and should define responsibilities throughout the organization.

Per ISACA, an effective BCP has the following components:

Many BCPs fail because of the following:

The BCP process can be complex and includes all levels of the organization. It is important to remember that this will be an emotional time for all personnel involved; the more detailed the plan and testing are, the better the chance is for success. Senior leadership, security, IT, and managers of business units must be involved in the process to achieve success. The business must identify critical business functions and assign responsibility for all the resources involved with those functions (personnel, procurement, replacement, systems, applications, and data). Senior leadership should involve the marketing or communications department, to define specific communications for each event outlined in the plan and directed communication for the stakeholders (shareholders, employees, and partners). The plan should be part of the change-control process and should be regularly tested and updated to reflect the business requirements. Individual roles and responsibilities should be clearly defined, communicated, and updated.

If the organization follows these rules, it can be reasonably sure that the economic viability of the organization will continue in the event of a disaster.

Contracting is generally used when talking about outsourcing, but this is not always the case. Contracts can be between the organization and the customer or partners. A contract is an agreement between or among two or more persons or entities (business, organizations, or government agencies) to do, or to abstain from doing, something in return for an exchange of consideration. If the terms of a contract are breached, the law provides remedies, including recovery of losses or specific performance. A contract is written documentation of a “meeting of the minds” and contains the following five elements:

The IS auditor might encounter a variety of contracts. The following paragraphs outline some of the more common contract types.

The combination of a defined organization structure, policies and procedures, and clearly defined job functions ensures that the IT organization can meet the continuing needs of the organization. The IT department continually faces challenges in the form of competing priorities, shifts in business priorities, and operational firefighting. The fast pace of business demands that the IT function be flexible and prepared for changes, as well as stay focused on the long- and short-term goals of the organization. If the IT function is unable to control change introduced into the environment by internal or external factors, IT staff will find themselves disregarding internal controls and will lead themselves and the organization into chaos.

The IT organization has to perform two high-level functions:

In most cases, clearly defined procedures and controls ensure that the IT organization can continue its operational mission while introducing new technology. The use of the security function, quality assurance, and the IS auditor assist IT leadership in maintaining and improving these controls.

Senior IT leadership is responsible for ensuring that the IT functions provide value to the organization. One of the top priorities is to ensure that the IT strategy aligns with the organization’s strategy; if this strategy is not aligned, IT will move from a position of value within the organization to a cost center with little or no value.

Most IT structures are defined along specific functions such as system development, computer security, computer operations, and user support. During the definition of the structure, management must keep in mind the segregation of incompatible duties. There are four areas of segregation:

Management of the IT infrastructure includes the overall maintenance or systems, user support, problem (incident) management, change management, and quality assurance. The IT department should use industry standards and performance measures to ensure that the IT functions meet the needs of the business through the IT organization’s mission, vision, and strategy. The IT organization should establish policies for all phases of the system development life cycle (SDLC), which entails the acquisition, implementation, maintenance, and disposition of information systems. The SDLC should include computer hardware, network devices, communications systems, operating systems, application software, and data. It is important to note that some or all of the IT function might be outsourced to third-party providers, and those similar policies and procedures should exist in addition to the contract and service-level agreements (SLA).

Ensuring security of the information systems and their associated data is another function associated with the SDLC. Maintaining confidentiality, integrity, and availability of information systems ensures the continued economic viability of the organization. The security function is responsible for securing the physical facilities, hardware and software, and data. In addition, IT management must mitigate the risk associated with the disruption of business activities because of system failures or disasters.