# Information Systems Acquisition and Development

> Chapter 8 of the Courseiva ISACA-CISA curriculum — https://courseiva.com/learn/isaca-cisa/information-systems-acquisition-and-development

**Official objective:** 3.1 — Evaluate the processes for acquiring and developing information systems.

## Introduction

Domain 3 of the CISA exam covers 'Information Systems Acquisition, Development and Implementation'. This chapter focuses on how organisations get new software and systems — whether they build it themselves, buy it from a vendor, or customise an existing product. For a CISA candidate, understanding this process is critical because a poorly managed systems acquisition is one of the most common causes of project failure, security vulnerabilities, and wasted budget.

## The Renovating a House Analogy

Have you ever watched someone try to fix a leaky tap by just putting a bucket under it, rather than actually replacing the washer? That short-term fix works for a while, but eventually the floor rots. Acquiring and developing an information system is exactly like deciding to renovate your house from scratch.

You start with a clear need: your family is growing, and you need an extra bedroom (the business requirement). You don't just call a builder and say 'add a room' — you first research what kind of room you want, what it must cost, and how long you can wait. That's the 'feasibility study'. Then you write a plan with detailed blueprints — the 'system requirements specification'. Only then do you decide: do we build it ourselves (in-house development) or hire a specialist firm (buy an off-the-shelf system)? If you hire a builder, you sign a contract that says exactly when they'll finish, what materials to use, and who checks the quality (contract management and vendor management). While they build, you visit the site weekly to make sure walls are straight and wiring is safe — that's 'quality assurance' and 'user acceptance testing'. When the room is finished, you move the furniture in, train your kids to use the new space, and throw out the old broken wardrobe. That's 'implementation' and 'data migration'. If you skip any step — say, you never test that the windows open before the builder leaves — you end up with a cold, useless room. The same happens with IT systems: the whole process must be controlled, documented, and audited, otherwise the system fails and you waste thousands.

## Core explanation

When a business decides it needs a new information system — say, a customer relationship management (CRM) system to track sales leads — it doesn't just go to a shop and buy one. There is a formal, structured process called the 'systems development life cycle' (SDLC). The SDLC is a project management framework that breaks building or buying an IT system into phases. Each phase has specific deliverables — documents, approvals, or working code — that must be completed before moving to the next stage. The standard phases are: feasibility, requirements, design, development (or procurement), testing, implementation, and maintenance.

Let us define the key terms you will see in the exam. 'Feasibility study' is the first formal step: it asks whether the proposed system is technically possible, financially worthwhile, and operationally practical. It produces a 'business case' that compares the expected costs against the expected benefits. If the business case is approved, the next step is 'requirements gathering'. Here, analysts interview the people who will actually use the system (the 'end users') to find out exactly what the system must do. These are documented as 'functional requirements' (what the system does, like 'generate an invoice') and 'non-functional requirements' (how it does it, like 'respond in under two seconds').

After requirements are confirmed, the organisation must decide whether to build or buy. 'In-house development' means writing custom software from scratch using the company's own programmers. 'Commercial off-the-shelf (COTS)' software is a pre-built product you buy and install — like Microsoft Office or Salesforce. There is also 'customisation', where you buy a COTS product and then hire a consultant to modify it to fit your needs. Each option has advantages: in-house gives full control but is slower and more expensive; COTS is cheaper and faster but may not fit perfectly; customisation sits in between but creates a dependency on the vendor.

If the organisation chooses to buy, it must go through a 'procurement process'. This involves sending a 'request for proposal' (RFP) to multiple vendors, evaluating the responses, negotiating a contract, and signing a 'service level agreement' (SLA). The SLA is a critical document that specifies exactly what the vendor must deliver — uptime percentage, response time for support, and penalties if they fail. If the organisation chooses to build, it enters the 'design phase', where architects create detailed technical blueprints showing how the software components fit together.

The next phase is 'development' (coding) or 'configuration' (setting up the bought software). Then comes 'testing', which has multiple levels:
- Unit testing: each small piece of code is tested alone.
- Integration testing: pieces are combined to see if they work together.
- System testing: the whole system is tested in a realistic environment.
- User acceptance testing (UAT): actual end users test the system to confirm it meets their needs.

After testing passes, 'implementation' happens. This can be done via different strategies:
- Direct cutover: the old system is turned off, and the new one is turned on.
- Parallel running: both old and new systems run together for a while.
- Phased approach: the new system is rolled out one module or location at a time.
- Pilot approach: the new system is installed in one location first, then scaled.

Finally, the system enters 'maintenance'. This is not just fixing bugs; it includes 'change management' — a formal process for making any modifications, because even a small change can introduce security holes or break existing features. Throughout the entire life cycle, the auditor's role is to check that each step was followed properly, that documentation exists, that approvals were given by the right people, and that risks were identified and managed. This is why CISA cares: a system built without proper controls is a security and compliance disaster waiting to happen.

