SOC 2 & ISO 27001 Compliant Unified APIs: The 2026 Zero Data Retention Guide

When your sales team is staring down a six-figure enterprise contract, the absolute last thing you want to hear is that InfoSec blocked the deal. Engineering teams spend months building native integrations to close these exact deals, only to watch them die in a vendor security review because of third-party data compliance issues.

If you need an integration tool that doesn't store customer data, handles integrations with real-time data, and holds both SOC 2 Type II and ISO 27001 certification for your B2B SaaS, the shortlist is remarkably short. Most unified API vendors advertise these attestations, but their underlying architecture caches your customers' CRM, HRIS, and financial records in a multi-tenant database. This turns your integration vendor into a fresh sub-processor of sensitive PII and expands your compliance surface with every connection you add.

This guide breaks down the architectural realities of unified APIs, the massive financial risks of third-party data breaches, what your InfoSec reviewers are actually looking for, and how a zero data retention architecture is the only mathematical way to scale integrations without failing enterprise security audits.

The Enterprise Security Wall: Why Integrations Kill SaaS Deals

Key Takeaways:

• Missing SOC 2 Type II or ISO 27001 attestation eliminates vendors from consideration before commercial conversations even begin.
• Enterprise buyers reject vendors whose integration layer stores customer data in a third-party middleware, even if that middleware has compliance certifications.
• The average cost of a data breach for US companies reached a record high of $10.22 million in 2025.

Every B2B SaaS company selling upmarket eventually hits the same wall. The buyer profile shifts from a product manager with a corporate credit card to a centralized procurement and InfoSec committee. Sales gets a $250k opportunity qualified. Engineering ships a Salesforce or Workday integration to unblock it. Then the prospect's security team sends over a 200-question vendor security questionnaire (VSQ), often based on the SIG Core or CAIQ frameworks.

Question #47 always asks: "Does your application or any third-party sub-processor store, cache, or replicate our data?"

If your integration layer caches customer HR records, CRM contacts, or financial data on a middleware provider's servers, the answer is yes. That single "yes" triggers a cascade of follow-up questions about data residency, encryption standards, retention policies, and breach notification timelines. Deals stall for weeks. Sometimes they die completely.

Enterprise procurement teams systematically gate purchase decisions on these security questionnaire outcomes, making it critical to understand how to pass enterprise security reviews with 3rd-party API aggregators. The financial stakes behind this scrutiny keep climbing. The average cost of a data breach for U.S. companies jumped 9% to an all-time high of $10.22 million in 2025, as the global average cost fell 9% to $4.44 million, IBM said in its 20th annual Cost of a Data Breach Report. While shorter investigations are pushing down costs globally, reflecting the first decline in five years, IBM found higher regulatory fines, along with detection and escalation costs, are driving up the ultimate recovery price in the United States. Customer personally identifiable information (PII) was the most frequently compromised data type, involved in 53% of breaches.

Against that backdrop, procurement teams are not being paranoid. They are protecting a $10M downside. Buyers are actively punishing software vendors who introduce unnecessary third-party risk into their supply chain. Your integration architecture is the single biggest lever they use to shrink that risk.

Decoding the Certifications: SOC 2 Type II vs. ISO 27001

Key Takeaways:

• SOC 2 Type II audits the operating effectiveness of security controls over a 3-12 month period, typically demanded by US buyers.
• ISO 27001 requires a formal Information Security Management System (ISMS) focused on continuous risk management, preferred in the EU, UK, and APAC.
• Selling upmarket in 2026 means you need both - and so does every vendor in your critical data path.

To pass enterprise procurement, your infrastructure - and every vendor in your critical data path - must hold specific compliance attestations. Claiming your platform is "secure by design" means nothing without independent verification. However, the frameworks overlap, but they are not interchangeable. No, ISO 27001 is not equivalent to SOC 2. These two standards are not interchangeable, and prospects that request ISO 27001 certification will not be satisfied with a SOC 2 report, just as clients that request a SOC 2 won't be satisfied with an ISO 27001 certification.

SOC 2 Type II is an auditing standard developed by the American Institute of CPAs (AICPA). A SOC 2 Type 1 attestation report focuses on an organization's IT security control design at a point in time. In contrast, SOC 2 Type 2 assesses the design and operating effectiveness of the controls over a specified lookback period, typically six months to a year. It measures your infrastructure against five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Enterprise buyers largely reject Type I reports; they require the historical proof provided by Type II, because it proves your controls did their job across an audit window, not just on the day the auditor showed up.

ISO 27001 is a different beast. ISO 27001 is an international certification requiring a comprehensive Information Security Management System (ISMS). Rather than just checking boxes on technical controls, ISO 27001 evaluates whether you run a systematic, documented, continuously improving security program. It forces organizations to identify risks, assess their implications, and implement systematic controls to mitigate them continuously.

There is meaningful control overlap that reduces the audit burden if you pursue both. SOC 2 and ISO 27001 share 40-85% of their controls, primarily in areas like risk management, access control, and incident response.

Here is how buyers actually read each artifact:

