How to Pass Enterprise Security Reviews When Using 3rd-Party API Aggregators

Your six-figure enterprise deal just stalled. Not because the buyer didn't love the product demo, and not because a competitor undercut you on price. It died in procurement.

The AE moved the deal to the final stages, and the enterprise procurement team sent over a Standard Information Gathering (SIG) Core spreadsheet. Your engineering lead breezed through the sections on encryption and access controls, then hit Domain 10: Third-Party Risk Management. The questionnaire demanded a complete list of all sub-processors that handle, transmit, or store the enterprise's data.

You listed your third-party unified API vendor. The security auditor looked at the vendor's architecture and discovered they cache your customer's CRM, HRIS, and accounting data in a multi-tenant database for 30 to 60 days to handle retries and pagination.

The deal stopped dead. The enterprise security team flagged your architecture as a supply chain risk and refused to sign off on a contract that allows their sensitive payload data to sit in an unverified third-party database.

Anyone who has spent a weekend fighting with NetSuite's SOAP endpoints or deciphering Workday's undocumented rate limits knows that building integrations is painful. Unified APIs solve the engineering problem by normalizing data across hundreds of SaaS platforms. But if you choose the wrong architectural pattern, you are trading an engineering problem for a compliance nightmare.

This guide explains exactly why third-party API aggregators fail enterprise security reviews, what procurement teams are actually looking for, and how to architect your integration layer so it survives the audit.

Executive TL;DR: Why Pass-Through Matters

If you only have five minutes before your next enterprise deal enters procurement, this is the summary that matters: a pass-through integration architecture is the single biggest lever you have to shorten vendor security reviews and keep deals from stalling.

The logic is direct. Once a third-party integration vendor caches customer payloads, it becomes a data sub-processor under GDPR, HIPAA, and every enterprise vendor risk framework in active use. That triggers BAAs, DPA amendments, sub-processor notifications, deletion-request coordination, and a full third-party risk assessment. A pass-through vendor - one that transforms responses in memory and never writes payload data to disk - stays a processor "in transit only," which is a dramatically simpler review.

Everything else in this article is downstream of that architectural choice. If you get pass-through right, the 12 artifacts, SIG responses, and DPA clauses fall into place. If you get it wrong, no amount of legal wordsmithing will unstick the deal.

Here's the pattern of failed reviews, distilled:

1. Data storage ambiguity. The vendor can't give a clear yes-or-no answer to "do you store our payload data?" Vague responses like "we cache briefly for performance" trigger deeper investigation.
2. Missing or stale compliance artifacts. No SOC 2 Type II report, an expired penetration test, or a DPA that doesn't name sub-processors. Procurement stalls while they chase documents.
3. No architecture evidence. The vendor can't produce a data flow diagram showing exactly where customer data transits and where it rests. Without visual proof, auditors assume the worst.
4. Weak credential isolation. Shared OAuth apps, no support for customer-owned credentials, or tokens stored without proper encryption.
5. No deployment flexibility. SaaS-only with no option for VPC or on-premises deployment. For regulated industries, this is often a non-starter.

The rest of this guide walks through each failure mode in detail, gives you a concrete checklist of artifacts to prepare, and shows how to verify vendor claims with technical evidence rather than marketing promises.

The Enterprise Procurement Trap: Why Integrations Fail Security Reviews

When a B2B SaaS company moves upmarket, the first surprise isn't the feature gap — it's the vendor risk assessment. Enterprise buyers don't just evaluate your product. They evaluate every sub-processor in your data supply chain. If you use a third-party unified API or integration platform, that vendor gets its own row in the risk register.

The SIG questionnaire is a good proxy for what you're up against. Shared Assessments updates it annually, and the 2025 SIG Core contains 627 questions covering data handling, encryption, access controls, sub-processor management, incident response, and more. This is not a niche process: more than 100,000 SIGs are exchanged yearly, the questionnaire is integrated into software from over 30 technology partners, and more than 500 organizations license it for security due diligence.

Here's the pattern that kills deals:

1. Your team builds the product. Sales gets a technical win.
2. The buyer starts procurement. The security team asks: "Which third parties handle or store customer data?"
3. You list your integration vendor.
4. They send the vendor a SIG Core questionnaire (or their own proprietary version).
5. The vendor's response reveals a sync-and-store architecture where employee records, CRM contacts, or financial data sits in the vendor's database for 30 to 60 days.
6. Legal flags it. The deal stalls.

Enterprises don't manage vendor risk in spreadsheets anymore. They use automated Third-Party Risk Management (TPRM) platforms like ProcessUnity, Mitratech, or Whistic. These systems map your sub-processors against known breach databases and compliance frameworks. If you list an integration vendor that caches data for 60 days, the TPRM platform automatically flags your architecture as high-risk. According to recent industry research, 73% of organizations have implemented continuous monitoring solutions to track the security performance of vendors throughout the contract lifecycle.

The regulatory landscape keeps tightening around that process. As of January 2025, 144 countries had national data privacy laws in force, covering roughly 82% of the world's population. Once your customer has users, candidates, employees, or financial records moving through multiple systems, the integration layer stops being plumbing and starts looking like regulated infrastructure.

If your integration strategy is still built for SMB, enterprise procurement will expose every weakness in it.

The Financial Stakes of Third-Party Data Breaches in 2026

Enterprise security teams aren't paranoid — they're doing math. The cost of getting this wrong has never been higher.

According to IBM's 2024 Cost of a Data Breach Report, the global average cost of a data breach spiked 10% to a record high of $4.88 million. For companies in heavily regulated sectors, the numbers are far worse. Healthcare remained the costliest industry for breaches for the 14th consecutive year, with an average incident cost reaching $9.77 million.

When you use an integration vendor that syncs and stores data, you are participating in the creation of shadow data — unmanaged, duplicated data sitting outside of official IT control:

• Shadow data amplifies damage. 35% of breaches in the study involved shadow data, and those breaches led to a 16% higher cost on average, totaling $5.27 million per incident.
• Slower detection. Incidents involving shadow data took 26.2% longer to identify and 20.2% longer to contain.
• Supply chain is a top attack vector. IBM's research found that vendor and supply chain breaches cost organizations an average of $4.91 million — the second costliest attack vector after phishing.
• Third-party exposure is accelerating. Verizon's 2025 Data Breach Investigations Report noted that third-party involvement in breaches doubled year-over-year to 30%. Third-party cybersecurity incidents affected over 60% of companies in 2024.

