ISACA CISA guideStudy & preparation

CISA System Development and Implementation: Follow the Audit Evidence

Follow an original invoice-system case from business requirements through design, acceptance testing, migration, and post-launch review, and explain what each record can establish.

Short answer

Evaluate system implementation by connecting the stated business requirements to design, testing, migration, and operational evidence. ISACA's CISA Domain 3 covers these topics, including post-implementation review, and carries a 12% exam weight in the outline checked November 3, 2026. A successful test or an acceptance signature supports a particular conclusion; neither alone establishes that all converted data are accurate or that controls operated throughout production.

What belongs in CISA Domain 3?

Evaluate a system implementation by tracing business requirements into the evidence of what was designed, tested, converted, and operated. ISACA's CISA Exam Content Outline places these topics in Domain 3, Information Systems Acquisition, Development, and Implementation, which accounts for 12% of the exam in the outline checked November 3, 2026.

The domain covers project governance, business case and feasibility analysis, development methods, control identification and design, readiness and testing, release and configuration, migration and data conversion, and post-implementation review. The CISA domains guide places that work within the whole exam. The weight does not establish a fixed number of scored questions about migration or any other individual topic.

The sequence below is an editorial teaching exercise using one fictional project. It is not a mandatory system development life cycle, or SDLC, for every organization. Follow the requirement through the records instead of treating the names of project stages as sufficient answers.

What should the business case establish before development?

ISACA's glossary, checked November 5, 2026, describes a business case as supporting an investment decision and subsequent management. It establishes why an investment is proposed; it does not, by itself, prove that the expected result was achieved.

In this original fictional case, an organization is replacing its invoice system. Its business case records the investment rationale and two requirements:

  • Preserve all 1,000 in-scope source invoices accurately in the replacement system.
  • Prevent an invoice from being paid without the designated approval.

The fictional project charter gives management the acceptance and go-live decision. This is a fact of this example, not a universal assignment of job titles or approval authority.

The project packet contains an approval-control design, two acceptance-test results, a migration summary, an acceptance signature, and a bounded sample of operational records after launch. Each item must be assessed against the relevant requirement. No amount of discussion about investment rationale resolves a discrepancy in the converted invoices.

Start your analysis by writing the requirement in concrete terms. Here, “the new system works” would be too vague: it could hide either a data-conversion problem or a failure to enforce approval. For broader topic practice, full ISACA CISA prep planned for launch covers the five exam domains.

How do control design and implementation evidence differ?

The design document specifies a check for the designated approval. That establishes the planned control. It leaves open whether the control was implemented as designed and how it behaved under relevant conditions.

ISACA's glossary distinguishes reviewing designed controls and intended processing from examining implementation evidence such as test plans and acceptance procedures. NIST SP 800-53A Revision 5, checked November 3, 2026, also distinguishes design artifacts, test outputs, and operational records when assessing controls. NIST provides explanatory assessment concepts here; it is not an exclusive CISA answer framework.

Use this evidence map for the fictional project:

Requirement or questionRecord suppliedSupported conclusionRemaining gap
Why invest, and what must be delivered?Business caseThe rationale and two requirements are documentedWhether the delivered system meets them
How should unapproved payment be prevented?Approval-control designAn approval check is specifiedWhether it was implemented and works in relevant conditions
Does the check behave as expected?One rejected unapproved test invoice and one accepted approved test invoiceExpected behavior occurred for those cases in the stated test configurationOther paths, conditions, and production operation
Were all 1,000 invoices preserved accurately?Summary showing 999 target invoicesThe reported target count is one below the source countCause, affected records, and accuracy of the converted data
Was acceptance recorded?Acceptance signatureAn acceptance decision was recordedWhether the conversion discrepancy was resolved
Were approvals recorded after launch?Approval records for the transactions in a bounded operational sampleSupporting approvals exist for the reviewed transactionsTransactions and periods outside that scope

For the underlying methods of selecting and assessing records, use the CISA audit-evidence guide. In this project, the next task is to identify which requirement remains unsupported, not simply to collect more documents of any kind.

What should testing and migration records demonstrate?

