Can Your SaaS Vendor See Your Data? (Yes.)

The Uncomfortable Truth

If you use Google Sheets, Airtable, Mailchimp, HubSpot, or almost any other SaaS tool, the vendor can see your data. All of it. Every row, every field, every piece of personally identifiable information you have entered. This is not a conspiracy theory or a worst-case scenario. It is the default architecture of virtually every cloud application you use.

Most people do not think about this. You sign up for a tool, accept the terms of service, and start working. The tool is convenient, the interface is polished, and the assumption is that your data is safe because the vendor says it is. But "safe" and "private" are not the same thing. Your data can be safe from external attackers while being completely visible to the vendor, their employees, and any government entity that issues a subpoena.

This article is not about fear. It is about understanding how SaaS data architecture actually works, why the standard approach leaves your data exposed, and what questions you should ask before trusting any vendor with sensitive information. It is also about an alternative architecture that eliminates the problem entirely.

How SaaS Encryption Actually Works

When a SaaS vendor says "your data is encrypted," they almost always mean two things: encryption in transit (TLS/HTTPS between your browser and their servers) and encryption at rest (data encrypted on disk in their database). Both are important. Neither protects your data from the vendor themselves.

Here is why. Encryption at rest means your data is encrypted when it is stored on the vendor's servers. But the vendor holds the decryption key. They have to — their application needs to read the data to display it to you, to run searches, to generate reports, to process your requests. The encryption at rest protects against a narrow threat: someone who steals the physical hard drive from the vendor's data center. It does not protect against the vendor's own employees, a software breach that compromises the application layer, or a legal demand for your data.

Think of it like a storage unit. The facility has a lock on the front gate. Your unit has a padlock. But the facility manager has a master key that opens every unit. You trust that they will not use it, but the key exists. If someone compromises the facility manager, or if a court orders the facility to open your unit, the lock provides no protection.

The "Encryption at Rest" Illusion

"Your data is encrypted at rest" is the single most misleading statement in SaaS security marketing. It sounds like your data is locked away where nobody can see it. In reality, it means your data is encrypted on disk with a key that the vendor controls. The vendor can decrypt your data at any time, for any reason, without your knowledge or consent.

Here is what encryption at rest protects against: a data center break-in where someone physically removes hard drives. Here is what it does not protect against: a disgruntled employee querying the database, a software vulnerability that exposes application-layer data, a government subpoena served to the vendor, a breach of the vendor's admin tools, or the vendor selling your data to third parties (which their terms of service may explicitly allow for "service improvement" purposes).

The gap between what "encrypted at rest" implies and what it actually provides is enormous. Most customers hear "encrypted" and assume their data is private. It is not. It is encrypted against one specific, relatively rare threat vector while remaining fully accessible to many common ones.

Customer-Managed Keys: Better, But Not Enough

Some enterprise SaaS vendors offer customer-managed keys, also called Bring Your Own Key (BYOK). With BYOK, you provide the encryption key, and the vendor uses it to encrypt your data at rest. You can revoke the key at any time, which makes the stored data unreadable.

BYOK is a meaningful improvement over vendor-managed keys. If you revoke the key, the vendor loses access. If the vendor is breached but the attacker does not compromise your key management system, the encrypted data is useless. BYOK gives you a kill switch that vendor-managed encryption does not.

But BYOK has a critical limitation: the vendor still decrypts your data during processing. When you load a spreadsheet, run a report, or execute a search, the application decrypts the data into memory to perform the operation. During those moments — which, for an active SaaS application, is most of the time — your data exists in plaintext on the vendor's servers. BYOK protects data at rest but leaves it exposed during the operations that actually matter.

Zero-Knowledge Processing: The Only Real Solution

The only architecture that truly protects your data from the vendor is one where the vendor never has access to plaintext data at any point — not at rest, not in transit, not during processing. This is called zero-knowledge or encrypted processing, and it is the foundation NoSheet is built on.

In NoSheet's architecture, sensitive data is encrypted with per-tenant keys at the cell level. The decryption key never exists on NoSheet's infrastructure. When you clean data, deduplicate records, or format phone numbers, those operations work on encrypted data. NoSheet processes the structure without accessing the values. For a detailed technical explanation, read our guide on how zero-knowledge data cleaning works.