This is why security teams are unimpressed by hand-wavy answers like "we only cache it briefly" or "the vendor is SOC 2 compliant." The real question is whether your architecture creates extra copies of sensitive data that the customer now has to govern, delete, audit, and explain after an incident.

The Top 12 Artifacts Enterprise Buyers Request

Before you get deep into architecture debates, know what procurement teams actually collect. If your integration vendor can't produce these documents within a week of being asked, you have a problem. If you can't produce them about your own integration layer, you have a bigger one.

The Problem with "Sync-and-Store" API Aggregators

Most legacy unified API platforms and integration sync engines use a sync-and-store architecture. When your application requests a list of contacts from a customer's Salesforce instance, the vendor doesn't simply pass the request along. Instead, they poll the third-party system, pull the data, write it to their own multi-tenant database, and serve it to you from their cache. The platform periodically re-syncs to keep the cache fresh.

This architecture exists for defensible technical reasons — it simplifies pagination, enables faster reads, handles rate limits, and supports delta sync. But it creates a compliance nightmare.

sequenceDiagram
    box rgb(235, 232, 226) Legacy Sync-and-Store Architecture
    participant App as Your Application
    participant Vendor as API Aggregator
    participant DB as Aggregator Database
    participant SaaS as 3rd-Party SaaS
    end
    
    App->>Vendor: Request Data
    Vendor->>SaaS: Fetch Data
    SaaS-->>Vendor: Return Payload (PII/PHI)
    Vendor->>DB: Write Payload to Disk (30-60 days)
    Note over Vendor,DB: Compliance Liability<br>Sub-processor Risk
    Vendor-->>App: Return Normalized Data

What this means for your security review:

• Your vendor becomes a data sub-processor. Under GDPR, HIPAA, and most enterprise security frameworks, any entity that stores or processes customer data is a sub-processor. That triggers BAA requirements, DPA amendments, and a full risk assessment.
• Data retention becomes your problem. If the vendor caches employee PII for 30 to 60 days, your customer's security team will ask: "Why does a company we've never heard of have a copy of our employee directory?" You won't have a good answer.
• You inherit the vendor's attack surface. Every database is a breach target. Every cache is a potential data leak. The vendor's security posture becomes your security posture.
• Deletion requests get complicated. When an enterprise customer asks you to purge their data, you have to coordinate deletion across your own systems AND your integration vendor's cache. Good luck getting that done within GDPR's 30-day window.

You can see the market reacting to this problem in public. Merge announced Destinations so customers can store data in their own environment instead of Merge's database, explicitly acknowledging that some companies have security postures that forbid data residency in third-party systems. Nango's documentation describes its records cache as an intermediate store with payloads pruned after 30 days and fully deleted after 60 days if a sync doesn't run.

These workarounds are honest acknowledgments of the architectural problem. But "Bring Your Own Database" features shift the entire engineering burden back onto your team — you're suddenly responsible for managing the infrastructure, maintaining database schemas, and handling sync state. That defeats the purpose of buying a managed integration platform in the first place.

Where teams get burned is not always the primary database. It's the secondary copies: sync caches, retry queues, debug logs, dead-letter storage, backups. If procurement smells unclear answers here, the review slows down fast, because now you're not discussing API connectivity — you're discussing lifecycle management of sensitive data across multiple platforms.

Step-by-Step Verification: Proving No-Storage Claims

Vendors will tell you they don't store data. Trust, but verify. Here's how engineering and security teams can independently confirm a pass-through/no-storage claim before the deal reaches procurement.

Step 1: Request the data flow diagram and map every persistence point

Ask for a diagram that covers the full request lifecycle - from your API call through the integration layer to the upstream provider and back. Specifically look for:

• Where the raw provider response is held during transformation
• Whether any queue, log, or object store receives the payload
• How webhook payloads are buffered before delivery to your endpoint
• What happens to payloads during retry and error-handling flows

If the diagram only shows the happy path (request in, response out), push back. The interesting persistence points are always in the error and retry paths.

Step 2: Inspect API response headers and latency

Make a few API calls through the vendor's proxy and examine the response. A true pass-through will typically show latency that tracks the upstream provider (because it's hitting the provider API in real time). If you get sub-20ms responses for an API that normally takes 300ms+, the data is coming from a cache, not the provider.

Also check for headers like X-Cache, Age, or vendor-specific caching indicators. Their absence doesn't prove no-caching, but their presence disproves it.

Run this side-by-side comparison against the same endpoint hit directly and through the vendor:

# 1. Direct upstream call (baseline latency)
curl -w "time_total=%{time_total}s\n" -o /tmp/direct.json -s \
  -H "Authorization: Bearer $UPSTREAM_TOKEN" \
  https://api.upstream.example/v1/employees
 
# 2. Same endpoint via the integration vendor
curl -w "time_total=%{time_total}s\n" -D /tmp/vendor-headers.txt \
  -o /tmp/vendor.json -s \
  -H "Authorization: Bearer $VENDOR_TOKEN" \
  https://api.vendor.example/unified/hris/employees
 
# 3. Look for caching indicators in the response headers
grep -iE '^(x-cache|age|cf-cache-status|x-served-from):' /tmp/vendor-headers.txt

Repeat the vendor call three times in a row. If the second and third calls are dramatically faster than the first, ask the vendor to explain what changed between requests. "Warm connection pool" is a legitimate answer for a small delta; a 10x speedup is not.

Step 3: Test with unique, traceable data (CI-friendly)

Create a test record in the source system with a unique identifier. Pull it through the integration vendor. Then delete it in the source system. Query the vendor again. If the deleted record is still returned, the vendor is serving from a cache, and their "no storage" claim doesn't hold.

Better, wire this into your CI so you catch regressions if the vendor changes their architecture:

// integration-tests/vendor-no-cache.spec.ts
import { describe, it, expect } from 'vitest';
import { randomUUID } from 'node:crypto';
import { createUpstreamRecord, deleteUpstreamRecord } from './helpers/upstream';
import { fetchViaVendor } from './helpers/vendor';
 
