Complementary subservice organization controls

To meet the complementary subservice organization controls requirement in SOC 1, you must identify every in-scope subservice organization, decide whether your report uses the carve-out or inclusive method, and document how the required controls are covered (by you, by the subservice org, or by your user entities). You operationalize this by maintaining a subservice control map, contract/SOC report intake, and audit-ready evidence for each dependency.

Key takeaways:

• You need a complete inventory of subservice organizations that support in-scope control objectives.
• Your SOC 1 approach must explicitly reflect the carve-out vs. inclusive method and its control coverage implications.
• Auditors will look for a traceable mapping from each subservice dependency to specific controls, monitoring, and retained evidence ¹.

“Complementary subservice organization controls” becomes urgent the moment your SOC 1 system relies on third parties to execute any processing or safeguards that affect user entities’ financial reporting. Common examples include cloud infrastructure providers, managed database services, payment processors, payroll platforms, and outsourced support operations. If a subservice organization performs part of the control environment, your SOC 1 description cannot treat that work as invisible. You must account for it in scope.

Operationally, this requirement is about preventing unowned controls. If a control step happens outside your four walls, you need a clear, testable story for who performs it, what evidence exists, and how you monitor it. You also need to align this story with the SOC 1 reporting method: carve-out (subservice org controls excluded from your description and opinion scope) or inclusive (subservice org controls included). Either way, your customers and your auditor need clarity on where your controls stop and where complementary controls (by subservice organizations and by user entities) begin ¹.

This page focuses on turning that requirement into a repeatable workflow: identification, method decision, control mapping, monitoring, and evidence retention.

Regulatory text

SOC 1 requirement (excerpt): “Account for controls performed by subservice organizations in scope.” ¹

What an operator must do:

• Identify subservice organizations that support systems, services, or processes that are in scope for your SOC 1 report.
• Determine whether you are using the carve-out or inclusive method for each relevant subservice organization, and document the rationale.
• Show how controls performed by subservice organizations are addressed in your control environment and in your SOC 1 description, including any complementary controls needed at your organization and at your user entities ¹.

Plain-English interpretation

If a third party performs steps that matter to your SOC 1 control objectives, you must explicitly account for those steps. “Account for” means you can’t rely on a subservice organization informally or assume their controls exist. You need to (1) name the dependency, (2) state what the subservice organization is responsible for, (3) state what you are responsible for, and (4) retain evidence that the arrangement is governed and monitored.

Who it applies to

Entity types

• Service organizations preparing a SOC 1 Type 1 or Type 2 report ¹.

Operational context (where this shows up in real programs)

This requirement applies when your SOC 1 in-scope system includes any of the following:

• Hosted infrastructure, platform services, or managed security services that affect logical access, change management, processing integrity, or data retention.
• Outsourced transaction processing (e.g., payment, billing, claims, payroll).
• Third-party support centers that can access production systems or initiate customer-impacting changes.

If the subservice organization can affect the completeness, accuracy, authorization, or timeliness of processing relevant to user entities’ financial reporting, treat it as in-scope for this analysis.

What you actually need to do (step-by-step)

Step 1: Build and validate your subservice organization inventory

1. Pull a list of third parties connected to your in-scope services from procurement, finance (AP), IT asset management, and architecture diagrams.
2. Tag which third parties are subservice organizations for SOC 1 purposes: they perform part of the service you provide, not just a general corporate function.
3. For each candidate, document:
   • Service provided
   • Systems touched (production vs. non-production)
   • Data types handled
   • Whether they can impact control objectives

Operator tip: Start with your SOC 1 system boundary. If the dependency sits inside that boundary, it belongs on this list.

Step 2: Decide carve-out vs. inclusive, and document the rationale

For each in-scope subservice organization, decide the reporting method and record why.

Decision point	Carve-out method (common)	Inclusive method (less common)
Subservice org controls appear in your description?	No	Yes
Your testing covers subservice org controls?	No (you monitor them instead)	Yes (requires deeper coordination)
Audit dependency	Their SOC report and your monitoring	Their cooperation, evidence, and inclusion in scope

