Domain 3 — Information Systems Acquisition, Development and Implementation (12% of exam, ~18 questions)

What this domain is really testing

Domain 3 is not a project-management exam and not a coding exam. It tests whether you can place the right control at the right phase of the system life cycle and whether you know who is accountable for what. ISACA's recurring themes: the project sponsor (business side) owns the benefits and the risk; the auditor reviews and advises — never builds, tests or signs off; developers never touch production; and the earliest phase (requirements) determines success, because defects fixed there cost the least. Nearly every question resolves to one of four ideas: (a) segregation of duties, (b) which phase or control addresses this risk, (c) who owns this decision, or (d) which test/control provides this evidence.

How the exam asks it

• "What is the MOST important / BEST / FIRST..." — ISACA wants the earliest, most preventive, most cost-effective control, or the accountable role — not the most technical answer.
• Role questions — sponsor, steering committee, PMO, product owner, data owner, end user, internal audit. If an option says "internal audit performs X", suspect it; independence is the trap.
• Phase-mapping questions — a risk or failure is described, and you choose the phase where it should have been handled.
• Control-classification questions — preventive vs detective. Batch control totals = detective; check digit = preventive; UAT = detective-ish verification owned by the user, not a control that prevents anything.
• Cutover-selection questions — read the constraint being optimised: risk-averse → parallel; cheapest/fastest → direct; large multi-site → phased; prove it at one site → pilot.
• "The auditor should..." questions — review the test plan, results and acceptance criteria; observe; interview; sample. The auditor does not execute UAT, approve the design, or sign off go-live.
• Distractors are usually true statements that answer a different question. Answer the question actually asked.

A. IS Acquisition and Development

A.1 Project governance and management

• Project charter — authorises the project, names the sponsor and PM, states objectives, high-level scope, success criteria. Without a charter the project lacks authority (a favourite exam answer).
• Triple constraint: scope, time, cost — with quality in the middle. Change any one and the others move; the PM balances, the steering committee/sponsor decides trade-offs.
• Benefits realisation is the sponsor's job, not the PM's. A project can be on time and on budget and still be a failure because the expected benefits were never realised.
• PMBOK process groups (know the five and what belongs to each):
  • Initiating — charter, stakeholder identification.
  • Planning — scope, schedule, cost, quality, resource, communications, risk, procurement plans.
  • Executing — perform the work, quality assurance, team/communications management.
  • Monitoring & Controlling — performance measurement, integrated change control, risk monitoring, quality control.
  • Closing — final acceptance, lessons learned, contract closure, releasing resources.
• PM knowledge areas (PMBOK-style) — integration, scope, schedule, cost, quality, resource, communications, risk, procurement, stakeholder. Exam-level use: match a described activity to the right knowledge area.
• Project risk management — identify → analyse (qualitative then quantitative) → respond (plan) → monitor & control. Response strategies: avoid, transfer, mitigate, accept (threats); exploit, share, enhance, accept (opportunities). Risk response is planned in the planning phase and monitored throughout — not "after go-live".
• Scope creep is controlled by formal change control, not by the PM absorbing extra work. Gold plating (extra unrequested features) is equally wrong.
• Segregation of duties inside the project: the person who develops must not be the person who tests, approves for production, or moves to production.

Earned value basics

• Reading the signs: SV or CV negative = behind schedule / over budget. Zero = on plan. Positive = ahead / under budget.
• Indices: SPI or CPI < 1 = behind / overspending; = 1 on plan; > 1 better than planned.
• Key insight: SPI measures schedule in cost terms — a high SPI does not prove the business value is delivered. EV says nothing about benefits; that is what the post-implementation review is for.
• Cost overruns are detected early by EV, which is why EV (not simple budget-vs-actual spend) is the preferred progress measure.

A.2 Business case and feasibility analysis

• The business case justifies the investment in business terms and is owned by the sponsor/business, not IT. It must be revisited as assumptions change and re-validated before major funding decisions.
• Cost-benefit analysis must include ongoing operating costs (licences, hosting, support, training, staff, maintenance) — not just build cost. TCO (Total Cost of Ownership) captures acquisition + operation + maintenance + retirement over the full life.

• Economic techniques:
  • NPV (Net Present Value) — discounts all future cash flows (in and out) at the cost of capital to today. Positive NPV = accept. Preferred method because it uses the time value of money and considers the whole life of cash flows.
  • IRR (Internal Rate of Return) — the discount rate at which NPV = 0. Compare to the hurdle rate; higher is better. Weakness: ignores absolute size and can be distorted by unusual cash-flow patterns.
  • Payback period — time to recover the initial investment. Simple, favours short-term/liquidity, ignores the time value of money and everything after payback. Use as a screening/risk indicator, not as the primary decision method.
  • ROI — (benefits − costs) / costs. Simple ratio; does not handle timing well.