describe('vendor storage regression check', () => {
  it('does not serve deleted records from cache', async () => {
    const marker = `verify-${randomUUID()}@test.local`;
 
    // 1. Create a record in the upstream system
    const id = await createUpstreamRecord({ email: marker });
 
    // 2. Warm the vendor path so any cache would be populated
    const first = await fetchViaVendor(id);
    expect(first.status).toBe(200);
 
    // 3. Delete upstream and wait past any short TTL window
    await deleteUpstreamRecord(id);
    await new Promise((r) => setTimeout(r, 5_000));
 
    // 4. If the vendor is truly pass-through, this must 404
    const second = await fetchViaVendor(id);
    expect(second.status).toBe(404);
  });
});

Run this weekly against a sandbox tenant. If it ever starts failing, you have hard evidence for the vendor conversation.

Step 4: Review the vendor's SOC 2 Type II report for storage controls

The SOC 2 Type II report describes the vendor's control environment over a period of time - typically 6 to 12 months. Look for:

• System description section: Does it mention databases, caches, or data stores that hold customer payload data?
• Control activities: Are there controls around data retention, purging, or lifecycle management for customer data? If yes, something is being stored.
• Complementary User Entity Controls (CUECs): Do they require you to manage deletion or data lifecycle on their behalf? That implies data persists on their side.

Step 5: Ask for the retention and deletion matrix

Request a written matrix that lists every data category the vendor handles (payloads, tokens, metadata, logs, webhook bodies, retry queues, backups) and the exact retention period for each. A vendor with nothing to hide will have this ready. A vendor that hedges is storing more than they're admitting.

Step 6: Query your own logs for evidence of caching

You can also verify the claim from your side by inspecting traffic patterns. In your observability stack, compare vendor response times against known-direct calls to the same upstream endpoints.

Splunk / SPL-style query:

index=api_gateway (source="vendor-proxy" OR source="upstream-direct")
| stats median(response_time_ms) as p50, count as n by source, endpoint
| xyseries endpoint source p50
| eval delta_ms = 'upstream-direct' - 'vendor-proxy'
| where delta_ms > 100 AND n > 50
| sort - delta_ms

Datadog / Elastic equivalent: group by endpoint and service, compare p50(response_time), and alert when the vendor path is consistently more than 100ms faster than the direct upstream path for the same endpoint. That kind of gap is a fingerprint of caching and is worth raising with the vendor in writing.

Architectural Must-Haves to Pass Vendor Security Reviews

If you want your integration layer to survive an enterprise security review, evaluate it against these specific technical requirements. This isn't a marketing checklist — it's what procurement teams actually look for.

1. Zero Data Retention (Pass-Through Proxy Architecture)

The single most impactful architectural decision is whether your integration vendor stores customer payload data. A zero-storage, pass-through proxy means the vendor receives an API request, translates it, forwards it to the third-party API, normalizes the response in memory, and returns it to your application. The raw payload is immediately marked for garbage collection. It never touches a disk, and it's never written to a log file.

A point of precision: "zero storage" doesn't mean literally nothing is stored. Serious platforms still store tokens and connection metadata. The meaningful distinction is whether customer payload data is retained. That's the line procurement cares about.

sequenceDiagram
    box rgb(235, 232, 226) Zero-Storage Pass-Through Architecture
    participant App as Your Application
    participant Proxy as Integration Proxy
    participant SaaS as 3rd-Party SaaS
    end
    
    App->>Proxy: Request Data
    Proxy->>SaaS: Fetch Data
    SaaS-->>Proxy: Return Payload
    Note over Proxy: In-Memory Transformation<br>Only
    Proxy-->>App: Return Normalized Data
    Note over Proxy: Payload NEVER<br>written to disk

2. White-Label OAuth Flows

Enterprise IT admins will not authenticate their corporate CRM or ERP through a third-party domain they've never heard of. If your integration vendor forces users through auth.random-vendor.com, the security team will block the connection. White-labeling the OAuth flow under your own domain keeps the third-party vendor entirely out of the user trust chain and removes a friction point in procurement.

3. Declarative Execution with Minimal Attack Surface

How much custom code does the integration vendor maintain per integration? A platform with thousands of lines of hand-written connector code per provider has a proportionally larger attack surface. Every line of custom code is a potential vulnerability.

The alternative is a declarative, configuration-driven architecture where integrations are defined as data — mapping configurations, transformation expressions, authentication templates — rather than imperative code. One generic execution pipeline handles every integration, dramatically reducing the codebase that needs to be audited and secured.

4. On-Premises and VPC Deployment

For the most security-sensitive buyers — healthcare, finance, government, defense — even a pass-through proxy might not be enough if it runs on shared cloud infrastructure. Your vendor must offer the ability to deploy the entire proxy infrastructure inside your own Virtual Private Cloud (VPC) or on-premises environment, completely removing the vendor from the data path.

Not every deal will require this. But having the option available can close deals that would otherwise be impossible.

5. An Escape Hatch to the Raw Provider API

A good unified API should not trap you. When the unified model doesn't cover a provider-specific field, custom object, or edge-case endpoint, you need a clean fallback — a pass-through proxy API that lets you make raw, provider-specific calls using the same managed authentication and rate limiting. Without this, engineers end up bolting on a second unofficial integration path, which creates its own security headaches.

Be honest about the trade-offs. Pass-through architectures are slower for bulk reads because every request hits the third-party API in real time. If your use case requires materializing large datasets for analytics, you'll need to handle that caching in your own infrastructure where you control the security perimeter. That's actually a feature from a compliance perspective — your customer's data lives in systems you control and can audit.

Architecture Evidence: What Diagrams to Demand from Your Vendor

A vendor's marketing page will say "we don't store your data." Procurement needs proof. The diagrams below represent what a rigorous security review demands - not one generic architecture slide, but multiple views that cover normal operations, failure paths, and credential handling.

Diagram 1: End-to-end data flow (happy path)

This should show the full lifecycle of a single API request - from your application to the integration proxy, through to the upstream provider, and the response back. Every box on the diagram should be annotated with whether data is persisted or in-memory only.

What to look for: No persistence points between the provider response and your application's receipt of the normalized data.

