SOC 2 Compliance Requirements for Integration Infrastructure

SOC 2 tells you almost nothing about whether your integration layer will pass, because most SOC 2 guides are written for a single product sitting on a single database, not for the tangle of API gateways, pipelines, and connectors that actually move your customer data around. That's the gap this piece is here to close. If your business runs on integrations, the standard checklist won't save you; you need to know what each Trust Services Criterion actually demands once data starts hopping between systems.

Here's the core problem. API gateways, data pipelines, connectors, and event buses don't own data. They move it, reshape it, and pass it along. That in-between role means a broken pipeline isn't just an outage; it's an availability event, a confidentiality problem, and a processing integrity failure, all at the same time, from the same root cause. Generic compliance guides treat "infrastructure" like one big box you can draw a line around. Integration infrastructure refuses to sit still like that. It's built to connect things, not contain them, so the audit boundary gets fuzzy fast: is every hop and transformation inside your control environment, or did some of it just become a subservice organization's problem? Teams that don't answer that question early show up to their first audit badly underprepared, and by then it's expensive to fix.

What SOC 2 is — and what kind of evaluation it actually performs

SOC 2 is not a certificate you hang on the wall. It's an opinion, written by a licensed CPA firm, developed under AICPA standards, about whether your controls are designed well (Type I) or actually worked over time (Type II). There's no registry, no badge that means anything on its own, no shortcut. The whole thing sits on the COSO Internal Control framework, and the auditor's report is the product, full stop.

Five Trust Services Criteria exist. Security is mandatory, always, in every report, and it carries more than 30 individual controls on its own. Availability, Processing Integrity, Confidentiality, and Privacy are technically optional; you include them only if they apply to what you do. Here's the catch for anyone running integration infrastructure: "optional" is mostly theoretical. If your pipelines move customer data, Availability, Processing Integrity, and Confidentiality are going to apply almost automatically. There's no dodging them.

Type I versus Type II matters more than most people realize when they're planning a timeline. Type I checks your controls at one moment, like a photo. Type II watches them work over a stretch of time, usually somewhere between 3 and 12 months. Enterprise buyers in banking, healthcare, and government treat a current Type II report as table stakes; show up without one and you're cut from the vendor shortlist before anyone even scores your product. And here's the part that trips people up: you have to lock your scope, meaning which criteria you're including, before that observation window starts. Add a criterion halfway through and the clock resets. You start over.

How the Security Common Criteria apply specifically to integration layers

CC6.1 requires logical access controls over protected information assets. For a normal SaaS company, that means databases and app servers. For an integration layer, it means every API endpoint, every message queue, every pipeline config file counts as a protected asset too. Service accounts that connectors use to talk to each other need the same treatment as human logins: inventoried, scoped to the minimum access they need, reviewed on a regular schedule.

Access lifecycle problems are the single most common thing auditors flag. Deprovisioning failures show up in something like 30 to 40 percent of audits, and access review gaps show up in 25 to 35 percent. In an integration environment, this gets worse, not better, because a connector gets retired and nobody remembers to kill its API key. That orphaned credential just sits there, active, invisible to any review process that only looks at human user accounts. It's the compliance version of leaving a spare house key under a rock nobody's checked in three years.

CC8 covers change management, and it applies just as hard to pipeline configs and connector updates as it does to application code. A schema migration that changes how data flows between two systems is a production change. So is an API contract update. Auditors want four things for each one: a documented reason in your ticketing system, a pull request showing the actual change, peer review plus automated test results, and a deployment record tied to a specific commit hash and the ticket that started it all. Screenshots of settings pages used to pass. Not anymore. Auditors now expect exported config files, CI logs kept for the full audit window, and deployment records that show exactly which commit went live and when.

MFA requirements apply to anyone with admin access to your integration tooling, meaning the orchestration layer, the gateway management console, the pipeline scheduler. Separately, machine-to-machine credentials (API keys, OAuth tokens, service account secrets) get their own scrutiny. The question auditors ask isn't whether you have credentials. It's whether they rotate, whether they're scoped tight, and whether every use gets logged.

Encryption requirements across every hop in an integration pipeline

A single record moving through your system might pass through an API gateway, land in a message queue, get transformed by a service, and finally settle in a destination datastore. Each one of those hops is a separate encryption event. TLS on the gateway doesn't cover the queue. And here's a detail people miss constantly: pipeline orchestrators often write intermediate state to disk while they work. That data is sitting "at rest," even if it only exists for four seconds, and it falls under at-rest encryption rules just the same as anything in permanent storage.

TLS 1.3 is the expected baseline now, and TLS 1.2 is the absolute floor; if you're still presenting only 1.2 configurations, expect the auditor to ask when you're upgrading. NIST required all US federal agencies to support TLS 1.3 by January 1, 2024 (SP 800-52 Rev. 2), and NIST published detailed enterprise deployment guidance in SP 1800-37 in September 2025. For data at rest, AES-256 is the standard everyone expects to see; AES-128 still passes cryptographic muster but draws more questions in sensitive contexts. A 2026 benchmark across 247 compliance engagements found that unencrypted data, whether at rest or in transit, was the single most common control failure across the board. Not a rare misstep. The most common one.

