Find SOC 2 iPaaS That Don't Store Customer Data (Sep 2026)

Not every embedded iPaaS vendor stores your customers' data, but plenty of them do without making it obvious in their marketing copy. There's a real architectural difference between a vendor that processes data in transit and one that maintains a normalized copy in their own database, and that difference shows up directly in your security review. Here's what to look for before you sign anything.

TLDR:

• A compromised embedded iPaaS vendor can expose every tenant in your pipeline, with breaches averaging $4.88M in 2025
• "Sync-and-cache" architectures store your customers' data long-term inside vendor infrastructure, expanding your sub-processor risk
• Always ask for SOC 2 Type II by name; Type I only confirms controls were designed correctly, not that they held up in production
• Per-tenant OAuth isolation and white-labeled app credentials are baseline requirements, not nice-to-haves, during vendor procurement
• Hotglue is SOC 2 Type II and GDPR compliant, processing data transiently without storing customer payloads long-term

What SOC 2 Actually Requires from Integration Vendors

SOC 2 is a security framework developed by the American Institute of Certified Public Accountants (AICPA). It measures vendors against five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. An independent auditor reviews your controls against each criterion and issues an attestation report.

For an embedded integration vendor, these criteria carry real weight. Your integration layer touches OAuth tokens, CRM records, payroll data, and accounting entries belonging to your customers' end users. That makes it a data processor in the eyes of any enterprise procurement team. A vendor without SOC 2 attestation is asking you to inherit their security risk, which is a harder sell to your own customers' InfoSec teams than it sounds.

Why Embedded Integrations Create a Unique Security Exposure

Embedded integrations are wired directly into your customers' most sensitive systems. When a user connects their QuickBooks, Salesforce, or Paylocity account inside your product, the integration layer handling that connection becomes a sub-processor touching payroll figures, AR ledgers, and contact records you never intended to warehouse yourself.

That sub-processor sits between you and a breach. According to IBM's 2025 Cost of a Data Breach, the global average cost of a data breach reached $4.88 million. A compromised integration vendor can expose every tenant syncing through that data integration pipeline, every customer, across the board.

Most security reviews miss this entirely. Procurement teams audit the SaaS product directly but skim the sub-processor addendum. The embedded iPaaS ends up as a quiet third party with read access to your customers' CRM, write access to their ERP, and a stored OAuth token that could persist long after a user deactivates their account.

The "Sync-and-Cache" Problem: What Data Persistence Actually Means

Some embedded iPaaS vendors maintain a normalized copy of your customers' data in their own database. Every sync writes records into their layer first, then delivers downstream. That persistent copy is what makes them useful for querying historical data, but it also makes them a long-lived store of your customers' most sensitive records. Security teams call this a sync-and-cache architecture, and it meaningfully expands your sub-processor footprint.

Transient processing works differently. The integration fetches data, runs it through a transformation pipeline, delivers it to your backend, and moves on. Nothing lingers. The distinction matters because stored data can be breached, subpoenaed, or retained past what your data retention policy allows.

When reviewing vendors, ask one direct question: after a sync completes, where does my customer's data live? If the answer is anywhere inside the vendor's infrastructure for longer than job execution requires, you are looking at a sync-and-cache architecture, whether they call it that or not.

The Five SOC 2 Trust Services Criteria and How They Map to Integration Pipelines

Each criterion hits a different layer of the pipeline. Security covers credential handling and access controls per tenant. Availability is about whether syncs run on schedule and recover cleanly when they fail. Processing integrity is the one vendors often skip in their SOC 2 marketing copy, a pattern tied to the stigma of embedded iPaaS, but it covers whether your data arrives intact and whether a half-completed job silently writes bad records. Confidentiality and privacy overlap but sit at different scopes: confidentiality covers data in motion, while privacy follows PII across its full lifecycle, including what happens after a tenant disconnects.

SOC 2 Type I vs. Type II: Why the Distinction Matters for Integration Vendors

SOC 2 Type I certifies that a vendor's security controls were designed correctly at a single point in time. An auditor reviewed the architecture, checked the policies, and signed off. There's no evidence of how those controls held up under real operating conditions.

Type II covers an observation window, typically six to twelve months, where the auditor tests whether controls actually worked as designed. For an integration vendor handling live OAuth tokens and customer data syncs daily, that window is what matters. Controls that look good in a design review can fail quietly in production.