Diagram 2: Error and retry paths

This is where hidden storage surfaces. When a request fails, where does the payload go? Is it written to a dead-letter queue? Is it logged with the full response body? Is it stored for retry?

A pass-through vendor should show that failed requests return errors to your application without persisting the payload. Your application owns the retry logic and the decision about whether to store the response.

Diagram 3: Webhook delivery flow

If the vendor offers unified webhooks, the diagram should cover: inbound event from the provider, transformation/normalization step, outbound delivery to your endpoint, and the retry mechanism if your endpoint is unreachable.

Webhook flows are the most likely place for a "no-storage" vendor to actually persist data, because they need to buffer events for delivery. Ask specifically: where are webhook payloads held during delivery retries, and for how long?

Diagram 4: Credential and token management

This diagram should show how OAuth tokens, API keys, and refresh tokens are stored, encrypted, and rotated. Key questions:

• Are tokens encrypted at rest (not just the database volume - the token values themselves)?
• Who owns the OAuth application - your customer, you, or the integration vendor?
• How is token refresh handled, and are expired tokens purged?

If a vendor can produce all four diagrams with clear annotations, they're serious about security. If they push back or offer a single high-level architecture slide, treat that as a yellow flag.

Technical Security Checks: TLS, Credential Encryption, and Webhook Signing

Beyond architecture, procurement and engineering teams should verify specific technical controls. These checks apply to any integration vendor, not just unified APIs.

TLS configuration

Every connection in the integration chain - your app to the vendor, the vendor to the upstream provider - should use TLS 1.2 as a minimum. TLS 1.3 is preferred and increasingly expected: NIST SP 800-52 Revision 2 mandates TLS 1.3 support for federal systems and recommends preferring it when both parties support it. PCI DSS requires strong cryptography and considers older TLS versions insufficient.

How to verify: Use tools like openssl s_client, testssl.sh, or Qualys SSL Labs to check the vendor's API endpoints. Confirm they support TLS 1.2+ and have disabled TLS 1.0/1.1. Check that cipher suites support forward secrecy (ECDHE-based key exchange).

# Quick TLS check against a vendor API endpoint
testssl.sh --protocols --ciphers api.vendor.example
 
# Or with openssl - confirm TLS 1.3 handshake
openssl s_client -tls1_3 -connect api.vendor.example:443 </dev/null 2>/dev/null \
  | grep -E 'Protocol|Cipher'

Include this as a pre-deployment check in your CI so you get alerted if the vendor ever regresses TLS support.

Credential encryption and isolation

Your customers' OAuth tokens and API keys are the highest-value targets in the integration layer. Verify:

• Encryption at rest: Tokens should be encrypted with AES-256 (or equivalent) using a managed key service, not stored in plaintext or with application-level obfuscation.
• Key rotation: Ask about the key rotation policy. Credentials should be re-encrypted when keys rotate, and the vendor should have a defined rotation cadence.
• Isolation: In a multi-tenant platform, can one customer's credentials ever be accessed through another customer's API calls? The answer needs to be architecturally enforced, not just policy-based.
• Token refresh: The platform should refresh OAuth tokens proactively before they expire, not reactively after a failed API call exposes an expired token to your application.

Webhook signature verification

If the vendor delivers webhooks to your application, those payloads must be signed so you can verify authenticity and detect tampering. The industry standard is HMAC-SHA256: the vendor signs the payload body with a shared secret, includes the signature in a request header, and your application recomputes the hash to verify.

What to check:

• Algorithm: HMAC-SHA256 at minimum. Avoid vendors still using SHA-1.
• Timestamp validation: The signature should include a timestamp component so you can reject replayed events outside a tolerance window (typically 5 minutes).
• Constant-time comparison: The vendor's documentation should recommend timing-safe comparison functions to prevent timing attacks.
• Per-endpoint secrets: Each webhook destination should have its own signing secret, not a single shared secret across all customers.

Reference verification snippet auditors expect to see in your code:

import { createHmac, timingSafeEqual } from 'node:crypto';
 
export function verifyWebhook(
  rawBody: Buffer,
  header: string,     // e.g. "t=1735689600,v1=abcdef..."
  secret: string,
  toleranceSeconds = 300,
): boolean {
  const parts = Object.fromEntries(
    header.split(',').map((kv) => kv.split('=') as [string, string]),
  );
  const timestamp = Number(parts.t);
  const provided = Buffer.from(parts.v1 ?? '', 'hex');
 
  // Reject replays outside the tolerance window
  if (!Number.isFinite(timestamp)) return false;
  if (Math.abs(Date.now() / 1000 - timestamp) > toleranceSeconds) return false;
 
  const expected = createHmac('sha256', secret)
    .update(`${timestamp}.`)
    .update(rawBody)
    .digest();
 
  return provided.length === expected.length && timingSafeEqual(provided, expected);
}

Field-level encryption considerations

For highly regulated data (PHI, financial records, SSNs), ask whether the vendor supports field-level encryption - encrypting specific sensitive fields within the payload rather than relying solely on transport-level (TLS) and storage-level encryption. In a pass-through architecture this matters less since data isn't persisted, but it becomes relevant for webhook delivery flows or any buffering mechanism.

Authentication & Credential Controls: AES-256, Token Lifecycle, and Tenant Isolation

The previous section covered the surface-level checks. Enterprise reviewers go a level deeper on how credentials are issued, rotated, isolated, and revoked. This is where a pass-through vendor either earns trust or reveals gaps.

AES-256 at rest, in practice

"AES-256" on a marketing page is easy. What reviewers actually want to see:

• Envelope encryption. Data-encryption keys (DEKs) wrap the token ciphertext; a key-encryption key (KEK) held in a managed key service wraps the DEKs. Rotating the KEK re-wraps DEKs without touching every ciphertext.
• Mode of operation. AES-GCM (authenticated encryption) preferred over AES-CBC. If the vendor still uses AES-CBC without a separate MAC, that's a bug, not a feature.
• Key custody. The KEK should live in a hardware-backed key service (HSM or cloud KMS with FIPS 140-2 Level 2+ modules). Application code should never see the KEK.
• Rotation cadence. DEKs rotated at least annually; KEK rotated per the KMS provider's guidance. Ask for the last rotation timestamp.

