4 MIN READ
Shadow cloud amounts to the largest single category of unknown risk in the typical 2026 enterprise, and the central IT org has not got a map. The unsanctioned AWS account, the forgotten GCP project, the SaaS tool the procurement lead signed up for on a personal credit card, none of it shows up in the asset inventory the security org audits against. The risk has a shape, and the shape sits as invisible to everyone who is supposed to be measuring it.
Lineage worth knowing. The pandemic kicked off the sprawl, and the work from home transition multiplied it. Per the Wiz 2026 State of Cloud Security report, 65 percent of security orgs admit they cannot identify more than half of their cloud footprint with any confidence. SaaS sprawl added another layer, with the average enterprise running more than 200 SaaS applications, and the typical IT org with visibility into less than 40 percent of them. The shadow cloud problem amounts to a category of risk the security lead cannot measure, the outside assessor cannot audit, and the executive team cannot budget for. The state of the problem in 2026 sits as worse every year for the last five years, and there sits no signal the trend amounts to reversing.
What shadow cloud actually is
Four layers make up the typical shadow cloud footprint, in roughly that order of how much risk each one carries. The unsanctioned cloud account leads the way: an engineer spins up an AWS account or an Azure subscription with a personal credit card, the project goes into production, the account runs for years without anyone in the platform org knowing it exists. The unsanctioned cloud workload sits as the next layer: the sanctioned account, the workload that does not match the team standards, the monitoring that does not pick it up, the security org that never sees it. The unsanctioned SaaS application covers a different shape entirely, with a line of business signing up for a tool, putting customer data into it, never telling IT, and the data sitting in a SaaS the security org has not assessed. The shadow data closes the picture, with an analyst exporting the customer list from the sanctioned warehouse into a personal Dropbox or a personal Google Drive, the data leaving the enterprise perimeter, and the data living in a system nobody monitors. Each layer carries a different risk profile: the unsanctioned account carries the data exfiltration risk, the unsanctioned workload carries the lateral movement risk, the unsanctioned SaaS carries the compliance risk, and the shadow data carries the breach notification risk.
Why the typical enterprise has not fixed it
A handful of reasons keep coming up in the postmortems. The tooling sits as the most common one, with the major cloud security posture management platforms (Wiz, Lacework, Orca, Prisma Cloud) all doing parts of the job and none of them doing all of it. An enterprise running AWS, Azure, GCP, and 200 SaaS apps needs a stack of three or four tools to cover the ground, and the integration cost sits as the part the budget never quite covers. The culture runs as a close second: the engineering orgs see the central IT org as the people who say no, and they work around them. The workaround runs faster than the central team can map it, and the visibility gap widens every quarter. The priority sits as the third reason: the central team focuses on the visible cloud because the visible cloud amounts to the one generating the incidents, and the shadow cloud does not generate incidents until the day it does. The incident that finally puts the shadow cloud on the priority list sits as the one nobody planned for.
How to actually fix it
A handful of moves if the security org sits as starting the shadow cloud program from scratch. The discovery sweep comes first: pick the tool that fits the environment (a CSPM for the cloud accounts, an SSPM like Adaptive Shield or AppOmni for the SaaS layer, a CASB for the network traffic, open source options like prowler for the budget constrained case), run it, get the list. The list sits as the foundation. The guess amounts to the foundation that fails the audit. The owner assignment covers the next step, with every shadow cloud item on the list getting a named owner, even if the assignment runs as provisional and the ownership sits as contested. The ownership creates accountability, and accountability creates the work that gets prioritised. The developer experience focus closes the program, with the security org building around what makes the engineering org’s life easier, not around what makes the audit cleaner. The shadow cloud program the engineering org actually uses amounts to the one that catches the shadow cloud. The program the engineering org works around amounts to the program that misses the next breach.
The bottom line
Discovery sweep, named owners, developer experience first. The shadow cloud program the security org can run sits as the program that knows what sits out there. The program the engineering org will use sits as the program that does not get worked around. Pick the tool, assign the names, and build for the engineer who has a deadline, not for the assessor who has a checklist.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
