CM-8 System component inventory: requirements and evidence

What CM-8 system component inventory requires and why it is hard to keep true

An assessor who asks for the system component inventory wants one list that describes the system as it actually is today, with every component accounted for once and only once. CM-8 in NIST SP 800-53 Rev. 5 asks for that list to be accurate, complete, detailed enough to track and report on, and to carry defined accountability information, such as who owns each component. The organization must also review and update the inventory at a defined frequency. The requirement is explained here rather than quoted, so check the control text in the CPRT or OSCAL catalog before you write your procedure. SP 800-53B selects CM-8 for the low, moderate and high baselines but not for the privacy baseline, so the obligation applies to any system authorized at those impact levels.

The inventory is not a standalone artifact. It is the reference that makes other controls testable. A baseline configuration under CM-2 is only meaningful if you know which components it covers. Secure settings under CM-6 and least functionality under CM-7 are checked against the components on the list, and the contingency plan under CP-2 depends on knowing what must be recovered and where it runs. When the inventory is wrong, the assessor can find an unmanaged host that sits outside every baseline, and that single gap weakens several findings at once.

The difficulty is drift. Discovery tools such as endpoint agents, network scanners and cloud APIs each see a different slice of the environment, and a configuration management database (CMDB) is usually filled by hand or by import jobs that run on their own schedules. Records then disagree about hostnames, IP addresses and ownership, and the same server appears twice under two names. Before the next assessment, confirm which system of record the organization will treat as authoritative, how each discovery source is reconciled to it, and who signs off on the review. Ask the auditor in advance which review frequency and accountability fields they expect to see.

Which components and teams belong in the CM-8 inventory scope

CM-8 is only as complete as the boundary it is measured against. The decisions below determine which asset classes enter the inventory, which teams must feed it, and where responsibility stops when a component is run by someone else. Settle these questions in writing before counting anything, because each one changes both the size of the inventory and the reviews that keep it accurate.

Physical and virtual hardware

Servers, workstations, network appliances, storage arrays and hypervisor hosts belong in scope when they process or transmit system data. Data center and facilities teams usually hold rack and serial records, while endpoint and server teams hold what is actually running. Check that asset tags, serial numbers and hostnames agree across both sources, so one device is not recorded twice under different names.

Virtual machines and containers

Short-lived workloads create the most duplicate and missing entries. Decide whether the inventory records VM templates, running instances or both, and whether container images are tracked as components or only the hosts that run them. Platform engineering should own the rule for ephemeral instances, so that a replaced node is retired from the record instead of accumulating beside its successor.

Software, firmware and operating systems

Installed applications, operating system builds, library packages and device firmware all count as components when they are part of the system. Firmware is often missed because it sits outside the operating system and is updated by a different team, typically the hardware or facilities group. Ask who approves firmware versions and whether those versions appear in the same record as the host they belong to.

Network devices and their configurations

Switches, firewalls, load balancers and wireless controllers are components that control the boundary, so their omission weakens every other control that depends on them. Network engineering usually owns these records, and they often live in separate management consoles. Confirm which device interfaces, management addresses and firmware levels are captured, and who updates the record after a device is replaced.

Cloud resources and SaaS services

Cloud accounts, subscriptions, managed databases and load balancers are components when the organization configures or depends on them within the boundary. Whether a SaaS product is inside the boundary is a documented decision, not a default. Where the provider holds the underlying components, record the service, its region, the responsible owner and the provider evidence reviewed, instead of listing infrastructure you cannot see.

Mobile devices and remote endpoints

Laptops, phones and tablets that access system data are in scope when they connect to it, including those used from home or travel. End user computing or the device management team typically holds enrollment records, which must be reconciled with the central inventory so that a retired device is removed. Decide how personally owned devices are handled before they are allowed to connect.

Contractor-managed and third-party components

Devices and services operated by contractors or managed service providers need an explicit boundary decision. If the organization accepts responsibility for them, they belong in the inventory with an accountable internal owner, even when the provider maintains them. Contract owners, procurement and the provider should agree who supplies the data, how often it is refreshed, and what happens to records when the contract ends.

Ownership and accountability across teams

No single team can see every class of component, so the inventory needs a named owner for each class and a named owner for the whole record. The owner decides scope, reviews the contents at the defined frequency and approves exceptions. Document the owner for each asset class in the configuration management plan, so reviewers can trace who should have caught a missing entry.