## Real-world context

Consider a mid-sized retail company, 'ShopWell', that wants to replace its ancient inventory system. The old system runs on a server in the basement, crashes twice a week, and cannot calculate stock levels across multiple stores in real time. The IT director – a real person with a real job – leads the acquisition process.

First, she calls a meeting with stakeholders: the warehouse manager, the chief financial officer (CFO), and three store managers. They agree that the new system must show live stock counts for all 15 stores, send automatic reorder alerts when stock is low, and integrate with the existing accounting software. These are the 'requirements'. The IT director writes a one-page 'feasibility study' showing that a cloud-based inventory system will cost £50,000 per year but will save £80,000 per year in lost sales and manual labour. The CFO approves the budget.

Next, she drafts a 'request for proposal' (RFP) and sends it to three vendors: CloudStock, OnPremInventory, and QuickShelf. The RFP lists all the requirements and asks each vendor to propose a solution and a price. The vendors submit their proposals. The IT director and the warehouse manager score each proposal using a 'weighted evaluation matrix' — they assign points for price, fit with requirements, vendor reputation, and support terms. CloudStock wins because it offers the best integration with their accounting software.

Now the 'contract negotiation' happens. The IT director works with the company's lawyer to draft a 'service level agreement' (SLA) that guarantees 99.9% uptime, four-hour response to critical bugs, and a penalty of £1,000 for every hour of downtime beyond that. The contract also includes a 'right to audit' clause, meaning ShopWell can send an auditor to inspect CloudStock's security practices.

During 'implementation', the IT director chooses a 'phased approach': first, they roll out the inventory system in the three largest stores, test it for two weeks, then roll it out to the remaining twelve stores one by one. This minimises risk — if the system fails, only one store is affected, not all 15. The warehouse manager runs 'user acceptance testing' (UAT) by having five store employees use the system for a week and report any problems. CloudStock fixes the reported bugs before the full rollout.

After go-live, the system enters 'maintenance mode'. The IT director schedules monthly 'change control board' meetings where any proposed modification — like adding a new field for 'expiry date' — must be reviewed, approved, and tested before being deployed to the live system. As the CISA auditor, you would come in at this point and ask to see the meeting minutes, the test results, and the signed approval forms. You would check that no unauthorised changes were made and that the vendor's access to the system was logged and monitored.

## Exam focus

The CISA exam tests 'Information Systems Acquisition and Development' very specifically. This is not a general software engineering test — it is an audit and control test. The examiners want you to know the correct order and sequence of SDLC phases, the key documents produced at each phase, and the auditor's responsibilities at each point.

Here are the exact concepts they love to test:

- The order of SDLC phases: feasibility -> requirements -> design -> development/procurement -> testing -> implementation -> maintenance. They will give you a scenario and ask: 'What should happen next?' If the scenario describes a project that has just completed the feasibility study, the correct answer is always 'conduct detailed requirements analysis', not 'start coding' or 'sign the contract'. You must know the sequence cold.

- 'Business case' vs. 'feasibility study': the feasibility study is the overall analysis; the business case is the document that contains the cost-benefit analysis. The exam may ask: 'What document justifies the investment in a new system?' Answer: the business case.

- 'Functional' vs. 'non-functional' requirements: they will give you a list and ask which one is functional (describes a specific behaviour) or non-functional (describes a quality attribute like performance or security). A common trap is listing a feature as functional when it is really about capacity.

- 'Request for proposal (RFP)' vs. 'request for quotation (RFQ)': an RFP asks for a detailed solution; an RFQ asks only for a price. If the buyer already knows exactly what they want, they use an RFQ. If they want vendors to propose creative solutions, they use an RFP.

- 'Service level agreement (SLA)' content: they love to test what an SLA must include – uptime targets, penalties, response times, and security requirements. A trap question might list 'price per user' as part of the SLA, but that belongs in the contract, not the SLA.

- 'User acceptance testing (UAT)': they will test who performs UAT (end users, not developers) and what it validates (that the system meets business requirements, not that the code is bug-free). A common wrong answer is 'UAT validates technical performance' — that is what system testing does.

- Implementation strategies: you must know the four main strategies (direct cutover, parallel, phased, pilot) and the risk level of each. Direct cutover is highest risk; parallel running is lowest risk but most expensive. They might give a scenario: 'A bank is migrating to a new core banking system. Which implementation method minimises financial risk?' The answer is parallel running.

- 'Change management' vs. 'configuration management': change management controls changes to the live system after it is in production; configuration management tracks the state of all system components (versions, patches, settings). The exam may ask: 'After implementation, what process should govern modifications?' Answer: change management.

