CISA Exam Preparation – Domain 3 Part 4

CISA Exam Preparation – Domain 3 Part 4

Information Systems Acquisition, Development & Implementation (Deep Dive)
Based on this slide deck:
This presentation continues my CISA Exam Preparation Series, focusing on Domain 3 — where we move from governance into how systems are actually built, controlled, and implemented in practice.

This is one of the most important domains for the exam, because failures in systems almost always originate early in the lifecycle — especially at the requirements stage.

🔍 What you’ll learn in this video:
📌 System Development Lifecycle (SDLC)
Full lifecycle: Feasibility → Requirements → Design → Build → Test → Implement → Review
Why requirements definition is the most critical phase (exam favourite)
How poor early decisions lead to later failures
Business Case & Feasibility
Cost vs benefit, alignment to business objectives
Technical, financial, and operational feasibility
Auditor focus: decision quality and risk awareness before approval
⚙️ Development Approaches
Agile, Waterfall, DevOps, RAD
Key insight: Methodology does NOT remove control requirements
Risks: weak documentation, poor change control, inadequate testing
🔐 Control Design & Effectiveness
Input, processing, and output controls
Ensuring accuracy, completeness, and authorisation across data flows
Why controls must be built in early — not added later
🧪 Testing & Implementation
Unit, integration, system, and UAT testing
Configuration and release management
Data migration and cutover strategies (parallel, phased, big bang)
Key risk: uncontrolled changes and data integrity failures
🔄 Post-Implementation Review (PIR)
Validate benefits, performance, and control effectiveness
Capture lessons learned and update risk register
Auditor focus: effectiveness, not just completion
🧠 CISA Exam Insights:
Failures usually start in requirements, not testing
Controls added late = design failure
Skipping review = no improvement
Always trace issues back to the lifecycle stage
Why this matters:

From an audit perspective, this domain is about ensuring that:

Systems meet business objectives
Risks are identified before implementation
Controls are designed and embedded, not retrofitted
Projects deliver real value, not just technical completion

Transcript