How to verify without source access: request the encryption whitepaper or the SOC 2 System Description section covering cryptographic controls. Look for named algorithms, key sizes, and rotation windows. Vague language ("industry-standard encryption") is a red flag.

Token lifecycle

OAuth tokens are the highest-value secrets in the integration layer because a leaked token is a persistent backdoor into a customer's SaaS tenant. Reviewers want to see a defined lifecycle across five phases:

Ask the vendor to walk through what happens when an end user clicks "Revoke access" in Salesforce or Google Workspace. If the answer is "we detect it on the next API call and clean up," that's acceptable. If the answer is "we don't detect it," that's a governance gap.

Tenant isolation

Multi-tenant platforms need architecturally enforced isolation, not just policy. Ask which model the vendor uses:

• Row-level isolation. Tenant ID enforced at every query, with database-level policies (for example, PostgreSQL row-level security) as a backstop.
• Schema-level isolation. One schema per tenant. Higher operational overhead but stronger blast-radius containment.
• Physical isolation. Separate databases or cells per tenant. Reserved for the most sensitive deployments; equivalent to a small-scale self-hosted model.

The verification question is: "Show me the code path that could return one tenant's data to another tenant's API call." A vendor that has thought about this can point to the tenancy check in their request handler and the corresponding database policy. A vendor that hasn't will hand-wave.

For token access specifically, isolation matters even more. A leaked or misconfigured internal token should never allow cross-tenant reads. Request-scoped credentials (short-lived, per-tenant) are stronger than long-lived service credentials that see every tenant.

IP allowlisting and last-used tracking

Two smaller controls mature vendors ship:

• IP allowlisting on API tokens. A vendor-issued token that can only be called from a defined CIDR range dramatically reduces the impact of a leaked key. Enforced at authentication time, not just logged.
• Last-used tracking. Every token has a "last used at" timestamp visible in the vendor's UI. Stale tokens surface as a candidate for revocation. Ask whether the vendor emits digest alerts for tokens unused past a threshold (30 or 60 days is typical).

Both controls turn credentials from a black box into an observable, containable surface. When a reviewer asks "how would you know if one of your integration platform tokens was compromised?", these features are the answer.

Operational Controls: Rate Limiting, High Availability, and Penetration Testing

Security reviews don't stop at data handling. Enterprise buyers also want evidence that the vendor operates the platform safely and can recover from failure without expanding the customer's blast radius.

Rate limiting and abuse controls

A shared integration platform is a shared fate. If one customer's traffic saturates the vendor's upstream connections to Salesforce, everyone's Salesforce calls suffer. Ask what the vendor does about it:

• Per-tenant quotas. Requests per second and per day enforced at the tenant level, not just globally.
• Upstream rate limit respect. The vendor should track each provider's rate limit headers and back off preemptively, using exponential backoff with jitter for retries.
• Circuit breakers. When an upstream provider is degraded, the vendor should short-circuit further calls to that provider for a short window rather than pile on failing requests.
• Idempotency. Write operations should accept an idempotency key so client-side retries don't create duplicate records.

Ask for a rate limit incident from the last 12 months and how the vendor handled it. A vendor with mature operational controls will have a story. A vendor without will change the subject.

High availability and disaster recovery

The metrics enterprise procurement expects:

• Uptime SLA. 99.9% is the floor for integration platforms; 99.95% is common for enterprise tiers.
• RTO (recovery time objective). Time to restore service after a regional failure. Typically 1-4 hours.
• RPO (recovery point objective). Maximum acceptable data loss window. For a zero-storage architecture, RPO for payload data is trivially zero because nothing is stored. RPO applies to operational metadata (tokens, connection state).
• Multi-region posture. Active-active, active-passive, or single-region with backup restoration. Multi-region is the enterprise expectation.
• DR test evidence. A tabletop or full failover test in the last 12 months, with a written report. An untested plan is not a plan.

For self-hosted deployments, most of this becomes your responsibility. Make sure the vendor's runbooks and health check endpoints are documented well enough for your team to operate the platform.

Penetration testing

Ask for the executive summary of the most recent third-party penetration test. What you want to see:

• Cadence. Annual at minimum; semi-annual for platforms handling regulated data.
• Scope. Web application, API endpoints, cloud infrastructure, and if applicable, mobile and self-hosted deployment artifacts. Scope should include the integration proxy runtime, not just the marketing site.
• Methodology. OWASP ASVS or a comparable framework; grey-box or white-box testing with source access, not just black-box.
• Remediation timelines. Critical findings closed within 30 days, highs within 60, mediums within 90. Ask for a summary of findings from the last report with remediation status.
• Tester independence. A named third-party firm, not the vendor's internal security team. Big Four consultancies and specialist firms (Bishop Fox, NCC Group, Trail of Bits) carry weight with enterprise reviewers.

Vulnerability management

The pen test is a point-in-time check. Continuous vulnerability management fills the gap:

• Dependency scanning. Automated on every build, with SLAs to remediate CVEs by severity.
• Container and infrastructure scanning. Baseline images scanned, drift detected.
• Bug bounty program. Public or private program with defined scope and payout tiers. Not mandatory, but a positive signal.
• SBOM (Software Bill of Materials). Available on request for enterprise deployments. Increasingly a hard requirement for federal and financial customers.

How Truto's Zero-Storage Architecture Solves the Compliance Puzzle

Truto was engineered specifically for this problem. We recognized early on that schema normalization is the hardest problem in SaaS integrations, but solving it by caching data creates an unacceptable security liability.

Truto uses a zero data retention architecture. We act as a real-time proxy and never store third-party API payload data in our database.

In-Memory Schema Normalization via JSONata

Instead of relying on a sync-and-store database, Truto transforms requests and responses on the fly using JSONata, a lightweight query and transformation language for JSON. Provider-specific fields are mapped to unified data models entirely in memory.

/* JSONata transformation: Salesforce → Unified Contact */
{
  "id": Id,
  "first_name": FirstName,
  "last_name": LastName,
  "email": Email,
  "phone": Phone,
  "company_name": Account.Name,
  "created_at": CreatedDate,
  "updated_at": LastModifiedDate
}

