What ID.AM-08 asset life cycle management asks for in plain terms
ID.AM-08 asks you to manage systems, hardware, software, services and data across their whole life cycles, from acquisition through use, change and disposal. If a customer questionnaire, an audit or an internal review has just asked you to show this, the practical question is whether you can name every asset that is in service, who owns it, how it was configured before it went live, and how its data was removed when it left. The risks behind the outcome are familiar: assets nobody remembers owning, systems that reach production with default settings or missing patches, and data left on drives that are sold, returned or repaired. Each of these becomes harder when a system was bought outside IT, when a cloud service was adopted by a team without review, and when the records for procurement, deployment, transfer and disposal sit in separate tools owned by separate people.
ID.AM-08 is a Subcategory of the Asset Management Category in the Identify Function of the NIST Cybersecurity Framework (CSF) 2.0. It describes an outcome, not a control that can be certified. NIST states that it does not offer certifications or endorsements of CSF-related implementations or services, so no assessor issues a "CSF 2.0 certificate" for this Subcategory. What a customer or auditor will accept is evidence that your organization achieves the outcome, and the choice of which framework to map that evidence to (for example ISO/IEC 27001 or SP 800-53) is a decision to confirm with the party asking. Confirm the wording of any contract or regulator request before you choose a mapping.
Which assets and teams ID.AM-08 applies to
ID.AM-08 covers every system, device, service and data store from acquisition to disposal, so the scope reaches well beyond the server room. The cards below separate the asset classes, the teams that own each stage, and the third parties that touch organizational data, with shadow IT and retired systems named as scope items in their own right.
Endpoints, servers and network gear
Laptops, desktops, servers, firewalls, switches and access points carry configuration from the moment they are built until they leave service. Check that each class has a defined build standard applied before the device reaches production, and that transfers between users, sites or departments update the inventory record. Repairs by external vendors are a common gap, so confirm that storage is sanitized before any unit leaves the organization. Hardware disposal often sits with facilities or a logistics provider, so the handover must be written down.
Cloud services, SaaS and containers
Infrastructure, platform and software-as-a-service resources can be created by any team with an account, which makes their life cycle harder to see than physical hardware. Confirm who may provision accounts, how resources are tagged with an owner, and how decommissioning removes data stores, backups and access grants together. Containers and virtual machines are short-lived, so their images and persistent volumes need the same retention and destruction rules as servers. Ask each provider how it erases customer data when a subscription ends.
Shadow IT and redundant systems
Tools adopted by a department without IT approval, such as file-sharing apps, spreadsheets with customer records or unlisted SaaS trials, fall outside the inventory and outside every disposal process. NIST's Implementation Examples for ID.AM-08 call for finding shadow IT and redundant systems, so discovery is part of this scope rather than an optional extra. Compare network traffic, expense records and identity provider logs against the inventory, then assign an owner or retire each unexpected system. Illustrative example: a team's old project wiki still holds personal data two years after the project closed.
Retired systems that still hold data
A decommissioned application, a mailbox after an employee leaves or a backup set kept beyond its retention period can still hold regulated data after it is switched off. Treat each retired system as in scope until its data has been destroyed under the retention policy and the destruction is recorded. Keep a disposal register that names the system, the data classes it held, the method used and the person who signed off. Backup copies and archived snapshots are the most frequently forgotten items on this list.
Teams that own each stage
Procurement sets security requirements into contracts, IT operations handles deployment, patching and retirement, engineering owns configuration of applications and cloud resources, security defines sanitization and retention standards, and facilities or a certified disposal vendor handles physical destruction. ID.AM-08 fails when any one of these teams assumes another holds the record. Map each stage to a named owner in a RACI table and confirm that the inventory system receives updates from each team. Ask who signs the final destruction record before a device is released.
Third parties that hold or dispose of data
Repair depots, recyclers, cloud providers, managed service providers and SaaS vendors may store, process or destroy organizational data on the organization's behalf. Contracts should specify how data is returned or destroyed at the end of service, what certificates or logs the vendor provides, and how quickly the vendor must act after a request. The organization still owns the outcome, so request evidence of destruction rather than accepting a verbal assurance. Confirm vendor sub-processors and their disposal practices before signing.
How an assessor tests ID.AM-08 life cycle records
This table compares how an assessor samples and traces ID.AM-08 records, what evidence the assessor asks for, and where organizations usually fail. Read each row as a test the assessor runs, then check whether your own records would pass it before the assessor arrives. The main takeaway is that assessors trace individual assets end to end, so records must link across procurement, inventory, build and disposal.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Sample recently acquired assets | Purchase orders, delivery records and the inventory entries for a selected set of recent acquisitions | Assets reach production without an inventory entry or with an incomplete owner field |
| Sample recently retired assets | Decommission tickets, retirement dates and the matching inventory status changes | Retired hardware or software remains listed as active in the inventory |
| Trace procurement to inventory to build record | Serial numbers or asset tags on the purchase record, the inventory item and the build or configuration record for one asset | Disposal and build records do not match hardware serial numbers, or the chain breaks at the build step |
| Check secure configuration before go-live | Build dates, hardening baseline records and change approvals that precede the production start date | Configuration baselines applied after the system already went live |
| Confirm discovered unmanaged systems were resolved | Discovery scan results, shadow IT findings and the tickets showing each system was onboarded or removed | Discovered systems logged but never added to the inventory or removed from the network |
| Review destruction and sanitization certificates | Destruction or sanitization certificates, the retention schedule and records showing who approved each disposal | Certificates exist but cannot be matched to a specific asset or retention period |
| Check transfers and reassignments | Records showing ownership or location changes and the matching inventory updates | Inventory keeps the previous owner or location after an asset moves |
How to implement ID.AM-08 in sequence
This sequence turns ID.AM-08 from a policy statement into a working life cycle that runs from acquisition to disposal, with each stage leaving records an assessor can sample. The order matters because discovery, configuration and inventory updates depend on knowing which stages and owners exist first.
Define life cycle stages and owners
Document the stages every system, hardware item, software product, service and data set passes through, such as request, acquisition, build, deployment, operation, transfer, retention end and disposal. Name an accountable owner for each stage and for each asset class, and agree which teams hand work to the next stage. The output is a life cycle standard with a stage-to-owner table that an assessor can compare against real records. Confirm the stage list with IT operations, security and the business owners before you publish it.
Set a secure build baseline before production
Define the configuration baseline each asset class must meet before it enters production, including hardening settings, approved software lists and default credential removal. Engineering or platform teams apply the baseline to images and build templates, and security reviews exceptions before go-live. The output is a versioned baseline per asset class plus a sign-off record for each new deployment. This step addresses the NIST Implementation Examples on securing systems before production, so keep the approvals, not only the document.
Connect discovery to the asset register
Run inventory collection from endpoint agents and network scanning, then reconcile the results against the asset register. Unmatched devices and software are shadow IT or redundant systems, so assign each one to an owner or schedule it for removal. Open-source tools such as GLPI, Wazuh and Fleet can feed this reconciliation, but confirm each product's coverage for your own device types, including OT and mobile. The output is a register that shows discovered, matched and unmatched items, with dated resolution records for each exception.
Define transfer and change triggers
List the events that must update the inventory: new hires or role changes that move equipment, hardware repairs, software upgrades, cloud service adoption, ownership transfers and decommissioning requests. Tie each trigger to a ticket or change record, using a helpdesk such as Zammad or your existing change process. The output is a trigger matrix and a sample of closed tickets showing that the register changed when the trigger fired. Ask your auditor which trigger evidence they will sample before you finalize the matrix.
Write the retention and disposal procedure
Set out how long each data class and asset is retained, what triggers destruction under that retention policy, and who approves it. Include legal hold handling so that data subject to a hold is not destroyed on schedule. The procedure should name the records kept at destruction, such as the asset identifier, data category, method, date and approver. The output is an approved retention schedule and disposal procedure, linked to the data inventory described in ID.AM-07, so the destruction records can be traced back to the data they cover.
Set sanitization methods per media type
Choose a sanitization method for each media type you hold, such as spinning disks, solid-state drives, mobile devices, network equipment and removable media, and document when each method applies. Cover both retirement and repair, because the NIST Implementation Examples address sanitizing storage before hardware is repaired as well as retired. Require a recorded outcome for every item, such as a certificate of destruction from a vendor or a verification log from your own team. Confirm with your hardware vendors and disposal partners which methods their processes actually perform before you rely on them.
Close each asset record with disposal evidence
When an asset leaves the environment, change its status in the register to retired or disposed only after the sanitization outcome, destruction record and approval are attached. Review a sample of closed records each cycle to find gaps, such as assets marked retired with no sanitization proof or devices still active in the network scan. The output is a register in which every retired asset links to its disposal evidence, plus a review log that shows the sample and the corrections made. This closing record is what ties the whole sequence together for an assessor.
Evidence that passes an ID.AM-08 review
An assessor testing ID.AM-08 wants to see that life cycle management happens in practice, not only on paper. The six artifacts below link together: each policy, register extract, baseline, discovery finding, transfer record and destruction certificate should point to the same asset identifiers so a reviewer can follow one system from acquisition to disposal.
Life cycle policy and stage definitions
This document defines the stages an asset passes through, such as request, acquisition, deployment, maintenance, transfer, retirement and disposal, and names the owner responsible for each stage. Keep it under version control with an approval date and a review date. Check that every stage has an entry requirement and an exit record, and that the policy names who may approve an exception. Reviewers often start here, so an outdated stage list undermines everything that follows. Assign a policy owner who reviews it on a fixed schedule and after any major change to tooling or sourcing.
Dated asset register extracts
Register extracts show each asset with its identifier, owner, status, location and the dates of acquisition, deployment and any status change. An assessor should be able to pick a sample asset and trace it through every stage. Export the register on a scheduled basis, such as monthly, and store each export with a timestamp so history cannot be rewritten. Confirm that retired assets stay in the record with their disposal date rather than being deleted. A named owner should reconcile the extract against procurement records before each export is filed.
Pre-production configuration baselines
A baseline is the approved secure configuration a system must meet before it enters production, along with the record that the system was checked against it. Reviewers look for evidence that configuration was secured before deployment, not after an incident. Store each baseline with its version, the hardening standard it follows and the approval record signed by the system owner and a security reviewer. Confirm that the approval is linked to the asset identifier. Review baselines when the platform is upgraded, because a baseline that predates the current version no longer describes the running system.
Discovery reports with dispositions
Discovery reports list systems found on the network or in cloud accounts that are missing from the approved inventory, including shadow IT and redundant services. A report alone does not satisfy ID.AM-08. Each finding needs a disposition, such as onboarded with an owner, decommissioned, or accepted with a documented risk decision and a review date. Schedule discovery scans on a fixed cadence and keep the reports with their disposition log. Reviewers will sample findings to confirm that unauthorized systems were resolved rather than quietly recorded.
Transfer and change logs
Transfer logs record when an asset changes hands, moves between business units, is reassigned to a new user or is sent to a third party for repair. Each entry should update the inventory, so the register and the transfer log agree. Capture the date, the previous and new owner, and the reason for the change. Change logs for software and hardware lifecycle events, such as major upgrades or end-of-support decisions, belong here too. Assign a responsible person to close each open transfer within a set period, and review open items during the monthly register export.
Sanitization and destruction certificates
Certificates confirm that data was destroyed under the retention policy or that storage media was sanitized before hardware was retired, repaired or resold. The reviewer will check that each certificate names the asset identifier, the method used and the person or vendor who performed the work. Where a third party destroys media, confirm that the contract requires certificates and that the vendor's records can be matched back to your register. Keep certificates with the disposal entry so an auditor can move from the asset record to proof of destruction without manual searching.
Open-source tools that produce ID.AM-08 evidence
GLPI's Assets module holds records for computers, monitors, software, network equipment, peripherals, printers, phones and racks. Records can be entered by hand or pushed automatically by the GLPI Agent, which uses the native inventory built into GLPI since version 10. Used well, the module gives you a life cycle register: each asset has a status, an assigned owner and a history you can point to when hardware moves between people, sites or disposal.
- Acquisition and assignment: Manual entry records purchase details, owners and locations at the point of receipt, which is the first life cycle event an assessor will ask about.
- Automatic inventory: The GLPI Agent reports hardware and software changes, so records drift less from what is actually on the network.
- Transfers and retirement: Status changes and assignment history show when an asset moved or left service, provided staff update the record each time.
- What it does not cover: GLPI does not perform data destruction or produce sanitization certificates. Those need a documented media sanitization procedure and signed records held outside the tool.
- Confirm in your environment: Check which asset types, agent versions and inventory fields your deployment actually populates, and whether lifecycle states match your own policy.
Ask the team who owns GLPI to show a sample asset from acquisition through retirement, so you can see which fields are filled in at each step.
Wazuh's Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates from each endpoint. The data is stored in the Wazuh indexer and shown in dashboard inventory views and reports. For ID.AM-08, this gives you current-state evidence: what a system looks like after it was built, and whether it still matches the approved configuration weeks or months later.
- Pre-production baseline: Syscollector output captured after build shows the software, services and open ports present before a system enters production.
- Shadow IT and drift: Unexpected software, services or listening ports on an endpoint can prompt review of systems that were never formally approved.
- Update evidence: Windows update records show patch state on the endpoint, which supports the secure-configuration and maintenance claims in the life cycle process.
- What it does not cover: Syscollector does not record purchase approvals, disposal decisions or who authorized a transfer. It also does not verify that data was destroyed.
- Confirm in your environment: Verify which collection intervals, operating systems and agent versions apply to your estate, and whether retention in the indexer meets your evidence period.
Export a dated inventory report for a sample of systems and check whether it matches the records in your asset register.
Fleet policies are yes or no questions asked of devices as osquery queries. The policies page shows which devices on each fleet pass or fail each policy. For ID.AM-08, policies let you test whether a device meets the conditions you set before or during its life cycle, such as an approved disk encryption state or an approved operating system build, and keep a record of the result.
- Pre-deployment checks: A policy can ask whether a new device meets the secure configuration baseline before it is released to a user.
- Ongoing conformance: Pass and fail results over time show whether devices still meet the baseline, which supports life cycle reviews.
- Retirement checks: Policies can confirm that a device scheduled for disposal is no longer enrolled or reporting, which helps close the record.
- What it does not cover: Fleet does not destroy data or prove that sanitization was performed. A device that stops reporting is not evidence of wiping, so a signed sanitization record is still required.
- Confirm in your environment: Check which osquery tables and policy queries are supported for your operating systems, and how long pass and fail history is retained.
Write down the policy that represents each life cycle condition and keep the policy definition with the results, so an assessor can see what was tested.
Zammad is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. For ID.AM-08, its value is as a request record: a single ticket can hold the transfer request, the approval, the handover to the team that performs the work and the closing note. Because tickets keep the communication thread, they can show who asked for an action, who approved it and when it was completed.
- Transfer and disposal requests: A ticket template for asset transfers or disposal gives every request the same fields and approval steps.
- Approval trail: The ticket history keeps the request, the decision and the closure in one place for later review.
- Link to the asset record: Reference the asset identifier from your GLPI or other register in each ticket so records can be matched.
- What it does not cover: Zammad does not perform sanitization or verify that a device was wiped. The sanitization certificate or destruction record must be attached or stored separately.
- Confirm in your environment: Confirm the ticket states, approval workflow and attachment retention settings your team uses, since these are configured locally.
Sample a closed disposal ticket and check whether it links to the asset record and to the signed destruction evidence.
What meeting ID.AM-08 costs in money and effort
This table breaks the cost of meeting ID.AM-08 into components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to structure a quote request, since NIST publishes no pricing and no duration for this Subcategory. The main takeaway is that open-source tooling removes license spend but not the engineering and evidence work that ID.AM-08 requires.
| Cost component | One-time or recurring | What drives it and how to keep it down |
|---|---|---|
| Tooling and licenses | Recurring for commercial tools, one-time setup for self-hosted | Self-hosted options such as GLPI, Wazuh and Fleet remove most license spend, but hosting, storage and upgrade effort remain. Ask whether the quote includes hosting and patching. |
| Engineering time for inventory integration | One-time, with later changes | Connecting asset records to procurement, HR onboarding and offboarding, and cloud accounts drives effort. Keep integrations to the systems that already hold the authoritative lifecycle events. |
| Secure baseline configuration before deployment | One-time per system type, recurring as baselines change | The number of distinct system images and the number of baseline reviews drive effort. Fewer, documented build standards reduce rework. |
| Shadow IT and redundant system discovery | Recurring | Discovery scans, network telemetry and reconciliation against expense and cloud billing records take ongoing review. Ask which discovery sources the quote covers. |
| Evidence upkeep | Recurring | Retaining inventory exports, change tickets, decommissioning records and sanitization certificates over time is continuous work. Define retention periods and an owner for each evidence type in the scope. |
| Data destruction and retention records | Recurring, tied to the retention schedule | Volume of data sets reaching retention limits and the number of systems involved set the workload. Ask how destruction is logged and who approves each action. |
| Physical sanitization or destruction services | Recurring per hardware batch | Third-party destruction is paid per service event, and costs rise with the number of drives and retired devices. Ask for certificates of destruction and whether on-site or off-site service is included. |
| External review or testing | Recurring, usually periodic | Independent checks of lifecycle controls and sampling of retired assets add cost. Scope the review to the systems the assessor will sample. |
| Auditor sampling effort | Recurring at each assessment | Assessors commonly select a sample of assets and trace them from acquisition through disposal. Complete, consistent records reduce the sample effort and follow-up questions. |
Who does what for ID.AM-08: your team, a partner and the auditor
Your organization owns the ID.AM-08 outcome. Accountability cannot be outsourced, so a named owner must approve the life cycle policy, decide how each system and data set ends its life, and keep the records that prove those decisions were made. Legal, records management and procurement usually set the retention periods and contract terms that feed into these decisions.
- Life cycle policy: Define the stages from acquisition to disposal, the approval gates before production, and who may place a system into service.
- Asset owners: Each business owner confirms that discovered systems are needed, classifies them and sets an end-of-life date.
- Disposal decisions: Decide retention periods for data and when hardware is retired, repaired or resold, based on legal and contractual duties.
- Records: Keep sanitization logs, destruction certificates, transfer records and inventory change history somewhere an assessor can reach.
Check that a named individual signs each disposal decision and that your records show the decision itself, not only a vendor's paperwork.
An implementation partner such as DeployOpen prepares the technical machinery that ID.AM-08 depends on. The partner works inside your own infrastructure and under your direction. It can build discovery, baselines and evidence packs, but it cannot approve your disposal decisions, sign off on your controls or issue an assurance report.
- Discovery: Configure inventory and agent tooling to surface shadow IT and redundant systems, for example by using the Syscollector module in Wazuh or the Assets module in GLPI on self-hosted deployments.
- Inventory integration: Connect procurement, change and identity sources so that transfers, new systems and retirements update the inventory record automatically.
- Secure baselines: Build hardened configurations and test them before systems reach production, so that the approval gate has something concrete to check.
- Sanitization procedures: Write media sanitization and data destruction runbooks, then test them on a sample device and record the results.
- Evidence packs: Assemble exports, logs, configurations and procedures mapped to the ID.AM-08 subcategory, so your team and your assessor can trace each claim to its source.
Before work starts, ask for a written scope, a list of deliverables, and confirmation that every record the partner generates is handed over for your team to own after the engagement ends.
An independent auditor, assessor or certification body is the only party that tests whether ID.AM-08 operates as described and issues any report, attestation or certificate. NIST states that it does not offer certifications or endorsements of CSF implementations, so any claim that an organization is CSF 2.0 certified should prompt questions about who issued it and under what engagement.
- Sampling: The assessor selects samples of new systems, transfers and disposals, then asks for the evidence behind each sampled item.
- Testing: The assessor compares the inventory against network discovery results and destruction records to find systems that were never recorded.
- Independence: An assessor that designed or built the controls it later tests may lose the independence its opinion depends on, so partner-built evidence is reviewed by the assessor rather than certified by the partner.
- Reporting: The assessor issues whatever report or attestation the engagement type allows, and only the assessor signs it.
- Background: NIST's CSF FAQs explain the voluntary status of the framework and its position on certification.
Confirm the assessor's engagement type, the output it will produce and who signs that output before any work begins.
Where organizations fall short on asset life cycle management
Most ID.AM-08 gaps are not failures to buy tools. They are points in the life cycle where a system changes state (is discovered, deployed, transferred, repaired or retired) and no record follows it. Each card below names one such point, what it looks like in practice and the check that shows whether it is closed.
Shadow IT outside the register
Teams often start SaaS tools, scripts or virtual machines without telling the asset owner, so they never reach the inventory. Under ID.AM-08, discovery is the first step in managing those systems across their life cycle. Check whether network discovery, cloud account reviews and procurement records are compared against the register on a schedule, and whether unmatched items get an owner or are retired. Unregistered systems cannot be configured, patched or retired.
Configuration applied after go-live
A system is often placed into production with default settings and hardened later, if at all. ID.AM-08 expects security to be built into the life cycle before a system is deployed, not added afterward. Check that a build standard exists for each asset class, that new systems are scanned against it before they receive production data, and that exceptions are approved and recorded. A system that goes live first and is hardened in a later ticket is an accepted risk, even if nobody wrote it down as one.
Inventories not updated on transfer or repair
Devices change hands between teams, leave for vendor repair and return with new owners, but the register still shows the original assignment. The inventory then describes a machine that is no longer where the record says. Check that transfers, loans and repair returns trigger a register update, and that the location and custodian fields are compared with live data. An inventory that is only reviewed at audit time will drift between reviews, so the update should happen at the event itself.
Retention periods without destruction records
Many organizations set retention periods for data but do not record when data was actually destroyed. When an assessor asks for proof that data past its retention date was removed, the answer is often a policy document rather than a log. ID.AM-08 covers destroying data under the retention policy with records kept. Check that each retention schedule links to a destruction procedure, that destruction is logged with the system, dataset and approver, and that the log is kept for the period the organization sets.
Sanitization logs that cannot be tied to serial numbers
Sanitization records often name a model or a batch rather than the individual drive or device. If a disk later appears in a different asset, nobody can show which wipe applied to it. ID.AM-08 includes sanitizing storage before hardware is retired or repaired. Check that each sanitization entry records the serial number or asset tag, the method used, the operator, the date and the outcome. Where a device cannot be wiped, check that physical destruction is recorded against the same identifier.
Third-party disposal without evidence
Recycling contractors, leasing companies and cloud providers may dispose of hardware or data on the organization's behalf, and the organization still owns the outcome. Without a certificate or report tied to specific assets, the disposal cannot be shown in an assessment. Check that contracts require itemized disposal certificates, that these are matched against the asset register, and that discrepancies are followed up. Ask providers which sanitization standard they follow and confirm that wording in the contract.
Questions buyers ask about ID.AM-08 cost, effort and outside help
How much effort does ID.AM-08 take, and what drives it?
The effort depends mostly on how many systems, hardware assets, software packages, services and data stores the organization runs, and on how many of them have no documented life cycle today. ID.AM-08 asks for management from acquisition through disposal, so the work covers intake approvals, secure build standards before deployment, change tracking, transfers between owners, retention-based data destruction and media sanitization at retirement. NIST publishes nine Implementation Examples for ID.AM-08, which gives a checklist to size the gap. Expect the largest effort where records are scattered across procurement, IT operations and business teams. No duration is given here because it depends on the environment, and a written scope should set it.
Can an organization meet ID.AM-08 in-house?
Yes, many organizations can, provided they have an owner for the asset life cycle, a documented process and the tooling to record what happens at each stage. The work is mostly process and records: who approves a new system, what hardened configuration it must meet before going live, how transfers update the inventory, and how disposal is recorded. Internal teams often struggle with shadow IT discovery and with proving that sanitization actually happened, because these need network telemetry and certificates or logs from third parties. Confirm internally whether procurement, IT operations and data owners will all feed one system of record before deciding to build everything yourself.
How long does it take to produce clean evidence for ID.AM-08?
The time to clean evidence depends on how far the existing records are from a complete life cycle trail. Evidence is clean when an assessor can pick any asset and follow it from approval through configuration, changes, transfers and destruction, with dated records at each step. Drivers include the age of the inventory, how many disposals were never logged, whether sanitization certificates exist for past retirements, and how long the retention policy has been applied to data. Ask any provider to show the evidence it will collect, the period it will cover and who will sign off the records, rather than accepting a generic timeline.
What does the work need from our staff?
The work needs named owners from IT operations, procurement, security, and the data or business teams that hold information. IT operations supplies configuration and inventory data, procurement supplies purchase and contract records, and data owners confirm retention periods and destruction requirements. Security reviews the secure configuration baseline and sanitization methods. Staff time is recurring because life cycle events never stop, so someone must process transfers, approvals and disposals after the project ends. Ask for the list of client roles and the time each role commits in the written scope.
Does NIST certify that we comply with ID.AM-08?
No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services and has no plans for a conformity assessment program. CSF 2.0 is voluntary for most organizations, although some customers or suppliers may require alignment. Any statement that you are certified against ID.AM-08 should be checked against what the requesting party actually asked for, which is usually an independent assessment report or a statement of alignment that you prepare yourself.
Who issues any report or attestation for ID.AM-08?
Only an independent auditor, assessor or certification body issues a report, attestation or certificate. The organization owns its controls and its statement of alignment, and an implementation partner such as DeployOpen prepares the systems, records and evidence that an assessor will review. DeployOpen does not issue audit reports, attestations or certifications. If a customer or regulator asks for independent assurance, the assessor is selected and engaged by the organization, and the assessor's scope decides what the report covers.
Which parts of ID.AM-08 are worth outsourcing?
The parts most often worth outsourcing are the ones that need specialist tooling or fresh eyes. These include setting up automated inventory and shadow IT discovery, building secure configuration baselines before deployment, integrating the inventory with helpdesk and ticketing records, and documenting the data destruction and sanitization procedures. Keep ownership of approval decisions, risk acceptance and retention periods in-house. A fixed-scope engagement with written deliverables makes the handover clear. Compare quotes on the same list of systems and evidence types, and confirm which items recur after delivery.
How DeployOpen prepares ID.AM-08 life cycle evidence
DeployOpen plans, implements and documents self-hosted open-source platforms that record systems, hardware, software, services and data from acquisition to disposal inside your own infrastructure. We prepare the systems and records that show life cycle management is working, while your organization owns the controls and an independent assessor reviews the evidence.
How we scope
- Agree in writing which asset classes, life cycle stages and teams fall within the ID.AM-08 scope.
- Confirm which disposal, sanitization and data destruction records your retention policy requires.
- Identify which inventory sources, such as endpoint agents or helpdesk workflows, will feed life cycle records.
How we build
- Deploy inventory tooling such as GLPI and Wazuh Syscollector within your own cloud accounts or data centers.
- Configure asset lifecycle states, owners and transfer workflows so inventory updates when assets move or change hands.
- Set up shadow IT discovery and secure baseline checks so new systems are reviewed before they reach production.
How we hand over
- Document the configured workflows, data sources and retention settings so your team can operate them independently.
- Deliver sample exports and records that show acquisition, deployment, transfer and disposal activity for in-scope assets.
- Provide a mapping from each configured control to the ID.AM-08 Subcategory and its informative references for your assessor.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work is complete.
- Review inventory coverage and life cycle records on a schedule agreed with your team.
- Confirm with your auditor which evidence formats and sample periods they expect before the assessment begins.
