Asset Inventory Across CMMC, FedRAMP Rev5, and FedRAMP 20x

The core concept

Asset inventory answers one question: what is running in our environment, and who owns it?

That sounds basic. It is not. Inventory is the substrate every other compliance discipline runs on. Vulnerability management needs it to verify scan coverage. Change management needs it to scope impact. Continuous monitoring needs it to know what to monitor. Compliance reporting needs it to define the authorization boundary. OSCAL documentation needs it to describe the system accurately. If inventory is wrong, everything downstream is wrong.

A stale inventory is not an administrative gap. It is a systemic failure. A server stood up three months ago and never added to the inventory was never scanned, its vulnerabilities were never tracked, and it does not appear in the authorization boundary. That is not a documentation gap. That is a security gap.

Every framework wants a current, complete inventory. They differ on update cadence, metadata requirements, and whether automated discovery is expected or required. The underlying need is the same.

What CMMC requires

You cannot secure CUI if you do not know where it lives.

The relevant practices:

• CM.L2-3.4.1 (Level 2): Establish and maintain baseline configurations and inventories of organizational systems. 5-point, not POA&M-eligible. This is the inventory practice. It covers hardware, software, firmware, and documentation across the system development lifecycle. CUI scope depends on knowing where CUI is processed, stored, and transmitted.

Supporting practices add depth:

• CM.L2-3.4.6 (Level 2): Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities. 5-point.
• CM.L2-3.4.7 (Level 2): Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services. 5-point.

Both depend on knowing what is running. You cannot restrict what you do not know exists.

What a C3PAO assessor looks for:

• A hardware and software inventory covering every CUI-scope asset
• Accuracy that matches what is actually deployed, not what was deployed six months ago
• Asset classification by type and CUI handling role
• Regular updates with evidence the inventory reflects the current state
• An onboarding process that adds new assets to the inventory before they enter production
• Detection of unauthorized assets, not just tracking of authorized ones

The common gap: inventory lives in a spreadsheet that is months or years out of date. Cloud resources are missing. Software inventory is incomplete, covering servers but not SaaS tools, not software libraries, not containers. No automated discovery to check accuracy against the real environment.

CM.L2-3.4.1 is 5-point and not POA&M-eligible. An out-of-date inventory at assessment time is not a finding you can close later. It is a scoring problem you have to fix before the audit. And because inventory feeds every downstream discipline, a broken inventory generates cascading findings across vulnerability management, continuous monitoring, and compliance reporting. A single broken dependency, the inventory, creates findings in four other disciplines.

What FedRAMP Rev5 requires

FedRAMP makes the inventory requirements explicit.

The relevant control:

• CM-8 (System Component Inventory): reviewed and updated at least monthly.

Monthly. Not quarterly, not annually. Every month, the inventory has to reflect the current state of the authorization boundary. Full coverage across hardware, software, firmware, cloud resources, and services, with accurate metadata: owner, location, function, FIPS categorization, and version.

Under Rev5 Balance MAS, inventory defines the assessment scope. Assets outside the boundary need justification for exclusion. MAS-CSO-IIR (MUST) requires identifying all information resources that handle federal customer data. At its core, this is an inventory exercise.

Scan correlation is testable. Vulnerability scanners have to cover every inventoried asset. Gaps between inventory and scan coverage are audit findings. If the inventory lists 80 servers and the vulnerability scanner covered 72, the assessor will ask about the other 8. Every time.

What 3PAOs look for:

• Monthly inventory updates with timestamps showing the cadence is met
• Scan coverage that matches the inventory exactly
• Full metadata on every asset: owner, FIPS categorization, federal data handling role, location, function
• Boundary alignment between the inventory and the SSP authorization boundary description
• Evidence that new resources are added to inventory as part of the provisioning process

Common gap: inventory and scan coverage do not match. Resources are added to the environment through cloud automation without an inventory update. Nobody reconciles the inventory against actual infrastructure on the monthly cadence. Decommissioned resources stay in the inventory for months after removal.

A spreadsheet updated quarterly fails both the monthly cadence and the coverage test. Even if the data is correct at the quarterly update, it drifts for three months until the next one.

What FedRAMP 20x requires

