Asset management, from purchase order to certificate of destruction

Objective 4.2 is about the life of an asset -- hardware, software or data -- from the moment someone decides they need it to the moment it is proven gone. The verb is explain: you are expected to say why each stage matters to security, not to run a procurement department. It is an objective people skim, and almost everything else in this domain quietly depends on it.

Why this matters

Every other control in Security Operations assumes you know what you have. You cannot patch, scan, harden, monitor or back up a system you do not know exists -- and the asset nobody knows about is the one that is unpatched, unmonitored and still running with a default password.

That is not a hypothetical. "How did they get in?" is answered by a forgotten server often enough that inventory is genuinely a frontline control. The exam treats it that way, and the disposal end produces its own category of breach: data leaving the building on hardware somebody thought was empty.

The lesson

Planning, scoping and procurement: security entering before the purchase

The life cycle starts before anything is bought. Planning and scoping is deciding what is needed, for what purpose, holding what data, and for how long. That is the cheapest moment for security to take part, because once the money is spent every objection competes with a signed contract.

Questions that belong in planning:

• What data will this asset hold or process, and how is that data classified?
• How long will the vendor support it, and how often will it be patched?
• How does it authenticate users, where does it send its logs, and what does it encrypt?
• What happens to it, and to the data in it, at the end of its life?

Acquisition and procurement then turns those answers into requirements:

• Security requirements appear in the request, not as an afterthought.
• Vendor assessment -- the third-party risk work in lesson 44 -- is done before selection rather than after an incident.
• Ownership is assigned at purchase, so the asset has a responsible person from day one rather than being discovered ownerless in four years.
• The asset is recorded in the inventory as it arrives, not when someone gets round to it.
• Provenance matters for hardware: buying through authorised channels reduces the counterfeit and tampering risk covered in the supply chain material of Domain 2.

The failure the exam describes: a department buys a SaaS product on a credit card, nobody assesses the vendor, nobody records the asset, the data in it is not classified, and nobody closes the account when the project ends. That is shadow IT arriving through procurement, and the control is a purchasing process that routes technology spend past security.

Assignment, ownership, classification and inventory

Assignment and accounting covers what must be recorded for every asset so that someone answers for it.

• Owner -- the person accountable for the asset: its classification, who may access it, and the decision to retire it. Ownership is a role, not a location.
• Custodian or steward -- whoever operates or maintains it day to day. The custodian implements what the owner decides, and confusing the two is how decisions end up being made by whoever happens to administer the box. Lesson 26 covers these data roles in full.
• Classification -- the data classification from lesson 25, applied to the asset, so that handling requirements follow it.

The inventory itself needs to cover three asset types, and organisations routinely do the first well and the others badly:

• Hardware -- servers, workstations, mobile devices, network equipment, IoT, and removable media.
• Software -- installed applications, versions, licences, and dependencies. This is where a software bill of materials earns its keep: when a widely used library turns out to be vulnerable, the SBOM answers "are we affected?" in hours instead of weeks.
• Data -- what data exists, where it lives, who owns it, how it is classified, how long it is kept. Usually the weakest of the three, and the one that determines breach notification obligations.

An inventory is only useful if it is current, which means it is maintained automatically wherever possible -- discovery scans, agent reporting, cloud API enumeration -- and reconciled against the manual record. A spreadsheet updated annually describes last year.

Monitoring, asset tracking and enumeration

Enumeration is finding what is actually there, as opposed to what the inventory claims. The two always disagree, and the gap is the interesting part.

Methods: network discovery scanning, authenticated agent reporting, DHCP and DNS records, cloud provider APIs, switch MAC address tables, and -- for shadow IT -- egress traffic and expense records.

Tracking follows an asset through its life: who holds it, where it is, what state it is in. For portable hardware this is a real control, because a laptop whose whereabouts are unknown is a potential data breach that nobody has reported. Asset tags, check-out records and MDM location reporting all serve it.

Monitoring here means noticing change: a new device on a segment where new devices should not appear, an asset that has stopped reporting, software installed that is not on the approved list, a device that has not checked in for patching in ninety days.

That last one deserves emphasis because it is quietly one of the most valuable alerts an organisation can build. A managed device that stops reporting has either been decommissioned without anyone telling the inventory, or it is still running and has fallen out of management -- and the second case is an unpatched, unmonitored machine on your network.

Sanitisation, destruction, certification and data retention

Disposal and decommissioning is where asset management becomes a breach prevention control.

Sanitisation methods, and which is appropriate:

• Wiping or overwriting -- writing over the data. Effective on traditional magnetic drives. Less reliable on SSDs, because wear levelling means the controller may not overwrite the physical cells that held the old data.
• Cryptographic erase -- where the drive was encrypted from the start, destroying the key renders the data unrecoverable at once. This is the practical answer for SSDs and for cloud storage, and it is why full-disk encryption from day one pays for itself at disposal.
• Degaussing -- a strong magnetic field destroying the data on magnetic media. It does not work on SSDs, which store data as electrical charge rather than magnetism -- a favourite exam distinction.
• Physical destruction -- shredding, crushing, incineration, pulverising. The most certain, and expected for the most sensitive data.

Certification is the evidence: a certificate of destruction from the disposal vendor, recording what was destroyed, by what method, when, and witnessed by whom. Without it you have a vendor's assurance and nothing to show an auditor or a regulator.

Note what is not sufficient, because the exam tests it: deleting files, a quick format, or "the vendor said they'd handle it". And remember the non-obvious assets -- printers and multifunction devices with internal drives, network appliances holding configurations and keys, backup tapes, and phones.

Data retention is the other half. Keep data as long as it is needed and as long as law requires, and no longer:

• keeping it too long enlarges every breach and increases discovery cost and privacy exposure;
• deleting it too early breaches regulatory retention requirements or destroys evidence;
• and a legal hold overrides the schedule entirely -- once litigation is anticipated, deletion of relevant data stops, whatever the policy says. Legal hold is examined with compliance in lesson 45.

The decommissioned asset that still holds data, which is the exam's favourite

The scenario appears in some form on most attempts. A system is retired, and some part of it continues to exist with data on it.

The common cases:

• a server is powered off and left in a rack for two years, still holding production data, still cabled, still with an account in the directory;
• virtual machines are deleted and their snapshots and backups are not -- retention outlives the system;
• a cloud instance is terminated and its storage volume, or a snapshot of it, persists and is later attached to something else, or made public;
• a decommissioned device's DNS entry remains pointing at an address or cloud resource that someone else can later claim -- subdomain takeover;
• an application is retired and its service account, API keys and third-party integrations stay live indefinitely.

A complete decommissioning therefore covers more than the hardware: sanitise or destroy the data including backups and snapshots; revoke accounts, keys and certificates; remove DNS records, firewall rules and monitoring entries; cancel the vendor contract and remove the integration; and update the inventory, so the asset is recorded as gone rather than silently absent.

The exam's expected answer to "what was missed?" in these scenarios is almost always one of: the backups, the keys, the DNS entry, or the inventory record.

What to take into the exam

• The life cycle runs planning and scoping, procurement, assignment, monitoring and tracking, then disposal -- and security is cheapest at the first step.
• The asset nobody knows about is the one that is unpatched and unmonitored -- inventory is a frontline control, not administration.
• Owner decides, custodian operates. Classification follows the owner's decision.
• Degaussing works on magnetic media and does nothing to an SSD; cryptographic erase is the practical SSD and cloud answer.
• A certificate of destruction is the evidence; "we deleted the files" is not.
• Decommissioning includes backups, snapshots, keys, DNS records, firewall rules, integrations and the inventory entry.