• Intangible benefits (better customer service, compliance, staff morale) should still be documented and, where possible, measured — they must not be silently dropped.
• Sunk costs are irrelevant to the go/no-go decision; only future incremental cash flows matter.

A.3 System development methodologies

• Agile shifts control emphasis — it does not remove control. What replaces waterfall sign-off gates:
  • Automated unit/regression tests in the pipeline (because documentation-based review is reduced).
  • Continuous integration — code merged and built automatically, breaking builds caught immediately.
  • Backlog control — the product owner owns priority and acceptance of stories; requirements are the backlog items.
  • Definition of done including security and test criteria.
  • Sprint review/retrospective as the control point; still needs segregation of duties and no developer production access.
• Secure SDLC — security must be designed in from requirements, not bolted on before go-live:
  • Security requirements written into the backlog/requirements spec.
  • Threat modelling during design (identify threats, trust boundaries, mitigations).
  • Secure coding standards, static/dynamic analysis, dependency scanning in CI.
  • Security testing (penetration testing) before release, with remediation tracked.
  • Exam angle: the cheapest and most effective security control point is requirements and design, not post-implementation patching.

A.4 Control identification and design in development

• The golden rule: developers must NOT have production access. Development, testing, staging and production are separate environments. The developer who can change production code can bypass every change control — this is ISACA's classic answer.
• Known-good pattern: developer writes code → version control → peer/code review → test environment → QA/UAT → change control board approval → separate operations/release staff deploy to production.
• Core development controls:
  • Segregation of duties — developer ≠ tester ≠ approver ≠ deployer ≠ operator.
  • Version control / configuration management — every change versioned, attributable, recoverable; baseline libraries; no direct edit of production source.
  • Code review / peer review / walkthrough / inspection — detective review of code against standards and requirements before testing.
  • Separation of environments — development, test, staging/pre-production, production. Promotion between environments is controlled and approved.
  • Test data — use masked, anonymised or synthetic data. Never copy production data (especially personal data) into development/test: it exposes real data, breaches privacy law, and removes accountability. (This is a top-frequency exam answer.)
  • Change control board (CCB) — approves changes to baselined scope/requirements and to production; evaluates impact, authorises, schedules.
  • Approval gates between phases — each phase's deliverable is reviewed and formally accepted before the next begins.
  • Requirements traceability matrix (RTM) — maps each requirement → design → code → test case → result. It is the evidence that everything required was built and tested and that nothing extra crept in.
  • Migration/implementation authorisation — a separate, formal go-live decision.
• Program change controls apply to all changes including emergency fixes: emergency changes may be fast-tracked but must be documented, approved retrospectively, tested and reviewed. Never "no approval needed for emergencies".
• Third-party / outsourced development — contract must cover: rights to source code, escrow for critical software, security and privacy obligations, right to audit, service levels, change control interface, and dependency on vendor viability.

Application controls — INPUT

• Mnemonic for input edit checks — "Very Rare Lemons Really Check Duplicate Sequences From Keys": Validity, Range, Limit, Reasonableness, Completeness, Duplicate, Sequence, Format, Key verification.

Application controls — PROCESSING

Application controls — OUTPUT

• Preventive vs detective — the exam's favourite distinction: preventive controls stop the error entering (edit checks, check digits, access control, segregation of duties). Detective controls find it after the fact (control totals, reconciliation, exception reports, review, sequence checks). Corrective controls fix it (error correction and re-submission, recovery, backup restore).

B. IS Implementation

B.1 System readiness and implementation testing

• Readiness criteria — before go-live, confirm: all requirements implemented and traceable, all test levels passed with defects closed or formally accepted, data converted and reconciled, interfaces tested, procedures and manuals written, users trained, security configured and tested, support/handover agreed, rollback plan documented and tested, and business sign-off obtained.
• Test levels:

• White box = internal logic/code visible (unit, code coverage, static analysis). Black box = inputs/outputs only, no internal knowledge (system test, UAT, penetration test). Grey box = partial internal knowledge (typical integration/security assessment).
• Alpha testing = at the developer's site, by internal staff. Beta testing = at the user's site, by real users before general release.
• UAT acceptance criteria must trace back to documented business requirements. Without an RTM/traceability, "acceptance" is unverifiable opinion.
• Internal audit's role in testing — review and evaluate the test plan, strategy, coverage, acceptance criteria, results and defect resolution; observe testing; review evidence. Audit does not design test cases, execute UAT, or sign off acceptance — doing so impairs independence and removes the assurance the organisation needs.
• Defect management — defects logged, prioritised by severity/business impact, tracked to closure, and formally accepted (with sponsor/business agreement) if deferred. Unexplained open defects at go-live are a red flag.

B.2 Implementation configuration and release management

