The asset lifecycle: from acquisition to sanitisation

An inventory is a snapshot; the lifecycle is the process that keeps producing and ending it. The NIST Cybersecurity Framework 2.0 asks in ID.AM-08 that systems, hardware, software, services and data “are managed throughout their life cycles”, and the governance question is which decision belongs to which stage. The two failures that actually surface are both end-of-life failures: a component that still runs after its developer stopped supporting it, and data still readable on media that has left the estate. This sheet is about the four stages, the decision each carries, and the record that makes it provable.

Four stages, one identity carried across them

acquisition ──► operation ──► end of support ──► disposal
   what the       the            replace, or       sanitise, or
   record must    remediation    record the        the data leaves
   foresee        clock          exception         with the media
        │              │              │                  │
        └──────────────┴──────────────┴──────────────────┘
             one component identity, traced across all four

SP 800-53 Rev. 5 puts disposal inside the earliest planning sentence: the risk management strategy weighs “the cost, schedule, performance, and supply chain issues” of a system’s whole life, “design, development, acquisition, deployment, operation, sustainment, and disposal” (§1.3). SP 800-128 names the unit that travels through those stages: a configuration item “is identified, labeled, and tracked during its life cycle”.

Acquisition: the disposal record is created here

SP 800-88 Rev. 2 states the dependency: “Information disposition and sanitization decisions occur throughout the information system life cycle. Critical factors that affect information disposition and media sanitization are decided at the start of a system’s development.” Initial requirements should therefore carry the “hardware and software specifications as well as interconnections and data flow documents that will assist the system owner in identifying the types of ISM used in the system” — the information storage media the system will hold. A purchase that records the media type and the confidentiality it will hold is what makes the later disposal decision possible.

Operation: supported components and a remediation clock

Two controls run here. SI-2 FLAW REMEDIATION requires the organisation to “Identify, report, and correct system flaws”, to test updates before installing them, to “Install security-relevant software and firmware updates within [Assignment: organization-defined time period] of the release of the updates”, and to incorporate flaw remediation into configuration management. That time period is an assignment; that assigning it is the governance act is this sheet’s reading. CM-8(1) closes the loop from the other side: update the component inventory “as part of component installations, removals, and system updates”; the record’s content is the sibling inventory sheet’s subject.

End of support: replace, or record the exception

SA-22 UNSUPPORTED SYSTEM COMPONENTS states the choice: replace a component “when support for the components is no longer available from the developer, vendor, or manufacturer”, or, in its words, “Provide the following options for alternative sources for continued support for unsupported components” — in-house support, or an external provider. Its discussion explains the risk: unsupported components create “an opportunity for adversaries to exploit weaknesses in the installed components”. It names the exception — “systems that provide critical mission or business capabilities where newer technologies are not available or where the systems are so isolated that installing replacement components is not an option” — and the compensating “prohibiting the connection of such components to public or uncontrolled networks”. An exception kept only in someone’s head, without its isolation and its owner, is an omission.

Disposal: what “infeasible” costs, and who decides it

MP-6 MEDIA SANITIZATION requires media to be sanitised “prior to disposal, release out of organizational control, or release for reuse”, with “mechanisms with the strength and integrity commensurate with the security category or classification of the information”. SP 800-88 Rev. 2 defines the target — sanitisation “renders access to target data on the media infeasible for a given level of effort (i.e., constraints on time, budget, and resources)” — and requires that “no reconstructible residual representation of the sensitive data is stored on ISM that has left the control of the organization”, whatever the media’s final intended destination. Control is the operative word: the document notes that its decisions “are influenced by who has control and access to the media”. Which technique fits which device — clear, purge or destroy — belongs to the technical areas; the decision here is the level of effort the organisation will accept.

The records that make sanitisation provable

MP-6(1) requires the organisation to “Review, approve, track, document, and verify media sanitization and disposal actions”; its discussion lists what the documentation holds — “personnel who reviewed and approved sanitization and disposal actions, types of media sanitized, files stored on the media, sanitization methods used, date and time”. SP 800-88 Rev. 2 adds the operating rule — “Once a sanitization decision has been made, the organization should record the decision and ensure that a process and proper resources are in place to support that decision” — and the certificate of sanitisation: serial number, method, technique, tool and version, verifier’s name, position and date. Its sharpest point is about span, not detail: records support a claim about the estate only if they run from introduction, through last use, to the post-sanitisation destination. The record runs the whole lifecycle; this sheet’s reading is that the property management officer and the records management officer both sit in the disposal path for that reason.

Level and prerequisites

L2 — operational: the decision each lifecycle stage carries, the evidence it owes, and the two end-of-life failures. It assumes the L1 scope chain and the inventory model; the inventory record, supplier arrangements and continuity planning belong to other sheets.

Where to go next

Knowledge — the index.
Cybersecurity Governance — the area this sheet belongs to.
Security governance foundations — this sheet’s node.

References

NIST — SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations — https://doi.org/10.6028/NIST.SP.800-53r5 — the SI-2, SA-22, MP-6 and MP-6(1) statements with their discussion, CM-8(1), and the §1.3 sentence that lists disposal among the stages the risk management strategy considers.
NIST — SP 800-88 Rev. 2, Guidelines for Media Sanitization — https://doi.org/10.6028/NIST.SP.800-88r2 — the definition of sanitisation and its “level of effort”, the requirement that no reconstructible residual representation remain on media that left the organisation’s control, the acquisition-phase statement that disposition decisions are taken at the start of development, and the documentation and roles of §4.3.6–§4.7.
NIST — SP 800-128, Guide for Security-Focused Configuration Management of Information Systems — https://doi.org/10.6028/NIST.SP.800-128 — the configuration item identified, labelled and tracked during its life cycle, which is the identity the four lifecycle stages carry.
NIST — The NIST Cybersecurity Framework (CSF) 2.0 (NIST CSWP 29) — https://doi.org/10.6028/NIST.CSWP.29 — the ID.AM category and subcategory ID.AM-08.