Workshop  ›  Lessons  ›  Lesson 4

Day 3 — Morning · Domain 3

IS Acquisition, Development & Implementation

Every new system brings new risk. Domain 3 equips IS auditors to evaluate the controls built into how technology is planned, procured, built, and deployed — before it's too late to fix the design. We cover the full path: acquisition and development (3A), then testing, release, migration, and post-implementation review (3B).

Session: Morning, Day 3 Duration: ~3 hrs Exam Weight: 12% (~18 Qs) Knowledge Check: 5 Questions

Overview

Controls are cheapest to build in, costliest to bolt on

Domain 3 is 12% of the exam, and its through-line is timing: the IS auditor's value is highest early, when controls can still be designed into a system rather than retrofitted after go-live. This lesson follows a project from business case and methodology choice (Waterfall, Agile, DevSecOps) through control design, testing, change and release management, data migration, and the post-implementation review. The recurring exam themes are independence (the auditor advises, never decides or builds) and evidence (verify benefits and validate migrations — don't accept assertions).

Learning Objectives

By the end of this lesson you will be able to…

Key Terms

Vocabulary flashcards

👈 Read the term, recall the definition, then click or press Enter to check yourself.

Lesson Content

Study the material

1

Project Governance & Management

An acquisition or development effort is a project, and projects need governance: clear sponsorship, defined roles, and oversight that can say no. The auditor's independence boundary is critical here.

  • Roles: project steering committee (oversight, go/no-go), sponsor (business owner accountable for benefits), project manager (scope/schedule/budget/risk), PMO (standards, methodology, portfolio).
  • Standards: PMBOK, PRINCE2, Agile (Scrum, SAFe).
  • Project risk register: scope creep, budget overrun, resource attrition, technology failure.
  • Auditor checks: project charter, executive sponsorship, status reporting cadence, independent project QA, formal change control.
💡 Exam TipAn IS auditor may advise on control requirements during a project — that's encouraged. Joining the implementation team and making design decisions creates a self-review threat. Auditors advise; they do not decide or build.
2

Business Case & Feasibility Analysis

Before money is committed, a business case should justify the investment and a feasibility study should confirm it is viable. The auditor checks that benefits are real, measurable, and later verified.

  • Business case: problem/opportunity, solution options (including a “do nothing” baseline), cost-benefit analysis, ROI and payback, risk, and a recommendation.
  • Feasibility dimensions: technical, financial, operational, legal/regulatory, and schedule.
  • Benefits realization is tracked after go-live to confirm projected benefits were achieved.
  • Auditor: case approved by proper authority; benefits quantified and measurable; assumptions documented and validated; a plan to measure benefits exists.

Acquisition & regulated-system controls

  • Software escrow: for licensed/COTS software, an escrow agreement deposits source code and build instructions with a third party, released to the licensee on defined triggers (vendor insolvency, acquisition, or failure to support) — protecting a business-critical system. The auditor verifies the agreement exists, is funded, names release triggers, and that deposits are current and periodically verified.
  • Validated systems (FDA 21 CFR Part 11): in regulated industries (pharma, medical devices, healthcare), systems handling electronic records and signatures must be validated — documented IQ/OQ/PQ, secure audit trails, access controls, and signature integrity. The auditor confirms validation evidence exists and that change control preserves the validated state.
3

System Development Methodologies

The methodology shapes where and how controls must be applied. None is inherently insecure — the question is whether controls are adapted to how the team actually works.

  • Waterfall: sequential phase gates; predictable for stable requirements but inflexible and tests late.
  • Agile (Scrum, Kanban, SAFe): short sprints; audit per sprint, keep security requirements in the backlog, maintain documentation.
  • Agile audit nuance: sprint retrospective notes improve the team but are not a substitute for the requirements baseline and control documentation an audit relies on — don't accept retrospectives as workpaper-equivalent.
  • DevOps / DevSecOps: CI/CD pipelines with SAST, DAST, SCA, and container scanning; infrastructure as code; control pipeline access and production-deploy approvals.
  • RAD (prototype-based) and COTS (source-code escrow, software composition analysis, contractual security terms).
