What Embedding a Third-Party API Means for Your SOC 2 Audit

If you're building a SaaS product with embedded third-party APIs, you already have a vendor management problem. You may not know it yet, but your auditor will. The practical work of a SOC 2 Type II audit isn't just about your own controls anymore. It's about documenting exactly where your controls end and someone else's begin. Think of it like a relay race: the baton doesn't care whose hand dropped it. Teams that figure this out before the audit window opens move fast. Teams that don't spend the engagement scrambling.

What SOC 2 Type II Actually Examines, and How Vendor Relationships Fit Into That Scope

SOC 2 is not a certification. It's an opinion. Specifically, it's an auditor's written opinion on whether your controls are designed well and actually ran during a defined period, typically six to twelve months.

That distinction matters. Type II auditors aren't asking "do you have a policy?" They're asking "show me the evidence that this control operated, repeatedly, across the full period."

The Trust Services Criteria define what gets tested. Security is universal. Availability shows up in the majority of reports. Confidentiality is worth flagging specifically: it appeared in roughly 64% of reports in 2024, up from about a third the year before, according to the CBIZ 2024 SOC Benchmark Study. That's a significant jump. APIs that move sensitive data between systems now fall squarely under a scrutiny that would have been optional just a year earlier.

The document that defines everything is the system description. It tells the auditor what's in scope and what's deliberately excluded. Every testing decision flows from it. According to the same benchmark study, nearly 90% of SOC 2 reports now include subservice providers. Which means if your system description doesn't mention your API vendors, that omission is visible and flagged.

The Classification Decision That Shapes Your Entire Audit: Vendor Versus Subservice Organization

Not all API providers are equal in an audit's eyes. The classification you assign them determines how much of your audit they touch.

The AICPA's test is actually pretty clear. If a provider's controls, combined with yours, are necessary to meet your trust services commitments, that provider is a subservice organization. Not just a vendor. A subservice organization.

The practical signal: ask yourself whether that API going down or getting compromised would directly break a control you're relying on in your audit. If the answer is yes, you're looking at a subservice organization.

Providers that typically qualify:

• Cloud infrastructure hosting your application
• Payment processors handling transaction data
• Managed security services performing monitoring you depend on
• HR platforms handling employee data flows your controls touch

A counter-example worth knowing: a monitoring tool whose alerts you review and act on is still your control. The vendor isn't a subservice organization because the judgment stays with you. The tool just informs it.

The most common readiness gap here is straightforward. Companies simply haven't done the classification exercise. So the system description ends up misrepresenting the actual control environment — like a map that confidently labels the wrong roads. Discovering that mid-audit means rewriting the system description, potentially re-scoping evidence collection, and explaining the gap to the auditor. None of that is fun.

Carve-Out Versus Inclusive Reporting: How Your API Provider Appears in the Final Report

Once you've classified a provider as a subservice organization, you have to decide how it shows up in your report. There are two options.

Carve-out is the dominant practice. The provider's controls are excluded from direct audit testing. Your system description names the provider and describes what it does. The auditor does not test its controls directly. This works when the provider has its own SOC 2 report that customers can review.

Important: choosing carve-out does not eliminate your responsibility. You still have to understand the provider's controls and manage the risk they create. That means reviewing their SOC report, sending periodic questionnaires, and maintaining internal monitoring routines. Carve-out is not "set it and forget it."

Inclusive means the provider's relevant controls are in scope and tested by the auditor directly. The provider has to open its environment, provide written assertions, and participate in the engagement. This is appropriate when no SOC report exists for the provider, or when the provider genuinely agrees to examination procedures.

Coordination complexity with inclusive is real. You're scheduling across two organizations, aligning documentation, and extending the timeline. The common failure pattern: teams assume inclusive will work because a provider verbally agrees, then discover at audit time that the provider's documentation is thin and doesn't map to the user entity's control objectives. Additional testing, reporting delays, and scope renegotiation follow.

The decision rule is simple. Default to carve-out when the provider has an adequate SOC report. Reserve inclusive for situations where no assurance exists and the provider has genuinely committed to the process.

CC9.2 and What Continuous Vendor Oversight Actually Requires

SOC 2 Common Criteria CC9.2 is the explicit requirement: "The entity assesses and manages risks associated with vendors and business partners." This isn't buried in a footnote. It's a named criterion auditors test against.

CC9.2 covers the full lifecycle of a vendor relationship, from onboarding through periodic reassessment through termination. What auditors specifically look for:

• A documented inventory of vendors, tiered by risk
• Defined scope, roles, compliance expectations, and service levels established at the start of the relationship
• Named owners accountable for each vendor relationship
• Periodic assessments conducted on a cadence proportional to risk tier
• Documented exception handling when issues surface
• A termination procedure covering data return or destruction

Here's the part most teams miss. Point-in-time vendor assessments do not satisfy Type II auditors. They need evidence that oversight ran continuously across the full audit period. One assessment at the start of the year is not continuous oversight. It's a snapshot.

The most common audit finding on vendor management isn't that organizations have no security. It's that they have strong internal security but incomplete vendor inventories and no documented evidence of ongoing monitoring. That gap fails audits.

