Keeping an audit trail for an assisted submission
A challenge to a statement you wrote a year ago is answered from the file, not from memory. Here is the record a practice needs and the minimum version of it.
The audit trail planning document drafting question comes up the moment someone challenges a statement you wrote 14 months ago. Not the document itself, which sits on the public register, but how it was produced: where a figure came from, which edition of the policy you cited, who checked it, and what changed between the draft and the version submitted. A practice that can answer those four questions in ten minutes is in a very different position from one that cannot.
None of this is required by any planning statute. It is required by professional accountability, by your insurer, and by the fact that planning decisions get revisited.
Why the file matters more than the document
The submitted report is a conclusion. The file is the reasoning, and the reasoning is what gets tested.
Three situations bring it out. An appeal, where your statement of case has to align with what you said at application stage. A complaint or a professional conduct question, where the issue is whether a member took reasonable steps to verify what they signed. And a dispute with a client about scope, where the contemporaneous record decides who agreed to what.
Add a fourth for anyone using assisted drafting: a challenge to the reliability of the material itself. The answer to that challenge is not an assertion that the draft was checked. It is a record showing what was checked, by whom, and against what.
What to record at each stage
Keep it proportionate. A householder statement does not need the file a 400-unit application needs. The structure below scales in both directions.
- Instruction: the client, the site, the scope agreed, the date, and anything expressly excluded from scope.
- Inputs: the drawings, survey reports and site information received, each with a date and a version.
- Constraint checks: which datasets were searched, on what date, and what they returned.
- Drafting: which sections were generated or drafted, and when.
- Sources: for each factual claim, where it came from.
- Review: who reviewed it, when, and what they changed.
- Submission: the final version, the date, and the reference the authority gave it.
A single sheet at the front of the project folder covering those seven headings does most of the work. The rest is discipline about saving files in the right place.
Recording sources for each factual claim
This is the part most practices do badly, and it is the part that matters most when a statement is questioned.
Policy citations need an edition and a date, because the National Planning Policy Framework has been revised repeatedly and the numbering changed with it. A note saying which edition you were working from, and when you checked it, turns a potential error into a dated and defensible position.
Site data needs a provenance and a date, because the mapping services update. A screenshot of a constraint check, saved with the date in the filename, is worth more than a sentence in a report saying the site is not in a flood zone.
Local plan policies need the plan name, the adoption date and the policy number. Consultation responses need the consultee and the date.
Where a fact could not be verified, record that too. A draft that carries a clear placeholder rather than an invented figure is doing the right thing, and the file should show that the placeholder was resolved before submission rather than quietly deleted.
Capturing the reviewer and the date of review
Somebody takes responsibility for the document that goes in. Record who.
The record should show the reviewer's name and role, the date, the version reviewed, the changes requested and whether they were made. Where the reviewer holds a professional qualification relevant to the content, note the qualification, because that is what a later reader will want to know.
For specialist content the point is sharper. A report on a matter requiring a licensed ecologist, a competent person under the biodiversity net gain regime, or someone with fire-engineering competence has to be authored or verified by that person, and the file needs to show it. PlanScope's own review flow runs through defined statuses from sent and accepted through in review and changes requested to signed off, which produces exactly this record without anyone maintaining a spreadsheet. The professional directory is the route to a reviewer where you do not have one in house.
An email saying looks fine to me is not a review record. It is an email.
Where more than one person contributed, record who did what. On a document with an ecology chapter, a transport chapter and a policy chapter, the useful record names the author of each, rather than only the person who assembled the whole.
Storing superseded versions
Keep them. All of them, in order, with dates in the filenames and a short note of what changed.
The instinct to tidy up by deleting drafts is understandable and wrong. Superseded versions show the development of the thinking, and they protect you against the allegation that something was removed. Where a client instructed a change you disagreed with, the version history and the covering email are the record of that.
Version numbering should be boring and consistent. A date-based scheme works well. Whatever you choose, apply it across the practice, because two people using different conventions on the same project produces exactly the confusion the system was meant to prevent.
Paid tiers on PlanScope save and version reports and allow individual sections to be regenerated, which keeps the history in one place rather than scattered across a shared drive. See pricing for what each tier includes.
Handling a challenge months later
When the query arrives, resist the urge to reconstruct. Go to the file.
- Identify the exact statement being challenged and the version it appeared in.
- Find the source recorded for it and the date that source was checked.
- Check whether the source has changed since, and note the date of the current position.
- Reply with the source, the date and the version, and say plainly where the position has moved.
- If the statement was wrong, say so, correct it and record the correction.
That last step is the one that preserves a professional reputation. An error acknowledged with a dated record behind it is a mistake. An error defended without evidence becomes something else.
Policy changes are a recurring source of these queries, and the planning law timeline is a reasonable place to follow what has moved.
A practical minimum for a small practice
One folder per project. Seven subfolders matching the headings above. A one-page project sheet at the front. Dates in every filename. A rule that nothing is submitted without a named reviewer recorded on that sheet.
That is a morning of setting up and about five minutes per project thereafter, and it is the difference between answering a challenge and improvising one.
This is general guidance, not legal advice. Check the position with your local planning authority or a qualified professional before relying on it.
Start a draft on PlanScope and use the review flow to keep the reviewer and version history in one place.
PlanScope provides AI-assisted draft reports for planning applications. Reports should be reviewed before submission. We do not guarantee planning approval.
Frequently asked questions
Is an audit trail required by planning law?
No statute requires it. The pressure comes from professional accountability, from insurers and from the fact that planning decisions get revisited at appeal, in complaints and in disputes about scope. A file that shows sources, dates, versions and the named reviewer answers those situations quickly and without reconstruction.
What should be recorded for each factual claim?
The source, the date it was checked and, for policy, the edition. National policy has been revised repeatedly and numbering has changed, so a note of which edition you worked from turns a potential error into a dated position. Save constraint checks as dated screenshots rather than describing them in prose.
How should a review be recorded?
With the reviewer's name and role, the date, the version reviewed, the changes requested and whether they were made. Where the reviewer holds a relevant professional qualification, note it. For content requiring a licensed or competent professional, the file has to show that person authored or verified the work.
Should superseded drafts be deleted?
No. Keep every version in order, with dates in the filenames and a short note of what changed. Version history shows how the thinking developed and protects against an allegation that something was removed. Where a client instructed a change you disagreed with, the drafts and the covering email are the record.
What is the minimum useful record?
One folder per project, subfolders for instruction, inputs, constraint checks, drafts, sources, review and submission, a one-page project sheet at the front, dates in every filename, and a rule that nothing is submitted without a named reviewer recorded. Setting it up takes a morning and maintaining it takes minutes.
Sources and further reading
This article is general guidance about the planning system in England and, where stated, the rest of the UK. It is not legal or professional advice. Check your local planning authority’s validation requirements and take professional advice for your specific site.