Information Systems Acquisition, Development and Implementation
What this domain tests
Domain 3 tests assurance over how systems are justified, built or bought, tested, migrated and handed over. The theme is that controls must be built in during the project, because retrofitting them after go-live is expensive and often skipped.
Business case and project governance
A business case establishes need, options analysis, costs, benefits and risks; a feasibility study tests technical, economic, operational, schedule and legal viability. Project governance needs an approved charter, a sponsor with authority, a PMO for methodology and reporting, and stage-gate reviews. Earned value analysis (cost and schedule performance indices) gives early warning of overrun; scope creep is controlled through formal change requests with impact assessment and re-baselining.
Development and testing
The auditor's role in the SDLC is review and advisory at each phase - requirements sign-off, design review, test-plan review - never performing user acceptance testing, which belongs to the business users. Test levels: unit, integration, system, UAT, then regression after changes. Data migration requires reconciliation of record counts and control totals between legacy and new systems.
Changeover and post-implementation
Parallel changeover runs old and new systems together: highest cost, lowest risk, and the best reconciliation evidence. Direct (big-bang) cutover is cheapest and riskiest; phased changeover moves by module or location; pilot runs one site first as a controlled trial. A post-implementation review measures whether the promised benefits were realised, not just whether the system works.
Worked example
A payroll replacement is going live in one weekend with no parallel run. The auditor notes the direct cutover, then asks what evidence exists that opening balances and year-to-date figures are correct. Because no parallel period exists, the compensating control is a full reconciliation of every migrated employee record and balance to the legacy system, signed off by payroll management before the first live run. Without that, the recommendation is a parallel cycle or a documented, independently verified migration reconciliation.
Traps
Assuming agile projects need no documentation (they need different, not absent, evidence); accepting 'testing complete' without reviewing defect logs and sign-offs; letting developers approve their own migrations; and confusing benefits realisation with delivery on time and budget.