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

CISA Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: CISA Orientation and Exam Strategy

1.1 Current CISA Exam Facts 1.2 Eligibility, Application, and Scheduling 1.3 Blueprint Domains and Weighting 1.4 Question Style and Score Report Thinking 1.5 Study Calendar and Practice Plan

2 Chapter 2: Information System Auditing Process

2.1 Information System Auditing Process Overview 2.2 Core Workflows and Decision Points 2.3 Scenario Practice for Information System Auditing Process 2.4 Common Traps in Information System Auditing Process 2.5 Practice Drills and Readiness Markers

3 Chapter 3: Governance and Management of IT

3.1 Governance and Management of IT Overview 3.2 Core Workflows and Decision Points 3.3 Scenario Practice for Governance and Management of IT 3.4 Common Traps in Governance and Management of IT 3.5 Practice Drills and Readiness Markers

4 Chapter 4: Information Systems Acquisition, Development, and Implementation

4.1 Information Systems Acquisition, Development, and Implementation Overview 4.2 Core Workflows and Decision Points 4.3 Scenario Practice for Information Systems Acquisition, Development, and Implementation 4.4 Common Traps in Information Systems Acquisition, Development, and Implementation 4.5 Practice Drills and Readiness Markers

5 Chapter 5: Information Systems Operations and Business Resilience

5.1 Information Systems Operations and Business Resilience Overview 5.2 Core Workflows and Decision Points 5.3 Scenario Practice for Information Systems Operations and Business Resilience 5.4 Common Traps in Information Systems Operations and Business Resilience 5.5 Practice Drills and Readiness Markers

6 Chapter 6: Protection of Information Assets

6.1 Protection of Information Assets Overview 6.2 Core Workflows and Decision Points 6.3 Scenario Practice for Protection of Information Assets 6.4 Common Traps in Protection of Information Assets 6.5 Practice Drills and Readiness Markers

7 Chapter 7: Final Review and Test Day

7.1 Timed Practice Strategy 7.2 Last-Week Review Map 7.3 Exam-Day Checklist 7.4 After the Exam and Next Steps

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

Key Takeaways Explain This Topic AI

Testing progresses bottom-up: unit → integration/interface → system → user acceptance (UAT), with regression testing run after any change to confirm nothing previously working broke.

UAT is owned and signed off by the business/user community and is the basis for the go-live decision; QA-passed system testing alone is not sufficient.

Migration (changeover) strategies trade risk for cost: parallel is safest, big bang is cheapest and riskiest, with phased and pilot in between.

Data conversion controls — record counts, control totals, and reconciliation of old vs. new — are the auditor's primary evidence that no data was lost or corrupted.

Last updated: June 2026

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.

Test level What it verifies Typical owner
Unit A single module/function works in isolation (white-box) Developer
Integration / interface Data flows correctly between modules or systems Dev/test team
System The complete integrated system meets functional, performance, and security requirements QA team
User acceptance (UAT) The system meets business and user requirements; readiness to deploy Business/users
Regression Changes did not break previously working functionality Test team

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.