4.3 Scenario Practice for Information Systems Acquisition, Development, and Implementation

Testing Types and Sequence

Testing in the SDLC escalates from the smallest unit to the whole business. CISA expects you to know what each level proves and who owns it.

A scenario will often ask which test gives final assurance the system meets business needs — that is UAT, owned and signed off by the business, not QA. System testing proves it works technically; UAT proves it works for the users. Regression testing is the answer whenever a change, patch, or fix has been applied and you must confirm nothing else broke.

Two further distinctions appear on the exam. White-box testing examines internal logic and paths (used in unit testing), while black-box testing checks inputs and outputs without knowledge of internals (typical of system and acceptance testing). Sociability testing confirms the new system can operate in its target environment without adversely affecting other systems sharing infrastructure. And the auditor verifies that test data is representative but does not expose production-sensitive data — using live production data in a test environment without protection is itself a control weakness.

Choosing a Migration (Changeover) Strategy

When the new system replaces the old one, the changeover strategy trades implementation risk against cost and effort.

• Parallel — old and new run simultaneously; outputs are compared until confidence is high, then the old system retires. Lowest risk, highest cost and effort. Preferred for mission-critical systems (e.g., core banking, payroll).
• Phased — the system is rolled out module by module over time. Moderate risk; complex interim interfaces between old and new modules.
• Pilot — the new system runs at one site or for one user group first to surface issues before broad rollout. Contains risk to a limited population.
• Big bang (direct/abrupt) — old system stops and new system starts all at once. Cheapest and fastest, but highest risk — there is no fallback if it fails.

A scenario describing a critical system where errors are unacceptable points to parallel; one emphasizing cost and a hard cutover date points to big bang with the explicit caveat that fallback planning is essential. The auditor evaluates whether the chosen strategy matches the system's criticality and the organization's risk appetite — choosing big bang for a core financial system without a back-out plan is a finding, while running an expensive parallel operation for a low-risk internal tool may be wasteful.

Each strategy also implies its own controls: parallel requires a defined comparison and reconciliation of dual outputs; phased requires interim bridge interfaces between old and new modules; pilot requires criteria to judge the pilot a success before rollout. The auditor also confirms that fallback (back-out) procedures were prepared and tested for whichever strategy is used, since even a parallel run can fail in ways that force a return to the legacy system.

Data Conversion and Integrity

Migrating data is where records are silently lost or duplicated, so the auditor focuses on reconciliation evidence:

• Record counts — the number of records in the source equals the number loaded in the target.
• Control totals / hash totals — totals of key fields (e.g., total account balance) match before and after conversion.
• Sampling and field-level comparison — selected records are verified field-by-field against the source.
• Exception and error logs — records that failed conversion are captured, investigated, and resolved, not dropped.

The single best assurance that conversion preserved integrity is a reconciliation of old-system data to new-system data. The auditor also checks that the original (legacy) data is retained until reconciliation is complete, providing a fallback. After cutover, the post-implementation review (PIR) confirms the system delivered its business case benefits and captures lessons learned.

Putting a Scenario Together

Domain 3 scenarios usually stack two or three of these decisions, and the skill being tested is sequencing them correctly. Consider a typical stem: a retailer is replacing its inventory system, the data must move from a legacy database, the business is nervous about errors, and management asks the auditor what to confirm before go-live.

The disciplined answer walks the controls in order — confirm UAT was completed and signed off by the business (requirements met), confirm the data conversion was reconciled by record counts and control totals with exceptions resolved (integrity), confirm a changeover strategy appropriate to the risk was chosen with a tested back-out plan (recoverability), and confirm a PIR is scheduled to verify benefits. Notice that none of these asks the auditor to perform the testing or own the conversion; the auditor verifies that the responsible parties did each step and retained evidence.

Training yourself to enumerate controls in life-cycle order, while keeping the auditor in a verification role, is what converts a long, intimidating scenario into a quick, correct selection.