ISACA's glossary describes acceptance testing as informing the customer or acquirer's acceptance decision. In the case, the test records show an unapproved test invoice rejected and an approved test invoice accepted in the stated test configuration. Those results support the expected behavior for those two cases. They do not establish every possible processing path or all later production activity.

Migration presents a separate question. The summary reports:

1,000 source invoices − 999 target invoices = a net count discrepancy of one invoice.

That is a reason to investigate, not proof that precisely one invoice is missing and nothing else is wrong. The summary does not identify which records differ or explain the cause. Ask for evidence that reconciles the source and target records against the preservation requirement, including whether the corresponding data are accurate.

Even matching totals would leave questions open. In an illustrative variation, one omitted invoice and one duplicated invoice could offset each other in the count. A count comparison alone would then conceal a failure to preserve the correct records. This arithmetic illustrates an evidence limitation; it does not prescribe an ISACA migration procedure or sample size.

The acceptance signature does not close the gap. It records acceptance, but the supplied packet still needs evidence of what happened to the discrepancy. Keep the test result, conversion finding, and acceptance decision separate in your notes.

If terms such as acceptance testing and post-implementation review blur together, practice recalling the question each addresses. Full ISACA CISA prep planned for launch includes 500 flashcards for recall alongside question practice.

What changes after the system goes live?

After launch, compare delivered functionality and actual operational evidence with the recorded requirements. The presence of a live system does not establish that the conversion issue was resolved or that every payment received its required approval.

The fictional operational sample contains approval records for the transactions reviewed. That supports a statement about those records within the review's scope and period. It does not establish compliance for every transaction or all future operation. The packet supplies no basis for silently expanding the conclusion.

Work through three questions:

  1. What happened to the conversion discrepancy? Identify whether further evidence explains and resolves the difference against the original requirement.
  2. What did the operational review cover? State the transactions, system functions, and period actually assessed before drawing a broader conclusion.
  3. Which requirement does each result answer? Approval records address the approval requirement; they cannot establish that all source invoices were converted accurately.

This case sets no mandatory date for a post-implementation review. Its focus is the relationship between requirements, delivered functionality, and evidence. Put that reasoning into a topic session using the free CISA study plan; the eight-week study-plan guide explains how to fit topic work into a larger calendar.

How do you state the limits of a project audit conclusion?

A defensible conclusion describes what the supplied records demonstrate and what remains unresolved. For this fictional packet, you could write:

The approval control behaved as expected in the two documented acceptance-test cases. The migration summary reports 999 target invoices against 1,000 source invoices, and the supplied evidence does not resolve that discrepancy. Approval records support the transactions reviewed after launch; operation outside that sample has not been established.

The auditor evaluates and communicates those evidence limits. Under this fictional charter, management owns the acceptance and go-live decision. An auditor should not convert the presence of a signature into an unsupported conclusion about data accuracy or operational performance.

Try a short exercise: Would another acceptance signature or a record-level explanation of the conversion discrepancy better address the unresolved preservation requirement? The explanation is more relevant because the remaining question concerns the invoices. Its contents would still need evaluation; merely receiving a document would not establish resolution.

Use the 20 free CISA practice questions to practice explaining the claim supported by an answer. If choosing between plausible options is the difficulty, continue with the CISA best-answer question guide.

For additional practice, full ISACA CISA prep planned for launch includes 1,350 questions. Keep exam preparation separate from earning the credential; the CISA requirements and cost guide explains those steps.

Your next task is to cover the evidence-map conclusions and reconstruct them from the requirements and records. For every conclusion, name one fact still needed before you could reasonably broaden it.

<!-- Writer self-check: Preserved the appended PLAN identity and outline; this entry has no assigned yearFocus. Official claims checked against RESEARCH.md O1/AO2, AL2, and N1–N3 with original checked dates; fictional requirements, records, arithmetic, charter, and conclusion match the per-slug audit claim map. No universal SDLC, migration procedure, approval hierarchy, review date, sample size, or question allocation asserted. Product facts checked against CONTEXT.md and exam.json. Three separated launch-worded commercial links, both free tools, both published sibling identities, and relevant new-guide links included. Independent editorial review remains required. -->

Trust the source

Official sources

Exam policies can change. Use these primary sources for the most current details.