• Release management — the controlled process for planning, building, testing, approving, scheduling and deploying release units into production. It ensures what reaches production is what was tested and approved, and that releases are reversible.
• Versioning and baselines — a baseline is the approved configuration at a point in time; every change creates a new version. Configuration management keeps the definitive software library under control.
• Environment promotion — artefacts move dev → test → staging/pre-production → production through gated, approved promotions, never by direct copy from a developer workstation.
• Rollback / back-out plan — a documented, tested procedure to restore the previous working state if go-live fails. Must include data rollback, not just code. A go-live without a rollback plan is the wrong answer.
• Golden image / hardened baseline — a standard approved build/config for servers, workstations and containers, so no unauthorised deviations exist.
• Deployment approvals — formal authorisation (change/release authority) before promotion to production, with evidence of testing.
• Release notes — what changed, why, impact, dependencies, known issues, rollback instructions.
• Modern deployment techniques:

• Segregation still applies: the ability to deploy, the ability to approve, and the ability to develop are separate. Emergency changes follow an abbreviated path but are still recorded, tested where possible, and reviewed after the fact.

B.3 System migration, infrastructure deployment and data conversion

• Data conversion/migration steps: identify source data → data mapping (source field → target field, transformation rules) → data cleansing (remove duplicates, fix invalid/incomplete values, standardise formats) → extract, transform, load → field-level verification → reconciliation → retention/archival of legacy data.
• The critical control is reconciliation: record counts and control totals (financial totals, hash totals, opening balances) must be agreed before and after conversion. Converting account balances without proving they agree to the legacy balances is the classic audit finding.
• Data mapping must be signed off by the business/data owner — mapping errors produce silently wrong data, which is far more dangerous than a crash.
• Legacy data retention — decide what to migrate, what to archive, and what to retain for legal/regulatory/statutory periods; the old system may need to stay readable/queryable.
• Data quality is a business responsibility, not purely technical; cleansing rules and exceptions must be approved by the data owner.
• Infrastructure deployment — capacity planning, network and interface readiness, security hardening of the new platform, backup and DR arrangements re-validated for the new environment, licence compliance, and environmental/facility readiness. Infrastructure must be in scope for testing, not assumed.
• Interfaces are the highest-risk migration area: formats, timing, error handling, and duplicate/missing record handling must be tested explicitly.

B.4 Post-implementation review (PIR)

• Timing — after the system has stabilised, typically 3–12 months after go-live (long enough for benefits to begin materialising and for post-go-live problems to settle; too early and the review is meaningless).
• Objectives:
  • Were the business case benefits realised (and are they measurable)? If not, why not?
  • Were the requirements met, and was the delivered scope what was approved?
  • Were controls effective — and did any control gaps contribute to problems?
  • Were costs and schedule within budget, and was the cost-benefit analysis accurate?
  • Were lessons learned captured and fed back into the methodology?
  • Is there any need for corrective action, further investment, or decommissioning?
• PIR should be performed by an independent party (internal audit or a party not on the project team). A project team self-assessment is not a PIR — the team cannot objectively judge the benefits it claimed.
• PIR ≠ system testing (which verifies the system works) and ≠ a security assessment (which verifies control/security effectiveness at a point in time). PIR evaluates whether the investment delivered the promised business value.
• Note the distinction: post-implementation review (benefits and lessons, independent) vs post-implementation/production support handover (operational). The exam usually means the former.

Acquisition alternatives: COTS, SaaS, outsourcing, cloud

• COTS / packaged software — evaluate: fit to requirements (configuration vs customisation), customisation cost and upgrade pain, vendor viability and roadmap, licence model and compliance, interfaces/integration with existing systems, support and patching cadence, and the vendor's own controls (SOC 2 / ISAE 3402 style assurance reports).
• SaaS / cloud — you inherit the vendor's controls but retain your own accountability for data classification, access management, configuration, integration, exit strategy and compliance. Review: data location/residency, encryption, tenant isolation, SLA and availability, sub-processors, right to audit / third-party assurance reports, data return and deletion on exit, and business continuity.
• Outsourcing/third-party development — contract controls: deliverables and acceptance criteria, source code ownership and escrow, security and privacy obligations, change control interface, service levels and remedies, right to audit, subcontractor disclosure, termination/transition assistance.
• Why escrow — if the vendor fails or is acquired, escrow gives access to source code (and often build/documentation) needed to maintain the system. Conditions for release of escrow must be defined.
• Vendor viability matters because a system you cannot maintain, patch or upgrade becomes a business continuity and security risk, not just a commercial one.
• Cloud migration at a high level (Domain 5 goes deeper): assess workload suitability, data classification and residency, identity and access integration, network architecture, encryption and key management, logging/monitoring, backup and DR in the cloud, and exit/portability. Migration itself needs the same conversion, reconciliation, testing and cutover discipline as any other implementation.

TRAPS

