New: Brownfield onboarding
Learn more
CMMC 2.0, HIPAA, PCI DSS 4.0, and state privacy laws now demand complete cloud asset inventories. Learn why full infrastructure visibility is a compliance prerequisite.
The US regulatory landscape is evolving. It’s also fragmenting, accelerating, and getting a lot less forgiving. And organizations that can’t produce a complete, current inventory of their cloud infrastructure are now starting every compliance conversation from a deficit. And not a small one.
Over the past two years, cloud compliance requirements in the US have shifted from “you should probably have this under control” to “prove it—before we proceed.”
The common thread running through all of it is the same: regulators are asking organizations to account for their full infrastructure estate, not just the part they’ve neatly organized.
Almost every compliance framework starts from the same assumption:
You know what you have.
You know where it is.
You can prove it’s governed.
So, asset inventory is a prerequisite for almost every other compliance obligation. Afterall, you cannot enforce access controls on assets you don't know exist, cannot apply patch management to systems outside your inventory, and cannot demonstrate data handling compliance for infrastructure that isn't accounted for.
In practice, most organizations have an up-to-date invetory… for a portion of their estate.
That portion is usually:
Everything else is still running. Still costing money. Sometimes still handling regulated data. Just… not in the inventory.
This is the ordinary condition of any enterprise cloud estate that has grown incrementally over multiple years across multiple providers. The gap between what's running and what's governed is the gap that compliance frameworks are increasingly designed to find and penalise.
The Cybersecurity Maturity Model Certification framework is now a hard contractual requirement for DoD work. At its core, the framework asks for something deceptively simple: a complete, current inventory of all assets within the authorization boundary — on-prem, cloud, everything. Not most of it. Not the well-behaved parts. All of it.
And it’s not a one-time exercise. That inventory needs to be reviewed regularly and kept current. Resources that exist within the boundary but outside the inventory are a control deficiency.
HIPAA has always expected health organizations to understand their environment. The proposed updates heading toward 2026 finalization raise the bar on technology asset inventory and network mapping across every system that creates, receives, maintains, or transmits electronic protected health information (ePHI).
The existing Security Rule already requires a “thorough and accurate” risk analysis, which, in practice, assumes you know what assets you’re analyzing. The modernization effort just removes any remaining ambiguity and tightens expectations around completeness and currency. An outdated or partial inventory will essentially become non-compliant.
The current version of the Payment Card Industry Data Security Standard raises the bar and removes a lot of the wiggle room organizations used to rely on. The standard tightens expectations around scoping, asset inventory, and cloud environment documentation within the cardholder data environment (CDE). And it’s very explicit about the need for a complete, accurate, and up-to-date inventory of every system component in scope.
Anything that exists inside the CDE but outside your documented inventory is a scope deficiency that assessors are trained to identify. For organizations that have expanded their cloud estate since their last PCI assessment, this is where problems tend to surface. There’s a decent chance that the inventory you were assessed against no longer reflects reality. New accounts, new services, automation-driven resources, especially those provisioned outside a governed platform, create a slow but steady scope drift.
The wave of state privacy laws that came into enforcement through 2025 and 2026 vary in their specific requirements, but some include obligations around data inventory, data mapping, and the ability to demonstrate what personal data is held and where. For cloud infrastructure, this translates to a requirement to know which systems handle personal data of residents of the relevant state, what controls apply to those systems, and how that governance is maintained over time.
An organization that cannot produce a complete inventory of its cloud infrastructure cannot produce a reliable data map. So, organizations can fail compliance checks simply because their asset inventory doesn’t reflect reality and everything else depends on it.
The standard response to compliance pressure is some version of: govern new deployments carefully, and address the existing estate over time through a migration or remediation programme. However, law enforcement doesn't wait for remediation programmes to complete. The compliance obligation applies to what exists now.
Closing the governance gap for existing infrastructure requires three things:
Every compliance conversation eventually reaches the same point: whether the organization's governance model covers its full infrastructure estate. The honest answer, for most organizations with multi-year cloud histories, is that it does not.
The gap between what's governed and what's running is known, deferred, and treated as a future-state problem. But now, the frameworks that apply to healthcare, defence, financial services, and technology organizations are asking the question more directly, with more specific evidence requirements, and with less tolerance for scope limitations.
Visibility, governance, and monitoring tools that allow brownfield onboarding is how that answer changes. Not by building a new governance model from scratch, but by extending the one that already exists to cover the estate in its entirety, just like it was always supposed to cover. Full coverage must be available now, not at the end of a multi-year programme.
Introducing brownfield onboarding for emma: connect your AWS, Azure, GCP and VMware accounts, discover what's running — instances and Kubernetes clusters — and bring it under emma’s unified governance without modifying any running workload. No migrations, no disruption. See how it works at: https://www.emma.ms/tutorials/how-to-import-your-existing-cloud-infrastructure
For US organizations navigating CMMC 2.0, HIPAA modernization, PCI DSS 4.0, or state privacy law requirements, speak with our team at emma.ms/contact
