Domain 5 · Objective reference 5.4 · Chapter 18 of 19
Asset lifecycle, secure configuration and controlled change
About 6 minutes · ISC2 CC outline effective 1 September 2026
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: Know it before changing it.
Explore the anchors
Identify assets owners and dependencies.
Concept matching activity
Match this task or description to its concept:
Approve test and control modification.
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
- Know what exists and who owns it
- Control intended change and detect unintended drift
- A controlled patching cycle
Know what exists and who owns it
An asset inventory should connect devices, software, services, information, identities and important dependencies to owners and business purposes. Include short-lived cloud resources and automated tools as well as office equipment. A list without responsible owners or update processes becomes stale. Track supported versions and end-of-life or end-of-support conditions so risks can be addressed before routine maintenance becomes impossible.
Acquisition should include protection and support needs; deployment should use an approved configuration; operation should monitor changes and exposure; retirement should revoke access and handle residual data and records. An unsupported device is not automatically safe because it still functions. Plan replacement or appropriately owned temporary safeguards.
Control intended change and detect unintended drift
A baseline defines the approved state. Configuration management records and maintains that state; change management evaluates, approves, tests and tracks modifications. Include impact, dependencies, maintenance conditions, rollback or recovery and post-change verification. Emergency changes can use an expedited route, but still need authorization, recording and subsequent review.
Drift is a difference from the intended configuration. It can arise through error, untracked maintenance or malicious action and needs investigation. For AI-enabled systems, track the relevant model, configuration, data-source and access changes. A code rollback may not reverse a database or dataset change safely. Verify service behavior and monitoring after the approved change rather than declaring success when a deployment job ends.
A controlled patching cycle
Discover the affected assets and versions, evaluate exposure, prioritize with business context, test compatibility, authorize the change, deploy it under the approved conditions and verify the result. Keep an emergency route for urgent cases and a record of temporary safeguards where a patch cannot be applied immediately. A severity score helps triage but does not capture every deployment’s reachability or consequence.
Configuration management and change management are related but different: the former maintains knowledge and control of the intended state; the latter governs modifications to that state. An inventory helps establish which assets need the process. Post-change checks should validate the version or behavior, service operation and removal of temporary access. Closing a ticket is not the same as verifying the correction.
Worked example
A cloud administrator changes a storage permission during emergency support. The team records the authorized change, verifies the necessary access, removes temporary broad permissions and checks for drift against the approved baseline afterward.
Check your understanding
Why is a successful deployment pipeline insufficient evidence of a successful change?
Show explanation
It shows that its configured steps completed. It may not establish correct permissions, business behavior, compatibility, recovery capability or removal of temporary access. Post-change verification must address those intended outcomes.
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.