When a request hits Truto's Unified API, the proxy fetches the raw payload from the upstream provider, applies the JSONata expression in memory, and returns the normalized JSON to your application. Here's the simplified execution flow:

async function handleUnifiedRequest(req) {
  const requestToProvider = applyMapping(req, providerRequestMapping);
  const providerResponse = await fetch(requestToProvider.url, requestToProvider);
  const unifiedResponse = applyMapping(
    await providerResponse.json(),
    providerResponseMapping
  );
 
  return unifiedResponse; // transformed in memory, never written to a sync store
}

sequenceDiagram
    participant App as Your Application
    participant Truto as Truto Proxy Layer
    participant Provider as BambooHR API

    App->>Truto: GET /unified/hris/employees
    Truto->>Truto: Resolve auth, build<br>provider-specific request
    Truto->>Provider: GET /v1/employees/directory
    Provider-->>Truto: Provider-specific JSON
    Truto->>Truto: Apply JSONata transformation<br>(in-memory, no disk write)
    Truto-->>App: Unified schema response

That does not mean Truto is stateless. We still manage credentials, integrated-account metadata, and operational controls. Stored tokens use AES-256 encryption. The honest win here is not "nothing is stored anywhere." The win is that customer payload data does not need to live in the integration platform's database to make the unified API work. That is a much better answer in a SIG review.

Zero Integration-Specific Code

Truto handles hundreds of integrations without a single line of integration-specific code in its runtime logic. Whether the request is going to HubSpot, Salesforce, Workday, or a niche HRIS platform, it passes through the exact same generic execution pipeline. Same runtime path, different configuration. Same transform model, different expressions. This drastically reduces the attack surface compared to platforms that maintain custom adapter code for every API.

The Proxy API Escape Hatch

Unified APIs are powerful for standard CRUD operations, but enterprise customers always have edge cases — custom fields, proprietary objects, bespoke workflows. Instead of forcing you to build a secondary integration infrastructure, Truto provides a pass-through Proxy API. You can make raw, provider-specific API calls through Truto, using our managed authentication and rate limiting, with the exact same zero-storage compliance guarantees. It's the difference between a unified API that helps and one that traps you.

White-Label OAuth and On-Prem Deployment

Truto fully supports white-labeled OAuth flows — your brand, your domain, your consent screen. The integration vendor is invisible to the end user. For strict compliance requirements, Truto can be deployed directly into your AWS, GCP, or Azure VPC, or on-premises, completely removing us from the customer's third-party risk surface. Learn more about Truto's security controls and architecture.

What this means for your SIG Core questionnaire:

• "Does the sub-processor store customer data?" No. Truto processes data in memory and returns it to your application. No payload data is persisted.
• "What is the data retention period?" Not applicable. There is no retained data.
• "Can customer data be deleted on request?" There is nothing to delete. Metadata like connection status and API logs can be purged, but customer payload data never touches Truto's storage.
• "Can the solution be deployed in our infrastructure?" Yes. Truto supports on-premises and VPC deployment.

This isn't a magic bullet. Real-time pass-through means you're subject to third-party API latency and rate limits on every call. You don't get the luxury of a warm cache for repeated reads. For use cases that require bulk data extraction or analytics, you'll want to sync data into your own data warehouse. But the compliance benefit is decisive: your integration vendor disappears from the data sub-processor list, and your security review gets dramatically simpler.

Sample Procurement Q&A: Short Answers for Your Security Review

Here are the most common procurement questions about integration vendors, with concise answers you can adapt. These are written from the perspective of a company using a pass-through integration architecture.

What to Ask Your Integration Vendor Before the Security Review Starts

Don't wait for procurement to surface these questions. Ask them during vendor evaluation:

1. "Does your platform store, cache, or persist any customer payload data? If so, for how long and where?" The answer should be unambiguous. "We cache for performance" is a red flag.
2. "Are you classified as a data sub-processor under GDPR/HIPAA, or only as a data processor in transit?" This determines the depth of the security review your customers will have to run.
3. "Can you deploy inside our customer's VPC or on-premises?" Even if you don't need it today, having this option signals architectural maturity.
4. "How much integration-specific code do you maintain per provider?" More code means a larger attack surface and more potential vulnerabilities.
5. "Can we white-label the OAuth flow so our customers never see your brand?" This simplifies the security narrative and removes procurement friction.

Better yet, don't wait for procurement to ask. Send them a one-page packet proactively:

1. Data flow diagram — source system, integration layer, your app, and every place data can persist
2. Stored vs. not stored matrix — payloads, tokens, metadata, logs, webhook bodies, backups
3. OAuth ownership note — whose app appears during consent and who controls scopes
4. Deployment options — SaaS, VPC, on-prem, region controls
5. Retention and deletion schedule — exact timelines, not vibes
6. Sub-processor list — with purpose and data categories

That packet won't make every security reviewer friendly. It will make them faster. And speed matters — the longer a deal sits in vendor risk review, the more time your champion has to change jobs, lose budget, or get beaten by a competitor with a cleaner answer.

The Evidence Pack: A Turnkey Packet for Faster Reviews

Everything above tells you what enterprise reviewers want. The Evidence Pack gives your sales and security teams the actual documents to hand them. It's designed for one job: turn a multi-week vendor security review into a single-meeting decision by pre-answering the 80% of questions that appear in every SIG or CAIQ response for an API aggregator.

What's Included

The pack ships as a zip archive with both PDF (for procurement uploads) and editable formats (Word/Markdown for text, draw.io + SVG for the diagram) so your team can adapt every artifact to your specific architecture.

The rest of this section previews the templates so you can see the shape of each document before requesting the full pack.

Bridge Letter Template

A SOC 2 Type II report covers a fixed audit window. If a customer's review lands six months after the report closes, procurement will ask for a bridge letter (also called a gap letter or subsequent-events letter) attesting that no material control changes have occurred since the report period ended. The skeleton looks like this:

[Vendor Letterhead]
[Date]
 
To Whom It May Concern:
 
This letter is issued in reference to the SOC 2 Type II report prepared by 
[CPA Firm] covering the period [Report Start] through [Report End] for 
[Vendor Name]'s [System Name] service.
 
From [Report End] through [Bridge Letter Date], [Vendor Name] confirms:
 
