Systems Development and Project Management Audit/Assurance Program

ISACA®
With more than 86,000 constituents in more than 160 countries, ISACA (www.isaca.org) is a
recognized worldwide leader in IT governance, control, security and assurance. Founded in
1969, ISACA sponsors international conferences, publishes the ISACA Journal®, and develops
international information systems auditing and control standards. It also administers the
globally respected Certified Information Systems Auditor™ (CISA ®) designation, earned by
more than 60,000 professionals since 1978; the Certified Information Security Manager ®
(CISM®) designation, earned by more than 10,000 professionals since 2002; and the new
Certified in the Governance of Enterprise IT™ (CGEIT™) designation.

Disclaimer
ISACA has designed and created Systems Development and Project Management
Audit/Assurance Program (the “Work”), primarily as an informational resource for audit and
assurance professionals. ISACA makes no claim that use of any of the Work will assure a
successful outcome. The Work should not be considered inclusive of all proper information,
procedures and tests or exclusive of other information, procedures and tests that are
reasonably directed to obtaining the same results. In determining the propriety of any
specific information, procedure or test, audit/assurance professionals should apply their own
professional judgment to the specific circumstances presented by the particular systems or
IT environment.

Reservation of Rights
© 2009 ISACA. All rights reserved. No part of this publication may be used, copied,
reproduced, modified, distributed, displayed, stored in a retrieval system or transmitted in
any form by any means (electronic, mechanical, photocopying, recording or otherwise)
without the prior written authorization of ISACA. Reproduction and use of all or portions of
this publication are permitted solely for academic, internal and noncommercial use, and
consulting/advisory engagements, and must include full attribution of the material’s source.
No other right or permission is granted with respect to this work.

ISACA
3701 Algonquin Road, Suite 1010
Rolling Meadows, IL 60008 USA
Phone: +1.847.253.1545
Fax: +1.847.253.1443
E-mail: info@isaca.org
Web site: www.isaca.org

© 2009 ISACA. All rights reserved. Page 2

Systems Development and Project Management Audit/Assurance Program

ISBN 978-1-60420-082-9
Systems Development and Project Management Audit/Assurance Program
Printed in the United States of America
ISACA wishes to recognize:
Author
Norm Kelson, CISA, CGEIT, CPA, The Kelson Group, USA

Expert Reviewers
Rafael Eduardo Fabius, CISA, Republica AFAP SA, Uruguay
José Manuel Ballester Fernández, Ph.D., CISA, CISM, CGEIT, IEEE, IT Deusto, Spain
Anuj Goel, Ph.D., CISA, CISSP, Citigroup Inc., USA
Larry Marks, CISA, CGEIT, CFE, CISSP, CSTE, PMP, Resources Global Professionals, USA
Bharath Nallapu, CISA, PMP, Smith, Nallapu & Associates LLP, USA
Kathy A. Rogers, CISA, USA

ISACA Board of Directors
Lynn Lawton, CISA, FBCS, FCA, FIIA, KPMG LLP, UK, International President
George Ataya, CISA, CISM, CGEIT, CISSP, ICT Control SA, Belgium, Vice President
Howard Nicholson, CISA, CGEIT, City of Salisbury, Australia, Vice President
Jose Angel Pena Ibarra, CGEIT, Consultoria en Comunicaciones e Info. SA & CV, Mexico, Vice
President
Robert E. Stroud, CA Inc., USA, Vice President
Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Vice President
Frank Yam, CISA, CIA, CCP, CFE, CFSA, FFA, FHKCS, FHKIoD, Focus Strategic Group Inc., Hong
Kong, Vice President
Marios Damianides, CISA, CISM, CA, CPA, Ernst & Young, USA, Past International President
Everett C. Johnson Jr., CPA, Deloitte & Touche LLP (retired), USA, Past International President
Gregory T. Grocholski, CISA, The Dow Chemical Company, USA, Director
Tony Hayes, Queensland Government, Australia, Director
Jo Stewart-Rattray, CISA, CISM, CSEPS, RSM Bird Cameron, Australia, Director

Assurance Committee
Gregory T. Grocholski, CISA, The Dow Chemical Company, USA, Chair
Pippa G. Andrews, CISA, ACA, CIA, Amcor, Australia
Richard Brisebois, CISA, CGA, Office of the Auditor General of Canada, Canada
Sergio Fleginsky, CISA, ICI, Uruguay
Robert Johnson, CISA, CISM, CISSP, Executive Consultant, USA
Anthony P. Noble, CISA, CCP, Viacom Inc., USA
Robert G. Parker, CISA, CA, CMC, FCA, Deloittte & Touche LLP (retired), Canada
Erik Pols, CISA, CISM, Shell International - ITCI, Netherlands
Vatsaraman Venkatakrishnan, CISA, CISM, CGEIT, ACA, Emirates Airlines, UAE

© 2009 ISACA. All rights reserved. Page 3

............ Purpose The audit/assurance program is a tool and template to be used as a road map for the completion of a specific assurance process............... Closure Phase.................................................................. Controls Maturity Analysis............ Initiation Phase........................ Planning Phase......................... sections 3400—IT Management Processes........... 3600—IT Audit and Assurance Processes.......... and reflect ITAF............... tools and templates to provide direction in the application of IT audit and assurance processes......................Systems Development and Project Management Audit/Assurance Program Table of Contents I.........................................4 II............ Audit/Assurance Program....................................... The tools and techniques provide methodologies......................................................9 V........................................ Execution Phase...................................................................................17 4............. Since COSO is widely used...........................................11 VI................ Target Maturity........................................... The audit/assurance programs are part of ITAF............................... Postimplementation Phase........................... Executive Summary of Audit/Assurance Focus............14 2...................... section 4000—IT Assurance Tools and Techniques................................ Using This Document.................. This audit/assurance program is intended to be utilized by IT audit and assurance professionals with the requisite knowledge of the subject matter under review.................71 VII......................................17 3.................................................24 5........... The guidelines provide information and direction for the practice of IT audit and assurance.... Assessment Maturity vs..........8 IV........ Assurance and Control Framework....................77 VIII............................................................................... The importance of the control framework has been enhanced due to regulatory requirements by the US Securities and Exchange Commission (SEC) as directed by the US Sarbanes-Oxley Act of 2002 and similar legislation in other countries...................... Introduction......................1— using generally applicable and accepted good practices.....................................44 6.... as described in ITAF................................. The reviewer may delete or rename these columns to align with the enterprise’s control framework................................................................14 1.. All rights reserved.............................................. Planning and Scoping the Audit. Maturity Assessment........................................97 I........................... © 2009 ISACA........ Introduction Overview ISACA has developed the IT Assurance FrameworkTM (ITAFTM) as a comprehensive and good-practice- setting model....................... and 3800—IT Audit and Assurance Management.................................................................................... Page 4 ................ Many organizations have embraced several frameworks at an enterprise level........................................... Understanding Supporting Infrastructure...................................67 7...................5 III....... Control Framework The audit/assurance programs have been developed in alignment with the IT Governance Institute ® (ITGITM) Control Objectives for Information and related Technology (COBIT®)—specifically COBIT 4....................... including the Committee of Sponsoring Organizations of the Treadway Commission (COSO) Internal Control Framework........... The ISACA Assurance Committee has commissioned audit/assurance programs to be developed for use by IT audit and assurance practitioners..................................... it has been selected for inclusion in this audit/assurance program............... They seek to integrate control framework elements used by the general audit/assurance team into the IT audit and assurance framework.......................................................................................... section 2200—General Standards......... ITAF provides standards that are designed to be mandatory and are the guiding principles under which the IT audit and assurance profession operates........

The specific test process follows the test objective. The first-level steps. II. Controls are the primary evaluation point in the process. the audit/assurance program describes the audit/assurance objective—the reason for performing the steps in the topic area. The IT audit and assurance professional is encouraged to make modifications to this document to reflect the specific environment under review. or has the necessary subject matter expertise required to conduct the work and is supervised by a professional with the CISA designation and necessary subject matter expertise to adequately review the work performed. Work Program Steps The first column of the program describes the steps to be performed. The specific controls follow and are shown in blue type. Each review step is listed below the control. or otherwise verifying the process and the controls that address that process.. specific tests need to be performed to provide assurance that the process associated with the control is being followed. Risk plays an important role in evaluating what to audit and how management approaches and manages risk. It is assumed that the IT audit and assurance professional holds the Certified Information Systems Auditor (CISA) designation. 1. It may be modified by the IT audit and assurance professional. The physical document was designed in Microsoft ® Word. The audit/assurance program is segmented according to phase. Test objectives are shown in green type. All rights reserved. are in bold type and provide the reviewer with a scope or high-level explanation of the purpose for the substeps. The audit and assurance professional should customize and select those phases within the scope of the specific audit/assurance review. Because the pre-fieldwork is essential to a successful and professional review. Both issues will be evaluated as steps in the audit/assurance program. Steps 1 and 2 are part of the fact gathering and pre-fieldwork preparation.Systems Development and Project Management Audit/Assurance Program IT Governance Risk and Control IT governance. Responsibilities of IT Audit and Assurance Professionals IT audit and assurance professionals are expected to customize this document to the environment in which they are performing an assurance process. Governance of the process under review will be evaluated as part of the policies and management oversight controls. Beginning in step 3. To simplify the use of the program. risk and control are critical in the performance of any assurance management process. In many cases. and is addressed in the Internal Controls section of this program. observing. Page 5 . the evaluation of specific application-based internal controls is often within the scope. the steps associated with the work program are itemized. it is not intended to be a checklist or questionnaire. The Systems Development and Project Management Audit/Assurance Program is intended to be utilized © 2009 ISACA. Using This Document This audit/assurance program was developed to assist the audit and assurance professional in designing and executing a review over the various phases of the project.g. and other C OBIT-related subjects that are impacted by the project. The numbering scheme used provides built-in work paper numbering for ease of cross-reference to the specific work paper for that section. In addition. This document is to be used as a review tool and starting point. e. The audit and assurance professional is encouraged to utilize sections of other audit/assurance programs addressing specific applications. IT operations. interviewing. the steps have been itemized in this plan. The audit/assurance program will identify the control objectives and the steps to determine control design and effectiveness. These steps may include assessing the control design by walking through a process.1. Details regarding the format and use of the document follow. once the control design has been verified.

Since COSO is the most prevalent internal control framework. This ties the assurance work to the enterprise’s control framework. he/she should refer to C OBIT 4. information and communication. © 2009 ISACA. The two frameworks are compared in figure 1. are grayed out. if relevant. report writing and report clearing—has been excluded from this document. since it is standard for the audit/assurance function and should be identified elsewhere in the enterprise’s standards. ERM is in the process of being adopted by large enterprises. COBIT Cross-reference The COBIT cross-reference provides the audit and assurance professional with the ability to refer to the specific COBIT control objective that supports the audit/assurance step. As such. but not generally necessary. ISACA has elected to utilize the five component model for these audit/assurance programs.1 or the IT Assurance Guide: Using COBIT for good-practice control guidance. The original COSO internal control framework addresses the needs of the IT audit and assurance professional: control environment. risk assessment. It is possible. The primary difference between the two frameworks is the additional focus on ERM and integration into the business decision model. which is described in more detail later in this document. The original COSO internal control framework contained five components. In all phases. in specific systems. preparation of issues and recommendations. COSO Components As noted in the introduction. As more enterprises implement the ERM model.Systems Development and Project Management Audit/Assurance Program during the various phases of the project. project management is addressed. the additional three columns can be added. When completing the COSO component columns. development processes and controls will vary based on that phase. and summarize assurance activities to the audit committee of the board of directors. to extend this analysis to the specific audit step level. As the professional reviews each control. Page 6 . COBIT provides in-depth control objectives and suggested control practices at each level. consider the definitions of the components as described in figure 1. control activities. All rights reserved. For each control. However. COSO and similar frameworks have become increasingly popular among audit and assurance professionals. makes up the last section of the program. Those control areas not applicable. This gives the professional the opportunity to to add them back into the plan if appropriate. and monitoring. The maturity assessment. The C OBIT control objective should be identified for each audit/assurance step in the section. Many audit/assurance enterprises include the COSO control components within their report. COSO was revised as the Enterprise Risk Management (ERM) Integrated Framework and extended to eight components. The audit/assurance plan wrap-up—those processes associated with the completion and review of work papers. In 2004. Multiple cross-references are not uncommon. it has been included in this document and is a bridge to align IT audit/assurance with the rest of the audit/assurance function. the audit and assurance professional should indicate the COSO component(s) addressed. While the IT audit/assurance function has COBIT as a framework operational audit and assurance professionals use the framework established by the enterprise. The audit/assurance program is organized in a manner to facilitate an evaluation through a structure parallel to the development process. Processes at lower levels in the work program are too granular to be cross-referenced to COBIT.

They include a range of activities as diverse as approvals. Information for figure 1 was obtained from the COSO web site www. financial and compliance-related information that make it enable people to carry out their responsibilities. a link to the work paper can be pasted into this column. across. Information and Communication: Information systems play a key Information and Communication: Relevant information is role in internal control systems as they produce reports. Risk assessment is a prerequisite for determining how the risks should be managed. The potential findings should be documented in a work paper that indicates the disposition of the findings (formally reported. regulators and shareholders. authority systems. Control activities occur throughout the organization. separate evaluations or both. The numbering system of this document provides a ready numbering scheme for the work papers. security of assets and segregation of duties. authorizations. integrity and ethical values. Control environment factors include the philosophy and risk appetite.htm. In a broader sense. Effective communication should also be ensured with external parties. A precondition to risk impact. flowing down. and the integrity. Control Activities: Control activities are the policies and procedures Control Activities: Policies and procedures are established and that help ensure management directives are carried out. accepting. the identification and analysis of relevant risks to achievement of assigned objectives. If desired. captured. It is tone of an organization. and communicated in a form and timeframe that operational. across and up and up the entity. reducing or sharing risk–developing a set of actions to align risks with the entity’s risk tolerances and risk appetite. Monitoring is accomplished time. Enterprise risk management ensures that management has in place a process to set objectives and that the chosen objectives support and align with the entity’s mission and are consistent with its risk appetite. Effective possible to run and control the business. ethical values. separate evaluations. delegation of environment in which they operate. Event Identification: Internal and external events affecting achievement of an entity’s objectives must be identified. Risk assessment is establishment of objectives. of the entity's objectives. management’s operating style. They help implemented to help ensure the risk responses are effectively carried ensure that necessary actions are taken to address risks to achievement out. providing addressed by an entity’s people. which describes the work performed. Risk Assessment: Every entity faces a variety of risks from external Risk Assessment: Risks are analyzed. such as customers. distinguishing between risks and opportunities. Issue Cross-reference This column can be used to flag a finding/issue that the IT audit and assurance professional wants to further investigate or establish as a potential finding. This is accomplished through ongoing monitoring activities or through ongoing management activities. All rights reserved. at all levels and in all functions. suppliers.coso. Opportunities are channeled back to management’s strategy or objective-setting processes. and thus risk assessment is areas are assessed on an inherent and residual basis. Reference/Hyperlink Good practices require the audit and assurance professional to create a work paper for each line item. and sets the basis for how risk is viewed and the foundation for all other components of internal control. communication must ensure information flows down. Internal control deficiencies detected through these monitoring activities should be reported upstream and corrective actions should be taken to ensure continuous improvement of the system. Monitoring: Internal control systems need to be monitored—a Monitoring: The entirety of enterprise risk management is monitored process that assesses the quality of the system’s performance over and modifications made as necessary. verifications. Risk Response: Management selects risk responses–avoiding. considering the likelihood and and internal sources that must be assessed. the organization. Page 7 . reconciliations. including risk management discipline and structure. including identified. influencing the control consciousness of its people. reviews of operating performance.org/aboutus. Objective Setting: Objectives must exist before management can identify potential events affecting their achievement.Systems Development and Project Management Audit/Assurance Program Figure 1—Comparison of COSO Internal Control and ERM Integrated Frameworks Internal Control Framework ERM Integrated Framework Control Environment: The control environment sets the tone of an Internal Environment: The internal environment encompasses the organization. effective communication also occurs in a broader sense. reported as a memo or verbal © 2009 ISACA. as well as the processes for managing and developing people in the organization. as a basis for determining how they could be managed. issues identified and conclusions. The reference/hyperlink is to be used to cross-reference the audit/assurance step to the work paper that supports it.

support the analysis and ensure that an IT process owner Employees are aware of their responsibilities for control. Controls Maturity Analysis One of the consistent requests of stakeholders who have undergone IT audit/assurance reviews is a desire to understand how their performance compares to good practices. Improvement strategies are supported by business cases. 3 Defined Controls are in place and adequately documented. selected IT processes to determine the current level of control Effectiveness is not adequately evaluated. There is no intent to assess the need for internal control. Many control maturity. IT © 2009 ISACA. It shows how the management of internal control. provides a generic maturity model showing the status of the internal control environment and the establishment of internal controls in an enterprise. The model provides a high-level guide to help COBIT users appreciate what is required for effective internal controls in IT and to help position their enterprise on the maturity scale. is used to issues are not prioritized or consistent. Control is not part of the organization’s culture or mission. Operating Critical IT processes are identified based on value and risk effectiveness is evaluated on a periodic basis and there is an drivers. The IT Assurance Guide Using COBIT. Maturity modeling for management and control over IT processes is based on a method of evaluating the organization. their responsibilities. the that exist. following a thorough but not all issues are routinely identified. III.Systems Development and Project Management Audit/Assurance Program finding. documented evaluation of controls and agreement from the relevant business process owners. Management actions to resolve control managers and the team involved in the process. This approach is derived from the maturity model that the Software Engineering Institute (SEI) of Carnegie Mellon University defined for the maturity of software development. Figure 2—Maturity Model for Internal Control Maturity Level Status of the Internal Control Environment Establishment of Internal Controls 0 Non-existent There is no recognition of the need for internal control. occurs frequently. Performance in achieving the desired outcomes is consistently monitored. tools are used and interviews are performed to weaknesses persist and impacts could still be severe. Audit and assurance professionals must provide an objective basis for the review conclusions. follow-up to address identified control weaknesses. When performed. It is not to be used in place of a work paper describing the work performed. However. Employees may not define an adequate approach to controls for the process and to be aware of their responsibilities. and an awareness of the need to establish better internal controls. There is a high risk of control deficiencies and incidents. the actual maturity of these processes. so it can be rated from a maturity level of nonexistent (0) to optimized (5). without communication or monitoring. A formal. the target level that should be reached and the gaps weaknesses exist and are not adequately addressed. some control workshops. cover any need to reassess process control capability. typically develops from an ad hoc to an optimized level. A detailed analysis is performed to identify control average number of issues. owns and drives the assessment and improvement process. In addition to facilitated predictably with most control issues. involving IT impact can be severe. Management is likely to detect most control issues. A limited. While management is able to deal improvement opportunities. 4 Managed and There is an effective internal control and risk management IT process criticality is regularly defined with full support Measurable environment. an ad hoc basis. 5 Optimized An enterprisewide risk and control program provides Business changes consider the criticality of IT processes and continuous and effective control and risk issues resolution. Incidents are dealt with as they arise. Appendix VII—Maturity Model for Internal Control. at a high level and in reaction to significant Deficiencies are not identified. Their operation Assessment of control needs occurs only when needed for Intuitive is dependent on the knowledge and motivation of individuals. An informal workshop approach. 2 Repeatable but Controls are in place but are not documented. motivate an agreed-upon action plan. There is no awareness of the need for assessment of what is The approach to risk and control requirements is ad hoc and needed in terms of IT controls. or waived). Accountability for these assessments is clear and enforced. in figure 2. Many controls are automated and regularly Assessment of control requirements is based on policy and reviewed. Assessment addresses only the actual incident. Page 8 . There is consistent and measured analysis involving key stakeholders. tactical use of technology is applied to automate controls. 1 Initial/ad hoc There is some recognition of the need for internal control. All rights reserved. External control reviews are organized occasionally. it is only on disorganized. Employees are not aware of incidents. the evaluation process is requirements and the root cause of gaps and to develop not documented. or other notations. Comments The comments column can be used to indicate the waiving of a step.