How to build the CM-8 inventory in six steps

This sequence turns scattered asset data into one authoritative, deduplicated record of system components, with named owners and a review cadence that an assessor can test against CM-8. Each step produces an artifact you can show during assessment.

Define inventory attributes and level of detail
Start by agreeing with the system owner, configuration management lead and assessment lead which attributes each component record must carry, such as unique identifier, type, make and model, software and firmware versions, location, IP and MAC addresses, and the component's function. CM-8 asks for enough detail to track and report on components without making the record so granular that nobody maintains it. Write the attribute list into the configuration management plan or the inventory procedure. The output is a signed attribute schema and a short note on what counts as one component. The step is done when a reviewer can pick any component and know exactly which fields must be filled.
Choose the system boundary
Confirm in writing which hardware, software, virtual resources, network devices and cloud services fall inside the authorization boundary and which sit in an external system. CM-8 expects the inventory to reflect the system and include all of its components, so a boundary that is drawn loosely will leave gaps in the inventory from the start. Agree the boundary with the authorizing official or compliance owner and record it alongside the system security and privacy plan. The output is a boundary statement with an attached component scope list. The step is done when every asset class has an explicit in or out decision.
Collect discovery data from every source
Pull component data from each source that can see part of the boundary, such as hypervisors and cloud APIs, endpoint agents, network scans, DHCP and DNS records, procurement and asset registers, and the configuration database. Self-hosted tools can help here. GLPI's Assets module can hold computers, network equipment and other items, entered manually or pushed by the GLPI Agent, and Wazuh's Syscollector can gather hardware, operating system, software and network interface data from endpoints. Keep the raw exports so each record can be traced to its source. The output is a set of source extracts with collection dates. The step is done when each boundary segment is covered by at least one source that you have verified against a known sample.
Deduplicate by a stable identifier
Merge the source extracts so that each physical or virtual component appears once. Match records on a stable identifier such as a hardware serial number, a cloud resource ID or a managed certificate of the agent, not on hostname or IP address, which change over time. Record which source won each conflict so the merge is repeatable. CM-8 specifically requires that the inventory avoid duplicate accounting, so this step is where assessors often find problems. The output is a merged inventory with a duplicate-resolution log. The step is done when a sample of records traces back to one source entry each and the count of unresolved conflicts is recorded.
Assign owners and accountability fields
For every component, record the accountable owner, the administrator responsible for its configuration and a backup contact. CM-8 includes defined accountability information in the inventory, so an owner field that is blank or filled with a team alias with no named person will not satisfy a reviewer. Confirm each owner with the team that runs the component, and document how the field is updated when staff change roles. The output is an inventory where every record carries an accountable owner and a confirmed administrator. The step is done when the exception list of records without owners is empty or each exception has an approved reason and a remediation date.
Set the review frequency and update triggers
Define how often the inventory is reviewed and updated, and list the events that force an immediate update, such as procurement, decommissioning, a configuration change approved under CM-3 or a new component found during scanning. CM-8 requires review and update at a defined frequency, so the frequency must be written down, and the organization, not the assessor, sets it. Assign the reviewer and record each review with the date, the reviewer and the changes made. The output is an approved review procedure and a first review record. The step is done when the next review date is scheduled and the update triggers are linked to the change control workflow.
Add CM-8(1) and CM-8(2) once the base inventory is stable
After the base inventory has run through a full review cycle without major corrections, add the enhancements. CM-8(1) asks that the inventory be updated as components are installed and removed, so connect the discovery sources to your installation and removal workflows. CM-8(2) asks for automated maintenance of the inventory, which can be done with scheduled discovery and reconciliation jobs. Automated discovery can also feed the unauthorized component detection work that CM-8(3) describes. CM-8(3) and CM-8(4) are selected in the moderate and high baselines, and CM-8(2) and CM-8(4) appear in the high baseline only, so confirm the baseline for your system before deciding how far to take the enhancements. The output is a documented automation design and a test record showing that a new component appears in the inventory within the workflow you defined. Confirm the implementation details with the tool vendors and your assessor, because product capabilities vary by version.

How an assessor tests CM-8 against its six determination statements

This table maps the examine, interview and test methods that SP 800-53A Rev. 5 uses for CM-8 to the objects an assessor reviews, the evidence to prepare and the findings that most often come up. Read each row as a question the assessor will ask, and use the evidence column to check whether your inventory can answer it without a manual rebuild.

