CISA - Information Systems Acquisition, Development and Implementation (12% of the exam) - Section 3.2

Evaluate system readiness, implementation testing, configuration and release management.

Recognise the criteria used to assess system readiness before go-live and the types of implementation testing - such as user acceptance testing and parallel testing - that validate readiness. Evaluate configuration management and release management controls to confirm that only authorised, tested changes reach production.

system readinessimplementation testingconfiguration managementrelease management

Practice question for this objective

Free sampleInformation Systems Acquisition, Development and Implementationmedium

An IS auditor is evaluating the system readiness review conducted before go-live of a replacement payroll application. Which statement BEST describes the PRIMARY purpose of a formal system readiness review in implementation governance?

  • ATo obtain documented confirmation from business and IT stakeholders that exit criteria have been met before cutover proceeds. Correct
  • BTo rerun user acceptance testing on a sample of high-risk transactions and confirm that residual defects have been remediated.
  • CTo capture lessons learned from the project and feed them into the next release cycle and project management methodology.
  • DTo recalibrate the business case by comparing forecast benefits with actual costs incurred during build and test stages.
Recognise the system readiness review as a structured go or no-go gate where defined exit criteria are checked before cutover into production. System readiness reviews collate evidence that defined exit criteria across testing, training, data conversion, infrastructure, security and support are satisfied. Business and IT stakeholders formally accept that residual risk is tolerable, and the cutover decision is authorised. The review consumes existing evidence rather than producing new test results, and it precedes post-implementation activities such as lessons learned and benefits realisation.

Why A is correct: Correct. A readiness review is a structured go or no-go gate where defined exit criteria, covering testing, training, data, infrastructure and support, are reviewed and signed off before cutover is authorised.

Why B is wrong: Re-executing UAT is part of test management before the readiness gate. Candidates confuse it with the readiness review because testing evidence is consumed there, but the review evaluates evidence rather than producing new test results.

Why C is wrong: Lessons learned belong to post-implementation review, which runs after stabilisation. Candidates confuse the two because both happen near go-live, but the readiness review precedes cutover and the post-implementation review follows it.

Why D is wrong: Benefits realisation reviews recalibrate the business case after benefits have started flowing. Candidates pick this because benefits are referenced in readiness packs, but the readiness gate is about cutover criteria, not benefit measurement.

See more CISA practice questions, answers explained.

Exam traps in Information Systems Acquisition, Development and Implementation

Answers that look right on this material and are not. Each one is a distractor from a different question in the CISA bank for this domain.

  • Readiness is acceptable because user acceptance testing passed and the steering committee has approved the go-live date.

    Why it is wrong: This conclusion treats UAT sign-off as sufficient readiness evidence, but readiness must also confirm recoverability before cutover, so this is a tempting but incomplete audit position.

  • Accept the project manager's position because regression testing is required only where the legacy source code has been modified directly.

    Why it is wrong: This view is tempting because regression historically targets code change, but data and interface contract changes can break unchanged legacy code paths, so the position is too narrow for an audit conclusion.

  • Release management approves the business justification and risk rating of each individual change request before any build work begins.

    Why it is wrong: This describes change management's authorisation gate. Candidates confuse it with release management because both gates appear in the pipeline, but justification and risk rating are change-management concerns, not release-management ones.

Examworthy is not affiliated with or endorsed by ISACA. Original, blueprint-aligned practice material only.