💡 Exam TipAgile is not inherently insecure. The auditor's concern is that audit checkpoints adapt to the sprint cycle, security requirements live in the backlog from the start, and documentation is maintained even when teams prioritize working software.
🔎 In practice

Iterative delivery has no single test-and-deploy event to sample, so the auditor samples across sprints: take a risk-based selection of user stories and releases over several iterations and test that each carried the required controls — security acceptance criteria met, code review and pipeline gates (SAST/DAST) passed, and deployment approved. The population is the flow of releases over the period, not one milestone.

4

Control Identification & Design

Controls are cheapest and most effective when designed in during requirements and design — not bolted on after deployment.

  • Application controls: input (validation, range, format, existence, reasonableness), processing (batch/hash totals, record counts, completeness), output (distribution, balancing, exception reporting).
  • Access design: role-based access by job function, least privilege, and SoD in the workflow.
  • Audit trail: which events are logged, log retention, tamper-evident logging.
  • Threat modeling: STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege).
🔎 In practice

A system whose requirements never mentioned logging or access control will be expensive to fix after launch. The auditor's highest-value moment is reviewing the requirements — not the finished product.

Explore furtherCybersecurity Design Principles — the secure-by-design fundamentals that belong in requirements and design.
Design Principles ↗
5

System Readiness & Implementation Testing

Testing produces the evidence that a system is fit to deploy. The auditor's eye is on coverage and, above all, independence.

  • Levels: unit → integration → system → user acceptance (UAT) → performance/load → regression (confirms existing functionality still works after changes) → security (SAST, DAST, penetration).
  • UAT must be performed by real business users, not developers.
  • Source-code review — manual peer review plus automated static analysis (SAST) — is a recognized audit technique for assessing control and security quality in custom-developed code.
  • Auditor: review the test plan for completeness and independence; confirm results documented and signed off; verify defects tracked and resolved before go-live.
  • Go/no-go: critical and high defects resolved, UAT sign-off, security findings remediated, data migration validated, rollback plan tested.
💡 Exam TipOn testing questions, check independence: who tests and who approves. Developers testing their own code without independent review, or a manager approving their own team's UAT, compromises independence — a finding.

Try it — the cheapest bug is the one you catch first

This is why the auditor’s value is highest early. A defect fixed at requirements costs a fraction of the same defect found in production. Set how many defects the project carries and how rigorously it tests early — then watch where the remediation money actually goes.

Interactive · adjust & explore
Your project

A fix costs 1× at requirements … 100× in production.

50
How many bugs the system carries, mostly baked in early.
45%
How aggressively each phase catches defects before the next.
The bill
Total remediation cost
—
Caught before production
—
Avg cost / defect
—
Reached production
—
— — Slide the rigor to shift detection earlier.
Where the remediation money goes

Total fix cost by the phase a defect is caught in. Late phases cost far more per defect — so even a few that reach production can dominate the bill.

Cost if caught here Production (most expensive)
🔎 In practice

This is the case for the auditor being in the room early: a control designed at requirements is cheap; the same gap found after go-live is a costly rework or a breach. It’s also why independent testing and a real go/no-go matter — letting critical defects through to production is exactly the expensive outcome the model shows.

6

Implementation, Configuration & Release Management

Once a system is live, every change is a risk. Change, release, and configuration management keep that risk controlled and traceable.

  • Change types: standard (pre-approved), normal (full Change Advisory Board review), emergency (expedited path).
  • Release management: major/minor/patch releases, release windows, deployment (smoke) testing.
  • Configuration management: the CMDB as the authoritative record, configuration baselines, and drift detection.
  • Auditor: every production change has a record; changes approved by an independent authority; emergency changes get a post-implementation review; CMDB reconciled to reality; separation between who develops and who deploys.
💡 Exam TipEmergency changes should have an expedited but documented approval process and a post-implementation review after every one. Emergency changes that bypass all controls entirely are a finding — not an acceptable exception.
Explore furtherConfiguration Management — an interactive module on baselines, patching, and change control.
Config Management ↗
7

Migration, Deployment & Data Conversion