Assessment method and object	Test approach	Evidence requested	Common findings
Examine: configuration management plan	Check that the plan defines what the component inventory is, who maintains it, what detail it holds and how often it is reviewed	Approved configuration management plan with inventory section, version history and approval record	Plan mentions an inventory but gives no owner, no level of detail and no review frequency
Examine: system component inventory	Compare the inventory against the system boundary and test for completeness, duplicate entries and missing accountability fields	Current inventory export with hardware, software, owner and location fields, plus the boundary definition it maps to	Same asset appears under several names, endpoints discovered on the network are absent, or owners are blank
Examine: inventory reviews and update records	Confirm reviews happened at the frequency the organization defined and that changes were recorded	Dated review sign-offs, change tickets or discovery scan logs showing additions and removals	Reviews are scheduled but not evidenced, or the last recorded review is older than the defined frequency
Interview: personnel with inventory responsibilities	Ask how new components enter the inventory, who verifies them and how disputes about ownership are resolved	Named role assignments and a walk-through of one recent addition from purchase or deployment to inventory entry	Staff describe a process that differs from the written procedure, or responsibilities sit with a team that no longer exists
Interview: system and network administrators	Ask how they add or retire components, whether they update the inventory during installation and how they learn of unmanaged devices	Examples of recent installs and decommissions and the discovery sources they rely on	Administrators update the inventory after the fact, or they rely on memory for components they did not install
Test: processes for managing the system component inventory	Trace a sample of components through the lifecycle and check that the process produces an accurate record at each step	Procedure documents, workflow records and a reconciliation between discovery results and the inventory	Process exists on paper but reconciliation is never run, so discovered and recorded components diverge
Coverage of the six determination statements	Map each statement to one examine, interview or test activity and record a finding for each, including the defined frequency and the accountability information	Assessment worksheet that cross-references statements to artifacts and the assessor's interview notes	Statements are assessed as a single item, which hides gaps in accountability fields or review frequency

Evidence that passes a CM-8 assessment and how to keep it current

An assessor testing CM-8 looks for an inventory that is complete, consistent and maintained, not one that was built once for the audit. The cards below cover the artifacts that show this, what the assessor checks in each, and how to keep them current through routine operations rather than periodic rework.

Current inventory export with timestamps

This is the core artifact: a full export of the component inventory showing every system component, its location and its status, with a generation timestamp. The assessor checks that the export matches the live environment on a sample of hosts and that its timestamp is recent relative to the review cycle your own policy defines. Keep it current by scheduling the export from the inventory platform rather than producing it by hand, and retain each dated export so you can show how the inventory changed over time. Confirm with your tool vendor exactly which export formats and filters it supports.

Inventory attribute definitions

A data dictionary explaining each field in the inventory, such as asset identifier, hostname, owner, environment, component type and software version, and how each field is populated. Assessors use it to confirm the inventory holds enough detail for tracking and reporting, and that fields are defined consistently across sources. Keep it current by version-controlling the dictionary alongside the inventory schema, and updating it whenever a discovery source or field changes. A field that no one can explain is a finding waiting to happen.

Reconciliation and deduplication records

Records showing how the organization identified and merged duplicate entries, such as one server reported by both a configuration tool and a network scanner under different identifiers. The assessor checks that duplicates were resolved by a defined rule and that the rule was applied, not just described. Keep these records current by running reconciliation as a recurring job and logging exceptions it cannot resolve automatically, with an owner assigned to each. Ask your implementation partner or tool vendor how matching keys are chosen, since the matching logic determines whether duplicates are actually caught.

Review and approval records with dates

Evidence that the inventory was reviewed and updated at the frequency the organization defined, with the reviewer, date, findings and approval for each cycle. Assessors compare these dates against the stated frequency and look for gaps. Keep this current by generating the review package automatically from the latest export, listing changes since the last review, and routing the sign-off through a ticket so the approval is retained. Records that show a missed cycle, documented with a corrective action, are generally more credible than a clean record with no history.

Update records tied to change tickets

Records showing that components added, removed or modified were updated in the inventory as part of the change, ideally at the time of installation and removal. The assessor traces a sample of change tickets to the inventory entries they should have produced and checks the timing. Keep this current by making inventory updates a required step in the change workflow and by using discovery scans to catch anything installed outside that workflow. Confirm with your change management owner which change types create inventory updates.

