hardMultiple Choice
COTS Customization: Best Practice to Avoid Extensive Changes
A company plans to implement a commercial off-the-shelf (COTS) application and requires significant customization to match its unique business processes. The vendor advises against extensive customization because it may complicate future upgrades. What is the BEST course of action?
Quick Answer
The best course of action is to avoid customization and re-engineer business processes to match the COTS application, because this preserves the vendor’s standard codebase and ensures seamless application of future upgrades and patches. Extensive customization creates a forked version of the software, introducing costly regression testing, security vulnerabilities, and upgrade incompatibilities that erode the long-term value of the COTS investment. On the CISA exam, this scenario tests your grasp of the COTS customization best practice—specifically, the principle that organizations should adapt their workflows to the software rather than forcing the software to fit legacy processes. A common trap is selecting “customize only critical modules,” but auditors expect you to recognize that any significant deviation from the vendor baseline undermines upgrade integrity. Remember the memory tip: “Don’t fork the code—re-engineer the road.”
⚠ Common exam trap
Watch out — candidates often choose 'customize but document' (Option B) because it sounds like a balanced, pragmatic approach, but the CISA exam emphasizes that any customization that deviates from the vendor's standard configuration introduces unacceptable upgrade and maintenance risks, making process re-engineering the only truly sustainable choice.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Avoid customization and re-engineer business processes to match the COTS application
The best course of action is to avoid customization and re-engineer business processes to match the COTS application. This approach preserves the integrity of the vendor's standard codebase, ensuring that future upgrades and patches can be applied with minimal friction. Extensive customization creates a fork from the vendor's baseline, leading to costly regression testing, potential security gaps, and upgrade incompatibilities that undermine the long-term value of the COTS investment.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use the vendor's customization module to minimize upgrade risks
Why it's wrong here
A vendor customisation module still alters application code, so upgrades remain complicated; the module only standardises how changes are packaged. It is tempting because vendor-supported extension points are the correct choice when requirements genuinely cannot be met by configuration alone and the vendor commits to maintaining those extensions.
- ✗
Customize but maintain detailed documentation for upgrade impact analysis
Why it's wrong here
Documentation does not reduce the upgrade burden that extensive customisation creates; the vendor's warning concerns code divergence, not traceability. It is tempting because impact analysis is genuine change-management practice, and it would be the right choice where customisations are unavoidable and must be tracked across releases.
- ✗
Proceed with extensive customization to meet business needs
Why it's wrong here
Extensive customization forks the vendor's codebase, so future patches and upgrades require rework and regression testing against bespoke changes. The recommended path is adapting processes to the COTS product or selecting an alternative. Customization suits bespoke builds where the organisation owns the full lifecycle.
- ✓
Avoid customization and re-engineer business processes to match the COTS application
Why this is correct
Re-engineering business processes to align with the COTS application preserves the vendor's upgrade path, since unsupported modifications typically break patching and future releases. This satisfies the stem's constraint that extensive customization complicates upgrades, accepting process change as the trade-off for maintainability and vendor support.
Go deeper
Related to this question
About these practice questions
One of 934 original CISA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on CISA
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. An organization is implementing a COTS application. The project team plans to heavily customize the application to meet unique business processes. Which of the following is the most significant risk?
hard- A.Vendor lock-in
- B.Incompatibility with future releases
- ✓ C.Difficulties in applying future vendor upgrades
- D.High implementation cost
Why C: Heavy customization of a COTS application modifies its core code or configuration in ways that diverge from the vendor's standard product. When the vendor releases updates or patches, these customizations often conflict with the new code, making upgrades complex, risky, or even impossible without rework. This directly threatens the organization's ability to stay current with security fixes and new features, which is a critical operational and compliance risk. Thus, difficulties in applying future vendor upgrades is the most significant risk.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CISA practice question is part of Courseiva's free ISACA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CISA exam.