- 'Waterfall' vs. 'Agile' methodologies: the exam expects you to know that waterfall is a linear, phased approach with strict documentation, while Agile is iterative, builds in short cycles (sprints), and relies on continuous user feedback. Agile requires strong requirements management and user involvement throughout, but it still needs controls – the auditor must verify that each sprint's deliverables are tested and approved.

- Trap pattern: they will try to trick you into selecting 'skip testing to save time' or 'implement all features at once' as the answer. Never choose any option that bypasses controls, documentation, or approval. The correct answer always involves a formal, documented, controlled process.

- Key definitions to memorise: 'governance' (who makes decisions and approves), 'due diligence' (researching a vendor before signing), 'post-implementation review' (evaluating whether the system achieved its expected benefits). The post-implementation review is a favourite exam topic — it happens after the system is stable, not immediately after go-live.

## Step by step

1. **Feasibility Study** — The organisation evaluates whether the proposed system is technically possible, financially viable, and operationally practical. A business case is created to compare costs and benefits. If approved, the project proceeds.
2. **Requirements Gathering and Analysis** — Business analysts interview stakeholders and end users to document exactly what the system must do (functional requirements) and how it must perform (non-functional requirements). These are written into a formal requirements specification.
3. **Build-or-Buy Decision** — The organisation decides whether to develop the system in-house, purchase a commercial off-the-shelf (COTS) product, or customise an existing product. This decision is based on cost, time, and fit with requirements.
4. **Vendor Selection and Contracting (if buying) / Design and Development (if building)** — If buying, the organisation issues an RFP, evaluates responses, negotiates an SLA, and signs a contract. If building, architects create technical designs and developers write the code. Both paths produce a system ready for testing.
5. **Testing and User Acceptance** — Multiple levels of testing are performed: unit, integration, system, and finally user acceptance testing (UAT). UAT is done by end users to confirm the system works for their business processes. All defects must be resolved before moving on.
6. **Implementation (Go-Live)** — The new system is deployed into the live production environment. The organisation chooses an implementation strategy (direct cutover, parallel, phased, or pilot) based on risk tolerance and business needs. Data is migrated from the old system.
7. **Post-Implementation Review and Maintenance** — After the system has been running for a few months, a formal review assesses whether it achieved its expected benefits. Ongoing maintenance includes change management, bug fixes, and updates, all governed by a formal control process.

## Comparisons

### Feasibility Study vs Business Case

**Feasibility Study:**
- Broader analysis of technical, operational, and financial viability
- Produces a recommendation of whether to proceed
- Includes risk analysis and alternative solutions

**Business Case:**
- Specific document within the feasibility study
- Focuses on cost-benefit justification to secure funding
- Contains quantitative financial projections (ROI, payback period)

### RFP (Request for Proposal) vs RFQ (Request for Quotation)

**RFP (Request for Proposal):**
- Asks vendors to propose a solution and approach
- Used when requirements are not fully defined
- Evaluates both technical creativity and price

**RFQ (Request for Quotation):**
- Asks for a price quotation on a predefined specification
- Used when requirements are fully specified
- Evaluates price only, not technical approach

### Parallel Running vs Direct Cutover

**Parallel Running:**
- Old and new systems run simultaneously
- Lowest risk of operational disruption
- Highest cost due to duplicate operations

**Direct Cutover:**
- Old system is turned off and new system is turned on immediately
- Highest risk of operational failure
- Lowest cost and fastest transition

### System Testing vs User Acceptance Testing (UAT)

**System Testing:**
- Performed by IT/QA team
- Tests technical performance and code quality
- Occurs before UAT in the SDLC

**User Acceptance Testing (UAT):**
- Performed by end users
- Tests business processes and fit to requirements
- Occurs after system testing and before go-live

### Change Management vs Configuration Management

**Change Management:**
- Controls the process of making changes to a live system
- Involves approval, testing, and documentation of changes
- Focuses on who can approve, when, and how

**Configuration Management:**
- Tracks the state of all system components (versions, patches, settings)
- Maintains a baseline of the system's current configuration
- Focuses on what the system contains at any point in time

## Diagram

_The standard SDLC flow for acquiring and developing information systems, from feasibility through maintenance._

```mermaid
flowchart TD
    A[Feasibility Study] --> B[Requirements Gathering]
    B --> C{Build or Buy?}
    C --> D[In-House Development]
    C --> E[Purchase COTS]
    D --> F[Design & Code]
    E --> F
    F --> G[Testing & UAT]
    G --> H[Implementation]
    H --> I[Post-Implementation Review]
    I --> J[Maintenance & Change Management]
```

## Common misconceptions

