Asset Management and Configuration Control

What the Exam Is Really Testing

The practical skill this module tests is straightforward: can you secure an environment when you do not have a complete picture of what is in it? The answer, of course, is that you cannot. Every other security operation — vulnerability scanning, patching, incident response, compliance reporting — depends on knowing what assets exist and how they are configured.

You cannot protect what you do not know you have — and you cannot maintain security if configurations change without control.

Exam questions in this area often describe scenarios where something goes wrong specifically because an asset was unknown, unmanaged, or changed without approval. Asset management is not glamorous, but it is the foundation everything else sits on.

Asset Inventory

An asset inventory is a comprehensive record of every hardware device, software installation, and data repository in the organization. It answers the fundamental question: what do we have?

What Gets Inventoried

• Servers (physical and virtual)
• Workstations, laptops, and mobile devices
• Network equipment (routers, switches, firewalls, access points)
• Cloud resources (VMs, storage, SaaS subscriptions)
• IoT and operational technology devices
• Software licenses and versions
• Data stores and databases

CMDB (Configuration Management Database)

A CMDB is a centralized repository that stores information about IT assets and the relationships between them. It goes beyond a simple inventory list by tracking:

• Configuration items (CIs) and their attributes
• Dependencies between systems
• Ownership and responsibility assignments
• Location and classification
• Change history

The CMDB is critical for impact analysis during changes and incidents. If a server goes down, the CMDB tells you which applications and business processes are affected.

Tagging and Classification

Every asset needs metadata that answers:

• Who owns it? — Ownership assignment ensures accountability
• What data does it process? — Determines handling requirements
• How sensitive is it? — Classification (public, internal, confidential, restricted) drives control selection
• Where is it? — Physical and logical location
• What is its lifecycle stage? — Active, deprecated, decommissioned

Configuration Management and Change Control

Configuration Management

Configuration management ensures that systems are built and maintained according to approved standards. It includes:

• Documenting approved configurations (baselines)
• Tracking changes to configurations over time
• Detecting unauthorized changes (configuration drift)
• Automating configuration deployment (Infrastructure as Code, golden images)

Change Control

Change control is the formal process for requesting, reviewing, approving, and implementing changes to IT systems. A typical change control process includes:

1. Request — A change request is submitted with justification
2. Impact analysis — Assess risk and impact on dependent systems (this is where the CMDB is invaluable)
3. Approval — A Change Advisory Board (CAB) or change manager approves or denies
4. Implementation — The change is deployed during an approved window
5. Verification — Confirm the change works as expected
6. Documentation — Record the change for audit and rollback purposes

Change control prevents the most common cause of outages: unplanned, untested changes to production systems.

Version Control

Version control tracks changes to code, scripts, configurations, and documents over time. It enables:

• Rollback to known-good states
• Audit trails showing who changed what and when
• Collaboration without overwriting others' work
• Comparison between versions to identify drift or unauthorized changes

Asset Lifecycle

Every asset follows a predictable lifecycle. Security responsibilities exist at every stage:

Procurement

• Evaluate vendor security posture
• Verify supply chain integrity
• Negotiate security requirements in contracts
• Document the asset in the inventory before deployment

Deployment

• Apply the organization's secure baseline
• Assign ownership and classification
• Register in the CMDB with all dependencies
• Verify configuration before connecting to the network

Maintenance

• Patch management and updates
• Configuration monitoring and drift detection
• Periodic vulnerability scanning
• License renewal and compliance tracking

Disposal and Decommissioning

This is where many organizations fail. Disposal requires:

• Data sanitization — Overwriting data so it cannot be recovered (NIST SP 800-88 guidelines)
• Physical destruction — Shredding, degaussing, or incinerating drives when sanitization is insufficient for the data classification
• Certificate of destruction — Documented proof that data was properly destroyed, often required for compliance
• Inventory update — Remove the asset from the CMDB and active records
• License recovery — Reclaim software licenses for reuse

Shadow IT

Shadow IT refers to technology that employees deploy without IT department knowledge or approval. Common examples include:

• Personal cloud storage (Dropbox, Google Drive) for corporate files
• Unapproved SaaS applications
• Personal devices on the corporate network
• Departmental servers or databases managed outside IT

Shadow IT creates risk because these assets:

• Are not in the asset inventory
• Are not patched or monitored
• May not meet compliance requirements
• Create data leakage paths outside corporate controls
• Cannot be included in incident response or disaster recovery

The solution is not just prohibition — it is understanding why employees seek alternatives and providing approved tools that meet their needs.

Pattern Recognition

When you see asset management or configuration control questions, look for these patterns:

• Unknown devices on the network = asset inventory gap, not a firewall issue
• Systems drifting from their configuration = configuration management failure
• Uncontrolled changes causing outages = missing change control process
• Old equipment with sensitive data = disposal and sanitization question
• Employees using unapproved tools = shadow IT risk
• Impact analysis during incidents = CMDB dependency mapping

Trap Patterns

Watch for these distractors:

• "Block all unapproved applications" — Addresses the symptom of shadow IT, not the root cause
• "Format the hard drive" — Formatting does not securely sanitize data; it can often be recovered
• "The network team manages the inventory" — Asset management is an organizational responsibility, not a single team's
• "Scan for vulnerabilities" — You cannot scan what you do not know exists; inventory comes first

Scenario Practice

Question 1

During a vulnerability scan, several devices are discovered on the network that do not appear in the organization's asset inventory.

What should the security team do FIRST?

A. Immediately block the devices at the firewall
B. Identify and inventory the unknown devices, then assess their risk
C. Run a penetration test against the unknown devices
D. Notify law enforcement of a potential breach

Question 2

An organization is disposing of servers that previously stored customer financial records. The data is classified as confidential.

What is the MOST appropriate disposal method?

A. Format the hard drives and donate the servers
B. Delete all files and recycle the hardware
C. Physically destroy the drives and obtain a certificate of destruction
D. Overwrite the drives once and sell the servers

Question 3

A production database server experienced an outage after a configuration change was made by an administrator without prior approval.

What process failure does this represent?

A. Incident response failure
B. Change control failure
C. Vulnerability management failure
D. Access control failure

Key Takeaway

Asset management is not an administrative task — it is the foundation of every security control that follows. Without an accurate inventory, vulnerability scanning misses systems, incident response is slow, and compliance audits fail.

When you see asset-related questions on the exam, the answer usually comes back to four things: Do we know what we have? Is it configured correctly? Was any change approved through a formal process? And when an asset reaches end of life, is the data properly destroyed? If you do not control the inventory, you do not control the risk.