Key management needs its own paper trail. Having AWS KMS or Azure Key Vault or an HSM in place isn't the evidence; the evidence is the log showing key creation, rotation events, and access policies actually enforced. And integration pipelines have a specific weak spot here: long-lived API keys and connector credentials that never rotate. That's not a hypothetical risk. That's a finding waiting for an auditor to notice it.

Worth flagging for anyone building integrations meant to last: NIST finalized three post-quantum cryptography standards in August 2024 (FIPS 203, 204, and 205). Connectors built into enterprise systems with multi-year replacement cycles are exactly the kind of thing that will need to migrate eventually. Nobody's asking for PQC compliance today. But if your integration is going to live for five years, the planning clock already started.

What Availability and Processing Integrity require from pipelines specifically

Availability isn't just "is the server up." SOC 2 wants proof your infrastructure can take a hit, an outage, a traffic spike, and recover inside a documented recovery time objective. For integration infrastructure, that means the pipeline itself needs monitoring, not just the systems on either end of it. You need business continuity and disaster recovery plans that get tested annually, high-availability setups, and a real plan for scaling when data volume spikes.

Here's the sneaky failure mode specific to pipelines: one that goes quiet. No errors thrown, no alerts triggered, just... nothing coming out the other end. Standard uptime monitoring won't catch that, because technically the service is "up." Auditors will ask pointed questions about dead-letter queues, alerts for zero-messages-processed conditions, and retry logic. If you don't have an answer, that's a gap.

Processing Integrity lives inside the transformation logic itself: does the data come out complete, accurate, and unmodified by anything it shouldn't be touched by? You need detailed logs with timestamps on every processing step, a documented way to catch and fix errors, and formal change management anytime the transformation logic changes. The failure mode teams miss most often isn't a crash. It's a silently wrong output: a field that gets truncated, a mapping that's slightly off, nothing that throws an error but everything that's incorrect. Unless your pipeline actually compares input record counts against output record counts and flags mismatches, that kind of failure leaves zero trail. Auditors will want to see test cases where you deliberately feed the pipeline garbage input just to confirm it rejects it and logs the rejection properly.

Confidentiality scope is expanding, and integration infrastructure is directly in the path

Confidentiality used to be the criterion companies skipped unless they were in healthcare or finance. That's changing fast. Per the CBIZ 2024 SOC Benchmark Study, published March 2025, the share of SOC 2 reports including Confidentiality jumped from 34% to 64.4% in a single year. Enterprise buyers are pushing for it, and it's turning into a default expectation in B2B procurement rather than a specialty add-on.

For integration infrastructure, Confidentiality means data classification has to follow data in motion, not just data sitting in a database somewhere. A pipeline routing customer records needs to know those records are classified as confidential and needs to enforce controls accordingly, at every hop, including the ones that only exist for a few milliseconds. One common finding: connectors set up to log full request and response payloads for debugging purposes. That's convenient during development. It's also a great way to accidentally persist sensitive fields nobody meant to keep around.

Once PII enters the pipeline, Privacy comes into play alongside Confidentiality. Privacy wants documented policies on how personal data gets collected, stored, shared, and deleted, including privacy notices and opt-out procedures. Integration infrastructure is usually the exact mechanism moving PII between systems, so without a documented map of those flows, Privacy can't be satisfied, even if every individual system involved has a clean policy on paper. That data flow map, a full inventory of where PII enters, moves through, and exits your integration layer, isn't a nice-to-have. It's the evidence base the whole audit rests on.

Vendor and third-party management when the integration layer depends on external providers

CC9 turns vendor risk into a real compliance requirement, not a footnote. CC9.1 requires identifying and reducing risk from vendor relationships; CC9.2 requires actually having, using, and communicating vendor management policies. If a third party processes your customer data, stores your backups, hosts part of your integration stack, or has system access, their security posture becomes part of your SOC 2 story whether you like it or not. Auditors will pull a sample from your vendor list, check the assessment paperwork, read the contracts for security language, and confirm the reviews you claim happened actually happened.

Most companies undercount their vendor list by something in the range of 30 to 50 percent, and integration tools are a big reason why. Low-code connectors and iPaaS platforms get adopted by marketing or ops teams without going through procurement at all. Nobody flags it. It never makes the vendor inventory. Then an audit happens, and there's a tool moving customer data that officially doesn't exist on paper. That gap becomes a finding, every time.

For subservice organizations, there are two paths. Carve-out excludes a provider's controls from your scope entirely and points to their own SOC 2 report instead; that's simpler for you, but it means your customers have to go read multiple reports to get the full picture. Inclusive means you take on responsibility for actively monitoring that provider's controls and folding them into your own scope, with evidence to back it up; more thorough, more ongoing work. Most companies carve out the big infrastructure providers (AWS, Azure, GCP) and go inclusive for specialized vendors woven tightly into daily operations. The practical rule for integration teams: if a connector or iPaaS platform touches customer data directly, just trusting their SOC 2 report and moving on isn't enough under inclusive expectations. You need your own active assessment evidence, not a screenshot of someone else's audit badge.