1. CISA Series Domain 3 – Part 4  Information Systems Acquisition, Development and Implementation  Deep Dive: Lifecycle, Risk, Control Effectiveness, Audit Perspective © Alison Wickens | Management System Insights CISA Series 2026 Not affiliated with ISACA. Redistribution or commercial use prohibited
2. CISA Series Overview Part 1 – Introduction & Overview Part 2 – Domain 1: Information System Auditing Process Part 3 – Domain 2: Governance and Management of IT Part 4 – Domain 3: Information Systems Acquisition, Development, and Implementation Part 5 – Domain 4: Operations and Business Resilience Part 6 – Domain 5: Protection of Information Assets Part 7 – Exam Practice & Revision Covers all 5 CISA domains in a structured learning journey
3. Domain 3 Overview Covers system acquisition, development, and implementation Ensures systems meet business and control requirements Controls must be built into the lifecycle Strong focus on risk, governance, and auditability
4. Domain 3 – Core Principle Systems must support business objectives Systems must support business objectives Controls must be built in early (NOT added later) Controls must be built in early (NOT added later) Failures usually originate earlier in lifecycle Failures usually originate earlier in lifecycle Audit focus = design + effectiveness Audit focus = design + effectiveness
5. Maturity Model and Domain 3 Key Characteristics Description Name Level No awareness, no structure, high risk No processes or controls in place Non-existent 0 Reactive, dependent on individuals Processes are informal and inconsistent Initial / Ad Hoc 1 Some consistency, limited documentation Basic processes exist but are not standardised Repeatable 2 Formal policies, roles defined Processes are documented and standardised Defined 3 KPIs, reporting, oversight Processes are measured and monitored Managed 4 Proactive, integrated, efficient Continuous improvement and automation Optimised 5
6. COBIT Governance & Management Mapping Type Purpose Full Name Domain Governance Governance – set direction and oversight Evaluate, Direct, Monitor EDM Management Strategy, planning, and organisation Align, Plan, Organise APO Management Deliver solutions and change Build, Acquire, Implement BAI Management Operations and service delivery Deliver, Service, Support DSS Management Performance and compliance monitoring Monitor, Evaluate, Assess MEA
7. Information Systems Acquisition & Development Project Governance & Management → structure, roles, oversight Business Case & Feasibility → justify value and alignment Development Methodologies → Agile, Waterfall, DevOps Control Identification & Design → build controls into the system early
8. Project Governance & Structure •Use structured methodologies (Agile, Waterfall, Hybrid) •Ensure projects are controlled, measurable, and aligned to business goals Project Management Practices •Defined project governance framework •Clear reporting lines and escalation paths •Oversight via steering committees and PMO Project Structure & Governance •Project Sponsor → accountable for outcomes and funding •Project Manager → delivers project objectives •Stakeholders → provide input and approvals •Clear segregation of duties and accountability Roles & Responsibilities •Scope, time, cost, and quality management •Risk, issue, and change management •Use of tools, metrics, and dashboards Project Management Techniques •Prioritise projects based on business value and risk •Align investments with strategic objectives •Balance resources across initiatives Portfolio / Programme Management •Standardises methods, tools, and governance •Maintains project portfolio and reporting •Ensures consistency and oversight PMO (Project Management Office)
9. Execution, Control & Auditor Focus • Define objectives, scope, and deliverables • Develop budgets and cost estimates • Use techniques like function point analysis • Establish timelines and schedules Planning & Estimation • Manage scope, changes, resources, and risks • Track performance against plan and KPIs • Ensure issues are identified and resolved Monitoring & Control • Formal acceptance and sign-off • Conduct post-implementation review • Capture lessons learned Project Closing • Evaluate project governance and controls • Verify alignment with business objectives • Assess risk, change, and resource management • Ensure projects deliver expected value Auditor’s Role (CISA Focus)
10. Project Lifecycle Initiation •Define business case, objectives, scope •Get management approval Focus: business alignment Planning •Define scope, budget, schedule, resources •Identify risks and controls Focus: clear scope + realistic estimates Execution •Build and deliver the solution •Manage team, vendors, and quality Focus: follow approved plan Monitoring & Control •Track progress vs plan •Manage changes, risks, and issues Focus: strong change control Closing •User acceptance + sign-off •Perform post- implementation review (PIR) Focus: value delivered + lessons learned Business Requirement Business Requirement → Acquisition Decision → Acquisition Decision → Development / Configuration → Development / Configuration → Testing & Validation → Testing & Validation → Implementation → Implementation → Post- Implementatio n Review → Post- Implementatio n Review
11. Business Case and Feasibility Analysis •This stage ensures that IT projects are justified before they begin — not just technically, but from a business value and risk perspective. Purpose: Business Case • Justifies why the project should be done • Includes: • Costs vs benefits (ROI) • Business objectives alignment • Risks and assumptions CISA focus: Value + alignment Feasibility Analysis Evaluates whether the project is realistically achievable: • Technical feasibility → Can we build it? • Financial feasibility → Can we afford it? • Operational feasibility → Will the business use it? • Legal/regulatory feasibility → Are we compliant? CISA focus: Risk awareness before approval Key Concepts The auditor does NOT create the business case, but evaluates its quality and reliability. Auditor Must Verify: • Alignment with business objectives • Complete cost-benefit analysis • Risks are identified and assessed • Assumptions are realistic and documented • Feasibility analysis is thorough • No bias or overly optimistic projections IS Auditor’s Role in Business Case Development • Weak business case = high project failure risk • Auditor focuses on: • Decision quality • Risk visibility • Governance oversight CISA Exam Insight Focus Type Can we build it? Technical Is it worth it? Financial Will it work in practice? Operational Feasibility Types
12. Software Development Methods (SDLC Approaches) • Prototyping / Evolutionary • Iterative, user feedback-driven • Risk: weak documentation • Rapid Application Development (RAD) • Fast delivery, reusable components • Risk: reduced control rigor • Agile Development • Iterative sprints, continuous delivery • Must include embedded controls • Object-Oriented Development • Modular, reusable design • Component-Based Development • Uses pre-built components • Risk: integration and third-party dependency Core Methods • Web-Based Development • High exposure → security critical • DevOps • Continuous integration and deployment • Automation ≠ no control • Reengineering / Reverse Engineering • Improve or analyse existing systems • Business Process Reengineering (BPR) • Redesign processes + systems • High organisational risk Modern Approaches • Development method does not remove control requirements • Key risks: • Poor documentation • Weak change control • Inadequate testing CISA Exam Focus
13. System Development Life Cycle (SDLC) PHASE 1 — FEASIBILITY STUDY ASSESS VIABILITY (TECHNICAL, FINANCIAL, OPERATIONAL) PHASE 2 — REQUIREMENTS DEFINITION DEFINE BUSINESS AND SYSTEM REQUIREMENTS MOST IMPORTANT PHASE (EXAM FAVOURITE) PHASE 3 — SOFTWARE SELECTION / ACQUISITION EVALUATE VENDOR OR BUILD OPTIONS PHASE 3A — DESIGN TRANSLATE REQUIREMENTS INTO SYSTEM ARCHITECTURE PHASE 4A — CONFIGURATION CONFIGURE SYSTEM SETTINGS PHASE 4B — DEVELOPMENT BUILD OR CUSTOMISE SYSTEM PHASE 5 — TESTING & IMPLEMENTATION VALIDATE SYSTEM MEETS REQUIREMENTS PHASE 6 — POST- IMPLEMENTATION REVIEW ASSESS SUCCESS AND LESSONS LEARNED
14. Control Identification & Design (Application Controls) • Ensure data is: • Accurate • Complete • Authorised • Protect integrity across the system lifecycle Purpose • Input authorisation • Data validation (format, range, reasonableness) • Batch controls & balancing • Error reporting and handling Prevent invalid or unauthorised data entry Input Controls • Processing logic checks • Data validation during processing • File control procedures Ensure correct and complete processing Processing Controls • Output accuracy and completeness • Controlled distribution to authorised users • Review and reconciliation Ensure reliable information for decisions Output Controls • Integrated controls across: • Input • Processing • Output • Support transaction integrity Application Controls • Controls must cover end-to-end data flow • Objective: Accuracy + Completeness + Authorisation CISA Exam Focus
15. Supporting Controls, DSS & Auditor Focus • Standardised user instructions • Reduce errors and ensure consistency • Support control effectiveness User Procedures Purpose • Support management decision-making Key Areas • Design and development • Implementation and use • Risk factors • Implementation strategies Decision Support Systems (DSS) • Poor data quality • Weak control over models • Over-reliance on system outputs DSS Risks • Validate: • Input data quality • Processing logic • Output relevance Assessment & Evaluation • Evaluate: • Control design and effectiveness • Data integrity across systems • Verify DSS outputs are reliable IS Auditor’s Role • Application controls = high priority audit area • Auditor tests: • Effectiveness, not just existence • DSS focus: • Data quality + controlled decision-making CISA Exam Focus
16. Information Systems Implementation  System Readiness & Testing → validate functionality and controls  Configuration & Release Management → controlled deployment  Migration & Data Conversion → ensure integrity and continuity  Post-Implementation Review → confirm value delivery and lessons learned
17. Testing Methodologies (Core Concepts) •Ensure systems: •Function as intended •Meet business requirements •Maintain data integrity Purpose •Unit Testing → Individual components •Integration Testing → Interfaces between modules •System Testing → End-to-end functionality •User Acceptance Testing (UAT) → Business validation •Confirms system readiness before go-live •Other Types of Testing •Functional testing •Regression testing •Performance testing •Security testing •Each targets different risk areas Testing Classifications •Verifies: •Logic correctness •Processing accuracy •Error handling •Focus on reliability and stability Software Testing •Testing must be: •Structured •Documented •Traceable to requirements CISA Exam Focus
18. Configuration Management •Ensure systems are: •Consistent •Controlled •Traceable Purpose •Configuration Items (CIs) •Hardware, software, documentation •Baseline Configuration •Approved standard state •Version Control •Track changes over time •Configuration Repository (CMDB) •Central record of all CIs Key Concepts •Change tracking and approval •Version management •Access control over configurations •Audit trail of changes Key Controls •Unauthorised changes •System instability •Inconsistent environments Risks if Weak •Configuration = foundation for change control •Auditor checks: •Accuracy of CMDB •Integrity of baselines •Traceability of changes CISA Exam Focus
19. Release Management & Auditor Focus • Ensure controlled movement of changes into production Purpose • Release planning • Testing and approval • Deployment to production • Post-implementation review Key Activities • Major releases • Minor updates • Emergency fixes Types of Releases • Formal release approval • Segregation of environments: • Development • Testing • Production • Backout (rollback) procedures Key Controls • Verify: • Releases are authorised and tested • Changes follow formal processes • Segregation of duties is maintained IS Auditor’s Role • No release without: • Testing • Approval • Documentation • Key risk: • Uncontrolled changes in production CISA Exam Focus
20. Data Migration & Changeover •Ensure systems transition to production: •Safely •Accurately •With minimal disruption •Ensure systems transition to production: •Safely •Accurately •With minimal disruption Purpose Purpose •Transfer data from old → new system •Key activities: •Data cleansing and validation •Mapping and transformation •Reconciliation after migration •Transfer data from old → new system •Key activities: •Data cleansing and validation •Mapping and transformation •Reconciliation after migration Data Migration Data Migration •Define: •Migration approach •Data volumes and timing •Responsibilities •Include: •Fallback (rollback) plan Critical if migration fails •Define: •Migration approach •Data volumes and timing •Responsibilities •Include: •Fallback (rollback) plan Critical if migration fails Migration Planning Migration Planning •Parallel Changeover •Old and new systems run together • Low risk • High cost •Phased Changeover •Gradual rollout • Controlled risk •Abrupt (Big Bang) •Immediate switch • Fast • High risk •Parallel Changeover •Old and new systems run together • Low risk • High cost •Phased Changeover •Gradual rollout • Controlled risk •Abrupt (Big Bang) •Immediate switch • Fast • High risk Changeover (Go-Live) Techniques Changeover (Go-Live) Techniques •Always ensure: •Data integrity •Validated migration •Tested rollback capability •Always ensure: •Data integrity •Validated migration •Tested rollback capability CISA Exam Focus CISA Exam Focus
21. Implementation, Controls & Auditor • Execution of deployment into production • Includes: • Infrastructure setup • Application installation • Final testing • Execution of deployment into production • Includes: • Infrastructure setup • Application installation • Final testing System Implementation System Implementation • Detailed project plan: • Resources • Timeline • Risk mitigation • Detailed project plan: • Resources • Timeline • Risk mitigation Implementation Planning Implementation Planning • Formal approval of changes • Controlled migration steps • Documentation of all activities • Formal approval of changes • Controlled migration steps • Documentation of all activities Change Procedures & Migration Process Change Procedures & Migration Process • Strong planning and coordination • Effective communication • Tested migration and fallback • Business readiness • Strong planning and coordination • Effective communication • Tested migration and fallback • Business readiness Critical Success Factors Critical Success Factors • Ensure users: • Understand system usage • Can operate effectively Reduces operational risk post go-live • Ensure users: • Understand system usage • Can operate effectively Reduces operational risk post go-live End-User Training End-User Training • Install and configure system software • Ensure compatibility and security • Install and configure system software • Ensure compatibility and security System Software Implementation System Software Implementation • Formal approval before go-live • Confirms system: • Meets requirements • Is secure and compliant • Formal approval before go-live • Confirms system: • Meets requirements • Is secure and compliant Certification / Accreditation Certification / Accreditation • Verify: • Migration is complete and accurate • Changeover is controlled and approved • Training and documentation are adequate • Verify: • Migration is complete and accurate • Changeover is controlled and approved • Training and documentation are adequate IS Auditor’s Role IS Auditor’s Role • Key risks: • Data loss or corruption • Poor planning • Inadequate rollback • Auditor evaluates: • Effectiveness of implementation, not just process • Key risks: • Data loss or corruption • Poor planning • Inadequate rollback • Auditor evaluates: • Effectiveness of implementation, not just process CISA Exam Focus CISA Exam Focus
22. Post-Implementation Review (PIR) Purpose • Assess whether the system: • Meets business objectives • Delivers expected benefits • Operates effectively and securely Key Areas Reviewed • Performance vs expectations • Cost vs budget • Benefit realisation (ROI) • User satisfaction • Operational stability What is Evaluated • Were requirements met? • Were timelines and budgets achieved? • Are controls functioning effectively? • Are there unresolved issues or risks? Common Findings • Gaps between expected vs actual outcomes • Control weaknesses • Inefficiencies in processes • User adoption challenges CISA Exam Focus • PIR = lessons learned + validation of success • Must be: • Formal • Documented • Action-oriented
23. The Auditor’s Role & Key Outcomes in PIR • Evaluate: • Whether objectives were achieved • Effectiveness of controls post-implementation • Accuracy of cost/benefit assumptions IS Auditor’s Role • System aligns with business objectives • Controls are: • Implemented • Operating effectively • Risks are: • Identified • Managed Auditor Must Verify • Lessons learned report • Improvement recommendations • Updated risk register • Control enhancements Key Outputs of PIR • Prevents repeating mistakes • Improves future project delivery • Strengthens governance and control environment Why PIR Matters • Auditor focuses on: • Effectiveness, not just completion • Key risk: • PIR skipped or treated as a formality CISA Exam Focus
24. Domain 3 in Practice – Controls & Evidence (COBIT Aligned) COBIT Audit Evidence Key Controls Scenario Risk Area APO02 / APO05 Approved business case, cost- benefit analysis, feasibility report Formal business case, feasibility study, approval process CRM selected without full analysis Business Case & Feasibility EDM02 / EDM05 Meeting minutes, status reports, escalation logs Steering committee oversight, reporting & escalation procedures No escalation of missed milestones Project Governance BAI02 Requirements documents, stakeholder approvals, traceability matrix Requirements gathering, validation, sign-off Incomplete requirements Requirements Definition BAI03 Sprint records, backlog, design documentation Defined SDLC / Agile framework, documentation standards Agile without controls/documentation Development Methodology BAI06 Design documents, control specifications, architecture diagrams Control design integrated into system architecture Controls added after deployment Control Design BAI07 UAT sign-off, test results, defect logs Formal UAT process, test plans, defect tracking Business processes not validated Testing (UAT) BAI06 Change requests, approvals, release logs, version history Change management, release approvals, segregation of environments Unauthorised changes Configuration & Release BAI07 Reconciliation reports, migration logs, data validation results Data validation, reconciliation, migration controls Data integrity issues Data Migration BAI07 Implementation plan, rollback plan, approval records Deployment planning, rollback procedures, go-live approvals No rollback plan Implementation MEA01 / MEA02 PIR report, lessons learned, updated risk register Formal PIR, performance evaluation, improvement tracking No lessons learned Post- Implementation Review
25. Domain 3 – Summary •Governance & Business Case •Strong project governance and accountability •Business case ensures value, feasibility, and risk alignment Key Focus Areas •Structured lifecycle: •Requirements → Design → Build → Test → Deploy → Review •Development methods (Agile, DevOps, etc.) must include controls SDLC & Development •Controls embedded across: •Input → Processing → Output •Ensures accuracy, completeness, and reliability Controls & Data Integrity •Comprehensive testing (UAT, security, performance) •Controlled migration and deployment •Rollback capability is critical Testing & Implementation •Validate: •Benefits realised •Controls effective •Capture lessons learned Post-Implementation Review •Evaluate: •Alignment to business objectives •Effectiveness of controls across SDLC •Key risks: •Weak requirements •Inadequate testing •Uncontrolled changes Auditor & Exam Focus
26. Domain 3 Exam Patterns Failures originate early (requirements) Testing failures = requirement failures Controls added late = design failure No review = no improvement Always trace root cause in lifecycle
27. Question 1 — Project Governance (3A1) A system implementation project continues despite repeated missed milestones and increasing costs, with no escalation to senior management.  What is the PRIMARY issue?  A. Weak testing procedures  B. Poor project governance  C. Inadequate system design  D. Ineffective vendor management
28. Answer & Explanation  Answer: B — Poor project governance  Why:  Governance = oversight + escalation  Failure to escalate = governance breakdown  Project failure is often governance failure
29. Q2: Question 2 — Business Case (3A2) An organisation selects a system without performing a cost-benefit or feasibility analysis.  What is the GREATEST risk?  A. System implementation delays  B. Selection of an inappropriate solution  C. Increased training requirements  D. Weak system performance
30. Answer & Explanation  Answer: B — Selection of an inappropriate solution  Root Cause: Poor decision-making  Wrong decision early = failure later
31. Q3 — 3A2 Feasibility A system is technically feasible but cannot be effectively used by operational teams.  Which feasibility area was MOST likely not considered?  A. Technical  B. Financial  C. Operational  D. Legal
32. Answer & Explanation  Answer: C — Operational  Why - Business usability  Technical success ≠ business success
33. Q4 — 3A3 Methodology An organisation adopts Agile development but lacks formal documentation and controls.  What is the PRIMARY concern?  A. Increased development speed  B. Lack of control and governance  C. Reduced system flexibility  D. Vendor dependency
34. Answer & Explanation  Answer: B — Lack of control and governance  Failure: Control gap  Agile ≠ no control
35. Q5: Risk  What is the PRIMARY risk associated with a direct (big bang) cutover?  A. Cost issue  B. Downtime risk  C. Data issue  D. Control issue
36. Answer & Explanation  Correct Answer: B  Highest risk implementation method  Why others are wrong:  Address symptoms, not root cause  Occur later in lifecycle  Not aligned to control failure
37. Q6: Controls  Unauthorised changes indicate a weakness in which control?  A. Documentation  B. Change control  C. Testing  D. Governance
38. Answer & Explanation  Correct Answer: B  No formal approval process  Why others are wrong:  Address symptoms, not root cause  Occur later in lifecycle  Not aligned to control failure
39. Q7: Requirements & Design  A system passes all testing phases but fails to meet user expectations after implementation. What is the MOST likely root cause?  A. Inadequate user training  B. Poor requirements definition  C. Weak system testing  D. Ineffective change management
40. Answer & Explanation  Correct Answer: B. Poor requirements definition Testing failures often trace back to requirements issues
41. Q8: Control Design  An organisation implements application controls after system deployment due to audit findings. What is the PRIMARY risk?  A. Increased  implementation cost B. Reduced system performance  C. Ineffective control integration  D. Delayed project delivery
42. Answer & Explanation  Correct Answer: C. Ineffective control integration Controls added late = design weakness
43. Q9: Testing  User acceptance testing (UAT) was skipped to meet project deadlines. What is the GREATEST risk?  A. Increased operational costs  B. System not meeting business requirements  C. Delays in future enhancements  D. Lack of technical documentation
44. Answer & Explanation  Correct Answer: B. System not meeting business requirements UAT = business validation, not technical testing
45. Q10: Migration & Cutover During system migration, data is transferred without reconciliation between old and new systems. What is the PRIMARY concern?  A. Performance degradation  B. Data integrity issues  C. Increased training effort  D. Vendor dependency
46. Answer & Explanation  Correct Answer: B. Data integrity issues No reconciliation = no assurance data is complete and accurate
47. Disclaimer PERSONAL LEARNING JOURNEY PERSONAL LEARNING JOURNEY BASED ON CURRENT UNDERSTANDING BASED ON CURRENT UNDERSTANDING OPEN TO INPUT AND DIFFERENT PERSPECTIVES OPEN TO INPUT AND DIFFERENT PERSPECTIVES I DO NOT REPRESENT ANY ORGANISATION I DO NOT REPRESENT ANY ORGANISATION ONE MAY USE THIS MATERIAL IF YOU WISH TO ALSO LEARN FROM THIS. ONE MAY USE THIS MATERIAL IF YOU WISH TO ALSO LEARN FROM THIS.