System Acquisition and Vendor Selection
Buying software moves the coding risk to the vendor. Every other risk stays with you.
Most Indian organisations buy rather than build: a core banking system, an ERP, a payroll package, a cloud HR suite. Buying moves the coding risk to the vendor but keeps every other risk at home. The organisation still has to define what it needs, pick the vendor on evidence, protect itself if the vendor fails, and test the package before trusting it with its books.
DISA Module 3 covers acquisition inside the SDLC, not as a separate process. The feasibility study produces the build-or-buy decision, analysis covers the vendor proposals, and testing and implementation apply to purchased software just as they do to in-house code.
You save ₹450
- Full-length timed mocks
- Module-wise practice
- Emerging-tech coverage
One payment, no subscription · Valid for 2 months
The Acquisition Route, Step by Step
- 1
Feasibility study and business case
Technical, economic and social feasibility decide between building, buying or a mix. ICAI's own chapter-end answer places the build-or-buy decision here.
- 2
Documented requirements
Business and functional requirements, including control and security requirements, written before any vendor is approached.
- 3
Request for proposal (RFP)
Requirements go to enough vendors to cover the true scope. Module 3 asks the auditor to check that an appropriate number of vendors were invited.
- 4
Evaluation
Responses scored against the requirements; demonstrations or a proof of concept on the organisation's own scenarios; reference checks with existing users.
- 5
Contract
Scope, service levels, support, licence terms, escrow, data ownership and exit terms agreed and signed.
- 6
Configuration and acceptance
The package is configured, then put through UAT in a secure test environment before a formal sign-off.
- 7
Ongoing vendor updates
Patches and new versions are reviewed for impact and tested through change management before they reach production.
What Drives the Choice of Package
Module 1 lists the parameters an organisation should weigh when selecting business application software:
- check_circleThe business goal and the nature of the business: a petrol pump's daily cash differs from a distributor's credit sales
- check_circleGeographical spread: round-the-clock availability and multi-currency accounting for a company operating abroad
- check_circleTransaction volume, with headroom for the next few years
- check_circleThe regulatory structure: a package that already handles the compliance the business faces is worth more
Terms to Know
- Software escrow
- An arrangement where the vendor deposits source code and supporting material with a neutral escrow agent, released to the customer if the vendor fails to support the product.
- Deposit materials
- What goes into escrow: source code for each licensed version, manuals not otherwise supplied, maintenance tools and utilities, compilation instructions, and names of key technical staff the customer could engage.
- Proof of concept (POC)
- A limited trial of the product on the buyer's own scenarios before the decision, to test claims made in the proposal.
- Component-based development
- Buying only the components needed and building the rest around them; Module 3 presents it as a compromise between build and buy.
Quick practice on audit concepts. No signup.
Where Acquisition Audits Find Problems
A co-operative bank choosing a core banking vendor, or a mid-size manufacturer choosing an ERP that must generate GST-compliant invoices, tends to fail in the same places. Requirements are written after the favoured vendor's demo, so the RFP describes one product. The evaluation sheet scores features but not controls such as audit trails, role-based access and maker-checker workflows. The contract has no escrow and no exit clause covering return of data. And because the package is "proven", UAT is cut short.
Module 3 is explicit that UAT applies to software developed in-house, by an outsourced team, or purchased and configured by a vendor. It also warns that licence agreements often forbid reverse engineering, so the customer cannot fall back on decompiling the product if the vendor disappears. That is the gap escrow exists to fill.
How the DISA Assessment Test Tests This
Questions here tend to test what a control protects against, and which phase owns a decision.
- check_circleEscrow protects continuity of support if the vendor fails; it is not a quality or performance guarantee
- check_circleThe build-or-buy decision comes out of the feasibility study
- check_circleNon-availability of skilled resources is the primary reason to outsource development, per ICAI's own answer
- check_circleUAT is still required for packaged software; the trap answer says the vendor's testing is enough
- check_circleVendor patches go through the organisation's change management, not straight to production
FAQs
What is software escrow and why does an auditor check it?expand_more
Escrow places the vendor's source code and support material with a neutral agent, released to the customer if the vendor stops supporting the product. The auditor checks it exists and that the deposit is kept current, because without it a critical system can become unmaintainable.
Which SDLC phase decides whether to build or buy software?expand_more
The feasibility study. It weighs technical, economic and social feasibility, and the business case built on it carries the decision.
Is user acceptance testing needed for off-the-shelf software?expand_more
Yes. ICAI's Module 3 applies UAT to purchased and vendor-configured software as well as in-house builds, because configuration and business processes are specific to the buyer.
What should an IS auditor review in a vendor selection?expand_more
That requirements were documented before vendors were approached, enough vendors were invited, evaluation criteria included controls and security, the choice was approved, and the contract covers support, escrow and exit.
Next steps
- SDLC Phasesarrow_forward
- Outsourcing Riskarrow_forward
- ERP Auditarrow_forward
- Data Migrationarrow_forward
Assessment Test format, timed and scored.