For embedded APIs specifically: each relationship needs a traceable record of assessment activity, not just a procurement checkbox.

Complementary User Entity Controls: The Shared-Responsibility Layer Most Teams Miss

Every SOC 2 report can include Complementary User Entity Controls, or CUECs. These are control activities that the service organization assumes its customers will implement for the overall system to stay secure. They don't transfer liability. They document the assumptions the audit relies on.

The obligation runs in both directions when you're embedding a third-party API.

As a customer of the API provider, you must implement whatever CUECs appear in that provider's SOC report. Your auditor will check this. Common CUECs in API vendor reports include things like: configure strong authentication, restrict API key permissions to least privilege, conduct periodic access reviews, review the vendor's SOC report annually.

As a service provider to your own customers, you define CUECs in your system description. These describe what your customers must do to preserve your control environment.

The failure risk is subtle but real. Even a low-volume or minor vendor relationship can become a significant audit exposure if the required CUECs are not implemented and documented. "We didn't use it much" is not an answer auditors accept.

One more thing worth noting: the absence of CUECs in a vendor's SOC report is itself a signal. It can indicate an incomplete report, which creates gaps in your own audit.

The practical check before your audit window opens: pull every API vendor's SOC report, extract the CUEC list, verify each one is actually implemented, and document the evidence. That's it. Do that before the audit starts.

The Technical Controls Auditors Test Directly for API Integrations

This is where it gets concrete. Auditors don't just review your policies. They ask for evidence that specific technical controls are configured and operating.

Authentication and access scope. OAuth scopes should be limited to only the data the integration actually requires. Over-provisioned scopes read as a control weakness. API tokens should be restricted to specific actions and tied to identifiable users or tenants. Administrative actions require MFA, and auditors test this by sampling access logs against authentication records.

Encryption. AES-256 is the de facto standard for data at rest. TLS 1.3 is the expected baseline for data in transit. Auditors ask for evidence of encryption configuration, not just a policy that asserts it exists. The policy and the configuration are two different things.

Logging. Your integration layer needs to produce detailed, timestamped logs: who accessed what data, when, through which integration path. Logs are primary audit evidence. Silent integration failures, meaning pipelines that drop or corrupt data without generating an alert, violate processing integrity criteria. That's not just an operational bug. That's a control failure.

Specific evidence artifacts auditors request for integrations:

• Access control matrices showing which integration has access to which data
• Permission change history for API credentials
• Incident response logs that include any integration-related events
• System monitoring reports covering the integration layer
• Vendor SOC reports and evidence of annual review

If a pipeline silently fails or corrupts data, that is a direct SOC 2 finding. Not a ticket for the engineering backlog.

How the Number of Embedded APIs Inflates Audit Surface Area, and What Constrains It

Here's the math that catches teams off guard. Each additional embedded API adds a potential subservice organization classification decision, a CUEC review obligation, a CC9.2 monitoring requirement, and a set of technical controls to evidence. Every single one.

Some integration architectures replicate customer data into their own databases via periodic sync jobs. The resulting data store becomes part of audit scope, expanding the surface further. A SaaS product integrated with dozens of HR, CRM, and messaging APIs faces a vendor assessment backlog that grows proportionally with every new connector.

The architectural response that actually works: a consolidated integration layer. A managed integration platform that holds its own SOC 2 attestation consolidates many API relationships into a single subservice organization review. Instead of dozens of separate vendor assessments for dozens of HRIS connectors, auditors review one. The platform vendor's SOC report. Pre-built, audited connectors with managed authentication and documented security controls reduce the technical evidence burden on your product team substantially.

The tradeoff to be honest about: consolidation only works if the integration platform has a rigorous SOC 2 report with clear CUECs and a system description that maps to your control objectives. Due diligence on the platform itself is still required. You're reducing complexity, not eliminating responsibility.

What Teams Should Have Documented Before the Audit Window Opens

This is the list. Start here, work through it before the audit period begins. Type II auditors ask for evidence spanning the full period. Gaps in the middle of the window cannot be retroactively filled — you can't patch a hole in the roof after the inspector has already walked through.

Vendor inventory with classification decisions recorded. Every embedded API listed. A documented rationale for whether it is a vendor or a subservice organization. Risk tier assigned to each, driving assessment cadence.

System description drafted with subservice organizations named and reporting method chosen. Carve-out or inclusive decision recorded with supporting rationale. Confirmation that each named provider has a current SOC report covering the relevant services.

CUEC implementation evidence for every API vendor's SOC report. Extract each vendor's CUEC list. Map it to internal controls. Collect evidence that each is operating.

CC9.2 monitoring record showing continuous oversight. Dated questionnaires, SOC report review logs, issue tracking for any findings. Not a single annual review. A continuous record.

Technical evidence for integration-layer controls. Access control matrices, OAuth scope documentation, encryption configuration evidence, API credential permission history, integration logs.

Termination procedures documented for each subservice organization relationship. How data is returned or destroyed if the relationship ends. Auditors treat this as a completeness check on CC9.2.

The timing point is worth repeating. This readiness work starts at the beginning of the audit period. Not three weeks before the auditor arrives. The audit covers the full period. Evidence from only the last month of a twelve-month window tells auditors exactly what they don't want to see.