Shadow data is what happens when the data your security team is responsible for protecting ends up in systems they don't manage, didn't audit, and often don't know are holding it. This is distinct from shadow IT (the use of unauthorized tools) because shadow data can live inside fully authorized SaaS applications. Your Salesforce instance is approved, your Google Workspace is managed, your Notion workspace is on the company plan. The security team knows about all of them. What they may not know is what data has accumulated inside each one, in what form, with what access controls, and whether any of it creates an exposure that wouldn't exist if that data had stayed in the source system.
This post is about how sensitive data ends up in SaaS applications through ordinary business workflows, why it's harder to detect than cloud infrastructure exposure, and what a realistic detection approach looks like.
How data gets there: the ordinary paths
Most shadow data in SaaS doesn't get there through reckless behavior. It gets there through legitimate workflows that nobody thought through from a data security standpoint.
Export to spreadsheet. A sales operations analyst needs to reconcile a list of contacts with a recent deal. They export a Salesforce report to CSV: contact names, email addresses, phone numbers, deal amounts. They upload it to Google Drive to share with a colleague. The file lives in a shared folder for a year. When the colleague leaves, the folder doesn't get cleaned up. The access permissions on that folder never got reviewed. The CSV containing thousands of customer contact records is sitting in Google Drive with sharing permissions set to "anyone with the link can view" because that's what was easiest when the sharing was originally set up.
Collaboration documents. An HR team uses Notion to track candidate information during a hiring sprint. Interview notes, compensation details, background check statuses. The Notion workspace is on the company plan, so it feels controlled. But Notion's page-level sharing allows any page to be made accessible to "anyone with the link" independent of workspace membership settings. HR staff share candidate pages with hiring managers who aren't in the workspace. Those links don't expire. The pages containing candidate names, addresses, and compensation details sit accessible via link indefinitely.
Support ticket context. A customer support team uses a ticketing system that stores full conversation history. Customers frequently include personal information in support requests: account numbers, partial payment information, diagnostic logs that contain embedded user data. The ticketing system is categorized as a "support tool" in the SaaS inventory, not a system of record for PII. Nobody added it to the data inventory because it doesn't feel like a "data store." It contains years of accumulated customer data.
Slack files. Slack's file search is not comprehensive, and most organizations don't actively monitor the file history. Team members regularly share spreadsheets, PDFs, and exports in Slack channels. A payroll administrator shares a payroll summary CSV in a private channel that includes 20 people. That file remains in Slack indefinitely. If someone screenshots it or downloads it, there is no record. If the channel membership hasn't been reviewed since the team reorganized, people who no longer need access may still be members.
Why this is harder to detect than S3 misconfiguration
Cloud infrastructure exposure (an S3 bucket with public access, an RDS instance without encryption at rest) is detectable by reading API-level configuration. You query the AWS API, get the bucket configuration, check the Block Public Access settings and bucket policy, and you have a deterministic answer about whether the bucket is exposed.
SaaS data exposure is harder for three reasons.
First, SaaS access controls are often at a granularity that doesn't map cleanly to standard security controls. A Notion page can be individually shared outside the workspace without any workspace-level policy violation. Google Drive file permissions are per-file and change constantly as users share and reshare. The access model is not just "who is a member of this workspace"; it's a graph of per-object sharing permissions that changes dynamically.
Second, SaaS content inspection requires API-level content access. To know that a Google Drive file contains PII, you need to read the file contents, not just the file metadata. Most security tooling reads metadata (file name, owner, sharing permissions, last modified date). Metadata tells you a file exists with certain permissions. It doesn't tell you whether the file contains 10,000 customer social security numbers or an internal meeting agenda. Content classification requires a different kind of API access, which many SaaS platforms do allow but which requires explicit setup and organizational authorization.
Third, SaaS data stores are organizationally distributed. S3 is infrastructure-owned and audited by the security team. Google Drive is owned by IT and used by everyone. Notion might be owned by no one in particular, provisioned by a team lead two years ago, and never formally added to the IT SaaS inventory. The organizational ownership gap means nobody is thinking about the data security implications of the tool.
The SaaS sprawl dimension
The problem scales with the number of SaaS applications in use. A company with 50 employees might be running 80 to 120 distinct SaaS applications, depending on how you count individual tools versus suites. Most of those are not in the security team's active monitoring scope. The CASB inventory tracks sanctioned tools and is updated when IT formally approves a new SaaS purchase. The actual SaaS footprint includes every app that any employee connected with their corporate Google or Okta credentials, which is a much larger set.
Each application in that footprint is a potential location for sensitive data, with its own sharing model, its own data retention behavior, and its own set of organizational owners who may or may not have thought about data security when they set the app up.
We're not saying every SaaS application is a significant data security risk. Many have no sensitive data at all. But you cannot know which ones do without looking, and you cannot look without a systematic approach to SaaS data discovery.
What detection actually requires
SaaS data discovery at the content level requires connecting to each application's API with read access scoped to inspect file contents and metadata. For the major productivity platforms (Google Workspace, Microsoft 365), the admin-level APIs expose enough to run content classification at scale. For purpose-built SaaS tools (CRM, ticketing, HR platforms), the APIs vary, and content access may be limited to field-level structured data rather than full document content.
The classification problem in SaaS is partly structural. In a database, you can sample column values and classify by column: this column contains email addresses, this column contains SSNs. In a document store like Google Drive, the sensitive data might be anywhere in a document. A single-page PDF might contain one sentence with a customer SSN in context. The sampling strategy has to be different, and the false positive/negative tradeoffs are different.
When PostQKey connects to a Google Workspace or Microsoft 365 tenant for SaaS discovery, the output includes: files with content matching sensitive data patterns, sharing permission state for those files (internal only, link-shareable within the organization, link-shareable publicly), and identity access mapping (which users and groups have access to the file). The combination of classification and access state is what makes a finding actionable. A file containing PII that is shared only with a specific internal group is a different risk than the same file shared publicly via link.
The remediation problem in SaaS
Finding the exposure is half the problem. Remediating it is operationally harder in SaaS than in cloud infrastructure because SaaS files and records are owned by end users, not by the security team. The security team can change an S3 bucket ACL directly. They cannot delete a Google Drive file that belongs to a sales analyst's My Drive without triggering an organizational process.
The practical remediation path for SaaS exposure is notification and owner-driven action. When a finding shows that a file containing sensitive data has overly broad sharing, the notification goes to the file owner with a specific recommendation: remove the "anyone with the link" share, replace with direct user grants or move the file to a shared drive with appropriate access controls. If the file owner doesn't respond within a defined window, escalation goes to their manager or the IT team depending on organizational policy.
For files without a clear living owner (the person who created the file has left the company), the remediation path goes to the file's Google Workspace organizational unit admin or to IT with a recommendation to restrict or archive.
The goal is not zero tolerance for SaaS data. Organizations run their businesses on SaaS tools and data will exist there. The goal is knowing what sensitive data exists in SaaS, knowing what the access state is, and having a workflow that closes the highest-risk exposures, specifically files with broadly accessible sharing containing directly identifying personal data, within a defined and monitored SLA.