Overview
Information Systems Acquisition, Development and Implementation follows a system from idea to production. Its 8 sub-topics cover project governance and management, the business case and feasibility analysis, system development methodologies, and control identification and design, then move to implementation: readiness and implementation testing, configuration and release management, migration and data conversion, and the post-implementation review.
Candidates must understand where controls are cheapest and most effective to build, which is early in requirements and design, and how to confirm before go-live that the system works, the data arrived intact and users accept it. The auditor's role is to review that project controls exist and that control requirements are built in, without taking ownership of design decisions. This domain draws on the portfolio and business-case governance of Domain 2 and hands over to the change, release and operations controls of Domain 4.
How it's tested
Questions sit at a project stage, such as feasibility, design, testing, conversion or post-implementation, and ask what is MOST important, what should happen FIRST, or what the GREATEST risk is. Correct answers respect the life-cycle order and favor controls designed early, independent verification, and documented business approval.
-
Life-cycle stage
Options name valid activities from different stages. Place the scenario on the life cycle and choose the activity that belongs at that point.
-
Who signs off
Options assign acceptance to developers, project managers, IT or business users. Business owners accept functionality; independent parties verify quality and conversion.
-
Data integrity at the handover
Conversion and migration scenarios test whether the candidate verifies completeness and accuracy with counts, totals and reconciliations before cutover.
A project is three weeks from go-live and testing is behind schedule. The sponsor proposes skipping user acceptance testing and fixing problems in production. Options include accepting the plan, extending the timeline, or proceeding with a documented risk acceptance. Reasoning: user acceptance is the business's confirmation the system meets requirements. The auditor should report the risk to the steering committee, which decides whether to delay or formally accept it.
Sub-topics 8
Official sub-topics from the ISACA outline, in outline order.
3.1 Project Governance and ManagementRoles, oversight and control techniques that keep projects on scope, schedule and budget.
- What it means
- Project governance assigns a sponsor who owns the business outcome, a steering committee that approves scope and resource changes, a project manager who runs delivery, and often a project management office that sets standards. Management techniques include work breakdown structures, Gantt charts, critical path analysis and earned value.
- What to understand
- The sponsor and steering committee make go or no-go decisions at stage gates; the project manager executes. Earned value compares planned value, earned value and actual cost to show schedule and cost variance early. Uncontrolled scope change drives overruns and needs formal change control.
- How it shows up
- A scenario shows a project adding features without approval and asks for the greatest concern or the control that would have prevented it, which is formal scope change control through the steering committee.
- Common confusion
- Treating the project manager as accountable for business benefits; that accountability belongs to the sponsor.
3.2 Business Case and Feasibility AnalysisJustifying an investment and confirming it can be delivered.
- What it means
- The business case states the problem, options, costs, benefits, risks and measures such as return on investment, net present value and payback period. Feasibility analysis tests whether the preferred option is technically, economically, operationally and legally achievable.
- What to understand
- The business case is a living document, revisited at each major stage gate, and the project should be stopped or redirected if the case no longer holds. Build versus buy decisions are part of feasibility, and acquired software requires a structured selection process with defined requirements and vendor evaluation criteria.
- How it shows up
- A question describes rising costs midway through a project and asks what the auditor should verify; the answer is that the business case has been updated and still justifies continuing.
- Common confusion
- Thinking the business case is a one-time approval document filed at project start.
3.3 System Development MethodologiesWaterfall, iterative, agile, prototyping and related approaches and their control implications.
- What it means
- Traditional waterfall life cycles move through sequential phases with formal sign-offs. Iterative and agile methods deliver in short cycles with continuous user involvement, while prototyping and rapid application development build early working models to refine requirements. DevOps integrates development and operations with automated build, test and deployment pipelines.
- What to understand
- Each method changes where controls sit: waterfall relies on phase documentation and sign-off, agile relies on backlog management, definition of done and frequent testing, and DevOps relies on automated controls in the pipeline. Requirements definition is critical in every method because errors found later cost far more to fix.
- How it shows up
- A scenario describes an agile team with little formal documentation and asks for the greatest concern; the right answer focuses on whether controls such as testing and approval are built into the method, not on the absence of waterfall documents.
- Common confusion
- Treating agile as uncontrolled; it uses different controls, and auditors should evaluate those rather than demanding waterfall artifacts.
3.4 Control Identification and DesignBuilding input, processing, output and audit trail controls into systems.
- What it means
- Application controls are designed into a system to ensure data is complete, accurate, valid and authorized. They include input edits such as range, validity, reasonableness and check-digit checks, processing controls such as run-to-run totals, output controls such as reconciliation and distribution, and audit trails that record who did what.
- What to understand
- Controls should be identified during requirements and design, when they are cheapest to add, based on a risk assessment of the business process. The IS auditor can advise on control requirements, but the business owner and project team decide and build them.
- How it shows up
- A question asks when an IS auditor's involvement adds the most value in a development project; the answer is during requirements and design, so controls are built in rather than retrofitted.
- Common confusion
- Confusing edit check types; a check digit detects transcription errors in an identifier, while a reasonableness check compares a value to expected norms.
3.5 System Readiness and Implementation TestingUnit, integration, system, user acceptance and specialized testing before go-live.
- What it means
- Testing progresses from unit tests of individual modules, to integration tests of interfaces between modules, to system tests of the whole application including performance and security, to user acceptance testing in which business users confirm requirements are met. Regression testing confirms changes did not break existing functions.
- What to understand
- User acceptance is performed by business users against documented requirements, in an environment that mirrors production, using test data rather than unprotected live data. Test results, defects and sign-offs must be documented, and unresolved high-severity defects should block go-live unless formally accepted.
- How it shows up
- Questions ask which test confirms the system meets business requirements, or what the greatest concern is when developers perform acceptance testing; the answer centers on user acceptance by the business.
- Common confusion
- Using regression testing to mean testing the whole system; it specifically re-tests existing functions after a change.
3.6 Implementation Configuration and Release ManagementControlling versions, configurations and promotion into production.
- What it means
- Configuration management records the approved version of every component, and release management bundles approved changes, tests them and promotes them into production through controlled steps. Separate development, test and production environments prevent untested code from reaching live systems.
- What to understand
- Migration to production should be performed by someone other than the developer, using approved and tested versions, with a rollback plan. Emergency changes follow an expedited path but still require logging and after-the-fact approval and review.
- How it shows up
- A scenario shows developers with direct access to promote code to production and asks for the greatest risk, which is unauthorized or untested changes.
- Common confusion
- Assuming version control alone prevents unauthorized releases; without segregation of the migration duty, a developer can still promote unapproved code.
3.7 System Migration, Infrastructure Deployment, and Data ConversionMoving data and users to the new system with integrity and a way back.
- What it means
- Cutover approaches include parallel operation of old and new systems, phased rollout by module or location, pilot rollout to a small group, and direct or abrupt changeover. Data conversion extracts, transforms and loads legacy data into the new system.
- What to understand
- Conversion integrity is verified with record counts, control totals and reconciliations, and data owners sign off on the converted data. Every cutover needs a tested fallback plan. Direct changeover is cheapest but riskiest, while parallel operation is safest but costly.
- How it shows up
- Questions ask which control BEST ensures converted data is complete and accurate, or which cutover approach fits a high-risk system.
- Common confusion
- Treating parallel operation as the conversion control; it compares processing results, while reconciliation of counts and totals confirms that all records moved correctly.
3.8 Post-implementation ReviewConfirming after go-live that the system met its objectives and delivered expected benefits.
- What it means
- A post-implementation review (PIR) evaluates whether the system meets requirements, whether controls work, whether the business case benefits are being realized, and what lessons the project offers.
- What to understand
- The review is held after the system has stabilized, often several months after go-live, so benefits and performance can be measured. It should be performed by a party independent of the project team and compared with the original business case.
- How it shows up
- A scenario asks the PRIMARY purpose of a post-implementation review or when it should be done; the answers are assessing benefits realization and controls, after a stabilization period.
- Common confusion
- Scheduling the PIR immediately after go-live, before enough operating data exists to measure benefits.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Earned value analysis
Earned value compares the budgeted value of work actually completed with the planned value and the actual cost, producing schedule and cost variances and performance indices.
- Remember
- Schedule variance is earned value minus planned value; cost variance is earned value minus actual cost, and a negative value signals a problem.
- Tested as
- Project questions ask which technique gives an early, objective view of cost and schedule status.
- Trap
- Comparing actual cost with budget alone, which ignores how much work has been finished.
-
Business case as a living document
The business case is revisited at stage gates so the steering committee can confirm the investment is still justified as costs, risks and benefits change.
- Remember
- If the business case no longer holds, the project should be stopped or redirected.
- Tested as
- Mid-project scenarios ask what the auditor should verify when costs rise or scope changes.
- Trap
- Assuming initial approval settles the question for the life of the project.
-
Requirements definition
The stage where business needs, including control and security requirements, are documented and approved by users before design.
- Remember
- Defects introduced in requirements are the most expensive to fix later.
- Tested as
- Questions ask which phase is most critical or where the auditor's involvement adds the most value.
- Trap
- Choosing coding or testing as the critical phase because that is where defects are found.
-
Input edit checks
Validity checks compare input to allowed values, range checks enforce limits, reasonableness checks compare to expected norms, completeness checks ensure required fields exist, and check digits detect transcription errors in identifiers.
- Remember
- Match the check to the error: transposed account numbers point to a check digit.
- Tested as
- Control design questions describe an error and ask which edit would have prevented it.
- Trap
- Picking a range check for an error that falls within range but is unusual for the customer, which is a reasonableness issue.
-
Testing levels
Unit testing checks individual modules, integration testing checks interfaces between them, system testing checks the complete application including performance and security, and acceptance testing confirms business requirements are met.
- Remember
- User acceptance is done by business users, not developers.
- Tested as
- Questions describe a test and ask what it confirms or who should perform it.
- Trap
- Accepting developer sign-off as user acceptance.
-
Specialized tests
Regression testing rechecks existing functions after changes, stress and volume testing check behavior under load, sociability testing checks that the new system does not harm others in the same environment, and parallel testing compares old and new system results.
- Remember
- Each answers a different question; match the test to the risk described.
- Tested as
- Scenarios describe a risk and ask which test addresses it.
- Trap
- Choosing stress testing to confirm that a fix did not break other features.
-
Cutover approaches
Parallel runs old and new systems together, phased introduces modules or sites in stages, pilot introduces the system to a small group first, and direct changeover switches everything at once.
- Remember
- Risk falls and cost rises from direct to phased to parallel.
- Tested as
- Questions ask which approach fits a critical system or what risk a direct cutover creates.
- Trap
- Choosing direct changeover for a critical system because it is fastest.
-
Data conversion controls
Record counts, control totals, hash totals and reconciliations compare source and target data, supported by exception reports and data owner sign-off.
- Remember
- Completeness and accuracy of converted data must be proven before the legacy system is retired.
- Tested as
- Conversion questions ask which control best verifies the migration.
- Trap
- Relying on user acceptance of screens or reports as proof the data is complete.
-
Rollback or fallback plan
A tested plan to return to the previous system or version if the implementation fails, including data restoration points.
- Remember
- No significant cutover should proceed without one.
- Tested as
- Readiness questions ask what must be in place before go-live.
- Trap
- Assuming thorough testing makes a fallback plan unnecessary.
-
Post-implementation review timing and purpose
A review held after the system stabilizes to assess benefits realization against the business case, control effectiveness and lessons learned.
- Remember
- Primary purpose is to assess whether objectives and benefits were achieved.
- Tested as
- Questions ask when it should occur and what it primarily evaluates.
- Trap
- Treating it as the final test phase before go-live.
-
Auditor involvement in projects
IS auditors may advise during requirements and design to ensure adequate controls, and may review project controls, while management keeps decision authority.
- Remember
- Advising does not impair independence; approving or designing does.
- Tested as
- Questions test the right timing and limits of auditor participation.
- Trap
- Thinking any early involvement disqualifies the auditor from later audits.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Parallel vs. phased vs. pilot vs. direct changeover
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Parallel | Old and new systems run together for a period | Lowest risk, highest cost and user workload | Treating it as proof that converted data is complete |
| Phased | Modules or functions go live in stages | Spreads risk but needs temporary interfaces between old and new | Ignoring the interface controls the staging creates |
| Pilot | One site or user group adopts the system first | Limits exposure while proving the system in real use | Assuming a successful pilot proves performance at full volume |
| Direct changeover | Old system stops and new one starts at once | Cheapest and fastest, highest risk | Proceeding without a tested fallback plan |
Unit vs. integration vs. system vs. user acceptance testing
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Unit testing | Tests individual programs or modules | Done by developers against design specifications | Treating it as evidence the whole system works |
| Integration testing | Tests data flow across interfaces between modules or systems | Focus on connections, not single components | Skipping it when each unit passed |
| System testing | Tests the complete system including performance, security and recovery | Technical validation of the whole application | Confusing it with business acceptance |
| User acceptance testing | Business users confirm the system meets requirements | The business's formal sign-off before go-live | Allowing developers or IT to perform it |
Quality assurance testing vs. post-implementation review
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Pre-implementation testing | Confirms the system works and meets requirements before production use | Occurs before go-live and focuses on defects | Expecting it to show business benefits |
| Post-implementation review | Evaluates objectives, benefits and controls after the system stabilizes | Occurs after go-live and compares results with the business case | Scheduling it immediately after go-live |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Right activity, wrong stage
- What candidates pick
- A valid control activity such as security testing when the scenario is still in feasibility.
- Why it looks right
- The activity is genuinely important and sounds rigorous.
- Why it's wrong
- The question asks what fits the current stage; doing it now is premature or impossible.
Clue to watch for Find the stage words: feasibility, design, testing, cutover or after go-live.
-
Auditor designs the controls
- What candidates pick
- Have the IS auditor specify and approve application controls for the new system.
- Why it looks right
- Auditors know controls well, and early involvement is encouraged.
- Why it's wrong
- The auditor advises on control requirements; designing and approving them makes the auditor responsible for what they will later audit.
Clue to watch for Watch for verbs such as approve, design or sign off attached to the auditor.
-
Skip UAT under schedule pressure
- What candidates pick
- Proceed to production and fix issues as they appear.
- Why it looks right
- Deadlines are real and many defects can be fixed later.
- Why it's wrong
- Without user acceptance, the business has not confirmed the system meets its needs; the decision to accept that risk belongs to the sponsor or steering committee.
Clue to watch for Behind schedule with go-live date fixed points to escalating the risk for a formal decision.
-
Parallel run as conversion proof
- What candidates pick
- Use a parallel run to verify that all legacy records were converted.
- Why it looks right
- Matching outputs from both systems feels like strong verification.
- Why it's wrong
- Parallel processing compares results for transactions processed, not whether every legacy record and balance migrated correctly.
Clue to watch for If the question is about completeness of converted data, look for record counts, control totals and reconciliation.
-
Immediate post-implementation review
- What candidates pick
- Conduct the review in the first week after go-live.
- Why it looks right
- Issues are fresh and the project team is still available.
- Why it's wrong
- Benefits and stable performance cannot be measured until the system has run for a period.
Clue to watch for If the question mentions benefits or business case, the review comes after stabilization.
-
Documentation over control
- What candidates pick
- Flag an agile project's lack of phase documents as the greatest concern.
- Why it looks right
- Auditors value documentation and waterfall artifacts are familiar.
- Why it's wrong
- Agile uses different controls; the concern is whether testing, approval and backlog controls operate, not whether waterfall documents exist.
Clue to watch for Check whether the scenario describes missing controls or only a different method.
Answer framework
For an acquisition or implementation question, place the scenario on the life cycle and protect business ownership and data integrity at each handover.
- Locate the stage: business case, requirements, design, build, testing, cutover or post-implementation, and rule out options that belong to other stages.
- Confirm the business case still justifies the project and that the sponsor or steering committee, not the project team, owns go or no-go decisions.
- Check that control requirements were defined early from a risk assessment and that the auditor's role stays advisory.
- Before go-live, verify user acceptance by the business, separation of development from production promotion, and a tested fallback plan.
- For conversion, prefer record counts, control totals and data owner sign-off; after go-live, schedule an independent post-implementation review once the system stabilizes.
Practice question
Want more like this? The CISA practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Study this domain in the order a project runs. Start with project governance and the business case, because they explain who decides and why the project exists. Then cover development methodologies, focusing on where each one places its controls, followed by control identification and design, where you should learn the input, processing and output controls well enough to match an error to the control that prevents it.
Next study implementation: testing levels, configuration and release management, cutover and conversion, and the post-implementation review. Candidates commonly underestimate the testing and conversion material. Build a table that lists each test type, who performs it and what it proves, and a second table for cutover approaches with their risk and cost.
High-priority concepts are the business case as a living document, requirements definition, user acceptance by the business, separation of code promotion, conversion reconciliation and the timing of the post-implementation review.
After studying, practice FIRST and MOST important questions that place you at different project stages. For each mistake, note which stage the scenario described and which stage your answer belonged to. Then continue to Domain 4, where change, configuration and release controls carry the same discipline into daily operations.
FAQ
Why is Domain 3 weighted lower than the others?
ISACA sets it at 12% in the current job practice. It is narrower in scope, but its questions on sequencing and project controls are still detailed.
How many questions should I expect from Domain 3?
ISACA does not publish per-domain counts. Applying 12% to 150 questions gives a planning estimate of about 18.
Does the exam favor waterfall or agile?
The outline covers system development methodologies generally. Questions test whether controls suit the method used, so know how agile and DevOps achieve testing, approval and documentation in their own way.
When should an IS auditor get involved in a development project?
Early, during requirements and design, so control requirements are identified while changes are cheap. The auditor advises and reviews but does not design or approve controls.
What is the difference between configuration management and release management?
Configuration management records and controls the approved versions of components. Release management packages approved, tested changes and moves them into production in a controlled way.
What does a post-implementation review prove?
It shows whether the system met its objectives, whether controls work in production and whether the benefits in the business case are being realized, along with lessons for future projects.
How long should I study Domain 3?
A planning estimate is 20 to 30 hours within a roughly 200-hour plan. This is an editorial estimate, not an ISACA figure.
Other Cybersecurity certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- CompTIA Cybersecurity Analyst+ Study guide
- Microsoft Security Operations Analyst Associate Study guide
- Certified Ethical Hacker Study guide
- Penetration Tester Study guide
- Systems Security Certified Practitioner Study guide
- Certified in Risk and Information Systems Control Study guide
- CompTIA PenTest+ Study guide
- CompTIA SecurityX (CASP+) Study guide
- Azure Security Engineer Associate Study guide
- CISM (Certified Information Security Manager) Study guide
- CISSP Study guide
- CompTIA Security+ Study guide
- Certified Cloud Security Professional Study guide
Test your Domain 3 knowledge
Check whether you can place a scenario on the project life cycle, choose the right test, and prove that converted data is complete before go-live.