How to write a policy briefing that gets read
Practical rules for policy briefings that busy people actually read, from the two-page ceiling to structuring by priority.

You will never get complete consensus on how to write a good policy briefing, but most professionals will agree on a few set principles. The best people to judge are, of course, the people who read them, whether that's your CEO, Board, or Directors. Briefings are often too long, crammed with unnecessary detail, and arrive too late.
This guide is about the elusive policy briefing, the document produced when something moves in Westminster (whether it be a new law, policy or Cabinet change) and the people who run your organisation need to know what it means for them. The rules are simple to state and hard to obey.
What a policy briefing is for
A policy briefing is a document that details a status change, and summarises how it will affect your reader. The briefing itself normally contains some recommendations for subsequent decisions. The reader of a policy briefing is usually an executive caught between meetings and the day-to-day work, who ordinarily would not have the time to delve into the minute detail.
Anything that helps the reader decide stays. Anything that shows how much you know goes.
Start with your reader
Before you type a word, picture the specific person this is for and what they already know. A briefing for your policy committee can assume context. A briefing for a board of trustees cannot assume they know what report stage is, and should not make them feel stupid for it.
Write for the least policy-literate senior person who will read it. Spell out every acronym on first use, translate procedure into organisational consequences, and never use the phrase "as you will be aware". If they were aware, you would not be writing.
Move fast: a briefing ages in days
A policy briefing a few days old has lost most of its meaning. The moment has passed. A tight briefing on the day beats a thorough one next week, every time.
Keep a blank template ready. Draw on primary sources first, the bill page or Hansard itself, and then verify with trustworthy secondary sources. For most policy developments, two hours from sitting down to sending is a realistic standard, and the constraint improves the writing.
Two pages is the ceiling
Not the guideline, but the ceiling. If the briefing does not fit on two pages, you have not yet decided what matters.
Cutting the fourth paragraph about the bill's background forces you to say plainly what the bill does to your organisation. If genuinely necessary, put supporting detail in an annex, but be aware that most people won't glance at it.
Lead with what bites
A briefing tells your organisation what a policy document means for it, and the points that matter most come first:
- Contradictions. Where the proposal cuts against your organisation's stated position or its published policy positions.
- Reputational exposure. Anything a journalist or a funder could put to your Chief Executive tomorrow. If the policy names your sector, quotes your research or affects the people you represent, say so at the top.
- Operational consequence. What this changes about what your organisation must do or can no longer do, with rough scale where you can give it.
- Openings. Where the development supports your objectives, and the window for saying so publicly while it still counts.
If none of these apply, question whether the briefing needs to exist. A development with no consequence for your organisation belongs in the weekly round-up instead.
Structure by priority, and be strict about it
Assume you will lose your reader partway through. Order the briefing so that wherever they stop, they leave with the most important thing. Lead with significance first and background last, with no warming up.
Here is a recommended policy briefing structure:
- Title, date and author. The date matters more than it looks, since it tells every future reader whether the briefing is still current.
- Summary. A few sentences at most about what happened, what it means for us, and what you recommend. Many readers stop here.
- What this means for us. The bite points above, in priority order.
- What happened. The development itself, briefly and precisely dated, with a link to the source.
- What we should do. Recommendations, each with an owner and a deadline. "We should monitor developments" is not a recommendation.
- What happens next. The upcoming stages and dates, so the reader knows when this lands back on their desk.
Make it easy to read
Reader-friendliness decides whether the document works. Write in short paragraphs with one idea each. Headings that state findings ("The bill removes the exemption we rely on") rather than labels ("Analysis"). Bold the sentences that must survive a skim. Give dates precisely: "committee stage begins 9 September", never "shortly". And read it once aloud before sending, which is the fastest waffle detector ever invented.
Fast does not mean sloppy
Speed and accuracy are not in tension if you keep the two kinds of content visibly separate. State facts with a source. Mark interpretation as yours. Where something is genuinely unknown, say "unclear" rather than guessing, and say when you expect to know more.
The short version
Write for the named reader, not the subject. Send it while it still matters. Hold the two-page line. Put what bites your organisation first, order everything by priority, attach an owner and a date to every recommendation, and keep fact and judgement visibly apart. The best compliment a policy briefing can receive is silence, followed by your recommendation happening.
Get intelligence like this, matched to your priorities.
Frontbench tracks every bill, committee, consultation and motion overnight and surfaces what matters to your organisation.