Accountability assignments and discovery coverage reports

Two linked artifacts: accountability assignments naming an owner or responsible party for each component, and coverage reports showing which network segments and endpoints discovery tools can reach and which they cannot. Assessors check that every component in the sample has an accountable owner and that coverage gaps are known, measured and tracked. Keep these current by setting owner as a required attribute, and by running coverage reports on a schedule that compares discovery results against your network ranges and asset sources. Unmanaged segments should appear as open items with a remediation owner.

What CM-8 costs in money and effort

This table breaks the cost of a CM-8 inventory into its components, marks each as one-time or recurring, and names what pushes it up or down. Use it to structure a written quote and to see where open-source discovery tools can remove license spend, while staff time remains the largest variable.

Cost component	One-time or recurring	Who is paid or who spends effort	What drives it up or down
Tooling or licenses	Recurring if commercial	Software vendor; internal budget owner	Number of endpoints and cloud accounts; self-hosted open-source discovery such as GLPI, Wazuh or osquery can remove per-seat license spend but not hosting or staff time
Engineering time to set up discovery	One-time	Implementation partner or internal platform engineers	Number of discovery sources (agents, cloud APIs, network scans, CMDB imports); heterogeneity of operating systems and network devices
Data cleanup and deduplication	One-time, sometimes repeated after mergers or migrations	Internal asset owners with partner support	Age of existing records, number of overlapping spreadsheets or CMDBs, and whether hostnames, IP addresses and cloud IDs are reconciled to one identifier per component
Accountability data setup	One-time, then recurring updates	Component owners and system owners	Number of owners per component and whether ownership is recorded in the inventory tool or a separate register
Recurring inventory review	Recurring at the frequency the organization defines	Inventory custodians and reviewing owners	Estate size, change rate and how many review cycles the organization sets per year; automated reports reduce manual comparison
Evidence upkeep	Recurring	Compliance lead and control owner	Number of systems in scope, retention of review records and export formats the assessor expects
Unauthorized component detection tuning	One-time setup, recurring tuning	Security operations staff	Number of network segments scanned, false positive rate and how alerts route into the change process
External review or testing	Periodic	Independent assessor or testing firm	Scope of the assessment, whether the assessor samples inventory records against live discovery data, and the number of systems sampled
Auditor sampling	Periodic	Independent auditor or assessor	Sample size set by the assessor, quality of the inventory export and whether reconciliation evidence is ready before fieldwork

Self-hosted open-source tools that produce CM-8 inventory evidence

Four self-hosted open-source tools can produce parts of the CM-8 evidence set: a managed asset register, endpoint software and hardware collection, scheduled host queries and forensic collection across groups of systems. Each covers a different slice of the inventory, so most programs combine two or more and reconcile their outputs against one authoritative record.

GLPI Assets module

GLPI's Assets module holds computers, software, network equipment, printers, phones and racks, entered by hand or pushed automatically by the GLPI Agent through native inventory available since version 10. It suits the accountability record CM-8 asks for: owner, location and status per component. Confirm that the agent covers your operating systems and that network devices without an agent are entered and reviewed on the same schedule. License: GPL-3.0-or-later, so review obligations if you modify and distribute it.

Wazuh Syscollector inventory

Wazuh's Syscollector module reports hardware, operating system, installed software, network interfaces, open ports, processes, services, users, groups and Windows updates from each endpoint into the Wazuh indexer. It supports CM-8 evidence that the inventory reflects live systems, and its reports can be compared against the register. Check agent coverage, collection intervals and how reports are retained as evidence. License: GPL-2.0-only, which carries source obligations for distributed modifications.

osquery fleet queries

osquery exposes running processes, loaded kernel modules, open network connections, browser plugins, hardware events and file hashes as SQL tables, and osqueryd schedules those queries across a fleet. Scheduled queries can show components that appear outside the approved inventory, which supports the unauthorized-component detection enhancement. Confirm query schedules, result handling and where results are stored, since those define the evidence. License: Apache-2.0 OR GPL-2.0-only, and you may choose either license.

Velociraptor hunts

Velociraptor collects artifacts defined in VQL and runs hunts across a group of systems, scheduling offline machines to collect when they reconnect. A hunt can answer a targeted question such as which hosts run a given software package, and each hunt produces a notebook for analysis. It fits investigations and one-time verification rather than continuous inventory. Confirm that hunt results are retained in a form your assessor can review. License: AGPL-3.0-only, which applies network-use source obligations to modified versions offered to users.