Traditional programs maintain inventory. 20x requires that inventory be generated automatically, in real time, from authoritative sources. Different verb, different architecture.

The relevant KSIs:

• KSI-PIY-01 (Automated Inventory): use authoritative sources to automatically generate real-time inventories of all information resources when needed. Machine-based validations check that automated configuration services provide inventory, that compute instances have required inventory tags (Name and Environment at minimum), and that storage resources have required inventory tags. Our 20x implementation data shows these validations running daily against the cloud environment.
• KSI-AFR-01 (Minimum Assessment Scope): the MAS process requires identifying all information resources likely to handle federal customer data. This is validated through the organization scoping document, active inventory reports, component inventory reports, and network diagrams.

MAS inventory-related MUST requirements:

• MAS-CSO-IIR: identify all information resources handling or impacting federal customer data
• MAS-CSO-FLO: document information flows for all resources
• MAS-CSO-TPR: document third-party information resources (usage, justification, mitigations)

KSI-PIY-01 is the hard differentiator. It does not ask whether you have an inventory. It asks whether your inventory is generated automatically from authoritative sources in real time. That rules out spreadsheets, manual edits, and quarterly update rituals.

Our 20x validation data makes this concrete. KSI-PIY-01 machine-based validations check three things: that an automated configuration service provides inventory (KSI-PIY-01.1), that compute instances have required tags (KSI-PIY-01.2), and that storage resources have required tags (KSI-PIY-01.3). These checks run daily. Failures create Issue Tickets automatically. When we first enabled these validations, we found untagged instances and untagged storage buckets. The validations caught what a quarterly manual review would have missed for months.

Common gap on the path to 20x: manual inventory processes, no API integration with cloud providers, no real-time capability, third-party resources not inventoried as structured data. An organization that passes Rev5 CM-8 with a well-maintained monthly process can still fail KSI-PIY-01 if that process depends on a human exporting data and updating a spreadsheet. The monthly cadence is fine. The manual method is not.

If your inventory update process involves a human editing a document, KSI-PIY-01 is a gap. This is an architecture change, not a policy change. You do not fix it by updating your inventory policy to say “automated.” You fix it by building the pipeline that generates inventory from authoritative sources.

The pain we lived

Inventory was the problem under everything else.

We managed asset inventories in spreadsheets. Cloud resources were stood up through infrastructure automation and never added to the inventory spreadsheet. Decommissioned resources stayed listed for months because nobody removed them. Every month, we reconciled the spreadsheet against the live environment by hand. Export the resource list from the cloud provider. Compare it against the spreadsheet. Find the mismatches. Update the spreadsheet. Do it again next month.

The reconciliation was not the worst part. The worst part was that every other discipline depended on an inventory we could not trust.

Vulnerability scanners reported on assets that were not in the inventory. The inventory listed assets the scanners never touched. When we prepared the monthly ConMon package, the vulnerability scan report covered one set of assets and the inventory listed a different set. The assessor would look at both, see the mismatch, and that was a finding.

Boundary definition suffered the same way. The SSP described the authorization boundary based on the inventory. When the inventory drifted, the boundary description drifted with it. New cloud resources that were never added to the inventory were, by definition, outside the documented boundary. But they were inside the actual environment, processing data. That is an undocumented resource in scope, which is an SSP accuracy finding.

Change management needed inventory to assess impact. When a change ticket referenced “application servers,” the assessor wanted to know which specific servers, tied to the inventory. If the inventory did not list them accurately, the change ticket’s impact assessment was incomplete.

Third-party resources were the worst. SaaS tools, external APIs, vendor-hosted services. These rarely made it into the inventory because they were not cloud resources in the traditional sense. Someone would sign up for a monitoring tool or integrate a third-party API. It never appeared in the inventory because the inventory was scoped to “infrastructure.” Under MAS-CSO-TPR, every third-party information resource needs to be documented with usage, justification, and mitigations. We tracked these in a separate spreadsheet that was even more out of date than the infrastructure inventory.

Software inventory was its own problem. Servers were tracked (sometimes). But the software running on them was not: application versions, libraries, container images, database engines. When a CVE was announced affecting a specific software version, we had no structured way to answer “which of our assets run this software?” without logging into each environment and checking manually. A critical CVE announcement that should take five minutes to scope took half a day across multiple environments.