When a vendor says "SOC 2 compliant" without specifying which type, ask for the report.

How to Assess Data Persistence Claims During Vendor Procurement

Vendor marketing copy rarely tells you where data actually lives, and vetting iPaaS tools has other hidden traps too. These questions will cut through it.

• Does the vendor use separate, access-controlled databases per customer, or is tenant data co-mingled in shared tables?
• How long are integration payloads retained after a job completes? Retries and snapshots are legitimate, but open-ended retention is a red flag.
• Where does the infrastructure run, and who are the downstream sub-processors? AWS hosting with named sub-processors is auditable. "Our cloud" is not.
• What happens to OAuth tokens and stored credentials when a tenant offboards? Ask for a documented deletion flow, not a verbal assurance.

As Konfirmity notes, enterprise buyers increasingly insert security addenda and data protection clauses before signing. If a vendor cannot answer these in writing, that is your answer.

Credential Security and OAuth Isolation in Embedded iPaaS

Per-tenant token storage is the baseline. If an embedded iPaaS vendor holds OAuth credentials in a shared table keyed only by an internal ID, a misconfigured query or access control gap exposes every connected customer at once. Proper isolation means each tenant's credentials live in a separate, access-controlled store, so a bug in one tenant's sync cannot touch another's tokens.

There are a few other security properties worth checking before you sign anything.

• White-labeled OAuth matters for a less obvious reason than you might expect. Many vendors route all OAuth flows through a single registered app, so every customer connecting Salesforce or QuickBooks authorizes the same third-party app identity. If that app is revoked, every tenant loses access simultaneously. White-labeled OAuth gives each SaaS vendor their own registered app credentials, containing the blast radius of any revocation.
• Scope creep is where things quietly go wrong. OAuth scopes requested during the initial auth flow often expand over time as connectors add features. A good vendor requests the minimum scope needed per connector and documents what each scope accesses. Ask for a scope inventory per integration before signing.
• Environment-level API key separation is worth checking. Development and production credentials should never share the same key space. A vendor that gives you one API key for everything is one misconfigured staging environment away from a production data exposure.

Infrastructure and Deployment Considerations

Cloud provider choice is the first infrastructure question worth asking. AWS inherits accreditations including ISO 27001, SOC 1/SSAE 16, and PCI Level 1 across its data center estate. A vendor running on AWS is not automatically secure, but the underlying physical controls are independently audited and documented, which is another reason building user-facing SaaS integrations yourself creates unacknowledged risk. Compare that to a vendor running on unspecified "cloud infrastructure" with no named provider.

Beyond the cloud provider, a few architecture specifics matter for procurement reviews:

• Network isolation via firewalls and security groups with a default-deny posture, not default-allow
• DDoS mitigations at the provider and application layer, such as SYN cookies and connection rate limiting
• Separate staging and production environments with distinct API key spaces
• Host-based firewalls isolating customer workloads from each other

Data residency is worth raising explicitly if your customers operate in jurisdictions with strict data governance requirements. Most embedded iPaaS vendors run entirely in US-based AWS regions. If a customer's data cannot leave a specific geography, confirm whether the vendor supports regional deployment or VPC options before you reach contract review.

What an InfoSec RFI for an Embedded Integration Vendor Should Cover

Four areas your InfoSec team should cover when reviewing an embedded integration vendor.

Data Handling and Persistence

• After a sync job completes, where does customer data reside, and for how long?
• Are integration payloads deleted from vendor infrastructure once delivered to the destination?
• Are tenant databases separated with independent access controls, or is data co-mingled?

Compliance Certifications and Audit Scope

• Is the vendor SOC 2 Type I or Type II, and what was the observation window?
• Which Trust Services Criteria were in scope? Security alone is not sufficient for an integration sub-processor, and different iPaaS integration platforms handle this very differently.
• Can they provide the full attestation report, and not merely a one-page summary?

Infrastructure and Deployment Controls

• Which cloud provider hosts the infrastructure, and what are the named sub-processors?
• Are production and staging environments fully separated with distinct API key spaces?
• How are OAuth tokens encrypted at rest, and are they isolated per tenant?

Sub-Processor Management and Incident Response