When an enterprise buyer evaluates your SaaS product, they are essentially evaluating your supply chain. As covered in our guide on which integration tools are best for enterprise compliance, you cannot borrow compliance from AWS or Google Cloud; the application layer processing the data must be independently certified. If your integration middleware is missing either one, you are inheriting their compliance gap.

The Hidden Liability of "Sync-and-Cache" Unified APIs

The pressure to ship integrations quickly pushes many engineering teams toward unified APIs. However, most traditional unified API platforms rely on a deeply flawed sync-and-cache architecture. They market their own SOC 2 and ISO 27001 compliance, but their underlying infrastructure creates a massive compliance liability for you.

Here is how sync-and-cache systems actually work under the hood. To normalize data across dozens of providers, the middleware continuously authenticates with the upstream SaaS (like Salesforce or BambooHR), pulls down thousands of records via background polling workers, normalizes the response into a common schema, and stores them in its own multi-tenant database. When your application requests data, it reads from this cached database rather than the source of truth.

flowchart TD
    YourApp["Your SaaS Application"] -->|"1. Queries cached data"| MiddlewareDB["Integration Provider DB"]
    MiddlewareDB -->|"2. Returns stale data"| YourApp
    MiddlewareDB -->|"3. Polling worker (every 5m)"| Upstream["Upstream API (e.g., Workday)"]
    Upstream -->|"4. Returns sensitive PII"| MiddlewareDB

That architecture ships fast. It also creates three specific liabilities that enterprise InfoSec teams will find:

1. New sub-processor of sensitive PII. Every time you connect a new customer, you are extracting their employee PII, financial ledgers, and customer contact lists, and placing them on a third-party server. The moment your vendor persists customer records, they become a data processor under GDPR and a sub-processor under most enterprise MSAs. You must update your Data Processing Agreements (DPAs), republish your sub-processor list, and notify your enterprise customers.
2. Expanded breach blast radius. A compromise of your unified API vendor exposes every customer's synced data at once. The security implications of using a third-party unified API don't disappear just because the vendor has a SOC 2 report. The report only proves controls existed, not that data was never there to steal. Third-party vendor and supply chain compromises emerged as both the second most frequent attack vector (15%) and second costliest ($4.91 million). These attacks took the longest to detect and contain at nearly 9 months (267 days), reflecting the complex web of relationships that attackers exploit. Every integration middleware you add is another node in that supply chain.
3. Stale data at read time. Cached data is by definition out of date. Background polling introduces latency. If a sales rep updates a HubSpot deal stage and your app reads a 15-minute-old snapshot, your workflow fires on wrong state. "Real-time" in most sync-and-cache docs actually means "eventually consistent after the next poll cycle."

The pitch that "we're SOC 2 Type II certified" is real - but it answers a different question than the one procurement is asking. Procurement is asking: does data leave my perimeter and land on someone else's disk? A certification does not change the answer.

What "Real-Time" and "Zero Data Retention" Actually Mean for Compliance

Definition: As we've detailed in our breakdown of what zero data retention means for SaaS integrations, a zero data retention (ZDR) unified API processes customer data ephemerally in memory during a single request, then discards it. No persistent copies. No shadow database. No polling loop. Nothing to breach, nothing to subpoena, nothing to add to your sub-processor list.

The only way to safely embed third-party integrations into enterprise products without failing security reviews is to adopt this Zero Data Retention architecture. This is achieved through a real-time pass-through proxy architecture. Instead of polling and storing data, the middleware acts as a high-performance translation layer.

In a true pass-through architecture, the request flow looks like this:

sequenceDiagram
    participant App as "Your SaaS App"
    participant UAPI as "Unified API (Pass-Through)"
    participant Upstream as "Upstream API (Salesforce, HubSpot, etc.)"
    App->>UAPI: GET /crm/contacts
    UAPI->>UAPI: Resolve OAuth token in memory
    UAPI->>Upstream: GET /services/data/v60/query
    Upstream-->>UAPI: Raw response (ephemeral)
    UAPI->>UAPI: Transform to unified schema in memory
    UAPI-->>App: Normalized response
    Note over UAPI: Memory flushed immediately.<br/>No persistent storage of customer records.

A few architectural details matter heavily for the security review:

• In-memory transformation only. The unified schema mapping (such as a JSONata expression) runs entirely inside the request lifecycle. Nothing gets flushed to disk, logs, or a queue. The memory is garbage-collected within milliseconds.
• OAuth tokens are the only persisted secret. Refresh tokens must live somewhere, but they are encrypted at rest and scoped per tenant. Customer business data does not.
• Webhooks are relayed, not stored. Incoming provider webhooks get normalized in memory and forwarded to your endpoint immediately. There is no archived event history in the vendor's database.

This is the architecture that closes the sub-processor conversation. Your InfoSec reviewer can look at the data flow diagram and confirm: no customer records ever come to rest in the middleware. The vendor is a network hop, not a data store. For teams operating under strict frameworks, our real-time pass-through vs sync-and-cache HIPAA guide walks through the exact same reasoning for PHI.

The Reality of Rate Limits in a Pass-Through System