Across 15+ environments, each with its own cloud accounts, its own resource lifecycle, and its own rate of change, keeping inventory accurate was a constant battle. And losing that battle meant losing trust in every downstream report, every scan coverage claim, and every boundary definition.

How we automate it

Here is how we built asset inventory in Stratus GRC-ITSM. The goal was to make inventory a live query against the environment, not a document someone updates.

1. Cloud integration. The platform syncs directly with the cloud environment. New resources are discovered automatically. Removed resources are flagged. Configuration changes are reflected. The cloud provider API is the authoritative source, and the inventory updates from it continuously.
2. OSCAL component linkage. Every asset links to its OSCAL Component definition. The inventory is not just a list of resources. It is tied to the system definition that drives authorization documentation. When the SSP references a component, the live inventory data for that component is current.
3. Scan coverage validation. The platform cross-references inventory against scan results. Assets without scan coverage are flagged automatically. Coverage gaps do not wait for a quarterly audit or a 3PAO assessment to surface. When a new server is provisioned and the next scan cycle does not include it, the gap is visible immediately.
4. Boundary enforcement. Assets within the authorization boundary are clearly marked. Under Rev5 Balance MAS, this sets your assessment scope. The federal-data-handling flag is captured at ingest, so MAS-CSO-IIR is satisfied by the data model itself, not by a retroactive classification exercise.
5. Sync health monitoring. Integration health is tracked as a first-class metric. If a sync fails, it is flagged right away, not discovered during the next monthly review. You know the inventory is current because you can verify the last successful sync timestamp for every integration.
6. Third-party resource catalog. Third-party information resources are tracked as first-class records with documented usage, justification, and mitigations per MAS-CSO-TPR. Not in a separate spreadsheet. In the same system as the rest of the inventory, with the same linkage to components and documentation.
7. KSI-PIY-01 validation. The integration pipeline itself satisfies the automated inventory generation requirement. Machine-based validations check that automated configuration services provide inventory, that instances have required tags, and that storage resources are properly tagged. Failures create Issue Tickets. The inventory is not just generated automatically. Its accuracy is validated automatically.

graph TD
    ASSET[Asset Record] --> VULN[Vulnerabilities / Issues]
    ASSET --> SCAN[Scan Coverage]
    ASSET --> CONFIG[Configuration Baseline]
    ASSET --> OSCAL[OSCAL Component]
    ASSET --> CHG[Change History]
    VULN --> POAM[POA&M]
    SCAN -->|gap?| FLAG[Coverage Gap Alert]
 
    style ASSET fill:#2b5797,stroke:#5b9bd5,color:#fff
    style VULN fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style SCAN fill:#1a3d5c,stroke:#4ecdc4,color:#fff
    style CONFIG fill:#5c4a1a,stroke:#ffc857,color:#fff
    style OSCAL fill:#4a1a5c,stroke:#c77dff,color:#fff
    style CHG fill:#1a5c3d,stroke:#51cf66,color:#fff
    style POAM fill:#5c1a3d,stroke:#ff6b9d,color:#fff
    style FLAG fill:#5c1a1a,stroke:#ff6b6b,color:#fff

Inventory should be a live query against your environment, not a document someone updates. When an assessor asks “show me your inventory,” you show the current state, not last month’s export. When they ask “which assets handle federal data?”, the answer is a filter, not a manual classification exercise. The same data source feeds CMMC assessment evidence, FedRAMP monthly inventory updates, and 20x real-time inventory requirements.

The asset is the core node. Everything connects to it: vulnerabilities, scan results, changes, configurations, OSCAL components, POA&M entries. That is not a spreadsheet. That is a data model. When someone asks “which assets have open critical vulnerabilities?” or “which assets in the boundary have not been scanned this month?” those are queries against live data, not questions that require someone to cross-reference two exports.

One data model produces CMMC hardware and software inventory evidence, FedRAMP monthly inventory updates for CM-8, and 20x automated inventory validation for KSI-PIY-01.

Compliance is a byproduct of operations, not a separate workstream.

FAQ

This article is part of a 15-part series on the operational disciplines that CMMC, FedRAMP Rev5, and FedRAMP 20x all test. [Read the series overview: Stop Building for Compliance. Build for Operations.]