1. No material changes have been made to the controls described in Section III 
   of the SOC 2 Type II report.
2. No control failures, exceptions, or security incidents have occurred that 
   would materially affect the conclusions expressed in the report.
3. The sub-processor list in Appendix [X] remains accurate, except as noted 
   below: [List any additions/removals, or "None"].
4. The next SOC 2 Type II audit is scheduled for [Next Audit Period].
 
This letter is issued in good faith based on management's knowledge and is 
not a substitute for an independent audit opinion.
 
Sincerely,
[Name], [Title]
[Vendor Name]

Guidance for procurement: Bridge letters are generally considered stale after roughly 90 days. If more than three months have passed since issuance, request a fresh letter. If the vendor cannot produce one within five business days, treat that itself as a signal about their audit maturity.

SOC 2 Request Language

When you ask your integration vendor for their SOC 2, ask for the whole package, not just the cover PDF. Copy-paste-ready request:

Subject: SOC 2 Type II Documentation Request - [Your Company Name]
 
Hi [Vendor Contact],
 
To complete our vendor security review, please provide the following under 
our existing NDA:
 
1. Current SOC 2 Type II report (full report, not executive summary), including:
   - Section II: Management's assertion
   - Section III: System description
   - Section IV: Description of controls and test results
   - Section V: Other information provided by management (if applicable)
 
2. Bridge letter covering the period from the report end date to today, if more 
   than 90 days have elapsed since the report period closed.
 
3. List of Complementary User Entity Controls (CUECs) extracted from Section IV, 
   with any implementation notes.
 
4. List of sub-service organizations, indicating whether they are included 
   using the inclusive or carve-out method.
 
5. Any exceptions or deviations noted by the auditor, along with management's 
   response and remediation status.
 
Please confirm the report covers the Trust Services Criteria applicable to our 
use case: Security (mandatory), and where relevant Availability, Confidentiality, 
and Processing Integrity.
 
Thanks,
[Your Name]

Guidance for procurement: A vendor who only sends the executive summary is either hiding something or unfamiliar with the process. Neither is acceptable at enterprise scale. Push for the full report every time.

DPA Clause Snippets

Most vendor DPAs default to permissive retention language. If you're standing on a zero-storage architecture, your DPA should reflect that in writing. These snippets are drafted to be pasted into a vendor DPA with minimal edits.

Clause: Zero retention of payload data

Processing in Transit Only. The Processor operates as a real-time proxy for 
Customer Data. Payload data received from upstream third-party services and 
returned to the Controller is processed in memory and is not written to 
persistent storage, log files (beyond metadata such as request identifiers, 
timestamps, and HTTP status codes), backups, or analytics systems. The 
retention period for Customer payload data is zero (0) days.

Clause: Sub-processor notification with named parties

Sub-processors. The Processor engages the following Sub-processors to deliver 
the Services, each with the stated purpose and data categories:
 
| Sub-processor         | Purpose                                    | Data Categories                          | Location |
|-----------------------|--------------------------------------------|------------------------------------------|----------|
| [Cloud Infra Vendor]  | Compute and network for the proxy runtime  | Operational metadata; encrypted tokens   | [Region] |
| [Managed KMS Vendor]  | Key custody for AES-256 envelope encryption| Key material only; no Customer Data      | [Region] |
| [Log Aggregation]     | Request/response metadata for observability| Timestamps, HTTP status, request IDs     | [Region] |
| [Email/Notification]  | Transactional notifications to Controller  | Contact identifiers of admin users       | [Region] |
 
The Processor shall maintain the current list at [URL] and shall notify the 
Controller at least thirty (30) days in advance of engaging any new 
Sub-processor. The Controller may object on reasonable data protection grounds 
within fifteen (15) days of notification. If the parties cannot resolve the 
objection in good faith, the Controller may terminate the affected services 
without penalty and receive a pro-rata refund of prepaid fees.

Clause: Metadata vs. payload separation

Categories of Data Processed. The Processor processes two distinct categories:
(a) Customer Payload Data - the content of API requests and responses routed 
    through the Processor's proxy. Retention: zero.
(b) Operational Metadata - connection identifiers, encrypted OAuth tokens and 
    refresh tokens, request timestamps, HTTP status codes, and error codes. 
    Retention: as specified in Schedule [X], not to exceed the period 
    reasonably necessary for service delivery, audit, and incident response.

Clause: Deletion on termination

Return and Deletion. Upon termination of the Agreement or upon the Controller's 
written request, the Processor shall (i) confirm in writing that no Customer 
Payload Data is retained (as none is stored during ordinary operation), and 
(ii) delete or return all Operational Metadata within thirty (30) days, 
providing a certificate of deletion signed by an authorized officer.

Guidance for procurement: If your vendor pushes back on the zero-retention clause, ask them to explain in writing exactly what payload data is stored and for how long. Their answer will tell you whether the marketing claim of "pass-through" matches the engineering reality. Named sub-processors in the DPA table are non-negotiable at enterprise scale; a DPA that only says "Processor may engage Sub-processors as necessary" will get flagged in every review.

Annotated Architecture Diagram Template

The diagram below is the template shipped in the Evidence Pack as an editable draw.io file and an SVG. Every persistence point is labeled with its retention behavior. Fill in your vendor's specifics and share it with reviewers as the single visual answer to "where does data live?"

flowchart LR
    App["Your Application<br>(Data Controller)"]
    Proxy["Integration Proxy<br>[IN-MEMORY ONLY]"]
    Provider["Upstream SaaS API<br>(Salesforce, Workday, etc.)"]
    Tokens["Token Vault<br>[PERSISTED: AES-256]"]
    Logs["Operational Logs<br>[PERSISTED: metadata only, 30d TTL]"]
    Webhook["Webhook Buffer<br>[PERSISTED: 24h retry window]"]

    App -->|"HTTPS / TLS 1.3"| Proxy
    Proxy -->|"HTTPS / TLS 1.3"| Provider
    Provider -->|"Payload (in-memory)"| Proxy
    Proxy -->|"Normalized response"| App
    Proxy -.->|"Read encrypted token"| Tokens
    Proxy -.->|"Write metadata only"| Logs
    Provider -.->|"Inbound event"| Webhook
    Webhook -->|"Signed delivery"| App