Radical honesty is required when discussing pass-through architectures. Because the system does not cache data, every request you make translates to a request against the upstream provider's API. You are subject to the upstream provider's rate limits.

A true pass-through system does not attempt to hide this reality by queuing requests or holding sensitive state in memory. If the upstream API returns an HTTP 429 Too Many Requests error, the middleware must pass that error directly back to your application.

Handling this on the client side is straightforward and ensures you retain complete control over your application's behavior and state management. This design keeps sensitive request payloads from sitting in a queue you don't control:

// Example of handling normalized pass-through rate limits
const response = await fetch('https://api.truto.one/unified/contacts', {
  headers: { Authorization: `Bearer ${TRUTO_TOKEN}` }
});
 
if (response.status === 429) {
  const limit = response.headers.get('ratelimit-limit');
  const remaining = response.headers.get('ratelimit-remaining');
  const reset = response.headers.get('ratelimit-reset');
  
  console.warn(`Rate limit hit. Limit: ${limit}. Reset at: ${reset}`);
  
  // Your application logic handles the backoff
  await applyExponentialBackoff(reset);
}

By passing rate limits directly to the caller, a pass-through architecture guarantees that sensitive data is never trapped in an opaque middleware queue.

The Honest Trade-Offs of Zero Data Retention

Zero data retention is not free. It has real trade-offs worth calling out:

• Bulk historical reads are slower. If you need to backfill 500,000 CRM records, a cached architecture can serve them from local storage in seconds. Pass-through has to paginate through the upstream API, subject to its rate limits.
• Your app handles state. Idempotency, retry logic, cursor management, and dedupe live in your code, not in the vendor's infrastructure.
• No cross-tenant analytics. You cannot ask the vendor to run a query across all your customers' data because they don't have it.

For compliance-strict SaaS - and any product selling into regulated industries - these trade-offs are worth it. You control the data, and your enterprise deals stop stalling in procurement.

How Truto's Pass-Through Architecture Solves the Compliance Puzzle

If you are building B2B SaaS and your enterprise prospects keep flagging third-party data storage in security reviews, you need an architecture designed specifically for compliance. Why Truto is the Best Zero-Storage Unified API for Compliance-Strict SaaS outlines how Truto eliminates the sub-processor trap.

Truto is a unified API built pass-through from day one. That means:

• Zero customer data at rest: Truto never persists your customers' CRM, HRIS, ticketing, or accounting records. Every request is proxied in real time to the upstream provider. Data is processed entirely in transit. There are no persistent copies and no shadow databases.
• SOC 2 Type II and ISO 27001 certified: Both attestations are current, ensuring enterprise-grade security controls are audited and verified, giving your security team an easy artifact to attach to their questionnaire response.
• Real-time reads: Your app always sees the current state in Salesforce, HubSpot, or Workday, not a snapshot from the last polling cycle.
• Transparent rate limit handling: Truto normalizes upstream rate limit info into IETF-standard headers and passes HTTP 429s directly to your caller. No hidden queues, no absorbed retries, no request payloads sitting in vendor infrastructure.
• In-region processing: Data can be processed in your customers' preferred region without ever landing in a persistent store.

Under the hood, Truto achieves this through a generic execution pipeline. There is no integration-specific code in Truto's core runtime logic. Instead, the platform relies on a highly optimized mapping configuration that links unified fields to provider-specific fields using JSONata expressions. When a request is made, Truto securely injects the necessary OAuth tokens (which it refreshes automatically before they expire), routes the request to the provider, applies the JSONata transformation in ephemeral memory, and returns the normalized result.

Because of this strict architectural boundary, when question #47 on the vendor security questionnaire asks if your third-party sub-processors store or cache customer data, Truto allows you to confidently answer "No."

Your Next Steps for a Clean Security Review

Before you sign a unified API contract, hand your engineering lead this checklist:

1. Get both certifications in writing. Request the vendor's SOC 2 Type II report (not just the attestation letter) and the current ISO 27001 certificate with the Statement of Applicability. Verify audit dates and scope match your data flow.
2. Trace the data flow end-to-end. Ask the vendor to diagram the exact path a customer record takes from provider to your app. If any arrow points to a database on their side, they are a sub-processor and will appear on your DPA disclosures.
3. Interrogate the word 'real-time'. If the vendor claims real-time, ask for the freshness SLA. Cache-based systems have measurable staleness (5 minutes, 15 minutes, etc.). True pass-through returns the upstream response synchronously with no staleness.
4. Confirm rate limit behavior. Ask what happens on an HTTP 429 from the upstream API. The compliance-friendly answer: the platform passes 429 through to the caller with normalized headers, and the caller owns retry and backoff. Absorbed retries mean vendor-side queues holding your sensitive payloads.
5. Review sub-processor disclosures. If the vendor persists any customer data, they must appear on your public sub-processor list and typically require notice under enterprise DPAs. Confirm this matches what you tell your own customers during their security reviews.

If you're evaluating unified APIs against a real security questionnaire and want to see how Truto's pass-through architecture handles your specific compliance requirements, we can walk through the architecture, share our SOC 2 and ISO 27001 reports under NDA, and stress-test it against your InfoSec team's questions.