Skip to main content
Legal review exists to catch the claims and uses that create risk. It is the one review that never defaults to approved when nobody responds. The general workflow, approvers, and turnaround times live in the approval process. This page is what sends work here and what the reviewer needs.
This page is a process framework, not legal advice. What is actually required depends on your jurisdiction, your industry, and the platforms you run on. Fill in the triggers table with what your own reviewer tells you, and treat the starting list below as a prompt rather than a ruling.

What triggers a review

Start from this list, then edit it with your reviewer. The point is that a producer can tell from the list alone whether their work needs to go, without asking. Not a trigger: copy that uses only claims already on the approved list in messaging, with the evidence unchanged. That is the point of maintaining the list.

Your reviewer and turnaround

What to send

Legal reviews the claim and its evidence together. Sending only the creative produces a request for the evidence and a lost round.
1

1. The work in its final form

Every version and placement that will run, not a representative sample.
2

2. Each claim, listed separately

Pull them out of the layout into a list. A reviewer should not have to find your claims for you.
3

3. The evidence for each claim

The source, the date, and how the number was calculated. “Product analytics” is not evidence; “median of 4,182 accounts, queried 2026-07-01, definition in the data dictionary” is.
4

4. Any release or license

For a customer’s name, likeness, quote, or logo, and for any licensed music, footage, or stock. Include the expiry, which is recorded in brand assets.
5

5. Where it will run, and for how long

Scope changes the answer. A license that covers a blog post may not cover the same image in paid media.

Recording the outcome

An approval that nobody can find later is an approval that gets sought again.
  • Record the decision, the date, the reviewer, and the exact version reviewed, on the brief in its library.
  • If the approval came with a condition (a required disclaimer, a cap on where it runs, an expiry), record the condition next to the claim in the approved claims table in messaging.
  • If a claim was approved, add it to that table so nobody re-submits it.
  • If a claim was rejected, record that too. Rejections get forgotten and re-proposed more often than approvals do.

Conditions have to survive the format

An approval with a condition attached is only met if the format can guarantee the condition. Several ad formats assemble their own combinations at serve time and will drop any individual element, which means a required qualifier can simply not appear. Record which mechanism was used, next to the condition, on the brief. An unexplained pin reads as a mistake to the next person optimizing the ad, and removing it silently breaks the approval.

Claims expire even when the wording doesn’t

The sentence stays the same while the number behind it moves. A claim cleared last year on data from the year before is not cleared today. Every approved claim carries a refresh date on its evidence, not on the claim. When the evidence is refreshed and still supports the sentence, nothing needs re-reviewing. When it no longer does, the claim comes down.

Exceptions

Urgency compresses the turnaround, using the expedited path recorded above. It does not remove the review. If there is genuinely no time, the work ships without the triggering element, not with it unreviewed.
Last modified on August 10, 2026