75) to indicate gradations in the maturity model. based on self-assessments and gap benchmarks to external best practices and seeks external and root cause analyses. supported with automated real-time that controls are at the right level of maturity to meet business monitoring with full accountability for control monitoring. Some practitioners utilize decimals (x. However. All rights reserved. ISACA Controls Framework © 2009 ISACA. it must be noted that the perception as to the maturity level may vary between the process/IT asset owner and the auditor. The IT audit/assurance professional can address the key controls within the scope of the work program. The organization evaluation is continuous. based on sample assessments. As a further reference. the process is provided as a separate section at the end of the audit/assurance program for those enterprises that wish to implement it.25. independent reviews take place to provide assurance that the controls are at the desired level of maturity and working as planned. Using the assessed and target maturity levels. It is suggested that a maturity assessment be made at the COBIT control level. once all findings and recommendations are completed. processes. and assigns it a maturity level using the six- level scale. Employees are proactively involved advice on internal control effectiveness. The maturity assessment can be a part of the audit/assurance report and can be used as a metric from year to year to document progression in the enhancement of controls. Therefore. Control make controls more efficient and effective. x. A graphic is provided as the last page of the document (section VIII). COBIT provides a definition of the maturity designations by control objective. While this approach is not mandatory. G26 Business Process Reengineering (BPR) Project Reviews and G29 Post-implementation Review. IS Auditing Guidelines G23 System Development Life Cycle (SDLC) Review. the professional can create an effective graphic presentation which describes the achievement or gaps between the actual and targeted maturity goals. Assurance and Control Framework ISACA IT Assurance Framework and Standards Systems development and project management are included in ITAF and the following are the relevant sections:  3420—IT Project Management  3450—IT Processes  3490—IT Support of Regulatory Compliance  3630. and formulate an objective assessment of the maturity level of the control practices. Guidelines and procedures provide detailed guidance on how to follow those standards.5. and IS Auditing Procedure P10 Business Application Change Control are relevant to this audit/assurance program. the professional assesses the current state of the COBIT control framework.8—Systems Development Life Cycle  3650—Auditing Application Controls  3657—Auditing Alternative Software Development Strategies ISACA has long recognized the specialized nature of IT assurance and strives to advance globally applicable standards. an auditor should obtain the concerned stake holder’s concurrence before submitting the final report to the management. At the conclusion of the review. To provide further value to the client/customer. x. needs and they consider maturity attributes to find ways to risk management and compliance enforcement. Page 9 . IV. the professional can also obtain maturity targets from the client/customer. The maturity model evaluation is one of the final steps in the evaluation process. For critical in control improvements.Systems Development and Project Management Audit/Assurance Program Figure 2—Maturity Model for Internal Control Maturity Level Status of the Internal Control Environment Establishment of Internal Controls Internal control and risk management are integrated with process owners regularly perform self-assessments to confirm enterprise practices.

Utilizing COBIT as the control framework on which IT audit/assurance activities are based aligns IT audit/assurance with good practices as developed by the enterprise. execution of a risk analysis and cost-benefit analysis. and the acquisition itself. This process requires the production of documentation and manuals for users and IT. implementation and upgrade of the technology infrastructure. review of technological and economic feasibility. approval by users. software and services. The C OBIT areas for this evaluation include:  PO10 Manage projects—A program and project management framework for the management of all IT projects is established. This process covers the design of the applications.’ All these steps enable organizations to minimize the cost to acquire and implement solutions while ensuring that they enable the business to achieve its objectives. All rights reserved.  AI7 Install and accredit solutions and changes—New systems need to be made operational once development is complete. the Plan and Organize (PO) domain. a formal test plan. the selection of vendors. C OBIT enables clear policy development and good practice for IT control throughout enterprises. The framework includes a master plan. improves communications to and involvement of business and end users. need to be procured. published in 2007.  AI4 Enable operation and use—Knowledge about new systems is made available. QA. technical issues and business risks. The framework ensures the correct prioritization and coordination of all projects. and maximizes their contribution to IT-enabled investment programs. definition of deliverables.Systems Development and Project Management Audit/Assurance Program COBIT is an IT governance framework and supporting tool set that allows managers to bridge the gap among control requirements. This process covers the definition of the needs. Executive Summary of Audit/Assurance Focus © 2009 ISACA. and the development and configuration in line with standards. the proper inclusion of application controls and security requirements. definition of rollout and migration instructions. V. and provides training to ensure the proper use and operation of applications and infrastructure. including people. 2nd Edition. Page 10 . Refer to the IT Governance Institute’s COBIT Control Practices: Guidance to Achieve Control Objectives for Successful IT Governance. maintenance and protection of infrastructure in line with agreed-upon technology strategies and the provision of development and test environments. for the related control practice value and risk drivers. assignment of resources. ensures the value and quality of project deliverables.  AI2 Acquire and maintain application software—Applications are made available in line with business requirements. hardware. This requires proper testing in a dedicated environment with relevant test data. and conclusion of a final decision to ‘make’ or ‘buy. the setup of contractual arrangements. The COBIT Acquire and Implement (AI) domain addresses good practices for systems development. consideration of alternative sources. and a post-implementation review. release planning and actual promotion to production. This allows organizations to properly support business operations with the correct automated applications. This requires the definition and enforcement of procurement procedures.  AI1 Identify automated solutions—The need for a new application or function requires analysis before acquisition or creation to ensure that business requirements are satisfied in an effective and efficient approach. Doing so ensures that the organization has all required IT resources in a timely and cost-effective manner.  AI3 Acquire and maintain technology infrastructure—Organizations have processes for the acquisition. This assures that operational systems are in line with the agreed-upon expectations and outcomes. IT process PO10 addresses managing projects. This requires a planned approach to acquisition. This approach reduces the risk of unexpected costs and project cancellations.  AI5 Procure IT resources—IT resources. and testing and post- implementation review after installation to ensure project risk management and value delivery to the business. a phased approach to delivery. This ensures that there is ongoing technological support for business applications.

Systems Development and Project Management Audit/Assurance Program

Systems Development and Project Management
The systems development methodology (sometimes referred to as the systems development life cycle) is
composed of the phases deployed in the development or acquisition of a software system. Experience has
shown that development of a new system cannot be executed in a vacuum. The business must be involved
as the driver, owner and overall manager of the project. The IT development team is a member of this
overall project team that is responsible for executing technical development of the business plan.
Therefore, the key to success of any IT initiative is to consider the project as part of a larger scope, which
is the implementation of a business solution. To keep the project on track, it is necessary to provide
project management, a structured set of activities concerned with delivering to the enterprise a defined
capability (that is necessary but not sufficient to achieve a required business outcome) based on an
agreed-upon schedule and budget. Many entities use the expression “program” to describe a business
initiative. The definition of program, a structured grouping of interdependent projects that includes the
full scope of business, process, people, technology and organizational activities that are required (both
necessary and sufficient) to achieve a clearly specified business outcome, is a superset of a project.

Systems development has traditionally used the waterfall approach, a procedure-focused development
cycle with formal sign-off at the completion of each level. The processes include:
 Feasibility study
 Requirements study
 Requirements definition
 Detailed design
 Programming
 Testing
 Installation/accrediation
 Postimplementation review

With the advent of prototyping, fourth-generation programming language (4GL) application development
tools and other approaches, more dynamic frameworks were required. These include: PMBOK, 1
PRINCE2,2 Agile,3 RUP4 and Spiral.5 While each framework utilizes different naming conventions, the
key processes are common to all:
 Initiation—Preparation of the initial concept, business case, scope, creation of project team, and
preparation and approval of budget and capital expenditure requests
 Planning—Preparation of the detailed plan, requirements definition, acquisition cycle and acquisition
of external consulting assistance
 Execution—Execution of project plan once planning phase is completed to the go-live phase.
Subphases of the phase include:
– Creating business processes (automated and manual), instructions and training
– Establishing controls
– Establishing conversion and transition processes, balancing routines, and verification of process

1
Project Management Body of Knowledge is a project management standard developed by the Project Management Institute
(PMI).
2
Projects in a Controlled Environment was developed by The Open Geospatial Consortium Inc., an international industry
consortium of companies, government agencies and universities participating in a consensus process to develop publicly
available interface specifications.
3
RAD, developed by James Martin, was built on prototyping.
4
Rational Unified Process is an iterative software development process framework created by the Rational Software
Corporation, a division of IBM.
5
This software development process combines elements of both design and prototyping-in-stages, in an effort to combine
advantages of top-down and bottom-up concepts.

© 2009 ISACA. All rights reserved. Page 11

Systems Development and Project Management Audit/Assurance Program

accuracy and completeness
– Testing:
- Business processes
- Conversion
- Stress testing the processes
- Fallbacks
 Implementation
 Reconciliation of conversion
 Go live—Activities associated with the commencement of the new process
 Closure—Closing project, accounting and costs finalized
 Postimplementation:
– Review of the project success
– Financial review of the business case vs. results

The decision to perform reviews at each phase is dependent upon the risks identified and the reliance
being placed on the application. The most important phases to audit/assurance professionals include
planning, execution and postimplementation. The initiation phase may require review if the business case
is questioned. It is recommended that the go-live phase be reviewed after the fact as a part of a
postimplementation review to ensure that the audit/assurance process does not interfere with the go-live
activities.

The systems development process occurs over a period of time, which can range from a few short weeks
for a small project to several years for large-scale projects and/or programs. For larger projects with
extended durations, it may be necessary to schedule multiple reviews of the same project. The timing of
the review needs to be in alignment with the development schedule and key milestone dates.

Business Impact and Risk
Applications developed or acquired are the backbone of the business’s operations. These systems (both
automated and manual) provide input into the financial reporting systems, are the source for analysis
related to business decisions, and either perform or control processes critical to the business’s livelihood.
Failure to implement good-practice systems development and project management may result in:
 Inappropriate supplier selection
 Solution failing to meet business and/or user requirements, not performing as expected, or unable to
integrate with the strategic IT plan, information architecture and technology direction
 Misunderstanding of project objectives and requirements
 Insufficient stakeholder participation in defining requirements and reviewing deliverables
 Incorrect solution selected or significant missing requirements discovered later in the project,
causing costly reworking and implementation delays
 Alternate solutions not identified
 High costs of fragmented solutions
 Contractual discrepancies and gaps between business expectations and supplier capabilities
 Management unaware of risks in the acquisition of software
 Gaps between controls and actual threats or risks
 System security and confidentiality compromised
 Invalid transactions or transactions processed incorrectly
 Costly compensating controls
 Reduced system availability and questionable integrity of information
 Poor software quality, inadequate testing and a high number of failures
 Disorganized and ineffective approach to project management, inappropriate priorities, delayed

© 2009 ISACA. All rights reserved. Page 12

Systems Development and Project Management Audit/Assurance Program

critical functions, inappropriate priorities
 Inadequate budgets and resources
 Failure to respond to project issues with optimal and approved decisions
 Unclear responsibilities and accountabilities for ensuring cost control and project success
 Increased reliance on key staff, problems in daily operations, help desk overload
 Inability to implement new system or ability to back-out new system and restore old system

Objectives and Scope
Objectives—The objectives of the systems development and project management audit/assurance review
are to:
 Provide management with an independent assessment of the progress, quality and attainment of
project/program objectives at defined milestones within the project/program
 Provide management with an evaluation of the internal controls of proposed business processes at a
point in the development cycle where enhancements can be easily implemented and processes
adapted
 Satisfy process audit/assurance objectives in reviewing the process before it goes live, place future
reliance on the process based upon the assurance work performed while the application is under
development, and implement integrated computer-assisted audit techniques (CAATs) as part of the
design of the application

Scope—The review will focus upon the (initiation/planning/execution/closure/postimplementation) phase
of the systems development process for the {insert application name}. It will rely upon the systems
development methodology to provide a design, development, and testing methodology and the project
management methodology to provide accurate and efficient planning, budgeting and cost control. Within
each phase, the review will address:
 Governance
 Project management
 Budget
 Internal controls
 Business process
 Third-party providers and other external influences

The scoping of the systems development and project management program must be further modified as
appropriate for the application and process under development. It may be necessary to take steps from the
Generic Applications audit program to supplement this program as necessary.

Minimum Audit Skills
The IT audit and assurance professional must have an understanding of the good-practice systems
development and project management processes. Those professionals having achieved CISA certification
should have these skills. Technical skills necessary to perform some audit steps may require specific
understanding of the operating system environments in use, library management systems and computer-
assisted audit techniques (CAATs).

© 2009 ISACA. All rights reserved. Page 13

1. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 1 . subject to a later risk assessment.1.2. 1. 1.1. annual plan and charter. 1. 1.2 Define boundaries of review. © 2009 ISACA.1. All rights reserved. The review must have a defined scope. 1.1 Determine what phase the project is in. 1.2. 1.2.4 Obtain a list of the Sarbanes-Oxley critical applications. Page 14 .2.1. 1.2 Modify the audit/assurance objectives to align with the audit/assurance universe. Systems Development and Project Management Audit/Assurance Program VI. 1.2.1.2. 1. Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.1 Define audit/assurance objectives. Cross.5 Obtain a list of implemented new systems or major enhancements to existing systems for the period under test. The reviewer must understand the operating environment and prepare a proposed scope.1.2 Obtain a list of implemented changes to production for the test period.2.2 Establish initial boundaries of the audit/assurance review.1 Review the audit/assurance objectives in the introduction to this audit/assurance program.1 Perform a high-level walkthrough of the project to be reviewed.3 Determine the applications and/or operating environments serviced by the project. The audit/assurance objectives are high level and describe the overall audit goals. PLANNING AND SCOPING THE AUDIT 1.

3 Define assurance.3 Review all phases and steps within this audit/assurance program.4 Identify and document risks. systems development methodology manual. The risk-based approach ensures utilization of audit resources in the most effective manner.3. audit resources are not available for all processes. 1.2 Consider additional steps as required based on the scope established. Page 15 . Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.2.2 Determine if COBIT and the appropriate systems development framework will be used as a good-practice reference. 1. At minimum.2. The corporate standards defined in policy and procedure documentation establish the corporate expectations.2. 1.3. establishes industry standards. The review requires two sources of standards.1 For the project identified as potentially being inscope: © 2009 ISACA.1 Identify limitations and/or constraints affecting audit of specific systems. a good-practice reference.3.1 Select those steps within the phase that are applicable to the scope and boundaries established.2. 1. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 1.2. 1.3. 1. The risk assessment is necessary to evaluate where audit resources should be focused.1 Obtain company systems development standards. project management standards and project methodology manual. Enhancements should be proposed to address gaps between the two.3 Consider using additional audit/assurance programs for application specific and IT operational issues.2. The second source.4. 1. In most entities. corporate standards should be implemented. 1. Cross. All rights reserved. 1.3.

The success factors need to be identified.4. 1.4. Page 16 .1 Identify the senior IT assurance resource responsible for the review. and adjust the risk assessment.1.3 Discuss the risks with IT. The initial audit approach is based upon the reviewer’s understanding of the operating environment and associated risks.4. 1. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 1. 1.2 Establish the process for suggesting and implementing changes to the audit/assurance program and required authorizations.5. Cross. 1.5. Communication among the IT audit/assurance team.1. 1. 1.2 Identify the technology risks associated with the application being developed.6 Define assignment success. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.4. © 2009 ISACA. other assurance teams and the enterprise is essential. All rights reserved.3 Evaluate business and technology risks. revise scope. As further research and analysis is performed.4 Based on the risk assessment. 1.1.1 Identify the business risk associated with the application being developed.4. identify changes to the scope. business and operational audit management.1 Identify the drivers for a successful review (This should exist in the assurance function’s standards and procedures). 1.2 Based on the risk assessment. 1.6. changes to the scope and approach will result. 1.5 Define the change process.4.

1 Determine the interim deliverables. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. processes.1 The systems development and project management process are supported by entity standards.8. including initial findings. The resources required are defined in the introduction to this audit/assurance program.2 Communicate success attributes to the process owner or stakeholder and obtain agreement.1.7. Page 17 .9 Communications The audit/assurance process is clearly communicated to the customer/client. 2.1.9. Cross.1 Review project management documentation and establish an understanding of the process and its controls. 2. All rights reserved. Communications between the audit/assurance teams and the process owner are essential to assignment success. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 1. draft reports. 1. 1. 2 . 1.7 Define audit/assurance resources required. 1. 1.2 Determine estimated total resources (hours) and time frame (start and end dates) required for review.1 Conduct an opening conference to discuss the review objectives with the executive responsible for operating systems and infrastructure. 1. To properly evaluate the process. The deliverable is not limited to the final report. 1.2 Review systems development documentation and establish an understanding of the © 2009 ISACA. status reports. the supporting infrastructure needs to be reviewed and evaluated. due dates for responses and the final report.6.7.1 Determine audit/assurance skills necessary for review.8 Define deliverables. UNDERSTANDING SUPPORTING INFRASTRUCTURE 2. and procedures.

1. estimated ME4. Page 18 .3 3. procurement of that service is a part of this phase. business case.2 X X study. 3 . expected benefits. Communications and escalation procedures should be in place to allow management to respond to issues as they arise. The PO10. Scope management AI1. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference process and its controls.1. If a third- party is required during the initiation phase.4 © 2009 ISACA. 3. All rights reserved. INITIATION PHASE The initiation phase addresses preparation of the initial concept. and technical resources are assigned. 3. 3.1. creation of project team.2 Review the business case to determine if it describes the reason for the request. cost savings or revenue generation. ME4.1 Governance Audit/assurance objective: Management should provide adequate governance over the project to ensure that the project is adequately defined and approved by senior management and the business.1 Control: The initial scope of the project has been established through a feasibility AI1. AI1.3 Interview the stakeholders to determine their involvement in the process.1. 3.2 X business case is the rationale for initiating the project. estimated cost.1.1 Obtain the business case document. scope. Business case PO10.1 Control: A business case has been prepared and reviewed by management.4 Review the basis for the business case to determine if the assumptions used to justify the project were supported.1.2 costs.1.3 project plan.1. Cross. Procedures should be defined to keep management informed of the progress. alignment with the IT architecture and the development of an initial high-level AI1. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. and key attributes to evaluate the success of the project. estimated return on investment (ROI) and key performance indicators (KPIs) for the project. and preparation and approval of budget and capital expenditure requests. expected benefits.

3.5 Control: The responsibility for the project is assigned to senior stakeholders from the X X X X AI1.1. © 2009 ISACA. determine how the scoping decisions are achieved and whether they support the objectives of the enterprise. Identify the project leader. Cross.1. 3.9 Determine if a steering committee has been established to oversee this project. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 3.4 Control: The project is approved by senior management.1. PO10.4 affected business units and IT. Page 19 . IT is leading the process).13 Determine the role of the steering committee.1. 3.1. 3. All rights reserved.1.8 Determine if appropriate levels of management have reviewed the initial scope. 3.1.1. 3.1. Roles and responsibilities ME1.7 If a feasibility study had not been performed.4 3.1 Approvals PO5.1. 3.1. determine the effect of this leadership on the project. and the approvals are documented. 3. depending on the investment PO10.g.1.6 Based upon the feasibility document and interviews with management.1. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.1.14 Determine if the senior project team has been assigned and report to the steering committee. If the leader is not from the business (e.4 AI1. PO5. review the charter or similar document.1.5 Obtain the initial feasibility study.12 Determine if the business units affected by the project are represented in the steering committee at the appropriate executive level. determine if the scope of the project was appropriately defined.3 X X X and criticality of the project.10 Determine the executive sponsor and chairperson of the steering committee.11 Determine if the chairperson has adequate authority to lead this project.1.1.1.1. and determine if he/she is at the appropriate authority level to approve the project. obtain evidence of his/her approval of the project.1. 3.1.15 Determine who the senior executive responsible for the project is..1.

Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.5 X X Control: Metrics to objectively evaluate the success of a project are established.17 Determine if the approvals are in compliance with organizational policies.21 Obtain the escalation procedure and evaluate the control design to ensure timely response.3 Control: Buy or build decisions are based on fact.1. the escalation should be documented and resolution monitored.1.2 Project management Audit/assurance objective: The project management approach should be commensurate with © 2009 ISACA.37 If a buy/build decision is to be or was made.1. 3. Supporting documentation supports AI2.38 Determine that the decision to buy or build was not influenced by compensation or other rewards.1. determine the objectivity of the criteria used in making the decision. Escalation management Control: Escalation of serious project issues should be directed to the steering PO10.13 X X X committee and senior management on a timely basis. Page 20 . 3.1.18 Determine if the budget has the appropriate capital expenditure and/or expense categories based on accounting practices.5 X X the buy or build decision.1.1. Evaluate the effectiveness of this metric and the objectivity of its calculation. 3.3 3.1. ME4.1. PO5.19 Determine if the expected return on investment has been defined in the business case.36 Determine if the project includes a buy or build decision. PO10. 3.1. 3. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 3. Cross. Buy or build decisions AI1.1.1 Return on investment and key performance indicators PO5.1.1.1.16 Determine if a project funding request has been prepared and approved.3 ME4. 3. All rights reserved.1.1.1. 3.20 Determine if key performance indicators have been established to measure the performance of the project team and the project.2 3.1.

). project objectives are aligned with X X X X PO10.2.3 If IT is managing the project.2. The project management controls should ensure adequate oversight of the project (financial.2.2 the project. The steering committee reviews the effectiveness of the integration. Consider his/her professional experience. 3.1 Interview team leaders representing the business units and information technology. Integration of business/information management PO8.5 Determine if there are any restrictions or encumbrances that would preclude the project team leader from effectively leading the project. risks PO10.1. representation of affected business units.2 Obtain the project organization chart and determine leadership positions.8 from their respective business units. appropriate processes have been PO10.3 X X management experience and the team consists of the skill sets and authority levels PO10.1. appropriate involvement by the stakeholders. 3.3 information requirements are clearly documented. and all affected business units are involved in ME4.4 Evaluate the experience of the project team leader.1 Control: The business and information management teams are integrated. PO10. PO9. 3. 3. Where risks can be mitigated.1.2.1. monitoring of issues. Page 21 . iterative evaluation of risks.1. Determine if the project teams are in alignment with their separate organization’s strategies.6 Review skills of the project team.1.1 X X X X Risk and issue management PO10. Consider business knowledge. All rights reserved. etc. etc. Determine if the appropriate skills are represented. leadership skills and authority granted by the steering committee. appropriate monitoring © 2009 ISACA. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. Composition of project team Control: The project team consists of a project team leader with appropriate project PO10. complexity and regulatory requirements of the project. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference the size.6 the business and information strategies.2. 3. and escalation of issues where required.2 Control: Risk analysis has been applied to the project during the initial phase. where risks are inherent to the process.13 implemented.9 have been identified.2. knowledge of the business processes being developed. IT experience. 3. Cross. determine the process to ensure full participation and agreement with the business units. meeting deadlines.

3.3 X X X committee. 3. Escalation procedures Control: Escalation procedures are established to include monitoring by the steering PO10.8 Review the risk assessment to determine if the assessment is comprehensive and risks are clearly identified. programming.13 Determine the systems development methodology used for the project. operational.2.1.2 Control: The project utilizes the organization’s development methodology and the X X PO10. 3. Cross.2.1. business.2 3.11 Review quality management requirements.2.1. PO8. identify the quality assurance process.1. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. etc.6 Quality management PO10. 3. financial. © 2009 ISACA.10 Review escalation procedures to verify the existence of an escalation plan and the inclusion of a documented review process by project management and the steering committee.1.10 X X X Control: Project sponsor has defined specific quality expectations and criteria.2.1.2.14 Based on the project’s size. Use of development methodology PO10. regulatory and organizational risks. scope and architecture.2. Consider user acceptance criteria. AI1. review significant decisions.8 3.12 Review management approval of quality plan and the communications with project team and stakeholders. 3.3 methodology is appropriate for the size.1. review process for financial models.1. 3.7 Determine if the project team has prepared an initial risk assessment. Consider reputational. scope and architecture of the project. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference processes are in place.2.9 Review the monitoring process to ensure that the steering committee and senior project sponsors have reviewed the risk assessment. verify that the systems development methodology is comprehensive to achieve the goals of the project and is not too complex for the project.2. Page 22 . All rights reserved. design oversight. AI2.

1.) and content to be issued. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference Change management Planning and control Progress control Expense and time management Communications Control: A communications plan is established to provide stakeholders and project PO10. presentation. formal report.1 Verify that the appropriate stakeholders.1 Determine if capital expenditure requests for the project have been authorized by the appropriate approver. 3.2.15. project participants and sponsors are included in the distribution lists. Budget status Accounting Control: The recognition of expenses vs. 3. 3. All rights reserved.1 X X leadership with appropriate information to ensure that the project meets functionality.3.2.1. PO10.15. etc.1. capital expenditure is in compliance with tax ME1. 3. Page 23 . complete and provide the information necessary to manage the project.2 budgetary and timeline goals.2.1. Cross.3 Budget Audit/assurance objective: The budget and accounting processes should be accurate.15. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. 3.15 Obtain the communications plan.2 X and accounting principles.2. © 2009 ISACA. status report. 3.2 Verify that the communications plan includes the method of communications (e-mail.1.3 Determine if the plan includes exception reports. including their frequency.

All rights reserved.1. Time accounting Internal controls Internal control requirements Internal control risk assessment CAATs development Adequacy of testing Implementation 3. the criteria for soliciting X AI5. 3.4.4 Determine if a third-party is necessary for the initial and planning phases. Page 24 . 3. review the procurement process and © 2009 ISACA.1.1 Determine if a business case has been documented for acquiring the services of a third-party provider.3 Review the documented criteria for soliciting and accepting third-party services.3.1.1. AI5.5 If a third-party is necessary for the planning phase. 3.4.3. 3.1.3 and accepting services are documented and follow a prescribed procedure.4. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.1 Service Providers AI5.1.1. Cross.2 Determine if the treatment of the capital expenditure is in compliance with accounting and tax requirements. AI5.3 Determine if initial project work has been expensed with the intent to later transfer the expenses to the capital expenditure account.4 Third-party Providers Audit/Assurance Objective: The use and procurement of third-party assistance should be defined. 3.4 3.4. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 3.4.2 Control: Service provider requirements are clearly stated. and the criteria for obtaining and evaluating third-party services objectively established and documented.2 Determine if internal alternatives have been considered.

3 Review project team procedures to verify that the project team routinely analyzes the alignment of the project plan and the business case.1. the requirements definition. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. 4. ME4. the project team leadership monitors and provides ME1.1.1 Control: On a regular basis. the planning phase involves a detailed design of the solution for use by the developers in the execution phase. 4 .2 business case. All rights reserved.1. If the solution is to be designed in-house. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference determine if procedures have been followed.5 X X X reports to executive sponsors on the continued alignment of the project plan with the ME4. scope and business value of the project before work has begun in the planning phase.1 Verify that the stakeholders have received a formally documented statement defining the objective. executive sponsors and the steering X X X committee. Communications and escalation procedures should be in place to allow management to respond to issues as they arise. Procedures should be defined to keep management informed of the progress. This involves soliciting requests for proposals (RFPs). 4. If the solution involves the purchase of software. © 2009 ISACA. Cross. PO10. describing the specific data attributes and business processes.1 Governance Audit/assurance objective: Management should provide adequate governance over the project to ensure that the project is adequately planned and the business and technical resources are assigned. Page 25 .1.2 Verify that the project has been agreed upon and that there is documented acceptance by key stakeholders. evaluating vendor responses.1.1. selecting a provider and negotiating a contract. an acquisition cycle is initiated.3 4. PLANNING PHASE The planning phase addresses the preparation of the project’s detail plan.1 Business Case AI1. is prepared. During this phase. 4.

1.6 Obtain the scope change procedure and determine if the procedure requires steering committee involvement when the scope is changed. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. and should be considered a living document. subprocesses. performed and approved by the project manager and executive sponsor (if above established threshold) © 2009 ISACA. For the sample of selected changes. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 4. All rights reserved. milestones and resource assignments should be documented.1.1. a detailed plan of phases. At minimum. Scope Management Control objectives: The scope of the project is clearly defined and a project plan has been developed that clearly identifies the phases.1.1. 4. assess the completeness of the project plan. processes and subprocesses.1.4 Review project team communications with the executive sponsors to determine that the project plan and business case are in alignment.2 Based on the reviewer’s knowledge of the project.5.1. Page 26 .1 Review the project plan and evaluate the detail of the plan.5 X X X Responsibility for managing scope changes is defined and procedures are in place to obtain approval of scope changes from the project steering committee or executive sponsors.1. This plan may change over time.5. Cross. 4. or that the communications describe changes to either the business case or the plan to maintain alignment. obtain the project notebook for all sampled changes to verify that each has:  Been entered into the project management tool  A cost-benefit analysis performed if within the threshold that requires such analysis  An analysis of effect on the overall project.1. processes.1. PO10. 4. 4.5 Obtain the project plan.

3 appropriate subject matter experts and stakeholders are included on the project team.1. systems development.1.1. Verify the following for the scope change:  Documented approval of management  Timeliness of approval 4. the project leader and third-party suppliers (if applicable).1.1. 4.1.6. and other appropriate areas. 4.1.9 Determine if the project team includes members from all affected business units.7 Determine that “out of scope” areas are clearly identified.8 Determine if the following roles are identified: Owner.1. IT operations. compliance.3 and the division of responsibilities is appropriate for the project and entity level organizational structure (including separation of duties). 4.11 Determine who is responsible for the overall project.1.1. suppliers.6. legal. Page 27 . project leader. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference  An analysis of resources performed and approved Test objective: To verify that scope changes are implemented with the knowledge and approval of the steering committee or executive sponsors 4. 4.1.1.1.1 Select a representative sample of scope changes.1. including delivery of © 2009 ISACA. X X PO10. focusing on those with the greatest impact to the project. the executive sponsor.10 Determine the appropriateness of the division of responsibilities among the organization’s executive group (steering committee). Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. All rights reserved. Cross. PO7. internal audit. information security. Roles and responsibilities Control: Roles and responsibilities of the project team are clearly identified. 4.1. steering committee representative (from the project team). executive sponsor.2 Determine if the process has been delayed or circumvented.

4.12 Determine if the project leader has appropriate assigned responsibilities.3 Control: The calculations for determining project ROI and KPIs are approved by the PO13.2 Control: The buy or build decision is based upon business and functional AI2.1 © 2009 ISACA.1.1. ROI and KPIs PO10. AI1.5 authorization.1. All rights reserved.13 X X X steering committee and executive sponsor. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. with appropriate disposition.1. repeatable and include relevant information that can be compared from period to period. 4.1.1 X X X Functional analysis supports buy or build decisions AI1.1. and provide meaningful status ME4. Escalation management Control: Steering committee and executive sponsors receive and act upon issues PO10. Consider if the attributes are objective. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference the approved project scope.13 X X X X escalated by the project team. and timing.14 Determine if KPIs objectively represent progress of the project.3 requirements.3 of the project and a measure of its success.15 Determine escalation issues identified in escalation procedures as seen in step that are presented to the steering committee.13 Determine the attributes for calculating the project’s ROI. AI3. budgetary authority (resources and expenses). Evaluate if the responsibility has been assigned at the appropriate executive level. 4. deliverables and go/no-go decisions. Consider if the KPIs fairly compensate the project team (if applicable) and the compensation will not affect the team’s objectivity in reporting (avoid conflicts of interest). Page 28 . Cross.1. budget. with appropriate procurement procedures and steering committee AI2. including quality management. 4. are objective.1.

1.1. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference AI5.1. © 2009 ISACA.20 Determine if legal.18 Determine if the procurement process included a request for proposal. 4.1. prioritized and documented in a way that is understandable to stakeholders and sponsors.22 Confirm through interviews with key staff members that all requirements and acceptance criteria have been considered. 4.1.2 ME4. a methodical selection of vendor candidates and established criteria for evaluating the responses. Page 29 .23 Confirm through interviews with key staff members that application and infrastructure technical requirements meet the needs of the organization’s information architecture standards and strategic direction.17 Determine if the build alternative was planned out and if costs associated with this alternative were considered.1.1 AI5.21 Determine if the final decision to buy or build provides for active steering committee participation and approval.1.16 Determine the process for deciding whether to buy or build. Cross.1.1. evaluated. 4. compliance and internal audit staff have reviewed the procurement agreements. 4.1. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.19 Determine if the project team—including business unit team members knowledgeable of the business process being replaced. 4.1. 4. 4.1.1.1.1.2 4.1. All rights reserved. and IT team— members knowledgeable of the IT strategic direction and architecture are actively involved in the vendor evaluation process.

4. 4. Integration of business/information management PO10.24 Verify through interviews with key IT staff members that exceptions and/or deviations from the information architecture standards and strategic direction have documented approval from senior IT management and strategic committees. 4.2 Project management Audit/assurance objective: The project management activity should provide appropriate oversight and process to ensure the timely execution of the plan.26 Verify that the feasibility study considers the potential cost-benefit analysis of each of the identified alternatives and system functionality. Cross.1. and a go/no-go decision is made at each critical milestone.6 X X project team creates the project plan.25 Verify whether a feasibility study exists that sets out an alternative course of action that will satisfy business technical and functional requirements.1. issues are resolved or escalated to the appropriate management level. Page 30 .3 Control: The business and information management teams remain integrated as the PO10.1.2. 4.1 Interview team members.2 Determine if team members appear to be intimidating or ignoring other team members. quality of process is maintained. all affected business units are involved in the ME4.2.3 Composition of project team PO7.1.1. mitigation of risks as they are identified. PO7. 4. 4.2 project.2.1. The steering committee monitors the effectiveness of the integration. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 4.1.1.4 © 2009 ISACA. costs are monitored and minimized.1. All rights reserved. review team meeting minutes. and observe team meetings to determine full participation of team members.3 Determine if the project manager has reported any conflicts in the integration process.

9 X X X X been implemented.6 Determine if contingency plans are in place to replace team members. 4. finance/budgetary. 4.) and likelihood of occurrence (probability).2.8 4. 4.2. Risk and issue management Control: Risk analysis has been applied to the project during the planning phase. All rights reserved. etc.1.13 processes are in place. where the risks are inherent to the process.5.1.1 Interview project manager and staff to determine availability.1.1.2. 4. completion date.2. 4.2 risks have been identified.2. 4.1. Cross. Issues identified during the planning are reported.4.2.4 Determine if the planning phase project team is appropriate in terms of skill sets. either permanently or on an interim basis. and issues AI1.1 Obtain and evaluate the resumes/professional experience of the team members. Page 31 . PO10.2 Obtain an organization chart and evaluate effectiveness of the project’s organization. © 2009 ISACA. operations. 4.2.5 Determine if the team members are available to participate in project activities and that other duties are not impeding project progress.1.2. appropriate monitoring PO10.5. to effectively plan the project.3 the business process and automated solution. appropriate processes have PO10. regulations. PO10.1.7 Determine if risks are classified in terms of impact (reputation. knowledge of the process and leadership for the size and scope of the project.2 are monitored and closed. with the knowledge of PO10.1.2. Where risks can be mitigated. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference Control: The project team consists of the appropriate resources.1.4. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.2 Review meeting minutes for attendance issues. 4.8 Determine if a holistic approach to the risk analysis is used.

4.2.2. documented and monitored.1 Obtain the initial risk assessment to determine the quality and scope of the risk assessment. how the stakeholders were notified.2. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.1.12.1. determine how the risk impact and likelihood were assessed.2.12. © 2009 ISACA. Escalation procedures Control: Escalation procedures are utilized to inform the project team and the PO10.1.2.2.2. If so. Cross.1. 4. Test objective: To verify that risks have been evaluated and reported to stakeholders. and the disposition of the risk (acceptance of risk or mitigation of process that triggered the risk).10 Determine if stakeholders are notified when their tolerance levels have been exceeded.1.3 X X X steering committee. 4. 4.2 Determine if new risks have been identified during the planning process.11 Determine if an issue monitoring system is in use. reviewed and monitored.12 Determine if issues are documented.10. All rights reserved.2 Obtain the issues log and compare the known issues to those reported. Page 32 . 4.1.9 Determine if the stakeholders establish the risk tolerance levels and have been involved in the risk analysis. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 4. where appropriate. 4. Test objective: To verify that issues are identified. 4.1.1.10.1 Interview project management and several team members to document known issues identified during the planning phase.2.

2.13 Verify that an escalation procedure is in use.18 Determine if the QA roles have been established.1.21 Verify that the quality plan clearly identifies ownership. 4. trace the process of the escalation.1. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 4. and that the original acceptance criteria are considered in the quality assessment. 4.2. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.2.17 Evaluate the robustness of the QA plan.10 X X Control: The project process has defined quality assurance (QA) procedures. if for significant decisions. 4.16 Determine.1. 4.2. if so.2.1.8 4. © 2009 ISACA.19 Determine if a QA review has been performed for the current phase.1. Page 33 . 4.20 Verify with business sponsor that quality reviews are being performed for business functional and technical requirements and feasibility study reports. AI2. consider approvals of deliverables. determine the effect on the project.1.1. peer reviews.1. processes and metrics to provide QA of the project deliverables that constitute the project quality system.2. All rights reserved.2.2. there is a QA plan addressing review of presentations. determine the level of documentation and management review. PO8. 4. 4.1 Quality management PO10. If so. 4.22 Verify that the quality plan outlines the requirements for independent validation and verification of the business and technical solution.1.2.14 Determine if any issues have required escalation.1. documentation review. Cross.2.15 Determine if any escalated issues remain open. assumption reasonableness and project management process. criteria and assumptions. and if so.

scope and architecture of the project.1.1. Test objective: To verify that high-level specifications translate to the business requirements. 4.23 Determine the systems development methodology being utilized for this project. Page 34 .1 X and obtains approval for changes in the scope. 4.1.2.1.1.2.2. 4. but rather to determine if the process fits the project.4 6 Note: It is not the reviewer’s position to evaluate which system development methodology to use. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference Use of development methodology AI2. © 2009 ISACA.6 4.25 Evaluate the use of the systems development methodology against the size. AI6. 4.1 Select several subphases of the planning phase.24. business case or key attributes of the AI6. All rights reserved. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. Cross.1.2.1 Control: The project utilizes the organization’s development methodology and the X AI2.3 project.26.2. determine if the process is being followed.11 Control: A change management procedure has been implemented that documents AI6.2. Change management PO10. 4.2 methodology is appropriate for the size.24 Confirm with key IT staff members that a high-level design specification is defined that translates the business requirements for software development.1 Obtain the project design specifications and determine that they address business requirements. scope and architecture.26 Determine if the systems development methodology is being used as intended.

2.2. 4.1.3.2.28.1.1.1.3.2.27.2.27. 4.3 Thresholds where the change must be submitted for approval to the executive sponsor and/or the steering committee 4.1. 4. 4. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. 4. including their effect on key risks.1.3.2. 4.2.1.27.27.1 Verify that the benefits for the change have been analyzed.28.2.28 Determine the process for changes affecting the business case.2 Thresholds where the project manager can approve the change without executive sponsor or steering committee authorization 4.1 Verify that the appropriate description of the change has been documented. Test objective: To verify that change management procedures have been followed.1. © 2009 ISACA.3 Select changes from the change management log. 4.1 Verify that the change procedure requires: 4.2 Verify that the effect on the business case and project has been documented.1.1.28.2.1. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 4.2.1.28.27 Obtain the change management procedure.2.3 Determine if a new risk assessment was required and whether it has been performed. Cross.2.1 A documented request for a change 4.1.28. costs and delivery dates.28. All rights reserved.1.2 Verify that business case changes require executive sponsor and/or executive committee approval.1. Page 35 .

4 Verify that the appropriate approvals were obtained. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. 4. based upon thresholds.1. subphase and task.1.29 Determine the comprehensiveness of the project plan.1.3. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 4.28.2.2. resource projections and activity dependency.28. a sequence of process. © 2009 ISACA.5 For any projects not successfully implemented in production.29. deliverables.2.4 Determine that project assumptions and constraints are documented and included in the plan. a PO10. 4.5 Determine that each task has a clearly stated objective and goal.1.1.2. 4. verify that a backout was properly documented and successfully executed by IT on a timely basis. Planning and control Control: The planning and control of the project includes effective time control. milestones and dependencies.3 Verify that deliverables have been translated into activities.29. All rights reserved.2.2. 4. 4. deliverables. 4.30 Determine if changes to the project planning documents require QA and management review. Page 36 .2.2. 4.2 Verify that resource utilization can be realized (resources working double shifts or maintaining regular responsibilities while being assigned to the project team).29.1.29.1 Verify that the milestones and tasks can be achieved with the resources available. 4. Consider the level of detail for each phase. resources required. Cross.6 X project plan with milestones.1.1.1.3.2.29.

All rights reserved.2.1. 4.33 Determine if resource time reports.2. PO10. 4. 4.1. © 2009 ISACA. Verify that no resources are unassigned.6 X X X decisions.32.2.32.1.32.32. Cross. which is appropriately authorized. Test objective: To verify that go/no-go decisions are being made at appropriate milestones. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.1. Progress control PO10.7 4.2 Determine if a go/no-go decision process was made at that milestone. approved by the authorized management and properly documented.3 X X X reported. Page 37 . Milestone go/no-go decisions Control: At major milestones.3 Evaluate if the milestone required a go/no-go decision.2.1 Select several milestones. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 4.2.2 Control: Progress defined as meeting milestones and budgets are maintained and PO10. 4.32 Determine if management reviews significant milestones.2.31 Determine if resource time is clearly established.1. and makes a go/no-go decision to go to the next subphase or task based on the successful completion of the previous task or subphase.1. 4.1. task completion percentages and deliverables are recorded in the project management document. management exercises and documents go/no-go PO10.2.4 Review the documentation for the decision-making process to ensure appropriate approval and description.

2.7 budgetary and timeline goals.35 Determine how resources record and expense time to the project.1. PO10.2 Expense and time management PO10. 4. Communications PO10. Cross.2.2 Control: A communications plan is established to provide stakeholders and project PO10.1.3 Verify that external consultants document their time.2.7 4.2.2 Verify that all costs are recorded.1.2.3 X X Control: Expense and time management are accurately recorded and approved. © 2009 ISACA.7 4. 4.36 Determine that the communications plan provides for status reports and exception reports that move up the project management hierarchy. Page 38 .35. especially when those costs are not capitalized.1 Verify that all team members record their time. 4.38 Determine that the communications frequency and content are in alignment with the documented communications plan. adequacy of the distribution list and the review process for the progress reports.34 Determine the reporting cycle for progress control.1.4 Determine how and expenses are approved.3 X X X leadership with appropriate information to ensure that the project meets functionality.2. 4.1.1.35. 4.1.2.35. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. All rights reserved. 4. 7 Some entities record systems development time. PO10. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 4.35.2.1. Failure to record all time will affect the return on investment calculation and a benchmark for future business unit involvement.2.1. but not business unit time. PO10.37 Determine that the communications plan provides for cross-team reporting.

1. complete and provide the information necessary to manage the project. 4.6 Determine if the following phases have separate components in the budget: analysis.2 X Accounting © 2009 ISACA. PO10.3. All rights reserved.1.13 4.3. 4.1. and infrastructure modifications. 4. documented and approved by the executive sponsor and/or the steering committee. segregated from other projects and is in PO10. design and selection. If not.3 Budget Audit/assurance objective: The budget and accounting processes should be accurate. determine if the variance has been approved by the executive sponsor and/or steering committee. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.3 Determine if the budget is equal to the business case estimate.2 Verify that the budget was established based upon a cost estimation process. PO5. Cross. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 4.3.4 Discuss the budget and deliverables with key members of the project team and executive sponsor. 4. conversion. 4. Page 39 .3 X alignment with the business case.7 Determine if there is a contingency built into the budget and if it is within accepted limits.3.1 Determine that project costs have been clearly identified.2 Budget status PO10. testing (including user acceptance testing [UAT]). Determine if there are known gaps that would impact the budget.3. implementation and rollout.1.5 Determine that the project has its own cost center that is not shared with other projects. PO10.7 PO10. 4.2 Control: The project budget is defined.3.3. training.1.1.1.

3 Control: The accounting of the project is in compliance with expense and PO10. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. 4. access control and database integrity controls are inadequate. audit trails.3 Review the requirements document for design controls. Cross.1. determine if the project team has identified the key controls required for oversight. should be designed in the planning phase.7 capitalization requirements. Test objective: To verify that the costs are properly allocated. All rights reserved. Determine if the allocations are within accounting guidelines. enhance or aggregate controls to provide a streamlined. security.4. security and regulatory requirements.2 Based on the application’s function. operations.8.4 part of the high-level system design or requirements definition. Page 40 .1 For a selected period. data integrity. Internal control requirements AI2.3. 4.1 Obtain an understanding of the intended functionality of the new application. Consider financial reporting. PO10. when it is most efficient to modify. 4. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference PO10.3 Control: Internal control requirements are established during the planning phase as X AI2. input. 4. and identify instances where authorization.4.1. approach to internal control of application data and processes.1.1. which ensure the accurate and complete processing of data.13 4.4 Internal controls Audit/assurance objectives: Internal controls. trace the expense and resource charges through the accounting system. 4.3.1.8 Determine if the appropriate costs are being capitalized or expensed based upon standard accounting principles.1. processing output and boundary controls.4 Review plans for implementing automated controls in packaged application © 2009 ISACA. 4.4.4. but thorough.

Consider parallel testing or separate operating platform testing prior to implementation. 4. testing should include unit testing. Internal control risk assessment PO9. conversion testing and stress testing. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.4. If sufficient testing will be performed and change management is at a good-practice level.5 Adequacy of testing Audit/assurance objective: The project plan should provide for adequate testing at the various stages of development.1.1 Control: A control risk assessment was prepared by the project team to identify PO10. Page 41 . and to allow reliance on the internal controls of ME2. integration of manual and automated processes.5 Determine that control requirements are approved. Cross.1.1.4. At minimum. 4.8 Determine the level of reliance to be placed on the IT audit/assurance review of the development process.6 Review the project team’s control risk assessment to determine if the controls identified are placed properly and the assessment is complete. © 2009 ISACA.5 the completed and implemented application. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference software and determine that business process control requirements are adequately addressed.1. 4.1.9 X X internal control requirements based upon processing. the delivered system can be relied upon for audit/assurance purposes.1 4. CAATs development Control: IT audit/assurance will utilize the reviews of the systems development phases ME2.4.4.4.2 Control: Testing requirements are established and include documentation and review X AI2.3 standards. Testing requirements AI1. All rights reserved.4 X X X to understand and test the application. the timeframe for testing and documentation requirements. 4.9 Determine if integrated computer-assisted audit techniques (CAATs) will be built into the system to facilitate later audit/assurance activities. ME2. operational and financial risks. integration testing. UAT. 4.7 Supplement the control risk assessment with IT audit/assurance-identified risks. including definition of the types of tests to be performed.

1.7 Review test plans to ensure full testing of the system.5.3 Determine if the planning process has defined how UAT will be performed: on a separate platform or on the production system.5.6 Implementation Audit/assurance objective: The implementation plan should be developed to ensure minimum disruption during the initial implementation of the new system and thorough vetting of the processes prior to final “throwing the switch” to the new system.1. integration.5.5. Page 42 . documentation.6 Determine what provisions have been made if the delivery of the UAT system is late—whether delays in development shorten or otherwise limit X the testing time available prior to implementation.1.1.1. Testing content Control: Test scripts and volumes are adequate to ensure accurate. 4. 4. Project plan PO8.5 Review the project plan and determine if adequate time has been provided for testing. Cross. 4.1.1.4 Determine if a test suite of transactions will be developed and be available later for regression testing after major system updates. All rights reserved. user acceptance.7 X © 2009 ISACA. Pilot test plan PO10. 4.1. 4.5. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. 4.2 Determine if the planning process includes unit. including test objective.5. timing.1. effective and PO10. 4. size.5.9 Review stress testing plans to ensurethat a realistic volume is used to stress-test the system for current and future volume. 4. stress and conversion testing.3 Control: The project plan provides adequate time for testing and remediation based PO10. scripting (where appropriate).1 Determine if testing requirements have been established for each type of testing. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 4.8 Review plans to reconcile test results to known results (either based on an independent process or manual calculation).5.5.2 upon test results. 4. review and approval.2 X complete results. scope.

9 Determine if the plan allows for contingencies.6. etc.1. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference Control: Pilot implementations of the new processes are utilized to minimize the risks AI7. 4.1. All rights reserved.6 X coverage of essential processes during implementation.6.1. 4. vacations.4 4.6 Determine if the readiness assessment includes an inventory of open issues.8 4.1.6. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. © 2009 ISACA. Page 43 .3 of a full roll-out of the application.6. and report to executive sponsor and/or steering committee. a risk analysis of the impact to the business of moving to implementation.8 Determine if the plan addresses coverage of existing workload as well as the new processes and interim conversion processes.6.7 system is ready for the implementation phase.5 Determine if a readiness assessment is required prior to moving the project to the next phase. Cross.4 Determine if go/no-go evaluation is included in the pilot implementation plan.1. 4.1.2 Determine that a review process has been established to ensure that pilot test results adequately address issues identified during the test process and that these issues are included in the issue monitoring system. illnesses.7 Determine that a resource plan has been completed to address the resources required to convert and implement the new system.1. 4. 4. Readiness assessment PO10.6.1.6 Control: A readiness assessment is part of the implementation plan to ensure that the X X X X PO10. 4. Resource planning Control: Resource planning is included in the planning process to ensure adequate PO10. AI7.3 Determine that pilot objectives are clearly stated to permit objective assessment of successes after the completion of the pilots.6.6.6.1. approval from key stakeholders. Determine the scope and evaluate the effectiveness of the pilot test. PO10. 4.1 Review the plans for pilot tests.

6 documented conversion specifications. Cross.6.1. 4. Training planning Control: An appropriate training program has trained affected functions prior to AI7. 4.1.1 Determine that transaction processors have been properly trained in the use of the new system. Page 44 . distribution list and content of the communication plan to ensure that it informs the appropriate interested parties of the roll-out on a timely basis.1.10 Review the conversion plan for completeness. a dress rehearsal of the conversion.10. Determine if the following tasks are included in the plan: 4.5 X X progress of the roll-out.5 plan in the event the conversion is not successful.6. and a reconciliation of data between the new and old systems. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference Conversion plan Control: A conversion plan is part of the overall planning activity and includes PO10.3 A backout plan in the event the conversion is not successful 4.10.6.4 An effective reconciliation between the new and old systems 4.1. Communication plan Control: A communication plan informs stakeholders and management of the AI7.1.11 The steering committee and/or executive sponsor has reviewed and approved the conversion plan. All rights reserved.6.6.2 A dress rehearsal plan for testing the conversion process using a copy of the full data volume to be converted 4.1. 4.12 Review the communication plan. Determine the frequency.1.1 X implementation.1 Conversion requirements and specifications 4.1.6.1.10. © 2009 ISACA.13 Review the training programs for the various affected parties. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.13.10. a backout X AI7. 4.6.6.6.

Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.7 Third-party providers Audit/assurance objectives: Third-party providers should be selected and managed effectively to provide maximum ROI. 4.2 Determine that IT operations have been trained in the scheduling and processing of the new system. 4. 4.6.18 Evaluate the backout plan for objective decision points to make a decision to back out of the conversion. 4. Transition plan Control: A transition plan is created to address interim processes that are required AI7.1. The ISACA/ITGI Outsourced IT Environments Audit/Assurance Program can be used for that purpose.3 Determine that the help desk is prepared to assist users in the use of the new system.13.16 Determine if the costs of additional resources have been included in the budget. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 4. major stakeholders and executive sponsor.19 Determine if the backout plan includes active participation by project management.1. the project team has identified interim processes that will be required due to temporary interfaces or processes until full integration of processes is achieved.3 X until the new system is fully operational and integrated with other systems. should be adequately vetted.8 8 It is recommended that a separate outsourcing assurance/audit evaluation be performed for the acquisition of large-scale third-party services. approval and decision AI7.6. 4.3 X points to initiate the plan.15 Determine if additional resources have been included in the plan to augment internal resources during the interim process period.6.13. as part of the planning process.6. Backout plan Control: The backout plan is prepared with appropriate review. Page 45 . and contracts should provide for measurable deliverables and safeguarding of entity intellectual property. © 2009 ISACA.1. 4.1.1.6. All rights reserved. Cross. 4.14 Determine if.1.1. 4.17 Review the backout plan.6.1.6.6.

6 Determine whether software acquisition contracts include and enforce the rights and obligations of all parties addressing ownership and licensing of intellectual property. 4.7. fitness for purpose. determine if SLAs are as described in the contract. 4. 4. 4. warranties.9 Determine if SLAs are appropriate to measure the activity performed by © 2009 ISACA.7 Determine if SLAs are documented.7. DS1. the selection AI5.7. arbitration procedures.6 4. security. 4. AI5. upgrade terms.1.7. escrow and access rights. DS1.7.1.2 Control: SLAs are defined and objective to permit monitoring of vendor activities.3 X compliance with contract and assignment of penalties for failure to comply with the DS1.1.7. Page 46 . Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference Vendor selection Control: Criteria for vendor selection are predefined prior to selection.5 DS1. 4. 4.3 Review the documented decision process and justification for the selection of the final vendor.7. 4.4 contract. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.3 DS1.4 Determine if standard and required entity contract provisions were included in the contract.7.1.1 SLAs and contract fulfillment DS1.1. All rights reserved.5 Determine if the contract authorization was in accordance with enterprise’s bill of authority for contract amount and scope. Cross.2 Determine that the selection process included the evaluation of these criteria against the vendors’ responses to the RFP or other selection processes. and the criteria and selection process are objective.1.1 Determine the selection criteria used for the selection of a third-party vendor.8 Review SLAs to determine if they utilize metrics that are monitored and measured.1.1. If documented.7.3 X and contract negotiation are performed according to policy. maintenance.1.

7.11 Determine if vendors sign confidentiality agreements relating to intellectual property. Intellectual property Control: Vendors sign confidentiality agreements restricting their access to and ability AI5.3 to disseminate the enterprise’s intellectual property.7. and verification of process accuracy and completeness  Testing: – Business processes (unit testing and integration testing) – UAT – Conversion testing – Stress testing the processes and equipment © 2009 ISACA. The vendor’s access is limited to information necessary to perform its contracted duties.1. 4. 4. Execution subphases include:  If the project under development is purchased. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference vendor.1. Page 47 . balancing routines.1.7. 5 . Cross.10 Determine if SLAs permit assessment of penalty for nonperformance of contracted worked. 4.12 Determine if management reviews vendor access to intellectual property. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. a gap analysis to determine modifications  Design of the new system including: – New business process (manual and automated) – New controls – Development of interfaces to bridge the new system with existing retained applications – Development of interim processes if the new system must operate with the older system until all processes are implemented – Conversion utilities to convert the new system  Development of the applications (programming)  Establishment of conversion and transition processes. EXECUTION PHASE The execution phase of the project plan usually is of the longest duration and includes all processes after the completion of the planning phase until the go-live phase. All rights reserved.

5.1. processes and subprocesses. All rights reserved. Interview the project team manager to determine if any changes to the project plan have impacted the business case. Interview project manager to determine impact of changes.1 Control: The project team leadership.5 X X X reports to executive sponsors on the continued alignment of the project plan with the ME4.3 Review the project plan and identify changes to the plan.2 business case and any changes in satisfying the business case. monitors and provides ME1.5 X X X Responsibility for managing scope changes is defined and procedures are in place to obtain approval of scope changes from the project steering committee or executive sponsors. Page 48 . PO10.1. Communications and escalation procedures should be in place to allow management to respond to issues as they arise. review steering committee meeting minutes and other documentation to determine evidence of management’s governance oversight.1 Review project change logs to determine if significant changes have been made to the project. The business and technical resources should be assigned to ensure planned progress of the project.1.1. Determine if changes have affected the business case. Cross.1 Governance Audit/assurance objective: Management should provide governance over the project to ensure that the project is adequately monitored. ME4.1.1 Business case AI1. Procedures should be defined to keep management informed of the progress. PO10.2 If significant changes have been implemented. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.3 5.1. Determine if changes from this © 2009 ISACA. on a regular basis. 5. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference – Backout if the conversion must be postponed  Implementation  Reconciliation of conversion 5. Scope management Control objectives: The scope of the project is clearly defined—a project plan is maintained and updated that clearly identifies the phases.

legal.1 identified.3 the project and entity-level organizational structure (including separation of duties). ROI and KPIs PO10.3. Cross.1. Select a representative sample of scope changes. verify that the project plan has been updated. Verify the following for the scope change:  Documented approval of management  Timeliness of approval  Determine if the process had been delayed or circumvented Roles and responsibilities Control: Roles and responsibilities of the project team continue to be clearly PO7. 5.4 Determine if roles and responsibilities issues have arisen during the project requiring senior management intervention to ensure timely and effective involvement by all affected business units.3 X X X Control: The calculations for determining project ROI and KPIs are updated and PO13. internal audit. information security. appropriate subject matter experts and stakeholders are actively PO7. All rights reserved. and the division of responsibilities is appropriate for PO10.1. 5. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference project or other interfacing projects affect the scope of this project. Page 49 . Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. focusing on those with the greatest impact to the project. suppliers and other appropriate areas are actively involved in the project. and to ensure systems development. 5. compliance.3 X X participating on the project team.1.3. IT operations.1.3 © 2009 ISACA.2 If the scope has changed.1.1. Test objective: To verify that scope changes are implemented with the knowledge and approval of the steering committee or executive sponsors.1 If scope has changed.13 reported to the steering committee and executive sponsor as scope or other components ME4. determine that appropriate steering committee and executive sponsor authorization was obtained.

3 PO10. issues are resolved or escalated to the appropriate management level. PO7. Escalation management Control: Steering committee and executive sponsors are receiving and acting upon PO10. 5. Page 50 . © 2009 ISACA.1.5 Determine if the attributes for calculating the project’s ROI and KPIs have changed due to project modifications. The steering committee monitors the effectiveness of the integration.2 Project management Audit/assurance objective: The project management activity should provide appropriate oversight and process to ensure the timely execution of the plan.2.2. and a go/no-go decision is made at each critical milestone.13 X X X X issues escalated by the project team.8 5.1.6 Determine if there are any open escalation issues identified in escalation procedures without appropriate disposition. Functional analysis supports buy or build decisions 5.2.1.1.1.2 project.2. to effectively plan the project.3 Determine if the project manager has reported any conflicts in the integration process. with the knowledge of PO7. costs are monitored and minimized. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference that affect performance or ROI changes. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. 5.3 Control: The business and information management teams remain integrated as the PO10.3 X the business process and automated solution.1 Composition of project team PO7. mitigation of risks as they are identified.1. Cross.1 Interview team members. PO10.2 Control: The project team consists of the appropriate resources. and observe team meetings to determine full participation of team members.1. all affected business units are involved in the ME4.1.4 Determine if the execution phase project team is appropriate in terms of skill sets.6 X X project team executes the project plan.2 Determine if team members appear to be intimidating or ignoring team members. quality of process is maintained. 5. 5. review team meeting minutes. Integration of business/information management PO10. 5. All rights reserved.

Test objective: To verify that risks have been evaluated and reported to stakeholders.7 Determine if risks have changed during the execution process.5. completion date.2. Issues identified during the planning are reported. 5.2.2. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.2 are monitored and closed.2 phase as risks are identified.1.1 Obtain the initial risk assessment to determine the quality and scope of the risk assessment. etc. Risk and issue management Control: Risk analysis continues to be applied to the project during the execution PO10.9 Determine if stakeholders have been notified when their tolerance levels have been exceeded. 5.2.9.1. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference knowledge of the process and leadership for the size and scope of the project.1. All rights reserved.2. and issues AI1. Page 51 . Where risks can be mitigated.2. 5.1. appropriate processes have PO10. If so.2.5. regulations.1. 5.2 Review meeting minutes for attendance issues.8 If risks have changed.1. finance/budgetary.) analysis and likelihood of occurrence (probability) have been applied. 5. Cross. how the stakeholders were notified.1 Interview project manager and staff to determine availability. 5. 5. determine how the risk impact and likelihood were assessed. appropriate monitoring PO10. and the disposition of the risk (acceptance of risk or mitigation © 2009 ISACA.9. operations.1. where the risks are inherent to the process. 5.2.1. determine if the stakeholders have been involved in the process and have approved the changes in risks. determine if appropriate impact (reputation.9 X X X X been implemented.5 Determine if the team members are available to participate in project activities and that other duties are not impeding project progress.13 processes are in place.2. 5.2 Determine if new risks have been identified during the execution process.1.6 Determine if contingency plans are in place and have been implemented to replace team members. If changes are noted. either permanently or on an interim basis.

6 Quality management PO10. 5.16 Determine if the process of monitoring software quality has been defined © 2009 ISACA. and if so.15 Determine if QA reviews are performed independent of the development team. 5.10 Determine if issues are documented.10. 5. All rights reserved.2. approved and corrective actions taken were appropriate. if so. determine the effect on the project.3 X X X steering committee. Test objective: To verify that QA reviews are performed by independent reviewers and their results are analyzed.15. where appropriate.2 Obtain the issues log and compare the known issues to those reported. If so.1. Escalation procedures Control: Escalation procedures are followed to inform the project team and the PO10.2.12 Determine if any escalated issues remain open.2.1.10 X X Control: The project process has defined QA procedures. 5.1.1. Page 52 .8 5. PO8.2.1 Review relevant documentation to verify the existence of routine QA reviews.13 Determine if the QA plan addressing review of presentations.1.1.14 Determine if a QA review has been performed for the current phase.10.2. AI2. Cross. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference of process that triggered the risk). 5. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. determine the level of documentation and management review. 5. documented and monitored.11 Determine if any issues have required escalation. criteria and assumptions has been followed.2. Test objective: To verify that issues are identified. 5.1.2.1. reviewed and monitored using the issue monitoring system.2. trace the process of the escalation.2. 5.1 Interview the project management and several team members to document known issues identified during the planning phase.1. 5.1.2.

Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference and is performed on a regular basis. AI2. 5.2.1. Verify that a QA review was performed on the programs and results reported.1.9 5.1. 5.2 Identify instances where QA was not performed or where no action was taken based on negative review.19 Examine information architecture and data dictionary documentation to identify deviations from the data dictionary standards in the program design.1. All rights reserved.1.3 X Control: The project utilizes the enterprise’s development methodology.1 Select several programs within the project development process. 5.2.8 AI7.2 Use of development methodology AI7. 5.18 Perform code walk-through and examine documentation associated with data inputs and outputs to determine whether proper storage. Page 53 .1.2.5 AI7.16.1. 5.17 Determine if the systems development methodology is being utilized for this project as intended.2.21 Confirm with key staff members that source data collection design is specified that © 2009 ISACA.2.20 Inquire of key staff members whether data dictionary standards are being used and compare actual performance of data inputs/outputs with responses from key staff members.1. AI7. Test objective: To verify that software development is reviewed on a routine basis for quality. 5. location and retrieval methods are implemented according to data dictionary standards. Cross.7 AI7.2.7 AI7.1.2 AI2.2.16. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.

All rights reserved. are considered.25 Review project documentation to determine if good practices.1.24 Review the backup plan and procedures to determine that they adequately address the availability requirements of the new system and are cost-effective. Cross. including transaction types. 5.2. 5. frequency and method of generation. such as different types of recipients. © 2009 ISACA. 5. Page 54 .1. 5. 5.28 Review detailed design documentation to determine that pertinent design details.2.1. change in system design needs to be approved by business and IT sponsors).2.1.22 Perform code walk-through and inspect plans to confirm that data are collected and validated for processing transactions.23 Confirm with key IT staff members that adequate redundancy.2.2.2.2. 5.g.31 Inspect the detailed design specifications to confirm that they adequately address user interface requirements. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.33 Review detailed design specification documentation to determine if it was prepared in conformance with organization and industry standards and the information architecture.1.1.2.1. 5.26 Inquire of key staff members and inspect relevant project documentation to determine whether processing steps. are considered.1. 5. 5. failure recovery and backup arrangements are defined and included in the detailed design specification. completeness. usage.32 Review documents such as system design analysis reports or system design change requests to confirm that the system design reassessment procedures are followed (e..2. 5.27 Confirm with key IT staff members that all identified output data requirements are properly defined.1.2. such as availability.29 Review detail design requirement documentation to determine if the availability.1.2.1. and network requirements. 5. 5.1.30 Confirm with key staff members that the interface between the user and the system application is defined and included in the detailed design specification. integrity and confidentiality of output data as well as the impact of data outputs to other programs are appropriately addressed. and processing rules including logic transformations or specific calculations are defined and included in the detailed design specifications. details required.2. control and auditability. security. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference incorporates controls over computed and stored data.

1.2.39 Confirm with key staff members that technical authorities and operations management applications are ready and suitable for migration to the production environment.2.2.1.2. Cross. code review and walk-throughs) to identify exceptions to specifications and standards. functional and technical requirements.43 Perform a walk-through of code and identify problems/exceptions. 5.42 Confirm with key staff members that technical authorities and operations management applications are ready and suitable for migration to the production environment.1.2.35 Review the detailed design specifications to confirm that a design walk-through is conducted for all stakeholders and that stakeholder sign-off has been initiated before development (e.44 Inquire of key staff members to determine compliance with all obligations and requirements.2. 5. 5. 5.2. 5. 5.2.1.2.41 Inspect relevant documentation (such as design.11 Change management AI6.2.38 Obtain and review assessment documentation of the developed software to confirm adequacy. business case or key attributes of the project. 5.2.1.1. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. AI6.40 Perform a walk-through of code and identify problems/exceptions. 5. code review and walk-throughs) to identify exceptions to specifications and standards. 5.3 AI6.1. Page 55 .1.45 Review contractual obligations and licensing requirements relating to third-party developers.2 X X approval in the scope. 5.. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 5.1. PO10. 5. signature and date or e-mail confirmation).34 Confirm with IT and business stakeholders that a design walk-through has been conducted before development commenced.2.4 © 2009 ISACA.1. All rights reserved.g.1.37 Inspect relevant documentation (such as design.36 Confirm with key staff members that all development activity has been established to ensure adherence to development standards and that developed software is based on agreed- upon specifications to meet business.1 Control: A change management procedure is being utilized to document changes and AI6.1.

Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.2.3 Determine if a new risk assessment was required and has been performed. a PO10.1.1. Cross. security group. All rights reserved. 5.2.50. 5.2.47 Confirm that the approval process identifies effective dates for promotion of new systems. applications or infrastructure to production. 5. 5..50.1.2. third parties and IT stakeholders as appropriate (e.1. Planning and control PO10.2.1.46 Review procedures for program transfer to verify that a formal process exists that requires documented approval from user management and system development.1.2.50.1.50.50 Inquire of key staff members concerning procedures for updating all source program libraries and procedures for labeling and retaining prior versions. Page 56 . 5.1.2.2 Verify that the effect on the business case and project had been documented. 5.1. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 5. 5.1.2. 5.1.50.2. development group.1. database management.7 © 2009 ISACA.48 Inquire whether and confirm that the approval process includes a formal documented sign-off from business process owners.4 Verify that the appropriate approvals were obtained based upon thresholds. user support and operations group). Test objective: To verify that change management procedures have been followed. 5.g.6 X Control: The planning and control of the project includes effective time control.49 Confirm procedures for updating copies of system documentation and relevant contingency plan.1.2.1 Verify that the appropriate description of the change had been documented.1 Select changes from the change management log.1.

2.1.51.1. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference project plan with milestones. resource and milestone changes. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.1.53.1. deliverables.51 Determine that the project plan is updated with scope.2. 5.3 Verify that deliverables have been translated into activities. and makes a go/no-go decision to go onto the next subphase or task based upon the successful completion of the previous task or subphase and that decisions are appropriately authorized.2.53 Determine if management reviews significant milestones.1 Select several milestones.51.6 X X X decisions. 5. 5. All rights reserved.51.2. Test objective: To verify that go/no-go decisions are being made at appropriate milestones.2. a sequence of process.53.2 Determine if a go/no-go decision process was made at that milestone.11 and activity dependency.5 Determine that each task has a clearly stated objective and goal. Cross.4 Determine that project assumptions and constraints are documented and included in the plan.2 Verify that resource utilization can be realized (resources working double shifts or maintaining regular responsibilities while being assigned to the project team). © 2009 ISACA. 5.52 Verify that the status of each subphase is updated on a timely basis to show accurate percentage completion and any delays.2. approved by the authorized management and properly documented.1.13 5.3 Evaluate if the milestone required a go/no-go decision.1.53.51. 5.1. 5.2. PO10.1.1. 5. management exercises and documents go/no-go PO10. 5. resource projections PO10. Milestone go/no-go decisions Control: At major milestones.1.2.1.1 Verify that the milestones and tasks can be achieved with the resources available. Page 57 .51. 5.2.2.2. 5.

2.1.56.2.1.55 Determine the reporting cycle for progress control.57 Determine that the communications plan providing for status reports and exception reports up the project management hierarchy is executed on a timely basis and reports are distributed as planned.3 Verify that external consultants document their time.53.9 5.1 Verify that all team members record their time.2. Page 58 . Failure to record all time will affect the return on investment calculation and a benchmark for future business unit involvement. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.1.1. Communications PO10.3 X X X reported.4 Determine how and expenses are approved. PO10. is maintained and PO10. All rights reserved. but not business unit time.3 X X Control: Expenses and time management are accurately recorded and approved. 5.2.56.2 Control: Progress.56 Determine how resources record and expense time to the project.58 Determine that the communications plan for cross-team reporting is being followed. defined as meeting milestones and budgets.2 Expense and time management PO10. 9 Some entities record systems development time.2 Control: A communications plan is established to provide stakeholders and project PO10.1.4 Review the documentation for the decision-making process to ensure appropriate approval and description.2. 5.2. 5.2. PO10.2. and deliverables are recorded in the project management document. PO10.7 budgetary and timeline goals.2. adequacy of the distribution list and the review process for the progress reports. 5.7 5. © 2009 ISACA.3 X X X leadership with appropriate information to ensure that the project meets functionality. especially when those costs are not capitalized. PO10. 5.1.2 Verify that all costs are recorded.54 Determine if resource time reports. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 5. Progress control PO10.1.1. task completion percentages.7 5.56.56.1.2.1. 5. Cross.

Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.1.1.1. 5.7 alignment with the business case.3.1. complete and provide the information necessary to manage the project.5 Verify that the actual costs at the current stage of the project (based upon percentage completion) are in line with the budget for the same stage of the project. determine if the variance has been approved by the executive sponsor and/or steering committee.7 Determine if the appropriate costs are being capitalized or expenses based upon standard PO10.2. PO10.3.59 Determine that the communications frequency and content are in alignment with the documented communications plan. Accounting Control: The accounting of the project is in compliance with expense and X capitalization requirements.2 Budget status PO10.3. Page 59 .3 Determine if the budget and actual costs (including resources and expenses) are in X PO10.3.4 Obtain the budget and actual costs. If not. PO10.2 accounting principles.1.3 PO10. 5. Determine if there are known gaps that would impact the budget. segregated from other projects and is in X PO10.1.2 Determine if the budget is equal to the business case estimate.7 alignment with the percentage completion.13 5. 5.3 Budget Objective: The budget and accounting processes should be accurate. All rights reserved.3 Control: The project budget is defined.1 Verify that the budget reflects any changes in scope or identified issues.7 © 2009 ISACA. PO10.3.1. PO10.3.3. PO10. 5. Cross.1.6 Based upon the results of the actual versus budget. 5.3 Discuss the budget and deliverables with key members of the project team and executive sponsor. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 5.2 Budget design PO10. determine if management exception reporting has been initiated if the project is behind.13 5. 5.

© 2009 ISACA.1. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference PO10.13 Test objective: To verify that the costs are properly allocated.1. Cross.1 For a selected period.4. should be developed to provide an efficient.4 Internal controls Audit/assurance objectives: Internal controls.4. operations.2.4.3 X design subphase as part of the detailed design. 5. Determine if the allocations are within accounting guidelines. determine if the project team has identified the key controls required for oversight.1.1.4. 5.4. trace the expenses and resources charges through the accounting system. 5. All rights reserved.1 If it is an acquired system.1. which ensure the accurate and complete processing of data.1. review gap analysis of system’s functionality to system’s requirements.1.7.1.2 Based on the application’s function. security and regulatory requirements.1 Obtain an understanding of the intended functionality of the new application. 5. 5. streamlined and thorough approach to internal control of application data and processes.1.1 Review the identified key controls and recommend additional controls as necessary to provide good practices. Consider financial reporting. Determine if modification list or parallel system provides required functionality.1. Page 60 . 5.3. 5. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.1 Design Subphase Internal control requirements Control: Detailed internal control requirements are established during the AI2.

Consider the following areas: interfaces with other applications.4. 5.4.3.1. CAATs development Control: IT audit/assurance will utilize the reviews of the systems X X X development phases to understand and test the application. 5. critical processes or calculations.4.1. operational and financial risks. Cross.1. Internal control risk assessment Control: A controls risk assessment prepared by the project team during the PO10.4.1 Expand this audit/assurance program to address the application’s processes. 5. 5.4.1. © 2009 ISACA. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 5. 5.2.1. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.1.3.2 Interview stakeholders to identify their view of internal control requirements and ensure that their needs are included in the design and the audit/assurance process.1.1. All rights reserved. and manual interfaces.4. document how each control will be executed in the new system.1.1. Page 61 .1.5 Supplement the control risk assessment with IT audit/assurance identified risks.9 X X planning phase is updated to identify detailed internal control requirements based upon processing. to allow reliance on the internal controls of the completed and implemented application.4 Review the project team’s updated control risk assessment to determine if the controls identified are placed properly and the assessment is complete.3 Prepare work papers for future audit/assurance reviews.2 Prepare control objectives for each control area.1.3. 5.1.3 For each control objective.4.1.

requiring monitoring during the development phase.1. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 5.1.1.3 X process have been mapped to and included in specific processing solutions.1.4.2 If expanded scope is required and approved. prepare additional audit/assurance steps within this program.6 Identify the design of the CAATs. © 2009 ISACA. 5. 5. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.1. Page 62 . 5. verify that the prototyping activities are focused on the development subphase. IT audit/assurance is a stakeholder in the design process and is part of the project team for this process.4.2.2.4.2.2. 5.1.2.1.1 If control issues have been identified.2.1.4.3 If prototyping is being used as a development methodology.4. evaluate whether the scope of the audit/assurance project should be expanded to include these areas.2 Development/Prototyping Subphase Internal control requirements Control: Internal control requirements established during the project AI2. All rights reserved. 5.1.4. Cross. 5.1 Expand this audit/assurance program to reflect the monitoring and review process.1.4.2 Review issue monitoring reports to determine if control issues have been identified.1.1 Identify controls that IT audit/assurance considers of high risk.4.2.4. Design should not be modified without appropriate reviews and approvals. 5.7 Determine that the CAATs design will satisfy future IT audit/assurance needs. 5.2.

1.4. Page 63 . 5.2 Review the quality of the test scripts to ensure that they can be executed in the future as the processes change and that the level of detail is adequate to © 2009 ISACA.4 X been mapped to their implementation and thoroughly tested.1.1 Review user test scripts to ensure that both automated and manual processes that constitute the system of internal controls are tested.2.2.3 Internal control requirements AI7.1 Review user acceptance testing plans to ensure thoroughness of testing.3.1.6 Perform review of CAATs functionality at milestones and ensure audit/assurance objectives will be met by the CAATs.4.7 AI7.4 Establish milestones in the CAATs development requiring IT audit/assurance participation.3. AI7. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.1.2.1.2 Control: Internal control requirements established during the project have AI7. 5. 5. All rights reserved.4.4. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference Internal control risk assessment CAATs development Control: IT audit/assurance participates in the development of CAATs X X X processes.5 Participate in the development as required by the project team.3.3 Testing AI2.4.8 5.4.1. 5. Cross.1. 5.1.4. 5.

© 2009 ISACA. 5.3.1. the issues are risk-assessed.4.4.1.3 Perform tests and document results. determine if testing can be re-performance of the UAT or if new scripts need to be created and executed.3.3. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference allow the scripts to be repeatable in the future. 5.4. 5.1.4.3. 5.1.4.4. 5. If sufficient testing will be performed and change management is at a good- practice level.4. 5.3. Cross.1 If independent testing is required.1.3. All rights reserved.5 Determine the level of reliance to be placed on the IT audit/assurance review of the development process. the delivered system can be relied upon for audit/assurance purposes.1. and remediation is appropriately scheduled.2 Review the results of the tests to ensure identified testing issues are registered in the issue management system.4.6 Determine if integrated CAATs will be built into the system to facilitate later audit/assurance activities.1.1.4 Determine if independent testing is required by IT audit/assurance to satisfy audit/assurance objectives.4.4. if necessary. 5.3 Review the issue monitoring reports to ensure that reported issues have been remediated on schedule with the solutions defined in the remediation documentation.2 Prepare test scripts. Internal control risk assessment CAATs development X X X Control: IT audit/assurance thoroughly tests CAATs processes as a UAT.3. 5.3.4. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. Page 64 .

4 Conversion Internal control requirements Control: Conversion internal control requirements established during the AI2.1. integration testing.4. Testing requirements AI7.2 Control: Testing is performed according to project and enterprise standards and X AI7.3 X project have been designed.4. conversion testing and stress testing. 5. At minimum. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.5 Adequacy of testing Audit/assurance objective: The execution phase should exhibit adequate testing at the various stages of development. Parallel testing or separate operating platform testing prior to implementation should be considered.7 requirements and the testing is documented and reviewed.4. integration of manual and automated processes. implemented and tested. Cross.1 Determine if testing requirements have been performed for each type of testing according to the subphase (unit.4. 5.4. 5. UAT. Assess internal control risk Develop CAATs 5.3 Review the final conversion control/reconciliation reports and conversion summary prepared for management to identify any control issues identified during the conversion process.1. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 5.5. integration.2 Review conversion test run to ensure that the process is ready for the final conversion prior to the system going live. the timeframe for testing and documentation requirements. including definition of the types of tests to be performed.1.4. stress © 2009 ISACA.1 Review conversion controls to ensure that data will be converted accurately and completely.1. user acceptance. Page 65 . All rights reserved. 5. testing should include unit testing.4.

documentation.1.5. Tests should include test objective. All rights reserved.2 Control: Test scripts and volumes are adequate to ensure accurate.1. Project Plan AI7. Testing content AI7.7 Determine if the delivery of the system UAT is late.5.1. Page 66 .6 Review the project plan and determine if adequate time has been provided for testing. resulting in limited testing or remediation identified by testing not included in the production release.9 Review test results to known results (either based on an independent process or manual calculation).5. size. effective and X AI7. 5.8 Review test results to ensure full testing of system.3 Verify approval of the test plan by the business owner.5.1. scope.4 Confirm that the project lead has signed-off on test results.5. 5. 5. Cross. scripting (where appropriate).5. 5.1.1.2 Control: The project plan provides adequate time for testing and remediation based X AI7. 5.5. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.10 Review stress testing results to ensure that realistic volume is used to © 2009 ISACA. 5.1. review and approval.5. timing.5. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference and conversion testing).7 upon test results.1. 5.2 Determine if the test suite of transactions will be available later for regression testing after major system updates.1.5 Verify that the test scripts and test results have been properly reviewed and approved by management and the business owner.7 complete results. 5. 5.

Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. Cross. 5.6.1.6. 5.3 X of a full roll-out of the application.7 X X X X system is ready for the implementation phase. Pilot test plan PO10. a risk analysis of the impact to the business of moving to © 2009 ISACA. 5. AI7. 5.1.1.1. Readiness assessment PO10.4 Determine if go/no-go evaluation was considered at the conclusion of the pilot.6.3 Determine that pilot objectives were achieved after the completion of the pilots.6.3 5. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference stress test the system for current and future volume. Determine if the scope of the pilot is complete and evaluate the effectiveness of the pilot test.6.7 Control: Pilot implementations of the new processes are utilized to minimize the risks AI7.6 Implementation Audit/assurance objective: The implementation plan should be developed to ensure minimum disruption during the initial implementation of the new system and thorough vetting of the processes prior to final “throwing the switch” to the new system.6 Control: A readiness assessment is part of the implementation plan to ensure that the PO10. 5. All rights reserved.5 Determine if a readiness assessment was performed prior to moving the project to the implementation phase.4 5. Page 67 .6. AI7.1.1.1 Review the results from the pilot tests.6 Determine if the readiness assessment included an inventory of open issues.2 Determine that a review process was effective in ensuring that pilot test results adequately address issues identified during the test process and that these issues are included in the issue monitoring system.

1. All rights reserved.6.5 implementation. 5.6 Control: A conversion plan has been thoroughly tested and data reconciled prior to X AI7. approval from key stakeholders and a report to executive sponsor and/or steering committee. evaluate the effectiveness of the disposition and any risks to the project.3 5.1. Resource planning PO10. AI7. © 2009 ISACA. 5.12 Review the communications plan.11 Determine if the steering committee and/or executive sponsor have reviewed and approved the conversion prior to going live. 5.9 Review the results of the conversion plan.6. 5. 5.6.6.1. Cross.1.6 Control: Resource planning is monitored during the execution process to ensure PO10.5 X X progress of the roll-out.6.7 X adequate coverage of essential processes during implementation.6.8 Determine if any resource planning issues were identified. distribution list and content of the communications plan. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference implementation. Determine that communications are in compliance with the plan including frequency. Conversion plan PO10. tests and data reconciliation for completeness and readiness. Page 68 .10 Consider further independent tests of the conversion reconciliation if it is considered high risk or the conversion tests don’t adequately document the assurance processes.1. Communications plan Control: A communications plan informs stakeholders and management of the AI7.1.7 Determine that the resource plan is maintained and monitored to address the resources required for the current subphase. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.

All rights reserved. training materials. © 2009 ISACA.1. 5. Cross. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.6. AI7. 5.13 Review the results of the training programs for the various affected parties.1..6. 5. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference Training planning AI4. Backout plan AI4. approval and X AI7.6.6.1 Control: A transition plan has been implemented to address interim processes that are X AI7. Page 69 .1 5.1.2 Interview the IT operations staff to verify they have been trained in the scheduling and processing of the new system.3 Interview the help desk staff to verify that they are prepared to assist users in the use of the new system. procedure manuals.1. online help.3 required until the new system is fully operational and integrated with other systems.6.6.1.13. 5. 5. user manuals.1.1 Control: The backout plan has been prepared with appropriate review.13.3 decision points to initiate the plan. 5.13.6. etc.2 Control: The training program has trained affected functions prior to AI4.16 Determine if interim processes that are required due to temporary interfaces or processes until all full integration of processes are functioning.14 Review training and implementation materials for required content.1.1.6.) for adequacy.15 Review support materials (e. 5.4 X implementation.g.17 Determine if the backout plan was initiated.1 Interview the transaction processors to verify they have been properly trained in the use of the new system. help desk written procedures. Transition plan AI4.

5. 5. and ensure deliverables are achieved and payments to vendors are paid upon achievement of contract provisions.1.1 Obtain SLA agreement and SLA monitoring documents. determine that processing has returned to a steady state using the old systems. 5.1.1. determine current status.18 If the backout plan has been initiated.7.1 Determine that SLAs have been achieved.7.2. 5.1. 5. 5. and AI5.1 Review the penalties assessed.2 Determine that remediation procedures have been implemented where SLAs have not been realized.7.7.7.7. Page 70 .1. Determine if they have been paid.4 Determine if further escalation has been initiated. needs to be initiated or © 2009 ISACA.2 Verify that SLAs have been achieved by comparing the agreements to the documents.6. Vendor selection SLAs and contract fulfillment Control: SLAs are fulfilled and the vendor is in compliance with contract.1.1.7. 5. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.1 Verify that SLAs that have not been achieved have been included in the vendor remediation plan.1. 5.7 Third-party providers Audit/assurance objectives: Third-party providers should be managed effectively to provide maximum ROI.3 Determine if penalties have been assessed and collected in compliance with the contract.1.1. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 5.7.1. If not.2 X assignment of penalties for failure to comply with the contract have been levied and collected. All rights reserved. Cross. 5.3.

PO10.5 analysis to ensure that it will integrate into the organization’s architecture. All rights reserved.7.1.8 Inspect good practices supplied by vendors.5 Determine if vendors provide timesheets to reflect work performed. CLOSURE PHASE Closure is the process of closing the project.1 Governance Audit/assurance objective: Governance over the project should be achieved through management’s oversight.1. and transferring the remaining processes to operations functions.7.1. 6 . 6. Determine that the timesheets are approved by project team management.1.6 Determine if vendor invoicing is accurate according to the contract and supported by timesheets or other deliverables. compare with the implementation strategy. 5. finalizing the costs and accounting treatment.7 Confirm with key staff members whether the application software is customized and configured utilizing good practice as advised by vendors and conforming with internal architecture standards. Vendor invoicing Control: Vendor invoicing is reviewed regularly and disputed charges are returned to AI5. 5. Page 71 . 5. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference legal issues need to be escalated.1 X X X Business case © 2009 ISACA. and identify inappropriate configuration and customization.4 X the vendor.7. Intellectual property Integration of vendor-provided application software into the organization Control: Vendor provided application software is subject to QA testing and further AI2. Cross.7. 5.

PO10. ME4. Page 72 .1. Integration of business/information management Composition of project team PO10. All rights reserved.14 © 2009 ISACA. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference PO10.3 6.1.1.5 and/or steering committee.3 Verify the formal closure of the project by the executive sponsor. 6.3 X the project. Return on investment and KPIs Escalation management 6.13 PO10.1.2 Review the scope change log and verify that all major changes affecting the business case have been included. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.2 Project management Audit/assurance objective: The project management activity should be ended. Cross.9 Control: Open issues have been transferred to line operations. Scope management Roles and responsibilities Control: The executive sponsor has approved and formally documented the closure of PO10.2 X Risk and issue management PO10.2 ME4.14 AI1. with all active project follow-up transferred to operations or business units.1 Control: All business case modifications have been approved by the executive sponsor ME1. 6.1.1 Interview the executive sponsor to ensure that the business case and the expected business processes/features were delivered with the application.1.

All rights reserved.1.1.2. PO10.1. PO10.2. Milestone go/no go decisions Progress Control Expense and time management PO10.4 Verify that no charges have been applied to the project since the closure date.1 Verify that open issues.2 Control: Expense and time management processes are closed. Escalation procedures Quality management Use of development methodology Change management Planning and control PO10.2 6. so no additional PO10.14 6. and open fixes (sometimes referred to as a “punch list”).3 X resource or expenses charges can be allocated to the project.7 6.2.6 X Control: Project management verifies that all deliverables have been completed.2 Verify that the project manager has formally documented receipt of all expected deliverables.2 Communications PO10. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference AI1.3 Verify that the time and expense has closed the project.3 X X X Control: The stakeholders have been notified of the closure of the project. 6. are transferred to the appropriate operating group. PO10. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. including needed revisions. PO10.1. Cross. Page 73 .2.7 © 2009 ISACA.

3. If not.1.1.2 Accounting PO10.1.3.3. Determine that all costs have been applied.3.5 Verify that stakeholders are aware that the project has been closed.4 Determine if the budget is equal to the business case estimate.7 X capitalization requirements.6 Determine if the appropriate costs have been capitalized or expensed based © 2009 ISACA.5 Discuss the budget and deliverables with key members of the project team and executive sponsor. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 6. PO10.2 Budget status PO10.14 6. PO10. All rights reserved.1.2. 6.3. with variance explanations. complete and provide the information necessary to allocate final costs to the project. PO10. 6.3 Control: The accounting of the project is in compliance with expense and PO10.3 Budget Objective: The budget and accounting processes should be accurate. The budget to actual is PO10.2 Determine if all scope changes have been included in the final financial report. Cross.13 PO10. Determine if the final budget figures were in line with the expectations.1.13 PO10.7 X prepared. Page 74 . Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. determine if the variance has been approved by the executive sponsor and/or steering committee.3 Perform a cut-off audit to ensure that all costs are included. 6.14 6.1 Review the final budget figures.1. 6.3.1. 6.3 Control: The project budget is finalized with all costs. PO10.

6.3.1. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference upon standard accounting principles. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.7 Determine if additional funding requests had been approved and reflected in the accounting for the project. Page 75 . Internal controls Internal control requirements Internal control risk assessment CAATs development Adequacy of testing Testing requirements Project plan Testing content Implementation Pilot test plan Readiness assessment Resource planning Conversion plan Communication plan Training planning Transition plan Backout plan © 2009 ISACA. All rights reserved. Cross.

3 Determine if vendors were required to return enterprise property (badges.) 6.4. etc. 6. Cross. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 6.1.1.5 X property returned.4 Third-party providers Audit/assurance objectives: Third-party providers should be paid according their contracts. Page 76 .4 Determine if vendor access to enterprise information systems has been suspended or deleted. if necessary. POSTIMPLEMENTATION PHASE The postimplementation review addresses the:  Review of the project success  Financial review of the business case vs. Vendor selection SLAs and contract fulfillment Control: Contract provisions have been reviewed. 6.1 Determine if the project manager has reviewed all deliverables to determine vendor satisfaction of contract. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.2 Determine if legal has reviewed the delivery of contract deliverables and agreed to successful completion of the contract. penalties collected and all deliverables due from the vendors received. Vendor invoicing Intellectual property Control: Vendor’s access to enterprise information is deactivated and all enterprise IA2. open contract issues have been reviewed by project management and the executive sponsor. 7 .1.2 X and accepted.1. 6. documents. All rights reserved.4. all deliverables have been reviewed AI5. remediation processes concluded. results © 2009 ISACA.4.4.

Systems Development and Project Management Audit/Assurance Program

COSO

Risk Assessment

Information and Communication
Reference Issue
Hyper- Cross- Comments

Control Environment
link reference

Control Activities
COBIT

Monitoring
Audit/Assurance Program Step Cross-
reference

 Lessons learned and improvements for the future
7.1 Governance
Audit/assurance objective: The business case should be achieved, (i.e. project costs are within
budget and management has provided governance over the project).
Business case
Control: The project team leadership, on a regular basis, monitors and provides AI7.9 X X X
reports to the executive sponsor on the continued alignment of the project plan with
the business case.
7.1.1.1 Interview the executive sponsor to ensure that the business case and the
expected business processes/features were delivered with the application.
Scope management
ROI and KPIs
Control: The project’s ROI and KPIs have been reviewed by the steering committee AI7.9 X X X
and executive sponsor.
7.1.1.2 Review the calculation of the project’s ROI.
7.1.1.3 Review the final KPIs for accuracy.
7.1.1.4 Determine if the key metrics have been reviewed and approved by the
steering committee and the executive sponsor.
Escalation management
Project management
Integration of business/information management
Risk and issue management
Escalation procedures
© 2009 ISACA. All rights reserved. Page 77

Systems Development and Project Management Audit/Assurance Program

COSO

Risk Assessment

Information and Communication
Reference Issue
Hyper- Cross- Comments

Control Environment
link reference

Control Activities
COBIT

Monitoring
Audit/Assurance Program Step Cross-
reference

Quality management
Use of development methodology
Change management
Planning and control
Milestone go/no go decisions
Progress control
Expense and time management
Communications
Control: The stakeholders have been received and reviewed ROI and key AI7.9 X X X
performance metrics.
7.1.1.5 Verify that the ROI and key performance metrics have been provided to the
key stakeholders, including the executive sponsor and steering committee.
7.1.1.6 Determine if there is documented evidence of executive review of the metrics.
7.2 Budget
Objective: The budget and accounting processes should be accurate, complete and provide the
information necessary to allocate final costs to the project.
Budget status
Control: The project budget is finalized with all costs. The budget to actual is AI7.9 X
prepared, with variance explanations. Management analyzes variances and evaluates
how negative variances can be minimized in the future.
7.2.1.1 Determine the project summary report received by management.
7.2.1.2 Determine if the level of detail provides management with the explanations
necessary to evaluate variances.
© 2009 ISACA. All rights reserved. Page 78

Systems Development and Project Management Audit/Assurance Program

COSO

Risk Assessment

Information and Communication
Reference Issue
Hyper- Cross- Comments

Control Environment
link reference

Control Activities
COBIT

Monitoring
Audit/Assurance Program Step Cross-
reference

7.2.1.3 Perform a cut-off audit to ensure that all costs are included.
7.2.1.4 Determine if the budget is equal to the business case estimate. If not,
determine if the variance has been approved by the executive sponsor
and/or steering committee.
7.2.1.5 Discuss the budget and deliverables with key members of the project team
and executive sponsor. Determine if the final budget figures were in line
with the expectations.
Accounting
Control: The accounting of the project is in compliance with expense and AI7.9 X
capitalization requirements.
7.2.1.6 Determine if the appropriate costs have been capitalized or expensed based
upon standard accounting principles.
7.2.1.7 Determine if additional funding requests have been approved and reflected
in the accounting for the project.
7.3 Internal controls
Audit/assurance objectives: Internal controls, which ensure the accurate and complete processing
of data, should be designed in the planning phase, when it is most efficient to modify, enhance or
aggregate controls to provide a streamlined but thorough approach to internal control of
application data and processes.
Internal control requirements
Control: Internal control requirements were reviewed and implemented during the X
development process and internal control deficiencies have not been identified after
implementation.
7.3.1.1 Verify that internal control requirements identified in the planning and
design phases have been implemented.

© 2009 ISACA. All rights reserved. Page 79

1.1. Determine if a remediation plan has been developed and implemented. Internal control risk assessment CAATs development 7.3. If sufficient testing will be performed and change management is at a good-practice level.4 Determine the level of reliance to be placed on the IT audit/assurance review of the development process.3 Review the identified key controls and recommend additional controls as necessary to provide good practices.3.5 Determine if integrated CAATs will be built into the system to facilitate later audit/assurance activities.1. 7. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference 7. during testing.2 Determine if control deficiencies identified after development. Cross. All rights reserved. the delivered system can be relied upon for audit/assurance purposes. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper.3. Page 80 . 7.3. implementation or after implementation remain.1. Adequacy of testing Testing requirements Project plan Testing content Implementation Pilot test plan Readiness assessment Resource planning Conversion plan © 2009 ISACA.

if necessary.4. open contract issues have been reviewed by project management and executive sponsor.1. Intellectual property © 2009 ISACA. Cross. Page 81 . penalties collected and all deliverables due from the vendors received. Vendor selection SLAs and contracts fulfillment Control: Contract provisions have been achieved. Systems Development and Project Management Audit/Assurance Program COSO Risk Assessment Information and Communication Reference Issue Hyper. remediation processes concluded.1. 7.1 Determine if open issues remain with the vendor.3 X and accepted.4. All rights reserved.2 Determine if remediation plans are in effect to address open issues. all deliverables have been reviewed AI5. Comments Control Environment link reference Control Activities COBIT Monitoring Audit/Assurance Program Step Cross- reference Communication plan Training planning Transition plan Backout plan 7. 7.4 Third-party providers Audit/assurance objectives: Third-party providers should be paid according their contracts.

communicating and authorising changes to the project scope. Systems Development and Project Management Audit/Assurance Program VII. Determine the interdependencies of multiple projects in the programme. Reference Assessed Target Hyper. Assign each IT project one or more sponsors with sufficient authority to manage execution of the project within the overall programme. 5. the initiating. Ensure that the project management method covers. put in place mechanisms such as regular reporting and © 2009 ISACA. IT resources and business resources where applicable. communication and liaison with these parties. and is an integral component of. evaluating. Review progress of individual projects and adjust the availability of resources as necessary to meet scheduled milestones. 2. including legal. Ensure that the project management framework includes: • Guidance on the role and use of the programme or project office • A change control process for recording. the organisation’s programme management framework. planning. at minimum. and the reviewer’s observations. All rights reserved. Specify required resources. project teams. Maturity Assessment The maturity assessment is an opportunity for the reviewer to assess the maturity of the processes reviewed. PO10. and. Ensure that the project management framework is consistent with. regulatory and reputational risks. 2. as necessary. including all the projects required to achieve the programme’s expected business outcomes. the project manager. Determine programme stakeholders inside and outside the enterprise.1 Program Management Framework 1. Gain formal approval of the document from key business and IT stakeholders. Define the responsibility and accountability of the programme sponsor. To track the execution of a project. assign a maturity level to each of the following C OBIT control practices. 4. 4. managing the risks and co-ordinating the project activities. Verify periodically with the business that the current programme as designed will meet business requirements and make adjustments as necessary. complexity and risks. Based on the results of audit/assurance review.2 Project Management Framework 1. executing. controlling the costs. Page 82 . including funding. Define and document the programme. and establish and maintain appropriate levels of co-ordination. including achieving the benefits. Assign accountability clearly and unambiguously for each project. controlling and closing project stages.3 Project Management Approach 1. project managers. 3. Comments COBIT Control Practice Maturity Maturity link PO10. the steering committee and project management office. establish a project management governance structure appropriate to the project’s size. project requirements or system design • Requirements for integrating the project within the overall programme 3. Prior to each project’s initiation. and develop a schedule for their completion that will enable the overall programme schedule to be met. PO10. as well as checkpoints and approvals. 2. 3.

. Obtain the commitment and participation of key stakeholders.6 Project Phase Initiation 1. within budget and aligned with the agreed-upon scope. 2. scope and business benefit of every project to create a common understanding of project scope amongst stakeholders. and identification of a critical path.5 Project Scope Statement 1. Ensure that the project definition describes the requirements for a project communication plan that identifies internal and external project communications. project board representation. clear work breakdown structures and work packages. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. user procedures documentation and project communication material development.4 Stakeholder Commitment 1. Assess the project at agreed-upon major review points. project planning. 2. milestones. Assess whether the project is on schedule. All rights reserved. key personnel) and deliverables with other projects. PO10. required resources and responsibilities. project checkpoint reporting. Base the approval process on clearly defined acceptance criteria agreed to by key stakeholders prior to work commencing on the project phase deliverable. Assess identified variances and identify the impact on the project plan and realisation of expected benefits. but is not limited to. 2. PO10. Identify interdependencies of resources (e. key dependencies. project approval. reflecting changing requirements. Provide to the stakeholders a clear. and make formal ‘stop/go’ decisions based on predetermined critical success criteria. product testing. estimates of resources required. Develop a project plan that provides information to enable management to control project progress. including definition of project success (acceptance) criteria and key performance indicators. With the approval of stakeholders. Page 83 .g. written statement defining the nature. 2. Comments COBIT Control Practice Maturity Maturity link stage reviews that are the responsibility of the project manager to complete in a timely manner. maintain the project definition throughout the project. 3. Ongoing involvement includes. user training. Outline during project initiation ongoing key stakeholder commitment and roles and responsibilities for the duration of the project life cycle. PO10. project phase approval. definition and authorisation of a project. 4. Maintain the project plan and any dependent plans to ensure that they are up to date and © 2009 ISACA. 4. Gain approval and sign-off on the deliverables produced in each project phase from designated managers and customers of the affected business and IT functions. The plan should include details of project deliverables. including management of the affected user department and key end users in the initiation. 3. Ensure that key stakeholders and programme and project sponsors within the organisation and IT agree upon and accept the requirements for the project.7 Integrated Project Plan 1. PO10.

human resources. PO10. and maintain a log of all project issues and their resolution. Maintain and review a project risk register of all potential project risks. PO10. Manage and communicate risks appropriately within the project governance structure. IT skills matrix). Staff the roles based on available skills information (e. success criteria and performance metrics. including finance. quality review processes. 2. Consider and clearly define the roles and the responsibilities of other involved parties. 5. Perform the project risk assessment of identifying and quantifying risks continuously throughout the project. 4. Clearly define and agree upon the responsibility for procurement and management of third- party products and services. procurement. Define any requirements for independent validation and verification of the quality of deliverables in the plan.g. with escalation and decision-making authorities agreed upon and understood. 2. accept or mitigate risks. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper.10 Project Quality Plan 1. Establish a formal project risk management framework that includes identifying. 3. 5. legal. Identify risk and issue owners for responses to avoid. Ensure that any changes made to individual plans are reflected in the other plans. 2. Ensure that there is effective communication of project plans and progress reports amongst all projects and with the overall programme. to provide quality assurance for the project deliverables. responding to. 3. Analyse the log periodically for trends and recurring problems.11 Project Change Control © 2009 ISACA. Identify required skills and time requirements for all individuals involved in the project phases in relation to defined roles. to ensure that root causes are corrected. Reassess project risks periodically.. monitoring and controlling risks. including at entry into each major project phase and as part of major change request assessments. mitigating. 6.8 Project Resources 1. PO10. and manage the relationships. Assign to appropriately skilled personnel the responsibility for executing the organisation’s project risk management framework within a project. especially if an objective viewpoint is required or a project is considered critical. Comments COBIT Control Practice Maturity Maturity link reflect actual progress and material changes.9 Project Risk Management 1. analyzing. internal audit and compliance. 4. All rights reserved. 3. Identify resource needs for the project and clearly map out appropriate roles and responsibilities. Consider allocating this role to an independent team. Page 84 . Utilise experienced project management and team leader resources with skills appropriate to the size. complexity and risk of the project. Identify ownership and responsibilities. PO10.

Define and apply key steps for project closure.. Recommend. Include key compliance stakeholders in the definition and approval of assurance tasks. 2. 5. when required. Monitor changes to the program and review existing key project performance criteria to determine if they still represent valid measures of progress. Comments COBIT Control Practice Maturity Maturity link 1. audit.12 Project Planning of Assurance Methods 1. but not limited to. Determine and document how the assurance tasks will be performed. Review the completed change request and document the approval or denial of the request by key stakeholders. Reporting and Monitoring 1.g. implement and monitor remedial action. © 2009 ISACA. Document the estimated project impact in the change request. 4. Define the assurance tasks required to ensure compliance with internal controls and security requirements that impact the systems or processes in the scope of the project. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. and communicate approved changes to all business and IT stakeholders in a timely manner. in line with the program and project governance framework. quality. Update the project and programme plans for all approved changes. Establish a standard change request form and request process requiring documentation of the requested change and the expected benefits of the change. schedule. deviations from established key project performance criteria. 3. Include appropriate subject matter specialists (e. scope. Review change requests and estimate the potential effects on the project. 2.13 Project Performance Measurement. including. including business project sponsor and IT project manager. 3. Communicate revised criteria to project managers for use in future performance reports. and assess positive and negative effects on the programme and its component projects. PO10. 2.14 Project Closure 1. Consider and approve at the programme level all approved project change requests based on an assessment of the effect the change will have on the other projects. IT personnel) authorised to make project change requests. cost and level of risk. Page 85 . Measure project performance against key project performance criteria. 4. including post-implementation reviews that assess whether a project attained desired results and benefits. including resource requirements and impact on schedule. Report to identified key stakeholders progress for the programme and component projects. Establish and use a set of project criteria as part of the programme management framework. Document and submit any necessary changes to the programme’s key stakeholders for their approval before adoption. If the requested change should not be implemented. and positive and negative effects on the programme and its component projects. PO10. All rights reserved. The program management team should designate the individuals (business stakeholders. PO10. share the reasons with the requesting project management team so they can evaluate alternative approaches. security or compliance) in the process. Analyse deviations from established key project performance criteria for cause.

Plan and execute post-implementation reviews to determine if projects delivered expected benefits and to improve the project management and system development process methodology. Collect from the project participants and reviewers the lessons learned and key activities that led to delivered benefits. ensuring that business. Identify. 2. technology and project risks are properly identified. complexity. assessed and understood by all stakeholders. operation. prioritised and recorded in a way that is understandable to the stakeholders. and disposal) on the organisation’s risk profile and © 2009 ISACA. deployment. operations. strategic direction. structure. Comments COBIT Control Practice Maturity Maturity link 2. Analyse the data and make recommendations for improving the project management method for future projects. Consider as part of the risk analysis the impact of the project (development or acquisition. are considered.1 Definition and Maintenance of Business Functional and Technical Requirements 1. examined. people skills and competencies. and enabling technology. All rights reserved. Define and implement a requirements definition and maintenance procedure and a requirements repository that are appropriate for the size. 4. Page 86 . strategic and tactical IT plans. objectives and risks of the business initiative that the organisation is considering undertaking. implementation. emerging regulatory requirements. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. configuration) AI1. 2. business case. captured and prioritised. 3. captured. Confirm that the functional and technical requirements are considered. communicate and track any uncompleted activities required to achieve planned programme project results and benefits. assign. including relevant acceptance criteria. Confirm that the requirements include aspects regarding: • Continuity • Legal and regulatory compliance • Performance • Reliability • Compatibility • Auditability • Security and risk management • Availability • Ergonomics • Operability and usability • Safety • Documentation (end user. Confirm that all stakeholder requirements. 4. retirement. This procedure should take into account the nature of the enterprise’s business. 3. business sponsors and technical implementation personnel. Use a holistic approach to risk analysis.2 Risk Analysis Report 1. in-house and outsourced business and IT processes. AI1.

3.g. AI1. and take into account scope and/or time and/or budget limitations. All rights reserved. operate and maintain. Involve appropriately qualified and experienced users in the design process to draw on their expertise and knowledge of existing systems or processes. Ensure that the high-level design is approved and signed off on by IT stakeholders (e.4 Requirements and Feasibility Decision and Approval 1.3 Feasibility Study and Formulation of Alternative Courses of Action 1.1 High-level Design 1. Perform quality reviews at the end of each key project stage to assess the results against the original acceptance criteria. 6. Establish that no project proceeds to development without appropriate sign-off by the business. 2. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. 3. Review the alternative courses of action with all stakeholders. and gather feedback requiring further feasibility analysis. strategies. functional. 2. Identify required actions for the acquisition or development. Define and execute a feasibility study that clearly and concisely describes the key alternative courses of action that will satisfy the business and functional requirements with an evaluation of their technological and economic feasibility. human/computer interaction. Establish that no project proceeds to the business approval process without appropriate review and sign-off by IT stakeholders. including risks and cost. and compliance with laws and regulations. Page 87 . 5.. and obtain approval and sign-off. constitutes a solution that the organisation can deliver. Confirm that the design is consistent with the business plans. Consider appropriate business. privacy. AI1. AI2. Establish a high-level design specification that translates the business requirements for the software development based on the organisation’s technological direction and information architecture model. Business sponsors and other stakeholders should sign off on each successful quality review.2 Detailed Design © 2009 ISACA. security. and select the most appropriate one based on feasibility criteria. 2. Obtain sign-off from the business sponsor and technical authority for the proposed approach. Confirm that the design approach and documentation are compliant with the organisation’s design standards. Submit the final high-level design after QA sign-off to the project sponsor/business process owner. availability. applicable regulations and IT plans. 3. technical and project risk mitigation activities as part of the definition of the possible solutions. security and other experts) to ensure that their inputs have been recognised and the design. AI2. 4. as a whole. Translate the preferred course of action into a high-level acquisition/development plan identifying resources to be used and stages requiring a go or no-go decision. Comments COBIT Control Practice Maturity Maturity link threats to data integrity.

including the capacity of personal computing devices and network bandwidth and availability. Consider the impact of differing update cycles. usage. Classify data inputs and outputs according to information architecture and data dictionary standards. Comments COBIT Control Practice Maturity Maturity link 1. including prototypes. processing and output) based on business process control requirements provided in the requirements documentation. Various aids can be used to assist with the sign-off. Conduct a design walk-through with IT and business stakeholders before development is initiated. packaged software. Consider the impact of system-to-system interface design on infrastructure performance. Design the interface between the user and the system application so that it is easy to use and self-documenting. Consider availability. to aid stakeholder understanding of the final design. web forms. Reassess system design whenever significant technological and/or logical discrepancies occur during design. Specify the source data collection design. Define how business processes will need to be adjusted to use the automated control © 2009 ISACA. AI2. Results of the reassessment should be subject to the normal approval cycle. failure recovery and backup processing arrangements. control and auditability. Define all automated application controls (authorisation. integrity and confidentiality of output data. logging. completeness. input. Prepare and document detailed design specifications in accordance with organisational and industry-accepted specification standards and the information architecture. method of generation and other design details. Consider availability. 5. external parties. and design appropriate integration approaches. external parties. Based on the user requirements and taking into account the different types of recipients. etc. 10. Define system availability requirements. Define the processing steps. 2. All rights reserved. and network requirements. 9. control and auditability. development and maintenance. and audit trails. etc. including specification of transaction types and processing rules incorporating logic transformations or specific calculations. 3. location and retrieval of data. 2. 6. details required. Assess the impact on existing applications and infrastructure during the process of gathering requirements and designing the solution. 4. 7. Page 88 . Consider the impact of data outputs to other programs. and design appropriate redundancy. 8. as a part of the sign-off process for the design specifications. Define file and database requirements for storage.3 Application Control and Auditability 1. frequency. documenting the data that must be collected and validated for processing transactions as well as the methods for validation. define the data requirements for all identified outputs. Consider data inputs from existing programs. including packaged software acquired from third parties. Appropriate design requirements should guarantee the availability. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. security. 11. Address integration of the planned application system with existing or planned co-operating applications and infrastructure.

load detection. and risk management standards and objectives. cost-benefit justification and other requirements.5 Configuration and Implementation of Acquired Application Software 1. data integrity and audit trails). Obtain their sign-off on and approval of the design. Confirm the design of security.4 Application Security and Availability 1. Confirm the design specifications for all automated application controls with IT technical authorities and business process owners. and regulatory and compliance requirements for security and privacy. appropriate user interfaces. and automatic recovery. to confirm understanding. and obtain their approval and sign-off. Also confirm with business process owners that the design meets their security and availability requirements using non-technical walk-throughs.. Confirm that the design has received sign-off from relevant technical design authorities and approval of the business process owner. AI2.. access management. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. where necessary. shared and federated databases. access control mechanisms. subject matter experts. Comments COBIT Control Practice Maturity Maturity link functions provided in purchased/packaged application software. Consider the security and availability infrastructure already in place. control. Consider the effect of compensating controls outside the application software realm. networks and storage) in the design specification. Confirm that the design includes automated controls within the application that support general control objectives (such as security. AI2. availability. 3. 4. Where possible. including access control mechanisms and database integrity controls. All rights reserved. and recovery mechanisms. These approaches should take into account the organizational security architecture and policies. industry security and privacy best practices. Consider interoperability with existing applications and databases. © 2009 ISACA. build on and extend these capabilities. authentication and transaction integrity. Define how the solutions for security and availability in the infrastructure will be integrated with the application. Consider access rights and privilege management. protection of sensitive information at all stages. Page 89 . auditability. Assess design specifications of automated application and general controls against internal audit. Assess the impact of any major upgrade and classify it according to agreed-upon objective criteria (such as business requirements). authentication and protection of transaction integrity with IT technical authorities and.g. 4. access management. paying particular attention to transactions. as appropriate. 2. based on the outcome of analysis of the risk involved (such as impact on existing systems and processes or security). Design approaches and solutions to security and availability that adequately meet the defined requirements. Internet). 3. local and wide area networks (e. security framework and standards. 5. and efficient utilisation of technology resources (e. 5. 2. availability.g. Follow normal system development and implementation processes as appropriate for the nature of the change.

Assess whether these changes restrict the ability of the organization to adopt vendor upgrades to purchased applications packaged software. Review contractual arrangements with the vendor. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. Assess the impact of any major upgrade and classify it according to specified objective criteria (such as business requirements). Obtain agreement on and approval of the implementation of the development and implementation process with the business process sponsor and other affected stakeholders. 7. interoperability with existing applications and infrastructure. 4. Follow normal system development and implementation processes as appropriate for the nature of the change. 10. Ensure that user and operational manuals (online help) are complete and updated where necessary to account for any customisation or special conditions unique to the implementation. Page 90 . Consider escrow arrangements where the source code is not available. Consider when the effect of cumulative customizations and configurations (including minor changes that were not subjected to formal design specifications) require a high-level reassessment of the acquired solution and associated functionality. 6. Comments COBIT Control Practice Maturity Maturity link 3. Assess the risks in the event that the acquired application packaged software is no longer available at the expiry of a contract or for other reasons. 5.6 Major Upgrades to Existing Systems 1. 8. integrated capacity and load stress testing. system performance efficiency. based on the outcome of analysis of the risk involved (such as impact on existing systems and processes or security). All rights reserved. Assess whether these changes trigger the development of a detailed design specification for customisation and configuration of the application software. 11. Conduct a design walk-through with IT and business stakeholders before customization is initiated. Consider the effect of contractual terms with the vendor on the design of customisation and configuration. operating systems and other infrastructure. Consider the impact of customisation and configuration on the performance and efficiency of the acquired packaged application software and on existing applications. Consider whether the implications of customisation and configuration require reassessment of strategies for acquired application packaged software. Ensure that testing procedures cover verification of acquired application control objectives (such as functionality. Obtain approval of business process owners for detailed design specifications for customisation and configuration of application software. as a part of the sign-off process for the customisation and configuration of application software specifications. 2. cost-benefit justification and other requirements. Ensure that the business process owners understand the effect of designating changes as © 2009 ISACA. 9. and data integrity). AI2. Consider the availability of source code for purchased/packaged applications in the customisation and configuration process.

Obtain approval and sign-off from all stakeholders following successful completion of functionality. Ensure that application software is developed based on agreed-upon specifications and business.. Comments COBIT Control Practice Maturity Maturity link maintenance or major upgrades. At the end of each stage. 2. establish that they adhere to contractual obligations and organisational development standards and that licensing requirements have been addressed. 5. Establish development procedures to ensure that the development of application software adheres to organisational development standards. 4.8 Software Quality Assurance 1. Ensure that requested changes arising within IT or from the business process owner are tracked.g. Define a software QA plan. 6. 3. Design a process that monitors the software quality based on: • Project requirements • Enterprise policies © 2009 ISACA. including business process users and IT technology representatives. 8. rapid application development. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. ensuring active participation of all impacted stakeholders. extreme programming) on the monitoring of the application development progress and approval of application software by stakeholders. When third-party developers are involved with the applications development. At the final stage. Ensure that the plan includes: • Specification of quality criteria • Validation and verification processes • Definition of how quality will be reviewed • Necessary qualifications of quality reviewers • Roles and responsibilities for the achievement of quality Consider: • The effect of embedding quality within the development process • The presence or absence of formal review by independent QA teams • Ensuring that reviewers are independent from the development team 2. confirm with IT technical authorities and operations management that the applications are ready and suitable for migration to the production environment. facilitate formal discussions of approved criteria with the stakeholders. Establish agreed-upon stages of the development process (development checkpoints). Page 91 . Monitor all development activities and track change requests and design. AI2. All rights reserved. 7. performance and quality reviews before finalizing stage activities. AI2. Consider the effect of dynamic. performance and quality reviews. non-sequential development techniques (e. functional and technical requirements. Assess the adequacy of software developed in terms of its compatibility and ease of integration with existing applications and infrastructure.7 Development of Application Software 1.

Design an effective and efficient process for application software maintenance activities. Monitor all quality exceptions. Track changes to requirements for development projects. Design a process for standardising. Establish the review and approval of all emergency or any other changes applied without adherence to the formal change process. where appropriate. programme walk-throughs and testing of applications. Ensure that corrective actions are taken. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. paying attention to business needs and resource requirements. Ensure that risk and security requirements and interdependencies are addressed. tracking. review and approve the changes. 3. Maintain a record of all reviews. AI2. Page 92 . Ensure that all changes in software comply with the formal change management process. AI3. Monitor all maintenance changes. 2. Ensure that the pattern and volume of maintenance activities are analysed periodically for abnormal trends indicating underlying quality or performance problems. recording and approving all change requests during development of application systems. enabling all stakeholders to monitor. update user systems and operational documentation. AI2. Ensure that the outcomes of the change process are fully understood and agreed to by the stakeholders. Report on outcomes of the monitoring process and testing to the application software development team and IT management. Repeat quality reviews. Ensure that any major maintenance is categorised and managed as a formal redevelopment. Prioritise maintenance activities. 5. 2. 3. All rights reserved. Comments COBIT Control Practice Maturity Maturity link • Adherence to site development systems methodologies • Quality management procedures and acceptance criteria 3. 4. results. Where necessary. Assess the impact of all project change requests.10 Application Software Maintenance 1. Establish processes to ensure that all maintenance activity is completed successfully and thoroughly.9 Applications Requirements Management 1. aggregate maintenance tasks into a single ‘change’ to make management and control easier. 4. including impact on other systems and infrastructure. Employ code inspection. Track maintenance activities to ensure completion. If appropriate.1 Technological Infrastructure Acquisition Plan © 2009 ISACA. and categorise and prioritise them accordingly. exceptions and corrections. based on the amount of rework and corrective action.

Approve all reviewed and accepted plans with a formal sign-off. Assess all the security aspects associated with system software installation and maintenance processes. Control movement of programs and data amongst libraries by ensuring that this is performed by an independent group (e. All rights reserved. 3. production to verify functionality and establish its security. Create and maintain a plan for the acquisition. for technology upgrade purposes. and ensure that passwords are changed as installation is completed. the lifetime of the investment. 3. © 2009 ISACA. costs. benefits and technical conformance with corporate technology standards. technical risks and. but sufficiently similar to. 6. This ensures that they operate appropriately and are in compliance with requirements established within the acquisition and maintenance framework for technology infrastructure. librarian). The plan should also consider future flexibility for capacity additions. 4.2 Infrastructure Resource Protection and Availability 1. Monitor when temporary access is granted to allow installation. Back up and secure all infrastructure data and software prior to installation or maintenance tasks. transition costs. Monitor that only appropriately licenced software is tested and installed. AI3. Review all acquisition plans considering risks. Review the process to ensure that system software installation is performed in accordance with vendor guidelines and any deviations are discussed with the vendor to assess potential impact. availability or integrity conditions. technology guidelines and standards. Page 93 . Establish a feedback process to support continuous improvement and raise any suggested changes to the technology infrastructure plan. such as vendor-established default parameter settings.g. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. Analyse and follow vendor recommendations. Test whether the application software environment is separated from.. especially the modification of original passwords assigned by service providers and the setup of parameters that may affect security. Ensure that the plan includes a financial appraisal stating the ROI over the expected lifetime of the infrastructure. 2. Any deviations should be authorised by the IT architecture board. 2. Comments COBIT Control Practice Maturity Maturity link 1. The plan should be integrated with the organisation’s strategic and operational planning processes. implementation and upgrade of technology infrastructure that meets established business functional and technical requirements and is in accord with the organisation’s technology direction. 5. 4.

Provide training to business management on how to manage the system effectively. 2. Establish ownership of the system. 4. Monitor and log access and maintenance of sensitive infrastructure components. 3. and ensure that these are regularly reviewed.1 Planning for Operational Solutions 1. and integrate any procedures with existing end-user procedures.g. segregation of duties. business continuity considerations. 2. Provide appropriate training to personnel who use sensitive infrastructure components. and internal control procedures. and training requirements.. Define and document the operational procedures in advance of implementation. accurate and usable. Create management documentation. AI4. 5. 8. access and privilege controls. Page 94 . Involve business management in the creation of management documentation. Create all the required user instructions. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. Define and document the user procedures in advance of implementation. and establish them during acceptance tests to ensure that they are complete. Create informative and understandable end-user documentation and reference materials. All rights reserved. and establish them during acceptance tests to ensure that they are complete. documentation. and integrate any procedures with existing management and control procedures. written in plain language and easily accessible (e. procedures and related training. designed for all levels of expertise. Define management and administrative functions. AI4. security and control procedures. Enforce acceptance procedures using objective acceptance criteria to ensure that product performance (including security and functionality) is consistent with the agreed-upon specifications and/or SLA requirements. Comments COBIT Control Practice Maturity Maturity link 7. administration procedures.3 Knowledge Transfer to End Users 1. Collect regular feedback from business management on the adequacy of the supporting documentation. electronic documentation). AI4. Involve end-user groups in the creation of end-user support documentation. © 2009 ISACA. 2. procedures and training materials on a timely basis to enable efficient and effective use of the new system. 3. 9. including roles and responsibilities. accurate and usable.2 Knowledge Transfer to Business Management 1.

Page 95 . FAQs and help desk support material) for content and quality as part of user acceptance testing of the system. Include the business purpose of the system and service levels required. online help and help desk support material) for content and quality as part of user acceptance testing of the system. 4. procedures and related training.g. 3. Provide training to end users on how to use the system effectively. Create informative and understandable system maintenance and support documentation that is written in plain language and is easily accessible (e. All rights reserved. 6. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. online help. Involve operations and support staff in the creation of maintenance and support documentation. AI4. procedures and related training. 5. Collect regular feedback from operations and support staff on the adequacy of the operations documentation. Provide training to operations support staff on how to support the new system effectively. Assess end-user documentation (such as procedure manuals. Assess operations documentation (such as procedure manuals. 5. Collect regular feedback from end users on the adequacy of the end-user documentation. service desk scenarios and electronic documentation).4 Knowledge Transfer to Operations and Support Staff 1. Define IT procurement policies and procedures in alignment with the organisation’s procurement policies and procedures. AI5. Comments COBIT Control Practice Maturity Maturity link 4. The IT procurement policies and procedures should address specific concerns such as: • Legislative requirements • Compliance with the organisation’s IT acquisition policy • Involvement of IT legal contract expertise • Licensing and leasing requirements • Technology upgrade clauses • Escrow arrangements • Vendor software support and security arrangements • Ensuring involvement of the business • Total cost of ownership • Acquisition plan for major acquisitions • Recording of assets 2.. and integrate any procedures with existing operational procedures. Define and implement standard procurement procedures that use selection approaches responsive to the risks associated with the © 2009 ISACA. 2.1 Procurement Controls 1.

Define and implement required approvals at key decision points during the procurement processes. if the existing policy will not be followed. Perform review of supplier internal controls by management or independent third parties based on contracts with key service suppliers. AI5. Establish supplier contract management policies and procedures in accordance with legal terms and conditions.3 Supplier Selection 1. Define and implement a policy and related procedures to establish. 3. Obtain approval from senior management in advance. 6. AI5. consider software escrow agreements and alternative suppliers or standby agreements in the event of supplier failure. 4. business and IT representatives. and assess the quality before making any payment. The policies and procedures should address specific concerns such as: • Supplier responsibilities • Client responsibilities • Supplier SLAs • Monitoring and reporting against SLAs • Transition arrangements • Notification and escalation procedures • Security standards. Obtain and review contracts for clauses relating to third-party reviews and obtain reports from such reviews. audit. Review all requests for information (RFIs) and requests for proposal (RFPs) © 2009 ISACA. Comments COBIT Control Practice Maturity Maturity link procurement. Enquire whether remedies were considered when defining the contract . 4. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. purchasing. Consult the appropriate stakeholders. 3. 2. All rights reserved. 5. When defining the contract remedies. change and terminate supplier contracts. Page 96 . including legal. Record receipt of all hardware and software acquisitions in an asset inventory. records management and control requirements • Required supplier QA practices • Right to audit • Penalties or incentives relating to agreed-upon service levels • Intellectual property rights • Provision for independent assurance • Technology upgrade clauses All contracts and contract changes should be reviewed by legal advisors.2 Supplier Contract Management 1.

and sign the contract. In the specific case of acquisition of development resources. including required performance criteria. Ensure that technology updates are available within agreed-upon time frames. inspection and testing. Verify the references of candidate vendors. and fit for purpose. These rights and obligations may include service levels. human resource management. 2. warranties. basis for payment and arbitration procedures. fit for purpose. Select the supplier that best fits the RFP. Page 97 . These rights and obligations may include ownership and licencing of intellectual property. arbitration procedures. include and enforce the rights and obligations of all parties in the contractual terms. AI5. through oversight. Review the technology delivery life cycle and related deliverables and approve deliverables at key points in the acquisition cycle. document and communicate the decision. In the specific case of acquisition of infrastructure. and maintain documentary evidence of the evaluations. facilities and related services. proposed and contractually agreed upon. access controls. warranties. Evaluate RFIs and RFPs in accordance with the approved evaluation process/criteria. 5. All rights reserved. performance review. maintenance procedures. Obtain legal advice on resource development acquisition agreements regarding ownership and licencing of intellectual property. performance reviews. Obtain broad licencing rights and ownership wherever possible and ensure that the supplier is in compliance with applicable regulations. quality management processes. basis for payment. In the specific case of software acquisition. include and enforce the rights and obligations of all parties in the contractual terms. including development methodologies. 3. escrow and access rights. 3. languages. 6. security. Comments COBIT Control Practice Maturity Maturity link to ensure that they: • Clearly define requirements • Include a procedure to clarify requirements • Allow vendors sufficient time to prepare their proposals • Clearly define award criteria and the decision process 2. © 2009 ISACA. Oversee the delivery of technology components of identified automated solutions. Confirm that the technology acquired delivers as required. 4. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. testing. including security. in appropriate environments and using representative data. include and enforce the rights and obligations of all parties in the contractual terms. and compliance with the organisation’s policies. These rights and obligations may include ownership and licencing of intellectual property. Test acquired software/hardware resources with the standard test procedures. upgrade terms.4 IT Resources Acquisition 1. maintenance. arbitration procedures.

Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. Ensure that the test plan reflects an assessment of risks from the project and that all functional and technical requirements are tested.g. and regulatory and compliance requirements (e. financial regulatory requirements). dependencies and critical path tasks impacting the delivery of the training plan. pilot and security testing. which aligns to the project quality plan and relevant organisational standards. AI7.. All rights reserved. for mission-critical systems. It should also identify staff members who must be trained and those for whom training is desirable. The training plan should incorporate the delivery of the training in a timely manner. Review documentation and knowledge transfer to enable efficient future maintenance. © 2009 ISACA. and select the most cost-effective approach that aligns with the organisation’s training framework. 4. and service providers. Consider alternative training strategies that satisfy the training requirements.g. Ensure that the training plan identifies and addresses all impacted groups.g. resources. 3. key milestones. Complete the documentation detailing compliance with the training plan.. risk level (e. The plan should consider alternative training strategies depending on the business needs. Ensure that the test plan addresses the potential need for internal or external accreditation of outcomes of the test process (e. 5. Page 98 . 2. Alternative strategies include train the trainer. Monitor training to obtain feedback that could lead to potential improvements in either the training or the system. end-user accreditation and intranet-based training. For systems development. AI7. implementation or modification projects. Examples of information include lists of staff members invited to attend the training. including business end users. 6. attendees. Monitor all planned changes to ensure that training requirements have been considered and suitable plans created.2 Test Plan 1. support and IT application development training. a formal system of user accreditation and reaccreditation may be appropriate). usability. IT operations. Ensure that the plan clearly identifies learning objectives. 2. 3. a training plan is an integral part of the overall project master plan. Consider postponing the change if training has not been performed and the lack of training would jeopardise the implementation of the change..1 Training 1. evaluations of achievement of learning objectives and other feedback. the plan should include requirements for performance. impact of varying privacy laws may require adaptation of the training at a national level). Communicate and consult with appropriate business process owners and IT stakeholders. Develop and document the test plan. Based on assessment of the risk of system failure and faults on implementation. Comments COBIT Control Practice Maturity Maturity link Maintain test data confidentiality where applicable. Confirm that there is a process to ensure that the training plan is executed satisfactorily. stress.

Ensure that the test plan identifies necessary resources to execute testing and evaluate the results. Obtain commitment from third parties to their involvement in each step of the implementation. 4. Examples of such testing phases include unit test. Define a policy for numbering and frequency of releases. and backup and recovery tests. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. Comments COBIT Control Practice Maturity Maturity link 4. Page 99 . installation or an update of a defined test environment. Confirm that the test plan considers test preparation (including site preparation). Ensure that the test plan identifies testing phases appropriate to the operational requirements and environment. Consult the business process owners and IT stakeholders in defining the success criteria. 2. 8. Include with the implementation plan: • The broad implementation strategy • The sequence of implementation steps • Resource requirements • Interdependencies • Criteria for management agreement to the production implementation • Installation verification requirements • Transition strategy for production support Align the implementation plan with the business change management plan. stress test. Ensure that stakeholders are consulted on the resource implications of the test plan. Create an implementation plan reflecting the outcomes of a formal review of technical and business risks. 5.g. Confirm that all test plans are approved by stakeholders. Ensure that the test plan establishes clear criteria for measuring the success of undertaking each testing phase. project managers and business process end users. training requirements. and formal approval. as appropriate. performance test. user acceptance test. the plan provides guidance on whether to proceed to the next phase. including technical and business. Confirm that all implementation plans are approved by stakeholders. security test. 6.. Examples of resources include construction of test environments and staff for the test group. error and problem handling. system test. All rights reserved. in a case of significant failures in a testing phase. © 2009 ISACA. correction and escalation. 7. 3. operational readiness. integration test. Determine that the plan establishes remediation procedures when the success criteria are not met (e. including potential temporary replacement of test staff in the production or development environments. data conversion test. planning/performing/documenting/retaining test cases. stop testing or postpone implementation). including business process owners and IT. AI7.3 Implementation Plan 1. Examples of such stakeholders are application development managers.

necessary application software. software. Confirm that the data conversion plan does not require changes in data values unless absolutely necessary for business reasons. or regulatory/compliance requirements demand. 4. Ensure that the test environment is representative of the future operating landscape. 5. storage and destruction. and secure approval from the business process data owner. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. Comments COBIT Control Practice Maturity Maturity link 5. including likely workload stress. Sanitise data used in the test environment from the production environment according to business needs and organisational standards (e. transaction data. Consider real-time disaster recovery. in the development of the plan. Page 100 . including access. consider whether compliance or regulatory requirements oblige the use of sanitised data). 4. Put in place a process to enable proper retention or disposal of test results. media and other associated documentation to enable adequate review and subsequent analysis as required by the test plan. and network and computing infrastructure found in the production environment. Ensure that retention of backup and archived data © 2009 ISACA. procedures and system documentation. freeze live operations. and reversion in the data conversion and infrastructure migration plan where risk management. 2. and identifying and resolving any errors found during conversion.g. audit trails are maintained to enable the conversion to be retraced.5 System and Data Conversion 1. retention.. This includes comparing the original and converted data for completeness and integrity. operating systems. 3. continuous transition with no loss of transactions. Where necessary. 5. business needs. backups and archives. 3. operating systems. Define a data conversion and infrastructure migration plan. Protect sensitive test data and results against disclosure. and there is a fallback and recovery plan in case the conversion fails. Document changes made to data values. Identify and document the fallback and recovery process. Ensure that the data conversion plan incorporates methods for collecting. 6. Co-ordinate and verify the timing and completeness of the conversion cutover so there is a smooth. converting and verifying data to be converted. for example. Consider the effect of regulatory or compliance requirements. interfaces with other systems (both internal and external). database management systems. hardware. Create a database of test data that are representative of the production environment. 2. All rights reserved. Ensure that there is a backup of all systems and data taken at the point prior to conversion. master files. business continuity planning. Consider the effect of interaction of organisational systems with those of third parties.4 Test Environment 1. in the absence of any other alternative. AI7. Ensure that the test environment is secure and incapable of interacting with production systems. Consider. AI7. networks.

Comments COBIT Control Practice Maturity Maturity link conforms to business needs and regulatory or compliance requirements.g. 4. Ensure that an audit trail of test results is available. Consider using scripts to verify the extent to which the system meets security requirements. configuration or workaround. 5. 2.. third parties (as appropriate) and IT stakeholders © 2009 ISACA. end-user response times and database management system update performance). Ensure that the categorised log of errors found in the testing process has been addressed by the development team. Ensure that testing of changes is undertaken in accordance with the testing plan. Consider a range of performance metrics (e. 4. Ensure that business process owners.. AI7.6 Testing of Changes 1.. significant and mission-critical) errors during testing. Document and interpret the final acceptance testing results. minor.7 Final Acceptance Test 1. Ensure that the final acceptance evaluation is measured against the success criteria set out in the testing plan.g. Ensure that the independent test group assesses and approves each test script to confirm that it adequately addresses test success criteria set out in the test plan. Communicate results of testing to stakeholders in accordance with the test plan to facilitate bug fixing and further quality enhancement. ensure that the fallback and rollback elements of the test plan have been addressed. and/or delayed correction where the error is minor). Ensure that the testing is designed and conducted by a test group independent from the development team. Consider using clearly defined test instructions (scripts) to implement the tests. by appropriate changes to the application. Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. 3. Undertake tests of security in accordance with the test plan.. Consider the effect on access and boundary controls. 7. Measure the extent of security weaknesses or loopholes.g. Ensure that the review and evaluation process is appropriately documented. application software. When undertaking testing. and present them in a form that is understandable to business process owners and IT so an informed review and evaluation can take place. 5. facilities. Ensure that testing is conducted only within the test environment. Consider the effect of security incidents since construction of the test plan. Undertake tests of system and application performance in accordance with the test plan. user procedures. Ensure that the cause of errors has been remediated (e. Consider the appropriate balance between automated scripted tests and interactive user testing. Ensure that the scope of final acceptance evaluation activities covers all components of the information system (e. Identify. 6.g. technology. All rights reserved. monitoring and support). operations procedures. 3. AI7. 2. Ensure that the tests and anticipated outcomes are in accordance with the defined success criteria set out in the testing plan. Page 101 . log and classify (e. Consider the extent to which business process owners and end users are involved in the test group.

All rights reserved. Page 102 . Systems Development and Project Management Audit/Assurance Program Reference Assessed Target Hyper. Comments COBIT Control Practice Maturity Maturity link formally sign off on the outcome of the testing process as set out in the testing plan. © 2009 ISACA. Such approval is mandatory prior to promotion to production.

Target Maturity © 2009 ISACA. All rights reserved. Systems Development and Project Management Audit/Assurance Program VIII. Page 103 . Assessment Maturity vs.