Field Guide

How to Write Terms of Reference for a Compliance Consulting Engagement

The short version

Terms of Reference (ToR) is the document that defines a consulting engagement before it starts: the problem to be solved, what a successful outcome looks like, the budget and timetable, what each party provides, and what is explicitly excluded from scope. Either the client or the consultant can draft it, but someone has to, in writing, before a proposal or a fee gets discussed. A complete ToR runs through eleven items. The two most commonly left blank, exclusions and constraints, are the two most responsible for the scope creep and fee disputes that surface months into the engagement.

A Terms of Reference (ToR) is the document that defines a consulting engagement before it starts: the problem to be solved, what a successful outcome looks like, the budget and timetable, what each party provides, and what is explicitly excluded from scope. A verbal understanding from a discovery call is not a Terms of Reference, and neither is a one-line email requesting help getting exam-ready. Both leave the boundary of the engagement to be negotiated later, after time has been billed.

This guide covers what belongs in a Terms of Reference, who is responsible for writing it depending on how the client relationship started, an item-by-item checklist, how a ToR supplied by the client is evaluated, and the specific mistakes that turn an ambiguous ToR into a dispute.

What a Terms of Reference is

A Terms of Reference is a pre-contract document. It is written before a fee is agreed, sometimes before a consultant is even selected, and its job is narrow: define the problem, the objectives, and the boundaries of an engagement clearly enough that a stranger reading it later would understand why the engagement exists and what it does and doesn't cover.

It is not the same document as a Statement of Work. A ToR defines the problem and the scope boundary; a Statement of Work is the enforceable deliverable, milestone, and payment schedule that follows once the client has accepted a proposal built on top of the ToR. For the SOW-drafting discipline that applies once scoping is done, see how to write a Statement of Work for a compliance consulting engagement. This guide stops at the point where the client says yes to the scope, not the contract.

Who should draft it

Drafting responsibility depends on which of three postures the client relationship is in. Each posture changes what the consultant is responsible for.

Client postureWhat it means for the consultant
Client drafts the ToR before engaging any consultantCommon where the client's policy requires internal scoping first, or where a formal ToR is a precondition of a competitive selection process, frequent in public-sector and donor-funded work. A client-drafted ToR is read critically: where it describes an assignment that is not achievable given the stated budget and timetable, accepting it at face value commits the consultant to fail against terms the consultant did not write.
The consultant does preliminary diagnosis and drafts the ToRCommon in institutional and donor-funded engagements, where the diagnosing consultant may then be excluded from bidding on the resulting work. The consultant establishes at the outset whether the engagement pays to scope the problem, to execute the fix, or, rarely, both.
No formal ToR is used at allTypical of private-sector clients who select a consultant first and define scope together afterward. The proposal becomes the de facto ToR, so it covers all eleven items below even though no template requires it.

The 11-item Terms of Reference checklist

The list works as a literal fill-in exercise regardless of who is drafting, and as a gap-finding instrument when the ToR is supplied by the client.

#ItemWhat to captureWhere it commonly goes missing
1Problem descriptionThe specific problem to be solved, in the client's own language, quantified wherever possible.Stated softly ("some challenges with our monitoring program") instead of specifically.
2Objectives and expected resultsThe final product and how "done" will be measured, kept separate from the methods used to reach it.Objectives describe activities ("review the program") rather than outcomes.
3BackgroundThe client's history, related work, and prior internal or external attempts to solve the same problem.Prior failed attempts are left out, so the engagement repeats them.
4Budget estimate or resource limitWhether the engagement runs to a fixed budget with an open target, or a fixed target with an open budget, stated explicitly.Neither party names a number, so early scoping conversations circle without landing.
5TimetableStart and completion dates plus the control dates in between, not just a final deadline.Only an end date is given, so there's no way to check progress mid-engagement.
6Interim and final reportingThe form, frequency, and named recipient of each report.Reporting cadence is assumed rather than agreed, so the client is surprised by silence between updates.
7Client-provided inputsWhat the client supplies: documents, staff time, system access, secretarial or facilities support.Client-side effort is underestimated, then discovered mid-engagement when the client hasn't budgeted the time.
8ExclusionsWhat the engagement will explicitly not cover.Left blank on most real engagements. Anything not stated as out gets treated as implicitly in.
9ConstraintsFactors likely to affect the work: system access limits, concurrent projects, internal politics, deadlines outside the consultant's control.Known to the client, never disclosed to the consultant until it becomes a delay.
10Consultant profile and competence requiredThe credentials, certifications, or sector experience needed to do the work credibly.Left unstated in competitive procurement, so unqualified bidders waste everyone's evaluation time.
11Contact personsA named individual on each side, not a title or a department.A title is listed instead of a person, and the real point of contact changes mid-engagement without anyone updating the document.