Document the choice in your SOC 1 governance file and ensure your system description reflects it ¹.

Step 3: Create a “subservice control coverage map”

Build a mapping that ties each subservice organization to:

• The SOC 1 control objectives/controls it supports
• Whether controls are performed by:
  1. your organization,
  2. the subservice organization, or
  3. the user entity (complementary user entity controls), where relevant
• The evidence source you will rely on (e.g., subservice SOC report, contract clause, monitoring logs)

Minimum viable format: spreadsheet or GRC record with clear ownership and review cadence. In Daydream, teams typically model this as a control-to-third-party relationship record, linked to the in-scope control library and the vendor due diligence workspace.

Step 4: Update contracts and due diligence intake to cover SOC 1 needs

For each subservice organization in scope:

• Ensure contracts address audit support, security responsibilities, incident notification, and access to assurance reports (as appropriate for your risk profile).
• Establish a standard intake requirement for the subservice organization’s assurance package (commonly their SOC report, bridge letter when needed, and relevant control statements), then track gaps to closure.

Keep the intake aligned to your method:

• Carve-out: you typically rely more on the subservice org’s independent assurance plus your monitoring.
• Inclusive: you need stronger operational access to evidence and testing coordination.

Step 5: Implement ongoing monitoring, not one-time collection

Auditors will challenge “we collected a SOC report once” if your dependency is continuous. Define monitoring activities, for example:

• Annual (or otherwise scheduled) collection of the subservice organization’s assurance reports and exceptions review.
• Ticket-based tracking for exceptions: assess impact, define compensating controls, confirm remediation.
• Internal control checks that validate your side of shared responsibilities (e.g., your access provisioning into the subservice platform, your configuration baselines, your change approvals).

Step 6: Reflect dependencies in your SOC 1 description and control narratives

Ensure your SOC 1 system description and control descriptions:

• Identify subservice organizations and the method used.
• Clearly state complementary controls required at the subservice organization and user entities, where relevant.
• Avoid “hand-waving” language like “a third party handles hosting” without specifying how control reliance is managed.

Step 7: Test readiness with a walk-through package

Before the auditor asks, assemble a walk-through binder per critical subservice organization:

• One-page dependency summary
• Control coverage map excerpt
• Latest assurance artifacts
• Your monitoring evidence and exception handling
• Management sign-off that the dependency remains acceptable

Required evidence and artifacts to retain

Retain evidence that proves you identified, evaluated, and monitored subservice organizations tied to in-scope controls:

Core artifacts (minimum set)

• Subservice organization inventory (in-scope list) with owners and service descriptions
• Carve-out vs. inclusive method rationale documentation
• Subservice control coverage map (controls → subservice org → evidence)
• Contracts and amendments addressing assurance/audit support expectations
• Due diligence intake records (received reports, review notes, exception tracking)
• Ongoing monitoring evidence (reviews, tickets, risk acceptances, remediation follow-up)
• SOC 1 system description excerpts showing subservice treatment and complementary controls ¹

Common exam/audit questions and hangups

Auditors and user entities typically probe in these areas:

• “Show me all subservice organizations that touch the SOC 1 in-scope system boundary.”
• “Which method did you use for each subservice organization, and why?”
• “Where is the mapping from subservice organization controls to your control objectives?”
• “How do you know the subservice organization’s exceptions don’t break your control objectives?”
• “What are the complementary user entity controls, and how do you communicate them?” ¹

Hangup to anticipate: Incomplete inventories. If procurement lists don’t match architecture reality, expect a finding or a scope qualification risk.

Frequent implementation mistakes and how to avoid them

1. Treating every third party as a subservice organization (or none of them).
   Fix: Define criteria tied to your in-scope services and control objectives, then apply consistently.

