New: Brownfield onboarding
Learn more
Ungoverned cloud infrastructure is precisely the condition under which the most serious security and audit failures happen.
Security teams spend years building controls around the infrastructure they know exists. Vulnerability management scans, policy enforcement, monitoring agents, and incident response playbooks all assume the same thing: that what you see is what you actually have.
That assumption is almost always wrong.
Cloud infrastructure doesn’t respect the neat boundaries drawn for it. It grows in the gaps:
These aren’t rogue deployments by evil insiders. This is just ordinary “shadow” infrastructure that quietly runs, and lives outside the controls designed to govern it.
The most honest reason is that monitoring coverage is opt-in, not automatic. Every observability tool requires someone to actively instrument resources. While some basic metrics may exist by default, meaningful monitoring only happens when someone deliberately sets it up. Resources don’t become fully monitored just because they exist in your AWS account.
Then layer on the practical realities. Engineers spin up resources during incident response or debugging — a test RDS instance, a temporary Lambda, an extra ECS task — and the urgency of the moment means nobody goes back to add it to the monitoring stack. It just persists.
IaC coverage is never 100%. Plenty of resources were ClickOps'd into existence through the console, especially in the early days of a company's cloud journey. Those resources don't show up in Terraform state, so any automation that derives monitoring config from IaC misses them entirely.
Teams also drift apart. The platform team might standardize on one monitoring approach, but an acquired team or a different business unit is running their own setup — or nothing at all. Multi-account strategies make this worse: security and platform teams often have great visibility into the accounts they manage, and near-zero into the ones they don't.
And then there’s the hybrid gap. When observability platforms are cloud-native by design — built for AWS, Azure, GCP — they don’t see on-prem workloads like VMware estates, bare metal, or private cloud. So organizations running hybrid environments have a structural blind spot baked into their tooling.
Several dynamics sustain and widen this gap over time.
Over time, a few consistent dynamics widen this gap:
It’s just the natural result of cloud environments growing faster than the systems designed to control them.
The security implications of ungoverned infrastructure fall into three categories that recur consistently:
Unpatched and unmonitored assets
Vulnerability management programmes, patch cycles apply, and monitoring agents, all cover infrastructure within the governed scope. Resources outside that scope receive none of these protections.
Exposed data and misconfigured access controls
Databases and storage outside the governance model don’t get the same access reviews, encryption, or logging. The policy gap becomes an exploitable gap.
Audit exposure
Auditors don’t care about “mostly governed” estates. If you can’t account for all running resources, you get a finding. The finding may be framed as a process gap, a control deficiency, or an incomplete scope of assessment.
Most security tooling addresses drift detection. It’s identifying when a governed resource changes in ways that deviate from its defined state. Configuration management tools flag when a setting changes. IaC drift detection identifies when deployed infrastructure diverges from the declared configuration. Change tracking logs modifications to resources already under management.
These are valuable, necessary controls. But they’re not sufficient. They answer what changed in what we're already managing?, not what exists that we didn’t even know about?
They answer the question:
They do not answer the question that ungoverned infrastructure poses: what exists in our cloud accounts that isn't under any management at all?
After brownfield import, the emma platform re-inventories every connected account on a schedule. Anything outside the governance perimeter is flagged in the UI. This ensures full cloud estate is always visible, and can be brought inside the governance perimeter in minutes. Learn more at: https://www.emma.ms/products/govern-existing-infrastructure.
Regulatory frameworks are tightening. DORA, NIS2, CMMC 2.0, PCI DSS 4.0—they all ask the same thing: can you demonstrate governance over everything that matters, all the time?
A governance model that only covers some deployments produces evidence with a scope limitation. That’s a finding in most frameworks. Fully controlled brownfield onboarding, combined with periodic discovery audits, fixes that.
Connect existing accounts, import resources, so that:
Without brownfield coverage and periodic discovery:
With brownfield coverage and periodic discovery:
The standard security review asks whether controls are operating effectively. The preceding question should be: does the governed estate equal the actual estate?
For most multi-year, multi-team cloud environments, the answer is no. The gap grows continuously, accumulates silently, and only partially shows up in manual reviews.
Closing that gap is not a one-time task. It requires ongoing ungoverned resource detection so that security and compliance teams operate from a complete, current picture, not just a convenient subset. And this is where meaningful improvement in cloud security posture actually begins.
emma's brownfield onboarding connects existing AWS, Azure, GCP, and VMware accounts to emma's governance model, with periodic audits that continuously surface ungoverned resources across the full estate. No migrations, no disruption.
See how it works at: https://www.emma.ms/tutorials/how-to-import-your-existing-cloud-infrastructure
For more information, visit: https://www.emma.ms/products/govern-existing-infrastructure