Who owns the inventory, who prepares it and what the auditor checks

The organization owns CM-8. The inventory is a record of the organization's own system, so the organization decides what counts as a component, who is accountable for each item and how often the inventory is reviewed. No partner or tool can make those decisions on its behalf. Owners of the inventory need to be named in the configuration management plan and the inventory itself, and they must be able to explain why each item exists and what it is used for.

Scope and granularity: Decide what level of detail is useful for tracking and reporting, such as hosts, virtual machines, network devices, containers and key software, and write that decision down.
Named owners: Record an accountable owner or team for each component, including the information that CM-8 calls accountability data.
Review cadence: Set the review frequency in policy, assign who performs each review and keep the records of reviews and updates.
Exception decisions: Approve which components are excluded, for example isolated lab systems, and record why.
Ongoing operation: Staff the process for new hardware, decommissioned assets and reconciliation against change records.

Before engaging anyone, confirm with your assessor which review frequency and accountability fields your own policy requires, since those are organization-specific parameters.

Where CM-8 inventories usually fall short and how to close each gap

Most CM-8 findings trace back to a few structural problems: records that do not reconcile, no owner on each component, blind spots in cloud and container estates, and no link between changes and the inventory. Each card below names one gap, the action that closes it and the evidence an assessor can examine.

Duplicate records with no stable key

When several discovery tools each create their own record for the same host, the inventory counts one server two or three times and the totals stop matching reality. CM-8 expects the inventory to avoid duplicate accounting. Close the gap by choosing one authoritative identifier, such as a hardware serial, asset tag or a hostname and MAC pairing, and reconciling every discovery source against it before records are published. Evidence: a reconciliation rule written into the CM procedure and a sample showing one record per component across tools.

No accountability field on components

An inventory entry without a named owner cannot answer who approves a change to it, who patches it or who is told when it fails. CM-8 calls for accountability information in the high baseline (CM-8(4)), and the inventory should carry it for every baseline. Add mandatory owner, business function and administrator fields, and reject records that leave them blank. Evidence: field definitions in the inventory schema and a report showing zero components without an accountable owner.

Cloud and container resources missing

Virtual machines, managed databases, serverless functions and container workloads are often created by pipelines and never reach the on-premises scan. Because CM-8 requires the inventory to include all components of the system, these resources are a direct finding. Define which cloud accounts, clusters and namespaces are in the system boundary, then pull their resource lists from the provider APIs or the cluster on a schedule. Evidence: the boundary list, the scheduled export and a reconciliation of cloud resources against the inventory.

Ad hoc reviews without a defined frequency

An inventory that is reviewed when someone remembers is hard to defend, because CM-8 requires reviews and updates at a defined frequency. Set the cadence in the CM plan, assign a reviewer, and record the date, scope and outcome of each review. Track exceptions, such as components that have not reported within the expected window, as open items. Evidence: the approved review frequency, signed review records and the update history that follows each review.

Change tickets not linked to inventory

When a server is added, moved or retired through a change ticket but the inventory is updated later or not at all, the record drifts from the live system. CM-8(1) expects updates during installation and removal, and the moderate and high baselines select it. Make the inventory update a required closure step in the change workflow, and compare change records with discovery data each cycle. Evidence: the change template with an inventory field, closed tickets matched to inventory entries and a list of discrepancies with resolution dates.

Unexpected components go undetected

A component that appears between reviews, such as an unapproved host, a rogue device or software that nobody registered, is invisible to a manual inventory. CM-8(3) asks for automated detection of unauthorized components in the moderate and high baselines. Run continuous discovery against the approved inventory, alert on any component that does not match, and record how each alert was investigated. Evidence: detection rules or scan configuration, alert logs and the disposition of each unauthorized finding. Confirm the discovery coverage of each tool against your own network before relying on it.

How much effort, time and outside help does CM-8 need?

How much effort does a first CM-8 inventory take and what drives it?

No researched figure is available for effort, so the honest answer depends on the size and churn of your estate. The main drivers are the number of component types you track (hardware, operating systems, installed software, network devices, virtual machines, containers), how many sources of truth already exist, and how many teams own parts of the system. A first inventory is mostly discovery and reconciliation: collecting records from cloud consoles, hypervisors, CMDBs and spreadsheets, then removing duplicates. Ask any partner to size the work by component count, number of data sources and number of owners, and to state which parts are one-time and which recur with each review cycle.

