# How to write scope exclusions in a statement of work
Source: https://korrel.ai/blog/write-scope-exclusions-statement-of-work
Published: 2026-09-14
Updated: 2026-09-07
Topic: how to write scope exclusions in a statement of work
Tags: proposals, scope-creep
---
## Key points

- Give each exclusion an observable boundary instead of naming a broad area as out of scope.
- Record the evidence, owner, and assumption needed to test each implementation unknown.
- Send uncertainty to discovery before pricing or to a change request when delivery evidence breaks an assumption.

To learn how to write scope exclusions in a statement of work, start with a test. State the work that your team has not priced. Then show the team how to test that boundary.

“Data cleansing is excluded” is not enough. The project still needs data, and somebody must decide whether a supplied file is usable. State the observable limit, the evidence needed, and what happens when the limit fails.

This operational method helps you build and manage scope. It is not legal advice or contract wording. Ask a qualified adviser to review the final statement of work where necessary.

## How do you write scope exclusions in a statement of work?

A testable exclusion answers six questions:

1. What fact is not known yet?
2. What boundary can the team observe?
3. What evidence will confirm the boundary?
4. Who must supply or check that evidence?
5. What assumption supports the current price?
6. What event sends the item to discovery or a change request?

General scope guidance puts exclusions beside requirements and assumptions, as well as deliverables. [ProjectManager describes project exclusions](https://www.projectmanager.com/blog/project-scope-statement) as work that is not included. An implementation supplier needs one more step: a repeatable test.

Write the boundary so that two delivery leads get the same result from the same evidence. Use counts, named systems, file formats, access dates, environment types, and responsible owners. Avoid words such as “reasonable”, “standard”, or “minor” unless you define them.

Apply the same discipline to included work. A deliverable needs a quantity and a completion test. The guide to [defining deliverables that clients cannot expand](/blog/define-deliverables-clients-cannot-expand) shows how to set those edges.

## Which implementation unknowns should you test?

Ask what must be true for your estimate to remain valid. With the delivery team, review every interface and rule. Then review each dataset, environment and client action.

The [NMS Consulting SOW guide](https://nmsconsulting.com/consulting-sow-template/) separates in-scope work and exclusions from assumptions and dependencies. It also identifies required client inputs. Keep those categories separate. They perform different jobs.

- An exclusion states work that the estimate does not cover.
- An assumption states a condition used to build the estimate.
- A dependency states something needed before your team can proceed.
- A client input states what the client must provide or decide.
- A risk states an uncertain event and its possible effect.

Link the categories. Do not repeat one vague sentence under each heading. An excluded data repair service can include an assumption about source-file quality. It can also depend on the client supplying a sample file.

Use the [proposal topic hub](/blog/topics/proposals) to check the other scope elements that must agree with these exclusions.

## What should an exclusion test matrix include?

Build the matrix before you write the short exclusions section in the SOW. Use one row for each unknown. Split a row when it has different evidence or owners.

| Unknown | Observable boundary | Evidence needed | Owner | Pricing assumption | Discovery or change trigger |
| --- | --- | --- | --- | --- | --- |
| Integration behaviour | Named endpoint supports the agreed request and response with the agreed authentication flow | Current API specification and one successful test call | Client system owner | Existing endpoint works without supplier changes | Discovery if evidence is absent before pricing; change request if the test fails during delivery |
| Business rules | Rules appear in the approved process map and decision table | Signed-off examples, exception list, and rule owner | Client process owner | No rules exist outside the supplied set | Discovery for unresolved rules; change request for a new or conflicting rule |
| Data quality | Each required field meets agreed format and completeness checks, plus the agreed uniqueness check | Profile report and representative extract | Client data owner | Source data passes the agreed checks | Discovery before estimate if no extract exists; change request for repair outside agreed tolerances |
| Migration volume | Records and attachments stay within the counted bands | Dated source count by object and file size | Client data owner | Volume stays within the stated bands | Re-estimate before approval or raise a change when a later count exceeds a band |
| Environments | Named environments exist with agreed access and configuration | Access test and environment inventory | Client technical owner | One development, one test, and one production target are available | Discovery for an unknown estate; change request for an extra target or rebuild |
| Client dependencies | Named input or decision arrives by its due date | Dependency log with owner and acceptance check | Client project manager | Work can follow the planned sequence | Replan or raise a change when delay adds effort or changes the sequence |

The matrix is a working control, not legal text. Keep it with the estimate and risk log. Put its approved boundaries through your normal SOW review.

## How do you test integrations and undocumented business rules?

For each integration, name both ends, direction, purpose, authentication method, and expected transaction. Then state which components are not included.

Do not exclude “third-party issues”. That phrase has no stable test. Instead, require a current specification, test credentials, sample payloads, and one agreed response. The result gives you a clear trigger. Missing evidence needs discovery. Behaviour that conflicts with the supplied evidence needs review.

One small request at a time can add integration work. The guide to [stopping unscoped integration work](/blog/stop-unscoped-integration-work) shows how to list interfaces and handle a new one during delivery.

Business rules need a similar test. Ask for examples at the edges: zero values, closed accounts, duplicate records, backdated changes, and approval exceptions. Record each accepted rule in a decision table or process map.

Exclude the analysis and implementation of rules that are not in the approved evidence set. Name the rule owner. If users later describe a conflicting exception, pause that item. Decide whether focused discovery can settle it or whether it changes priced work.

## Why should you separate data quality from migration volume?

Data quality and data volume are different cost drivers. Keep them in separate matrix rows.

Quality tests inspect whether records are usable. Define required fields, accepted formats, duplicate rules, permitted values, and referential checks. Referential checks confirm that linked records point to valid records. Use a representative extract before final pricing where possible.

State which repair tasks are excluded. Examples include deduplication, manual completion, source-system correction, and investigation of unmatched records. Do not promise a clean migration while you exclude all data repair.

Volume tests count the work. Record source objects, rows, attachments, total file size, history periods, and migration runs. State the date and method of the count. A percentage increase is less useful than a band linked to the estimate.

The boundary can cover one trial load and one final load for specified objects. This gives extra runs, added history, or a new source a clear trigger. If no reliable count exists, use [paid discovery to price the unknown](/blog/how-to-price-paid-discovery-phase).

## How do you define environments and client dependencies?

“Infrastructure excluded” creates confusion because delivery still occurs somewhere. List each environment that your team will use. For each one, record who provisions it, who configures access, and which services must already exist.

Test access before the dependent task starts. Check identity permissions, network routes, certificates, secrets, deployment rights, test services, and reset procedures. Exclude work for unnamed environments or client-controlled infrastructure changes that are not in the estimate.

Client dependencies need dates and acceptance checks. “Client to provide access” does not identify the access, system, or date. In the working matrix, give the system, role, due date, and a successful login or test action.

Include decisions as dependencies too. A late field mapping, security approval, or test sign-off can change the work sequence. Record the decision owner and latest useful date. Lateness alone is not the trigger. The trigger is the extra work or schedule effect that the delay causes.

## Where should each failed test go?

An exclusion should not become a reason to stop every difficult task. Give the delivery team a route for each result.

Use discovery when evidence is missing and you cannot make a sound estimate. Keep discovery narrow. It must produce the specification, sample, test result, decision, or count that closes the unknown. Discovery ends with a pricing decision, not a longer list of questions.

Use a change request when delivery evidence shows that an approved assumption is false or a boundary has expanded. Record the affected deliverable, added or removed work, cost, schedule effect, and decision owner. The [change request process for fixed-price projects](/blog/change-request-process-fixed-price-projects) gives the operating sequence.

Some failed tests need no commercial change. The team can use an included allowance or move work within the agreed plan. Record that choice too. Otherwise, each issue becomes free work or a dispute.

Implementation cost guidance also supports this operating model. [Coderio recommends a formal change process](https://www.coderio.com/blog/software-development/strategies-to-prevent-project-cost-overruns/) for material scope changes. Its review questions cover cost and timeline effects, plus risk. Use that discipline after a test fails, not as a substitute for defining the test.

## When should you review exclusions during delivery?

Review the matrix at kick-off, before each affected workstream, and when new evidence arrives. The project manager maintains the record. Technical and data owners perform the tests. The commercial owner decides whether a failed assumption needs repricing.

Connect each row to the estimate line that it protects. Then compare actual cost with the priced work during delivery. The method for [tracking costs against a fixed-price SOW](/blog/tracking-costs-against-a-fixed-price-sow) helps reveal work that crossed a boundary without a matching decision.

A discovery sprint can test uncertain integrations and migration risks before the build. The [72Technologies discovery sprint article](https://www.72technologies.com/blog/pricing-discovery-sprints-agency-deals) includes technical spikes and a risk register among its example outputs. Choose only the evidence your estimate needs. Do not copy a full sprint format by default.

Take one current SOW and build six matrix rows. Use one row for each implementation area in this guide. If you cannot write an observable boundary, move the unknown into discovery before you fix the price.

[Start a free Korrel trial](https://app.korrel.dev/signup) to keep requirements and assumptions, questions and risks, plus deliverables and estimates together before the work becomes a project.