GetSOC2

Build the boundary your SOC 2 system description will draw

Scope is the decision that sets your audit fee, your evidence load and what your report can honestly claim. This drafts the boundary statement and settles the carve-out question before anyone quotes you.

Last reviewed 2026-09-14Written by Jacob Masse, TrazTech Inc.

Every SOC 2 report opens with a system description written by management, not by the auditor. It names the service, the infrastructure, the software, the people, the procedures and the data inside the boundary, and by omission it names everything outside it. A boundary drawn too wide costs money and evidence work for years. A boundary drawn too narrow gets the report rejected by the customer who asked for it.

This asks what you run, what you depend on, and what you would rather leave out. It returns a drafted boundary statement, the carve-out or inclusive method decision with the reason, and the exclusions a buyer will push back on. The draft renders on this page and nothing is emailed anywhere unless you ask for it at the end.

What is being reported on?

The service as a customer names it, and the legal entity that signs their contract. Both appear in the first paragraph of the system description.

Which environments support that service?

Tick what the service depends on to be delivered. Anything a customer's data passes through belongs in, whatever the org chart says.

Where does production run?

Which vendors sit inside the service you deliver?

A subservice organization is a vendor whose controls have to operate for your own commitments to be met. A tool your team merely uses is a vendor, not a subservice organization.

Can you obtain their own assurance reports?

What do you want to leave outside the boundary?

Tick anything you were hoping to exclude. Some of these are ordinary and some of them will be challenged by the buyer who asked for the report.

Which trust services categories are elected?

How many people work there?

When does the report need to exist?

Carve-out and inclusive, in plain terms

When part of your service is delivered by another organization, the system description has to say how that organization is treated. There are two methods and they are not equally practical.

The carve-out method excludes the subservice organization's controls from the description and from the auditor's testing. You state what you rely on them to do, and you list the complementary subservice organization controls a reader must assume are operating. Almost every SOC 2 report uses this method for infrastructure providers, because the alternative requires that provider to participate in your audit.

The inclusive method brings the subservice organization's relevant controls into your description and into the testing. It produces a stronger report and it requires the vendor to agree, to be tested, and to sign a management assertion alongside yours. That is achievable with a small provider who depends on your business, and it is not achievable with a global infrastructure provider.

Choosing carve-out does not let you ignore the vendor. The common criteria still ask you to select, assess and monitor them, which means an inventory, risk tiering, and evidence that somebody read their assurance report and acted on the exceptions in it. Subservice organizations covers that obligation in full, and complementary user entity controls covers the mirror image: the controls your own customers have to operate for your report to mean anything.

Common questions

Can we scope the report to one product and leave the rest out?

Yes, and it is a normal way to run a first report. The constraint is that the boundary has to be coherent: if the excluded product shares a database, an identity provider or an operations team with the included one, the shared piece is in scope whichever product it belongs to. Excluding a product that is genuinely separate is ordinary. Excluding one that runs on the same infrastructure is a boundary an auditor will not accept.

Do corporate laptops have to be in scope?

In practice yes, if engineers use them to reach production. The common criteria on logical access do not care whether a device is described as corporate or production; they care about how access to the system is granted, reviewed and removed. Companies that try to exclude corporate IT usually end up putting most of it back in during the readiness work.

Does a wider scope cost more?

Yes, on the audit fee and much more on the readiness effort, because scope drives the number of systems that have to produce evidence every period. What drives a SOC 2 quote works through the relationship, and the cost calculator puts a Canadian dollar range on it.

What happens if we get the boundary wrong?

If it is too narrow, the customer who asked for the report reads the description, sees their deployment is not in it, and asks for another report. If it is too wide, you pay for evidence on systems nobody asked about, every year, until somebody re-scopes. The first mistake is recoverable in weeks. The second is recoverable at renewal, which is why erring slightly wide in year one is not the safe choice it looks like.

Who writes the system description?

You do. Management writes it and asserts to it; the audit firm forms an opinion on whether it is fairly presented and whether the controls met the criteria. A firm that offers to write your description for you has taken on a conflict, because it would then be opining on its own work. Readiness help with the drafting is a different thing and is normal.

Price this boundary

Send the same scope to Canadian audit firms so the quotes you compare are quotes for the same report.

Get matched