2. No explicit method decision (carve-out vs. inclusive).
   Fix: Record the method per subservice org and ensure the system description matches the decision ¹.

3. Collecting a SOC report without reviewing exceptions.
   Fix: Require documented review notes, impact assessment, and remediation tracking for relevant exceptions.

4. No linkage between controls and dependencies.
   Fix: Maintain a control coverage map that an auditor can trace end-to-end in a single sitting.

5. Forgetting the “shared responsibility” split.
   Fix: For each dependency, document what your team must configure, monitor, and approve inside the subservice platform.

Enforcement context and risk implications

SOC 1 is an attestation framework rather than a regulator-issued rulebook, so “enforcement” typically shows up as:

• Qualified SOC 1 opinions or report scope limitations.
• Customer escalations, stalled deals, or contractual noncompliance if you cannot provide a coherent subservice control story.
• Increased audit testing, longer fieldwork, and higher effort when subservice dependencies are unclear ¹.

The practical risk: unowned controls that affect transaction processing or security over systems relevant to financial reporting. That risk becomes real when a subservice organization has an outage, a control failure, or a material exception you did not evaluate.

Practical 30/60/90-day execution plan

Days 0–30: Identify and classify dependencies

• Assign an owner (usually GRC) and contributors (IT, Security, Engineering, Procurement).
• Produce the initial subservice organization inventory from multiple sources (AP, contracts repository, architecture).
• Decide preliminary in-scope vs. out-of-scope classification based on SOC 1 boundary.
• Draft the carve-out vs. inclusive method rationale for each in-scope subservice organization.
• Stand up a tracking register in your GRC system (Daydream works well when you need to link third parties to specific controls and evidence requests without manual cross-referencing).

Days 31–60: Map controls and close the biggest evidence gaps

• Build the subservice control coverage map for all in-scope dependencies.
• Request and collect assurance artifacts and contract terms needed to support your method choice.
• Perform exception reviews for received reports and open remediation items where needed.
• Update SOC 1 control narratives and system description drafts to reflect subservice organization treatment ¹.

Days 61–90: Operationalize monitoring and audit readiness

• Define ongoing monitoring owners, review triggers, and escalation paths for subservice exceptions.
• Run a readiness tabletop: pick one critical dependency and walk the trace from control objective → dependency → evidence → issue handling.
• Finalize the audit binder structure so your team can respond consistently during fieldwork.
• Implement “no new critical subservice org without intake” gating in procurement and architecture review processes.

Frequently Asked Questions

How do I tell whether a third party is a “subservice organization” for SOC 1?

If the third party performs part of the service you provide to user entities and that activity affects SOC 1 control objectives, treat it as a subservice organization. Purely ancillary services (for example, generic corporate tools with no tie to the SOC 1 system boundary) often fall outside.

Do I have to use the same method (carve-out or inclusive) for every subservice organization?

No. You can apply the method per subservice organization, but you must document the rationale and keep your system description consistent with the choice ¹.

If we use the carve-out method, are we “off the hook” for subservice controls?

No. Carve-out changes what is included in your description and testing scope, but you still need governance and monitoring over the dependency and clarity about complementary controls.

What evidence is most persuasive to auditors for subservice coverage?

A traceable control coverage map plus documented reviews of subservice assurance artifacts and exceptions. Auditors also expect your contracts and internal monitoring records to align with how you describe reliance on the subservice organization ¹.

What do we do if a subservice organization refuses to provide a SOC report or similar assurance artifact?

Document the refusal, assess the risk to your control objectives, and implement compensating controls where possible (for example, stronger monitoring, technical controls on your side, or an alternative provider). Expect tougher audit questions and possible scope constraints if the dependency remains critical.

How should we communicate complementary controls to customers (user entities)?

Put them clearly in your SOC 1 description and any customer-facing control responsibility matrix. Keep them specific and actionable (for example, “user entity must restrict access to X portal”) rather than generic statements ¹.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control lifecycle management

Footnotes

1. AICPA SOC 1 overview