What is an example of Carve-Out Method in practice?

How Carve-Out Method Works in a Real SOC 2 Report

A practical example is a SaaS provider that uses a hosting company, payment processor, or other subservice organisation for part of its delivery chain. Under the carve-out method, the report describes the provider’s own controls and makes clear that the subservice provider’s controls are outside scope. That lets readers see the boundary without assuming the upstream controls were tested by the reporting organisation.

For example, if the service depends on a managed infrastructure platform, the company may describe its monitoring, access review, incident response, and change management controls, while stating that the platform’s physical security, host hardening, and some operational controls are handled separately by the provider. The point is not to deny the dependency, but to define who is responsible for which control set.

What Readers Need to Understand About the Boundary

The carve-out method is about scope clarity. It is useful when the organisation can credibly explain its own internal controls, but cannot or does not include the subservice provider’s controls in the same control narrative. That distinction matters because it changes what an auditor, customer, or partner can reasonably conclude from the report.

In practice, the boundary should be explicit enough that the reader can distinguish internally operated controls from outsourced controls. A vague description creates uncertainty about where evidence starts and stops, which is especially problematic when the subservice provider contributes materially to availability, access control, logging, or data protection.

When the boundary is well written, the report helps the reader answer two separate questions: what does the organisation control directly, and what is dependent on a third party? That separation is the practical value of the carve-out approach.

How It Differs From an Inclusive Description

Carve-out and inclusive reporting are both about subservice organisations, but they communicate scope differently. Under the inclusive method, the report includes the subservice provider’s controls in the scope narrative. Under the carve-out method, those controls are excluded from the organisation’s control description and must be understood as external dependency.

This distinction is important when comparing reports across providers. Two organisations can both rely on the same class of subservice provider, yet present very different scoping language. A reader should not assume the same assurance boundary just because both reports mention the same vendor or service dependency.

For practitioners, the choice usually comes down to how much the organisation can substantiate about the external control environment and how transparently it can describe the handoff points. The carve-out method is acceptable only when the dependency is still described clearly enough to avoid implying coverage that does not exist.

Risk and Threat Considerations

Carve-out reporting can hide operational dependency risk if the boundary is written too loosely. Readers may overestimate control coverage when a critical process is actually dependent on a third party, especially for access, availability, logging, or incident response.

Failure mechanism: The report omits or under-describes the subservice provider boundary, so assurance appears stronger than the evidence actually supports. That can mask gaps in oversight, evidence collection, and responsibility assignment.

Impact: Stakeholders may make procurement, assurance, or risk decisions on an incomplete picture, and weaknesses at the subservice layer may be discovered only after an incident or audit challenge.

Practitioner Guidance

What to verify: Make sure the control description states exactly which controls are operated internally and which are handled by the subservice provider. If the dependency is material, the description should make that dependency obvious without requiring the reader to infer it.

What good looks like: The report names the outsourced function, states the carve-out plainly, and still gives enough detail for a reader to understand the control boundary, responsibility split, and any compensating controls the organisation operates itself.

Practitioner takeaway: Carve-out is acceptable when it improves clarity, but it only works if the report makes dependency visible rather than implied. The main test is whether a reader can tell, without guesswork, what the organisation actually controls and what it does not.

Related resources from NHI Mgmt Group

• What is an example of an opt-out preference signal in practice?
• How does the carve-out method work?
• Why do CCPA opt-out programmes fail in practice?
• How should organisations rebuild identity governance after a carve-out or similar infrastructure separation?