3.2 Support and Implement the Asset Management Lifecycle

Support and Implement the Asset Management Lifecycle

SSCP Knowledge Area 1.5 asks you to support and implement the asset management lifecycle for hardware, software, and data. The exam is not asking you to memorize a procurement slogan. It is asking whether an operational practitioner can keep track of a laptop, a logging library, and a payroll file from the moment someone proposes them until they are destroyed.

If an asset is not in inventory, you cannot patch it, license it, encrypt it, or prove you destroyed it. Shadow information technology (IT) — a department credit-card Software as a Service (SaaS) tool, an unsanctioned lab device, a spreadsheet of customer personally identifiable information (PII) on a personal drive — is an asset-management failure first and a technical-control failure second.

The October 1, 2025 outline lists the lifecycle in this order: process, planning, design, and initiation; development and acquisition (including Development Security Operations (DevSecOps) and testing); inventory and licensing (open source and closed-source); implementation and assessment; operation, maintenance, and end of life (EOL); archival and retention; disposal and destruction. Walk those stages as a sysadmin and as an asset owner.

What Counts as an Asset

Asset owner is accountable for the business risk (the finance director who owns the payroll file). Custodian (often IT) operates the control. Do not let a sysadmin silently become the owner of data they only host.

The diagram below is the outline order. Hardware may jump from operations to destruction when no records remain; data more often passes through archive first.

Process, Planning, Design, and Initiation

Before anyone buys or builds, someone states the business need, classifies the data, names an owner, and writes security requirements. Initiation is where you decide whether a new invoicing SaaS is allowed to hold payment data, whether it must stay in a specified jurisdiction, and whether it integrates with existing identity and access management (IAM).

Scenario. Accounts payable wants a cloud invoicing tool next month. If security first hears about it at go-live, you have already skipped planning. The SSCP's job at initiation is to inject classification, encryption, logging, retention, and exit criteria into the design — including how you will destroy data when the contract ends.

Development and Acquisition

When you build, DevSecOps shifts security left: threat modeling, static application security testing (SAST), dynamic application security testing (DAST), dependency scanning, and a software bill of materials (SBOM) travel with the pipeline. Testing includes unit, integration, user acceptance, and security testing — not a production poke after launch.

When you buy, acquisition includes an approved vendor list, supply-chain checks, contract clauses for breach notification and data return, and a requirement that the vendor can meet your control catalog. Hardware should arrive via a trusted channel; a box that appeared on the loading dock is not an approved acquisition path.

Scenario. A developer copies a popular open-source logging library into a microservice because it "just works." That is acquisition, even though no purchase order exists. It still needs testing, license review, and inventory.

Inventory and Licensing

Inventory is the operational backbone. Many organizations use a configuration management database (CMDB) or equivalent asset register. If it is not listed, it will not be patched.

Closed-source software is governed by an end-user license agreement (EULA), seat counts, and true-up audits. Running extra unlicensed cores is both a compliance finding and an inventory miss.

Open source is not "no license." Permissive licenses such as the Massachusetts Institute of Technology (MIT) license impose notice conditions; GNU General Public License (GPL)-family licenses can impose copyleft obligations if you distribute a derived work. You still track versions, known vulnerabilities, and whether the project is abandoned. "It was free on a public repository" is not an SSCP answer.

Scenario. During a quarterly license review, a sysadmin finds an untracked database client on a reporting server and three GPL libraries inside a product that legal thought was proprietary. Both are inventory and licensing defects, and both are in-scope for Domain 1.

Implementation and Assessment

Implementation is not "copy files to production." Harden to a baseline (for example a Security Technical Implementation Guide (STIG) or an internal gold image), restrict admin paths, enable logging, and assess before acceptance: vulnerability scan, configuration review, access review, and a go-live checklist signed by the asset owner.

If assessment fails, you do not negotiate the finding away in chat. You remediate, or you accept residual risk in writing.

Operation, Maintenance, and End of Life

Operations is patching, monitoring, recertification of access, backup testing, and capacity. Maintenance includes firmware and library updates, not only operating-system patches.

EOL is a date, not a surprise. When a vendor announces that a server operating system, a firewall model, or a clinical appliance will lose support, the lifecycle response is a replacement project or a documented compensating design (isolation, extra monitoring, paid extended support if it exists). Leaving an internet-facing EOL host in inventory because it still boots is how preventable incidents start.

Keep EOL assets in inventory until they are destroyed. Removing a dying system from the CMDB to make a dashboard look clean hides risk.

Scenario. A clinic's electronic health record appliance vendor announces EOL in 90 days. The SSCP does not wait for the outage. You start replacement or compensating isolation now, keep the serial in inventory, and only mark the record disposed after sanitization evidence exists.

Archival and Retention

Not every asset goes from production straight to the shredder. Records, logs, and some backups move to archive under a retention schedule: tax records, health records, and security logs often have different clocks. Legal hold freezes deletion when litigation or investigation is reasonably anticipated.

Write once read many (WORM) storage appears in some regulated log and financial archives. Archiving forever "just in case" is not conservative — it increases breach impact and discovery cost. Retention is a maximum and a minimum: delete when the schedule says delete, unless a legal hold says stop.

Scenario. Human resources keeps personnel files for a stated period; the SIEM keeps hot logs for a short window and warm logs for a year because that is what the logging standard requires. Payroll files do not belong in an unlabeled box of old laptops.

Disposal and Destruction

Disposal is the last control you will ever apply to that copy of the data. NIST Special Publication 800-88 Revision 1 describes media sanitization as clear, purge, or destroy, chosen from classification and media type. A quick format of the system volume is not a purge. Degaussing, cryptographic erase of self-encrypting drives (destroy or lose the keys), shredding, incineration, and a vendor certificate of destruction are how you prove the asset left the organization empty.

Cloud and SaaS require contractual destruction plus your own key destruction (crypto-shredding) when you hold the keys. Do not assume a "we deleted the tenant" ticket wiped every backup the provider holds unless the contract and evidence say so.

Scenario. Finance laptops go to surplus. They held payroll spreadsheets. The SSCP's path is: inventory check-out, 800-88 purge or destroy, update the CMDB to disposed, file the certificate, then release hardware. Donating a "formatted" laptop with an intact disk is a data disclosure waiting to happen.

Treat data, software, and hardware as one lifecycle with different destruction methods. A license you still pay for after the server is shredded is an inventory bug. A disk you shredded without recording serial numbers is an audit finding.