Asset Lifecycle, Configuration Management, and Change Management

Asset protection begins with a complete, accurate asset inventory. An asset is anything of value to the organization that needs protection: servers, laptops, mobile devices, network equipment, software licenses, virtual machines, cloud instances, and the data they hold. If a device or application is not in the inventory, nobody is patching it, monitoring it, or including it in risk assessments. Attackers actively look for exactly these forgotten systems, because an unknown asset is an undefended asset.

The guiding principle appears on the exam in almost those exact words: you cannot protect what you do not know you have. Every downstream security activity depends on the inventory. Vulnerability scans need a list of targets. Patch management needs to know which systems run which software. Incident responders need to know what a compromised host is, who owns it, and what data it touches. License compliance and budgeting depend on it too, but for the CC exam the security angle is what matters.

A useful inventory records more than a name. It typically captures the asset type, owner, location, operating system and software versions, classification of the data it handles, and its criticality to the business. Inventories should be kept current through regular reviews and, where possible, automated discovery tools that detect devices joining the network. A stale inventory is only slightly better than none: the unmanaged laptop that joined the network last month is precisely the asset most likely to be missing from a list compiled last year.

Assets are managed through a lifecycle: a sequence of stages with security responsibilities at each step. The exam expects you to recognize the stages and match activities to them.

Two ideas connect the stages. First, the inventory is updated at every stage, not just at acquisition: an asset that changes location, owner, or purpose gets its record updated, and a disposed asset is removed. Second, security is applied from the very beginning. A server that goes live before it is hardened and patched is exposed during exactly the window when attackers scan for fresh, defenseless systems. Building security in at deployment is far cheaper and safer than bolting it on after an incident.

Every product eventually reaches end of life (EOL), the point at which the vendor stops supporting it. The critical consequence for security is that no more security patches are released. When a new vulnerability is discovered in an EOL operating system, application, or device, it will never be fixed: the flaw is public, attackers can weaponize it at leisure, and the defender has no patch to apply. Over time the number of known, permanently unpatched vulnerabilities in an EOL product only grows.

The preferred response is to replace the asset with a supported version before the support date passes; lifecycle planning exists precisely so migrations are scheduled in advance rather than forced by surprise. When replacement is not immediately possible, for example a factory controller that runs only on an obsolete operating system, the asset should be isolated: segmented onto a restricted network, cut off from the internet, limited to the minimum necessary connections, and monitored closely. Isolation is a compensating measure while a replacement path is found, not a permanent answer. If an exam scenario mentions software that no longer receives updates, the expected concerns are unpatched vulnerabilities and the need to replace or isolate.

Retirement also demands secure disposal of stored data. Deleting files or reformatting a drive does not truly remove data; contents frequently remain recoverable with inexpensive tools. The media must be sanitized or destroyed first: overwriting (wiping) replaces the data with meaningless patterns and allows reuse, degaussing magnetically scrambles hard drives and tapes, and physical destruction such as shredding is the most certain method for the most sensitive data.

Finally, document the disposal, obtain a certificate of destruction when a third party destroys media, and update the inventory. Remember the less obvious media too: printers with internal drives, phones, and USB sticks all need the same care as a server drive.

Configuration management is the practice of establishing and maintaining systems in a known, secure, documented state. Its centerpiece is the secure baseline: an approved standard configuration for a given type of system that defines the operating system settings, installed software, enabled services, patch level, and security controls every system of that type must have. When a new server or laptop is deployed, it is built to the baseline rather than configured from scratch by whoever happens to set it up.

Creating a baseline usually involves hardening: reducing the attack surface by removing what is not needed and tightening what remains. Typical hardening steps include disabling unnecessary services and accounts, removing unneeded software, changing default passwords, closing unused network ports, enforcing strong authentication settings, and applying current patches. Default vendor configurations are built for easy setup, not for security, so a system running factory defaults is presumed weak. Many organizations base their baselines on published hardening guides and industry benchmarks rather than inventing every setting themselves.

Baselines deliver two security benefits. First, consistency: every system of the same type starts from the same secure state, so defenders are not reasoning about hundreds of unique snowflake configurations. Second, detectability: because the correct state is documented, any deviation from it can be identified. A machine that differs from its baseline is either misconfigured, changed without authorization, or possibly compromised, and each of those deserves attention. On the exam, associate the word baseline with a documented, approved, secure starting configuration.