- **Misconception:** Building software from scratch in-house is always cheaper than buying commercial software. **Reality:** In-house development is usually more expensive because you pay for programmers, project management, testing, and ongoing maintenance. COTS spreads these costs across all buyers, so it is often cheaper unless you need highly specialised features. (People assume 'do it ourselves' means saving on vendor profit margins, but they forget the hidden costs of labour, training, and long-term support.)
- **Misconception:** Once the system is implemented and running, the acquisition process is completely finished. **Reality:** The process includes a 'post-implementation review' to evaluate if the system meets its objectives, and ongoing maintenance and change management continue for the system's entire life. Acquisition does not end at go-live. (In everyday language, 'acquiring' something ends when you own it. But in IT auditing, acquisition includes all activities from planning through the first major operational review.)
- **Misconception:** User acceptance testing (UAT) is done by the IT team to make sure the code has no bugs. **Reality:** UAT is performed by actual business end users to confirm the system works the way they need it to in their daily work. It tests business processes, not code quality. Bug detection is done in system testing before UAT starts. (The word 'testing' makes people think of technical quality assurance. But UAT is a completely different type of test focused on business fit, not technical accuracy.)
- **Misconception:** A feasibility study and a business case are the same thing. **Reality:** A feasibility study is the broader analysis of whether the project is possible (technical, operational, financial). The business case is a specific document within that study that details costs and benefits to justify the investment. The feasibility study produces the business case, but they are not identical. (The terms are used loosely in casual conversation. The exam marks them as distinct phases and documents.)
- **Misconception:** An RFP (request for proposal) is the same as a purchase order. **Reality:** An RFP is an invitation for vendors to submit their proposed solution and price — it is part of the evaluation phase. A purchase order is issued only after a vendor is selected and the contract is signed. They occur at completely different stages. (Both involve paperwork and vendors, so beginners lump them together. But the RFP is pre-selection, the purchase order is post-selection.)

## Key takeaways

- The phases of the systems development life cycle are always executed in a specific order: feasibility, requirements, design, development/procurement, testing, implementation, and maintenance.
- A business case is the document that justifies the investment by comparing expected costs against expected benefits; it is part of the feasibility study.
- User acceptance testing is performed by end users to validate that the system meets business requirements, not by the IT team to find technical bugs.
- Parallel running is the safest implementation strategy for high-risk systems because the old and new systems run simultaneously until the new one is proven stable.
- An SLA (service level agreement) defines measurable performance targets, penalties for non-compliance, and response times — it is not a pricing document.
- Change management must be formally established before the system goes live, and any post-implementation modification must be approved, tested, and documented through that process.

## FAQ

**Do I need to memorise the order of SDLC phases for the CISA exam?**

Yes. The exam tests the correct sequence frequently. Practise the order: feasibility, requirements, design, development/procurement, testing, implementation, maintenance.

**What is the difference between an RFP and an RFQ?**

An RFP (request for proposal) asks vendors to propose a solution and price, while an RFQ (request for quotation) asks only for a price on a predefined solution. Use an RFP when you don't know the best approach; use an RFQ when you already know exactly what you need.

**Who performs user acceptance testing?**

End users from the business side perform UAT, not the IT or quality assurance team. They test real business scenarios to confirm the system meets their needs.

**Is parallel running always the best implementation method?**

No. Parallel running is the safest but also the most expensive because both systems run at the same time. It is best for high-risk systems like banking or healthcare. For lower-risk systems, a phased or direct cutover approach may be more cost-effective.

**What is a post-implementation review and when is it done?**

A post-implementation review is an evaluation conducted after the system has been operational for a period (usually a few months) to check if it achieved its intended benefits and to identify lessons learned for future projects.

**Does the CISA exam cover Agile methodologies?**

Yes, but only at a high level. You need to know that Agile is iterative with short sprints, requires constant user feedback, and still needs control over changes, testing, and documentation — just like waterfall. The exam will test whether you recognise that Agile does not eliminate the need for formal controls.

## Check your understanding

1. **What is the first phase of the systems development life cycle?**

   Answer: The feasibility study, which determines whether the proposed system is technically, operationally, and financially viable.

2. **Who is responsible for performing user acceptance testing (UAT)?**

   Answer: End users from the business side, not the IT team. They validate that the system meets their business needs.

3. **What document should an organisation issue when it knows exactly what it wants to buy and only needs pricing from vendors?**

   Answer: An RFQ (request for quotation), not an RFP.

4. **Which implementation strategy carries the highest risk of operational failure?**

   Answer: Direct cutover, because the old system is immediately switched off and the new system takes over with no fallback.

5. **After a system is implemented, what process governs any modifications to the live system?**

   Answer: Change management, which requires formal approval, testing, and documentation before changes are deployed.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/isaca-cisa/information-systems-acquisition-and-development