All eleven items are either filled in or explicitly marked not applicable with a stated reason. Item 8, exclusions, should never be left blank on a real engagement: an assignment with no stated exclusions is a scope-creep liability from day one.

Exclusions and constraints

Of the eleven items, exclusions and constraints are the two a client rarely thinks to ask for and a consultant, eager to look accommodating early in the relationship, often skips writing. Both take little effort to draft and are costly to omit.

An exclusion is a boundary stated affirmatively rather than implied by what the problem description leaves out. For a compliance engagement, that might read: "This engagement covers the customer due diligence and transaction-monitoring components of the BSA/AML program. It does not include a review of the sanctions-screening tool's underlying vendor architecture, litigation exposure from prior filings, or state-specific licensing analysis outside the client's home jurisdiction." The boundary is specific, named, and not open to a later argument that it was implied.

A constraint is a fact outside the consultant's control that will shape how the work gets done: "The client's core banking system migration is scheduled for the engagement's final month and may limit consultant access to production transaction data during that window." Naming it in the ToR means neither party is surprised when it happens, and neither party has to argue later about whose fault the resulting delay was.

A worked example: scoping a BSA/AML gap-analysis engagement

For a fintech client seeking to close gaps ahead of an exam, the problem description and exclusions in a draft ToR might read as follows:

Where gap analysis or risk assessment is the subject matter of the engagement being scoped, the underlying methodology those deliverables have to meet is covered separately: see the guides to AML program gap analysis, BSA/AML risk assessment, and BSA/AML independent testing. Those guides supply the technical content of the problem description and objectives sections; this one covers the scoping document that wraps around them.

Evaluating a client-supplied ToR

A ToR supplied by the client is audited before it is accepted. The 11-item checklist is run against what was given, and the gaps are flagged before the work is priced or agreed, especially exclusions and constraints. Where the ToR describes an assignment that is not feasible given the stated budget and timetable, that mismatch is raised before sign-off rather than absorbed into a longer engagement than the client understands itself to be buying.

Where a formal ToR was used to run a competitive selection process, the consultant who diagnosed the problem and drafted the ToR is sometimes excluded from bidding on the resulting engagement. Eligibility is confirmed before time is invested in a full proposal response.

What comes after the ToR

A ToR by itself doesn't sell an engagement. It's the raw material for the assignment strategy, the phased plan, role definitions, and resource allocation, that then gets written up into the actual proposal a client signs. For how a ToR feeds into that sequence, see the phases of a compliance consulting engagement. Once the client accepts, the ToR's role is done and the enforceable version of the same boundaries moves into a Statement of Work.

Common mistakes that turn into scope creep

Primary sources

Common questions

What is a Terms of Reference (ToR) in consulting?
A Terms of Reference is the document that defines a consulting engagement before it starts: the problem to be solved, the objectives and expected results, budget, timetable, reporting, what each party provides, exclusions, constraints, the consultant profile required, and named contacts. It is written before a proposal is drafted or a fee is agreed.
Who is responsible for writing the Terms of Reference, the client or the consultant?
Either can. Some clients draft the ToR internally before approaching any consultant, especially in public-sector or donor-funded procurement. In other cases the consultant does preliminary diagnosis and drafts it. Private-sector clients often use no formal ToR at all and select a consultant first, in which case the proposal itself becomes the de facto ToR.
What's the difference between a Terms of Reference and a Statement of Work?
A Terms of Reference is a pre-contract scoping document written before a fee is agreed. A Statement of Work is the enforceable deliverable, milestone, and payment schedule that follows once the client has accepted a proposal. The ToR defines what problem and boundaries the engagement addresses; the SOW turns that into a contractual work product.
What happens when a client supplies an incomplete Terms of Reference?
The 11-item checklist is run against it as an audit tool, and the gaps are flagged before the work is priced or accepted, especially exclusions and constraints, the two items most often left blank. Where the ToR describes an assignment that is not feasible given the stated budget and timetable, that is raised before sign-off rather than accepted at face value.
How long should a Terms of Reference document be?
Length isn't the standard; completeness against the 11 items is. A bounded engagement can run one to three pages. A complex or competitively procured engagement, especially in the public sector, typically runs longer because more of the items require formal detail.
About this library

This reference library is maintained by Rupture Labs, the company behind Compliance Command Center, compliance software built and reviewed by practitioners. Contact.