Configuration drift is the gradual, unplanned divergence of a system from its approved baseline. It rarely happens through malice. An administrator opens a firewall port to troubleshoot an issue and forgets to close it. A developer installs a utility on a production server. A quick fix disables an agent that was slowing something down. Each individual tweak seems harmless, but over months the system no longer matches its documented configuration, and nobody knows exactly what state it is in.

Drift matters because it silently reopens the doors that hardening closed. The extra open port, the re-enabled service, the missed patch: these are exactly the weaknesses attackers scan for. Drift also breaks assumptions during incident response and troubleshooting, because responders act on documentation that no longer describes reality. A drifted environment is harder to defend, harder to audit, and harder to repair.

The defenses against drift are verification and discipline. Organizations periodically audit systems against their baselines, either manually or with automated compliance tools that continuously compare actual settings to the approved configuration and flag deviations. Detected deviations are investigated and either rolled back to the baseline or, if the change is genuinely needed, formally approved and incorporated into an updated baseline through change management. That last point links the two practices: configuration management defines the correct state, and change management is the only legitimate way that state gets modified. A change made outside that process is, by definition, drift.

Change management is a formal, documented process for making changes to systems in a controlled way, so that changes do not introduce vulnerabilities, break dependencies, or cause outages. The exam expects you to know the standard flow and its order.

Two supporting ideas recur in exam questions. A rollback plan (backout plan) defines how to return to the previous known good state if the change fails, and it is prepared before implementation, not improvised afterward. And documentation is part of the change itself: an undocumented change leaves the configuration records wrong, which is drift by another route.

An emergency change is the sanctioned exception for genuine urgency, such as patching a vulnerability that is being actively exploited or restoring a failed critical service. The change may be implemented first with expedited or verbal approval, but it is still reviewed, approved, and fully documented afterward. Emergency changes bypass the waiting, never the accountability. An answer choice suggesting that emergencies excuse skipping documentation or after the fact review is wrong.

Consider a concrete case. A database administrator gets a late night call: an application cannot reach its database. Under pressure, the administrator disables the host firewall on the database server, the application recovers, and everyone goes back to bed. No change request is filed, no one else is told, and the firewall stays off. Three months later, an attacker who has phished a workstation scans the internal network, finds the database listening with no host firewall, and exfiltrates customer records. The subsequent investigation takes days longer than it should, because the documented configuration says the firewall is enabled and responders trust the documentation.

Every failure in that story maps to this lesson. The fix bypassed change management, so it was never risk assessed; a reviewer would have insisted on opening one port rather than disabling the firewall entirely. It was never tested or given a rollback plan. It was never documented, so the baseline records became false, and the deviation sat undetected because baseline audits were not being run. One unmanaged change created a vulnerability, defeated the configuration records, and lengthened the incident response.

This is why unmanaged change is one of the leading causes of both security incidents and outages. Change management can feel like bureaucracy, but each step exists to catch a specific failure: review catches bad ideas, testing catches broken ones, scheduling contains the blast radius, and documentation keeps every later decision honest. When an exam scenario describes an outage or breach that followed an undocumented or unapproved modification, the expected diagnosis is a change management failure, and the expected remedy is enforcing the formal process, not punishing the technician or buying a new tool.

The three practices in this lesson are close neighbors, and the exam likes to test whether you can tell them apart. Use the questions each practice answers. Asset management answers: what do we have, who owns it, and where is it in its lifecycle? Configuration management answers: what state should each system be in, and does it still match that state? Change management answers: how do we modify that state safely? They interlock: the inventory lists the systems, the baseline defines their correct configuration, and the change process is the only approved way the configuration moves.

Watch for these trap patterns. A question about a device the security team did not know existed is an asset inventory question, not a monitoring question. A question about systems slowly deviating from their approved settings is configuration drift, answered by baseline audits, not by more patching. A question about a modification that caused an outage is change management. A question about software that no longer receives vendor patches is end of life risk, answered by replace or isolate, not by scanning it more often. And the ordering trap: in the standard change flow, testing happens before implementation, and approval happens before testing effort is spent building out the change; only an emergency change inverts the order, and even then documentation and review still happen afterward.

Finally, remember the lifecycle bookends. Security starts at acquisition, when the asset enters the inventory, and does not end until disposal, when its data is sanitized or destroyed and the inventory is updated. An asset that skips either bookend is a risk the organization cannot see.