Moving to a new system is where data integrity is most at risk. The controls here are about proving that what arrived matches what left.

  • Strategies: big-bang cutover (high risk, low cost), parallel run (low risk, high cost), phased migration, pilot implementation.
  • Data conversion: mapping, cleansing, then validation.
  • Validation controls: record-count reconciliation, aggregate-value reconciliation, sample comparison, exception reporting — with business-owner sign-off.
  • Infrastructure: environment parity, infrastructure as code, network segmentation, certificate and key management.
🔎 In practice

A 2% drop in record count after migration isn't automatically acceptable “because it's small.” The auditor wants evidence that the missing records were identified, reviewed, and authorized for removal.

8

Post-Implementation Review

The project isn't over at go-live. A post-implementation review closes the loop on whether the investment actually delivered.

  • Conducted ~3–6 months after go-live, once operational issues surface.
  • Scope: benefits realization, control effectiveness, user adoption and satisfaction, performance against SLAs, outstanding defects.
  • The auditor may perform the PIR independently or evaluate management's PIR process.
  • Lessons learned are documented for future projects.
🔎 In practice

An ERP delivered on time and on budget but never reviewed leaves one question unanswered: did it deliver the benefits that justified it? Without a PIR, nobody actually knows.

Scored Knowledge Check

Test your Domain 3 judgment

Select the best answer for each question, then submit for your score and the rationale for every item. Watch the independence and evidence themes.

Q1.An IS auditor is asked to join a project implementation team for a new core banking system, contributing control requirements to the system design. The auditor should:

Question 1 options
Correct: B. Auditors may advise on control requirements without impairing independence — provided they don't make design decisions. Full participation as a team member (A) impairs future independence; complete non-participation (C) forgoes a chance to improve controls at the lowest cost. Why the others fall short: A making design decisions impairs later audit independence; C declining all involvement forfeits advice the auditor may properly give; D UAT-only observation understates the appropriate advisory role.

Q2.During a data migration audit, the record count in the new system is 2% fewer than in the legacy system. Management says the difference represents duplicates removed during conversion. The auditor should:

Question 2 options
Correct: B. The auditor must verify the explanation with evidence. A 2% shortfall requires documentation of the identification, authorization, and validation of removed records. Accepting a verbal explanation without evidence violates professional skepticism. Why the others fall short: A accepting the variance on management’s word skips verification; C expanding to the full population is premature before reviewing the evidence; D a qualified opinion is premature before evaluating the explanation.

Q3.An organization using Agile releases to production every two weeks through a CI/CD pipeline. An auditor evaluating change management should FIRST verify:

Question 3 options
Correct: B. In CI/CD pipelines, automated controls that enforce approvals (code-review sign-off, security-scan passage, manager approval) before code reaches production are the primary change-management control — the Agile equivalent of a CAB review. Why the others fall short: A ‘adapting waterfall’ misframes a CI/CD environment; C PMO oversight isn’t the deployment-control question; D awareness training is unrelated to whether approvals gate production.

Q4.An auditor reviewing a large ERP implementation notes the project was delivered on time and within budget, but no post-implementation review was conducted. The MOST significant concern is:

Question 4 options
Correct: A. Without a PIR, there is no formal verification that the ERP delivered its promised benefits. On-time and on-budget delivery does not mean objectives were met — benefits realization is a governance accountability. Why the others fall short: B vendor warranty isn’t the significance of a missing PIR; C on-time/on-budget doesn’t prove benefits were realized — that’s what a PIR checks; D the concern is unverified benefits, not a standards ‘violation.’

Q5.A new payroll application went live after a parallel run showed a 0.3% variance between old and new outputs. Management approved cutover, accepting the variance as immaterial. The auditor should:

Question 5 options
Correct: B. The auditor should verify the variance was investigated and understood — not simply accepted. Any variance in a financial system, even one deemed immaterial, should be explained and documented, with the root cause determined and the acceptance decision authorized. Why the others fall short: A agreeing it’s ‘immaterial’ skips whether the variance was understood; C another 30-day parallel run is disproportionate before inquiry; D escalating to the external auditor is premature.