• Developers with production access is the wrong answer, always. Any option that gives developers (or testers) direct production access, or lets them deploy their own code, is incorrect — regardless of how convenient it sounds.
• Internal audit signing off the system, approving the design, or performing UAT is the wrong answer. The auditor reviews the test plan, results, traceability and acceptance criteria; the user/business owns acceptance, and the sponsor owns benefits.
• Copying production data into the test environment is wrong — even when it is "faster" or "more realistic". Use masked/anonymised/synthetic data; production data in test is both a privacy breach and a control failure.
• Parallel cutover is the safest and the most expensive; direct (big bang) is the cheapest and riskiest. Read what the question optimises for ("minimise risk" → parallel; "minimise cost/time" → direct; "multiple locations" → phased; "one region first" → pilot). Do not reflexively pick parallel.
• A project that is on time and on budget can still fail — the failure is unrealised benefits. When the options include "the business case benefits were not achieved", that usually beats cost/schedule options.
• NPV beats payback. If an option chooses payback period as the primary criterion, it is normally wrong because it ignores the time value of money and cash flows after payback.
• Cost-benefit analysis that omits ongoing operating cost is incomplete — look for the option that adds recurring costs, licences, support, training and maintenance.
• Cheapest place to fix a defect is the earliest phase. Design/requirements fixes cost a fraction of production fixes; a question asking where to prevent a class of defect wants requirements/design, not more testing.
• Testing levels are not interchangeable. UAT validates against business requirements (not technical specs), is owned by users, and cannot be replaced by system testing or by developer unit tests.
• PIR is not testing and not a security assessment, is independent, and happens 3–12 months after go-live — not at go-live, and not by the project team.
• Batch control totals and reconciliation are detective, not preventive. Check digits, edit checks and access controls are preventive.
• Agile does not mean "no controls" — the controls move to automated testing, CI, backlog/product-owner control, environment promotion and segregation of duties.
• Security bolted on at the end is the wrong answer; the right answer is security requirements, threat modelling and secure coding from the start, with penetration testing before go-live.
• Emergency changes still require documentation, testing where feasible, and after-the-fact review. "No approval needed" is never correct.
• Feature flags are a new risk — flipping a flag changes production behaviour, so flag changes need authorisation and logging.
• A rollback/back-out plan must exist and be tested before go-live — including data rollback.
• Without a data mapping sign-off and a before/after reconciliation of record counts and control totals, the conversion is unproven — regardless of how smoothly it ran.
• Watch for options that are true but not responsive: an accurate statement about a different control area is still the wrong answer.

60-second recall

• Sponsor owns the business case and benefits realisation; the PM owns delivery to the triple constraint (scope/time/cost, with quality).
• SV = EV − PV, CV = EV − AC, SPI = EV/PV, CPI = EV/AC; negative/<1 = behind or over budget.
• On time and on budget ≠ success — benefits may be unrealised; EV does not measure benefits.
• NPV is preferred (time value of money, whole life); payback ignores both.
• Cost-benefit must include ongoing operating cost; TCO covers the full life.
• Feasibility types: economic, technical, operational, legal/regulatory, schedule.
• SDLC: feasibility → requirements → design (logical then physical) → development → testing → implementation → PIR.
• Requirements is the highest-leverage phase; defects cost least to fix there.
• Developers never have production access — separate development, test, staging and production environments.
• Use masked/synthetic test data; never copy production data into test.
• Version control, code review, RTM and CCB approval are core development controls.
• Input controls: source documents, batch totals (financial/hash/record count), check digit, validity, range, limit, reasonableness, completeness, duplicate, sequence, format, key verification, error correction.
• Processing: run-to-run totals, reconciliation, reasonableness/limit, file integrity, program change control, exception reports.
• Output: reconciliation to input, distribution lists, user review of output, error handling, retention and secure disposal.
• Input edit checks prevent; control totals and reconciliations detect.
• Test levels: unit → integration → system → regression → UAT (user-owned, traces to requirements) → performance/load/stress/volume → recovery → security → parallel/pilot.
• White box = internal logic; black box = inputs/outputs; grey box = partial knowledge. Alpha = developer site, beta = user site.
• Audit reviews the test plan and results; it does not perform UAT or sign off go-live.
• Cutover: direct (risky/cheap), parallel (safe/expensive), phased (by module/location), pilot (subset first).
• Conversion's critical control = data mapping plus reconciliation of record counts and control totals before and after.
• Release management: versioning, baselines, environment promotion, deployment approval, release notes, tested rollback plan; canary, blue-green, dark launch, feature flags.
• PIR: independent, 3–12 months after go-live, tests benefits/requirements/controls/cost/lessons — not a test, not a security assessment.
• COTS/SaaS/outsourcing: vendor viability, escrow, integration, vendor's own assurance reports (SOC 2 style), exit strategy — you can outsource work, never accountability.