This is not an incremental improvement over encryption at rest. It is a fundamentally different architecture. Encryption at rest is a padlock where the landlord has the master key. Zero-knowledge processing is a safe where only you have the combination and the locksmith can repair the mechanism without ever opening the door.

Five Questions to Ask Every SaaS Vendor

Before you trust any SaaS tool with sensitive data, ask these five questions. The answers will tell you everything you need to know about whether your data is actually private or merely encrypted with a key someone else holds.

1. "Can your employees access my data in plaintext?"

Most vendors will say something like "only authorized personnel with a business need." That means yes. Database administrators, support engineers, and on-call staff can query your data. Some vendors limit this with access controls and audit logs, but the technical capability exists. If any employee at the company can run a SQL query and see your customers' SSNs, your data is not private.

NoSheet's answer: No. Our employees cannot access your data in plaintext because the decryption key does not exist on our infrastructure. Even with full database access, an employee would see only encrypted ciphertext.

2. "Do you hold the decryption keys?"

If the vendor holds the decryption key, they can read your data. Period. It does not matter what policies they have, what certifications they display, or what promises they make. If the key is on their infrastructure, your data is accessible to them.

NoSheet's answer: No. Encryption keys are per-tenant and wrapped with a key-encryption key that NoSheet does not possess. We could not decrypt your data even if we tried.

3. "Is my data decrypted during processing?"

This is the question that separates real security from security theater. Most vendors encrypt data at rest and in transit but decrypt it during processing. Your data is in plaintext during every search, every report, every export, every cleaning operation. This is the window where data is most vulnerable, and it is the window that most vendors leave wide open.

NoSheet's answer: No. Cleaning operations, deduplication, formatting, and validation all run on encrypted data. Your PII is never decrypted on our servers. For more context on how traditional tools compare, read why your data cleaning tool sees everything.

4. "Can you comply with a government subpoena for my data?"

If a government agency serves a subpoena to your SaaS vendor demanding your data, the vendor must comply if they have access to the data. This is not a theoretical risk — it happens thousands of times per year. Google's transparency report shows they received over 200,000 government requests for user data in a recent year. If the vendor can read your data, they can be compelled to hand it over.

NoSheet's answer: No. We can comply with the subpoena in the sense that we would hand over whatever we have, but what we have is encrypted ciphertext. Without your tenant key, the data is computationally useless. We cannot decrypt it for law enforcement because we cannot decrypt it at all.

5. "What happens to my data if you are breached?"

This is the question that reveals the real consequence of a vendor's architecture. If a vendor that holds your data in plaintext (or holds the decryption key) is breached, your customers' personal information is compromised. Full stop. Their SSNs, their medical records, their financial information — all of it is in the hands of the attacker.

NoSheet's answer: If NoSheet were breached, the attacker would obtain encrypted ciphertext. Without your per-tenant decryption key — which does not exist on our infrastructure — the data is random noise. A breach of NoSheet does not become a breach of your customers' data. That is the difference between architecture that protects you and architecture that hopes nothing goes wrong.

Why This Matters More Than You Think

You might be thinking: "I trust my vendors. They have SOC 2 certifications. They have privacy policies. They train their employees." All of that is true for most reputable SaaS companies, and none of it changes the fundamental architecture. SOC 2 certifies that a vendor has security controls in place. It does not certify that the vendor cannot read your data. A privacy policy is a legal commitment, not a technical constraint. Employee training reduces risk but does not eliminate it.

The strongest security posture is one where trust is not required. Not because vendors are untrustworthy, but because trust-based security has a 100% eventual failure rate on a long enough timeline. People make mistakes. Companies get breached. Policies change. Court orders override privacy commitments. The only guarantee that survives all of these scenarios is a technical one: the vendor cannot see your data because the cryptography makes it impossible.

NoSheet exists because we believe your data cleaning tool should not be the weakest link in your security chain. Every other tool decrypts your data to process it. We do not. We clean your data without ever seeing it. That is not a marketing claim — it is a provable property of our encryption architecture. And it is the reason that a NoSheet breach cannot expose your customers' personal information, no matter what.

If you want to understand the encryption technology behind this, read our guide to encrypted data cleaning explained. If you are evaluating your current tool stack for compliance, our PII audit guide will help you map where sensitive data flows in your organization.