CISA domain 3: Information systems acquisition, development and implementation

The purpose of this element of CISA is to make sure candidates can assure the effective operation of the processes used for IS acquisition, development, and implementation.

The domain covers six areas:

• Developing the business case
• IT supplier selection
• project management
• system development
• implementation readiness
• post implementation review

Developing the business case

Before starting any IS project, the organization should make sure it supports the IS Strategy, is affordable and decide what benefits it must deliver to be judged a success. This information is brought together in the business case which is approved by senior management and continually re-evaluated throughout the project.

A benefits realization process is also used throughout the project to ensure the benefits, such as cost reduction or improved system reliability, are delivered.

The need for the project will come from the portfolio which has been created to support the IS strategy (link to previous article CISA Domain 2), and a feasibility study might be used to evaluate the approach, and the results included in the business case.

The candidate must understand the approach to business case development and investment evaluation techniques such as return on investment (ROI).

IT supplier selection

All organizations use third party suppliers to deliver some elements of their IS strategy and candidates are expected to know how suppliers are selected and managed.

The initial process for engaging a supplier is through a Request for Proposal (RFP) that contains business and IS requirements, information about the supplier and contractual terms. Since the organization will most likely use the selected solution for many years, the RFP is a critical document and, when reviewing it, the auditor should:

• validate the completeness and accuracy of the requirements through interviews and desk research,
• confirm the RFP has been fully approved by legal and senior IS and business managers, and
• ensure enough quality vendors have been invited to respond.

Project management

Candidates must understand how project management tools and techniques are used to manage the risks associated with IS acquisition, development, and implementation, and should be able to evaluate if projects are progressing to plan and are on track to deliver the benefits contained in the business case.

Attention must be paid to the project brief and project plan. A comprehensive project brief and accurate delivery plan, developed with input from the main stakeholders, are the foundations for a successful project and poor-quality content should be a major concern for the auditor.

There are various project management methodologies, such as those offered by APM and PMI, and, although candidates don't need to know the details, they should have a basic understanding of the different approaches. Additionally, many organizations tailor these methodologies to meet their own needs, and auditors should familiarize themselves with what's being used before starting a review.

Agile development methods have a different approach to project management - largely abandoning it and using the concept of self-managed teams - and that also needs to be borne in mind by auditors.

An important element of the project management process is Governance, and the auditor should look for evidence that risks, issues, and dependencies are being actively managed, and the project controlled by a steering committee or project board.

System development

Different system development methodologies have emerged over the years in response to the need for speed, agility, flexibility and cost reduction. The original waterfall approach has been largely replaced - although there are still organizations using it for changes to large, complex legacy systems - by 'agile' techniques such as RAD, Scrum and Object Orientated development.

Candidates aren't expected to have detailed knowledge of all methodologies but should have a basic understanding of the different types and their approach to the systems development life cycle (SDLC).

IS requirements include functional, non-functional, performance, availability and support, and effective requirements gathering is critical for systems development. Auditors can refer to published techniques to help evaluate if all considerations have been addressed during the process.

A change control process should also be in place along with evidence it is being used effectively.

Auditors need to be able to identify the type of controls used during the SDLC, evaluate their strength and find evidence that demonstrates they've been adequately tested. Control types include:

• application controls - which regulate input, processing, and output functions.
• input controls – to make sure only valid data or other inputs are entered.
• processing controls – for ensuring that inputs are acted on according to the requirements and design logic and produce the predicted outcome, and
• output controls - provide assurance that system outputs are provided to users securely and in a consistent, usable format.

Controls can be evaluated through reference to design documentation, user manuals, test results and user feedback.

Implementation readiness

Before implementation, testing must be completed, and an implementation plan agreed.

The different types of testing - unit, system, UAT and so on - all have the same purpose: to ensure the system operates as defined in the requirements. Auditors should confirm test plans consider all requirements and that test data is an accurate reflection of production load. Testing by 3rd party suppliers should also be reviewed.

Pay attention to performance and regression testing since they can often be pushed down the priority list in favor of functional testing.

After testing has been successfully completed - or, for minor issues, a post-implementation remedial plan has been agreed – the system is implemented. Auditors should confirm an implementation plan containing the following has been approved before implementation starts:

• criteria for deciding if the implementation should go ahead or be delayed
• implementation activities and timeline; this might be a minute-by-minute step-by-step activity list
• success criteria to be used to confirm the implementation has completed
• backout arrangements, to be used if the implementation fails part way through
• support arrangements during implementation and then for business as usual
• staff training and communication

Post-implementation review

The PIR is an important tool for documenting lessons learned and other feedback from the project team, all of which can help improve the next implementation. It should also confirm project objectives have been met, contain a plan for closing any open actions, stand down resources and close the financials.

Depending on the timing for delivery of the benefits, it might include a review and final statement on benefits realization otherwise that will be documented as an open action.

For more on the CISA certification, view our CISA certification hub.