Can a small team build a CM-8 inventory in-house?

Often yes, if the system boundary is small and one person can name the owner of every component. CM-8 does not require a particular tool, so a small team can start with a spreadsheet or an existing asset register and add discovery tooling later. The risk grows when components are created automatically, such as autoscaling instances or containers, because a manual list goes stale quickly. A small team should confirm it can reconcile against cloud or hypervisor records, assign accountability information to each entry and keep the review schedule your organization defines.

What does the organization need to supply before the work starts?

The organization owns the inventory and must provide the people and access that make it accurate. Expect to supply named owners for each system area, read-only access to cloud accounts, hypervisors, network management and endpoint consoles, existing asset data and any change records, and a decision on the level of detail each component type needs. Someone with authority must approve the review frequency and the accountability fields. Confirm these inputs in writing before scoping, because missing access is the most common reason discovery stalls.

What will an auditor ask for at the first CM-8 assessment?

An assessor working from SP 800-53A will typically examine the configuration management plan, the current system component inventory and records of inventory reviews and updates, interview the people responsible for inventory and the system administrators, and test whether the inventory process works in practice. Expect to show that the inventory matches the live environment, that duplicates were resolved, that accountability information is present and that reviews happened at the frequency your organization defined. Only an independent assessor issues the assessment result, so ask your assessor to confirm the evidence format before you collect it.

Do self-hosted open-source tools satisfy CM-8 on their own?

No. Tools produce evidence, but CM-8 is met by an organization process that defines the inventory, its detail level, owners, review frequency and reconciliation. Self-hosted options such as GLPI for asset records, Wazuh Syscollector for endpoint hardware and software inventory, and osquery for scheduled queries across hosts can feed that process. Velociraptor is mainly used for forensic collection and hunts, so it supports inventory checks rather than replacing them. Confirm each tool's coverage against your own component types, because no tool discovers everything in every environment.

What should a written, fixed-scope quote for CM-8 include?

A fixed-scope quote should state the system boundary, the component types in scope, the data sources to be reconciled, the tools to be deployed or integrated and who hosts them, and the evidence deliverables such as the inventory export, review records and procedure documentation. It should separate one-time work from recurring work, name the reviews covered and the assumptions about access and owner availability. Ask which items are outside scope, such as the auditor's fees, and how changes to scope are priced. DeployOpen plans and documents this work in writing before it starts, and does not publish a price list, so a quote follows from the agreed scope.

Which CM-8 enhancements add the most effort?

Enhancements that automate updates and detect unauthorized components usually add the most work, because they depend on integration rather than documents. Under the SP 800-53B baselines, CM-8(1) and CM-8(3) apply at moderate and high, while CM-8(2) and CM-8(4) apply only at high. Automated detection needs reliable agents, network visibility and an agreed response path, and accountability fields need ownership data that many organizations do not yet hold. Confirm with your assessor which baseline and enhancements apply to your system before estimating integration effort.

How DeployOpen scopes, deploys and prepares CM-8 inventory evidence

DeployOpen plans and implements self-hosted open-source inventory tooling inside your own infrastructure, so that the CM-8 component inventory is defined, collected and documented before any assessor looks at it. We prepare systems and evidence; your organization owns the control and an independent assessor tests it.

How we scope

Confirm which system boundary the CM-8 inventory must cover, including cloud accounts, data centers and air-gapped segments.
Agree in writing which component types, detail fields and accountability attributes the inventory will hold.
Define the review frequency and the owner for each inventory data source, documented in the scope before work starts.

How we build

Deploy and configure a self-hosted inventory source such as GLPI Assets, Wazuh Syscollector or osquery, matched to your environment.
Set up deduplication rules so each component is counted once, with checks that compare collected records against the agreed scope.
Test that unauthorized or unrecorded components surface in reports, and document the results for your own review.

How we hand over

Deliver the configured inventory tooling, data source mappings and runbooks for updating records at install and removal.
Provide inventory export samples, review records and update logs that show how the CM-8 inventory is maintained over time.
Walk your control owners through the evidence package so they can explain it to the independent assessor themselves.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts; we provide a quote from that scope.
Ongoing support, upgrades and continuous testing of the inventory tooling are available as a retainer.
Confirm any retainer terms, response expectations and update cadence in the written agreement before you sign.