How to fill it in for your review:

1. Rename each node with your vendor's actual component names.
2. Color-code every persistence point: green for in-memory only, yellow for encrypted metadata storage, red for any payload persistence.
3. Add TTL and encryption annotations to every yellow and red node.
4. If a reviewer asks "where else does data live?", the answer should already be on the diagram.

Guidance for procurement: If a diagram from the vendor has no yellow or red boxes at all, that's a claim worth verifying. Every real system has some persistence (tokens, metadata, logs). A diagram with only green boxes is aspirational, not accurate.

Sample SIG Core / CAIQ Answers

The Evidence Pack ships a spreadsheet keyed to the most-flagged SIG Core 2025 and CAIQ v4 domains for integration vendors. A representative subset is shown below; the full sheet is editable so your security lead can adapt each answer to your deployment.

Guidance for sales and security: Do not send the pre-filled sheet as-is. Review each row against your actual deployment, delete rows that don't apply, and have your security lead sign off before it reaches the buyer. A wrong answer here is worse than no answer, because it undermines every other document in the pack.

How to Present the Evidence Pack to Procurement

Having the artifacts isn't enough. How you deliver them determines whether the review takes two weeks or two months. Treat this section as a sales enablement runbook.

Send it before they ask

The single biggest time-saver is proactive delivery. When your AE moves a deal into procurement, send one email to the buyer's security lead containing:

• A one-page cover memo naming the artifacts included and the point of contact for follow-ups
• The full artifact pack (SOC 2, DPA with named sub-processors, sub-processor list, data flow diagram, retention matrix, pen test summary)
• Pre-filled SIG Core / CAIQ responses keyed to the buyer's likely framework
• A calendar link for a 30-minute security review call

This changes the reviewer's default from "chase the vendor for documents" to "read what's in front of me." Response times measurably drop.

The security review call

Book a 30-minute walkthrough with the buyer's security lead and your own security engineer or solutions engineer. Recommended agenda:

1. Architecture overview (10 min). Walk through the annotated data flow diagram. Point to every persistence node and its retention policy.
2. Data handling deep-dive (10 min). Zero-storage claim, credential encryption, webhook signing. Show live examples where possible - a curl against the proxy, a webhook signature verification, a token revocation event.
3. Compliance artifacts (5 min). SOC 2 scope, pen test cadence, bridge letter status, sub-processor list.
4. Open questions (5 min). Capture follow-ups with owners and dates. Send written responses within 48 hours.

Skip the marketing slides. Reviewers value clarity over polish.

Who should be in the room

For larger deals, having your CISO on the call carries weight. It signals that security isn't a checkbox function.

Handle follow-ups on a clock

Enterprise reviews stall when responses lag. Commit to a written SLA for follow-up questions:

• Trivial clarifications: same business day
• Documentation requests: 48 hours
• Custom control questions: 5 business days with an interim acknowledgment

Track every question in a shared document. When the review closes, that document becomes the seed for the next deal's response.

What "closed" looks like

The review is done when the buyer's security team issues one of:

• A signed-off risk assessment (may include conditions like annual review or breach notification tightening)
• Approval to proceed to contract, sometimes conditional on DPA execution
• A written exception note if any control is waived, filed with their internal risk register

Get the sign-off in writing. Verbal approvals evaporate when the champion changes teams.

Next Steps: Escalation Paths and Contract Red Flags

You've done the technical verification and gathered the artifacts. Before the contract is signed, watch for these red flags in the vendor agreement itself - and know when to escalate.

Contract red flags specific to integration vendors

• No right-to-audit clause. If the vendor won't contractually allow you (or your customer) to audit their security controls, walk away. Trustworthy vendors understand that compliance is a shared responsibility.
• Vague data handling language. Terms like "reasonable security measures" or "industry-standard practices" without specifics are a warning sign. The contract should reference specific encryption standards, retention periods, and deletion procedures.
• Unilateral sub-processor changes. The DPA should require the vendor to notify you before adding new sub-processors and give you the right to object. If they can change the data supply chain without telling you, your customer's security posture is out of your control.
• No breach notification timeline. The contract must specify how quickly the vendor will notify you of a security incident. GDPR requires 72-hour notification to the data protection authority. Your vendor should commit to notifying you faster than that so you can meet your own obligations.
• Termination data provisions missing. The agreement should clearly state what happens to your data (and your customers' data) when the contract ends - return timelines, deletion confirmation, and format of exported data.
• Liability caps that don't match risk. If the vendor's total liability is capped at 12 months of fees but they're handling your enterprise customers' PII, the math doesn't work. Negotiate carve-outs for data breaches and confidentiality violations.

When to escalate

If your integration vendor can't satisfy these requirements, you have three options:

1. Negotiate. Many vendors will improve contract terms and produce missing artifacts if the deal is large enough. Give them a specific list and a deadline.
2. Self-host. If the vendor offers VPC or on-prem deployment, this can resolve most data residency concerns by removing the vendor from the data path entirely.
3. Switch vendors. If the vendor's architecture fundamentally relies on caching customer data and they can't offer a pass-through mode or self-hosted deployment, the compliance gap won't close through negotiation. It's an architecture problem, not a contract problem.

The worst outcome is signing a contract with known compliance gaps and hoping procurement doesn't notice. They will - either during the initial review or, worse, during an incident investigation.

Stop Losing Deals to Your Integration Layer

When you sell to SMBs, integrations are a product feature. When you sell to the enterprise, integrations are a security risk.

Enterprise security reviews are getting harder, not easier. Third-party cybersecurity incidents have surged in recent years, affecting over 60% of companies. Procurement teams are responding by scrutinizing every vendor in the supply chain, and your integration layer is one of the first things they'll examine.

The fix is architectural. You cannot afford to lose six-figure deals because your integration vendor decided it was easier to cache data than to build a performant proxy layer. Enterprise procurement teams will catch sync-and-store architectures, and they will weaponize them against your deal.

By adopting a zero-storage, pass-through architecture, you turn security from a liability into a competitive advantage. You can look the enterprise CISO in the eye and state definitively that your integration layer does not store their data, does not cache their PII, and does not expand their shadow data footprint. That is how you pass the SIG Core. That is how you close the deal.