• What is the documented process for credential and token deletion when a tenant offboards?
• How quickly are customers notified in the event of a security incident affecting integration data?
• Does the vendor maintain a current sub-processor list, and how are customers notified of changes?

How hotglue Approaches Integration Security and Data Handling

Hotglue is SOC 2 Type II and GDPR compliant by design, running on AWS ECS via Fargate. If you're still weighing the best embedded iPaaS solution for your stack, that matters. At roughly 10 billion records processed weekly across 38,000+ active tenants, those controls have been tested under real production load.

The architecture maps directly to standard security evaluation criteria:

• Customer data lives in separate, access-controlled databases per application, so tenant data is never co-mingled.
• Staging and production environments are fully separated with distinct API key spaces, so a misconfigured development job cannot touch live customer data.
• White-labeled OAuth gives each SaaS vendor their own registered app credentials, containing any revocation event to a single vendor instead of every connected tenant.
• Partial sync failures never silently succeed. Hotglue either delivers all data or fails the job and preserves state for retry, giving you a clean audit trail.

On data persistence: Hotglue processes integration data and delivers it to you. Snapshots and job artifacts exist for stateful sync correctness, but Hotglue is not designed as a long-lived store of your customers' sensitive payloads.

For teams going through InfoSec review, reach out to security@hotglue.io with your questionnaire.

Final Thoughts on Picking a SOC 2 Compliant Embedded Integration Vendor

Your customers trust you with their data, and that trust extends to every sub-processor you bring into the pipeline. Knowing what questions to ask, what answers are acceptable, and where the real risks sit in an integration architecture makes the procurement process less of a guessing game. Hotglue is built from the ground up to pass that review: SOC 2 Type II, GDPR compliant, transient by design, and already processing 10 billion records a week across 38,000+ tenants without storing your customers' sensitive payloads long-term. It's the kind of thing that's genuinely nice to be able to tell your InfoSec team. If you want to walk through how hotglue approaches data handling and security controls, book a demo and we can go through it together.

FAQ

Which embedded iPaaS platforms are SOC 2 compliant and never store customer data?

Hotglue is SOC 2 Type II and GDPR compliant, and its architecture processes integration data in transit without caching it in a persistent store. Once a sync job delivers data to your backend, it moves on. Most embedded iPaaS vendors use a sync-and-cache model that writes customer records into their own database first, which expands your sub-processor footprint and creates a long-lived store of sensitive payloads you never intended to hand off.

What security certifications does Hotglue hold, and how does it handle data residency requirements for customers with strict data governance needs?

Hotglue holds SOC 2 Type II and GDPR certifications, runs on AWS ECS via Fargate, and maintains separate access-controlled databases per tenant so data is never co-mingled across customers. If your customers operate in jurisdictions with strict data residency requirements, raise this directly with the Hotglue team. Most embedded integration platforms run entirely in US-based AWS regions, so confirming regional deployment options before contract review is worth doing early.

How do I determine whether an embedded integration vendor is a sync-and-cache architecture or a transient processor?

Ask one direct question during procurement: after a sync job completes, where does my customer's data live, and for how long? If the vendor cannot give you a clear answer, or if the answer involves any persistent copy inside their infrastructure beyond job execution time, you are looking at a sync-and-cache architecture regardless of how they describe it in their security documentation.

Should a B2B SaaS product team choose an embedded iPaaS that doesn't store customer data or one with a persistent data layer?

For most B2B SaaS teams, a transient-processing iPaaS is the lower-risk choice from a compliance and procurement standpoint — it reduces your sub-processor surface, simplifies data retention policies, and avoids the scenario where a vendor breach exposes every tenant syncing through that pipeline. A persistent layer only makes sense if querying historical integration data inside the vendor's infrastructure is a core product requirement, and even then you should weigh that against the security review overhead it adds with enterprise customers.

What does SOC 2 Type II cover that Type I does not, and why does it matter for an embedded integration sub-processor?

SOC 2 Type I only confirms that security controls were designed correctly at a single point in time — it says nothing about how those controls held up under real operating conditions. Type II covers an auditor observation window of six to twelve months, testing whether controls actually worked in production, which is the bar that matters when a vendor is handling live OAuth tokens, payroll records, and CRM data for thousands of tenants daily.