Domain 8 · Objective reference 8.4 · Chapter 61 of 62
Evaluate acquired and managed software
About 5 minutes · Current ISC2 outline effective 15 April 2024; the announced 15 April 2027 replacement requires separate mapping
Session only. Enable saving or download a backup from this course’s hub.
Completion is self-reported and does not certify understanding.
See it · Try it · Recall it
Picture the topic
Remember this: Buying software also buys dependencies and obligations.
Explore the anchors
Assess security requirements and supplier evidence.
Concept matching activity
Match this task or description to its concept:
Validate configuration support and contractual needs.
Choose a concept before checking the explanation.
A quick way to study this topic
- Hide the explanation and redraw these three anchors from memory.
- Explain the difference between the anchors in your own words.
- Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
- Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.
Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.
What this chapter explains
- Concepts and mechanisms
- Design, evidence and tradeoffs
- Acquire evidence for the actual service
Concepts and mechanisms
Commercial, open-source, third-party, cloud and managed software create different assurance and responsibility relationships. Evaluate suitability, provenance, licensing, component exposure, support, update behavior and integration. Open source is not automatically secure because it is visible, and commercial software is not automatically secure because it is purchased. A supplier assurance report has a scope and period.
Design, evidence and tradeoffs
Consider administrative access, data handling, telemetry, recovery, exit and subservice dependencies. Review new versions and material supplier changes. Assess retained customer configuration and authorization duties. For AI-assisted components or models, include approved use and provenance without assuming a confident output proves correctness. Validate the actual deployment and its required properties rather than generalizing from the supplier’s reputation.
Acquire evidence for the actual service
Commercial software, open-source packages, third-party components, managed applications and SaaS/PaaS/IaaS services have different responsibility boundaries. Evaluate the actual version, configuration, support lifecycle, update process, data handling and contractual evidence. Open source permits inspection under its license but does not guarantee independent review; a commercial contract does not guarantee defect-free code. Assess what the supplier does, what remains with the customer and how changes or incidents are communicated before accepting the residual risk.
Worked example
A managed application’s report excludes customer-side access reviews; the customer supplies that evidence instead of treating the report as a complete pass.
Check your understanding
Why should assurance for one supplier product not be applied automatically to another?
Show explanation
The service scope, implementation, dependencies, period and retained responsibilities can differ.
Source and study boundary
Official syllabus source. The reference identifies the topic being taught. Explanations and examples are original academy material; a topic link does not establish independent approval or sufficient exam mastery.