Resources • audit trail • evidence • sign-off

How to build a fire door audit trail (without chaos)

A practical playbook for identity, evidence continuity, sign-off, and exports that trace back to the same door record — not a folder of disconnected photos and PDFs.

7‑day trial. No card required. Cancel anytime.

Last updated:

Audit trail checklist

A door-by-door story —
not a folder of disconnected photos and PDFs

A strong audit trail is mostly about preventing broken links between steps. Lock identity, keep evidence attached, and ensure sign-off traces back to the same record that holds the findings.

Goal 01

Outcome

Every door keeps one history: inspections → remedials → outputs → sign-off. PDFs and history trace back to the same record. Anyone picking up the file can follow the story without asking questions.

One record · end to end
Inspect Remedials Outputs Signed off One record · all links intact

Goal 02

Make it repeatable

Lock door IDs, use consistent checklists, and review missing evidence before exporting. A broken link at any stage — renamed door, detached photo, missing sign-off — stops the story being trustworthy.

Consistent across every visit
Visit 1 Stable ID BKA-014 Visit 2 History accumulates · links intact

Goal 03

In Fire Door App

Door register, history, documents, and Client Portal exports all map to the same door record. Capture on site, generate PDFs, share with clients — traceability is built in, not assembled after the fact.

Traceability built in
Door record Register + history Documents + PDFs Client portal All trace back to the same record

Door identity

Stable door IDs and consistent locations ensure the same physical door keeps one record across time — no duplicates, no guessing.

Evidence continuity

Photos, notes, and outputs attached to the door record — not stored in folders that get renamed or lost between visits.

Sign-off & exports

Remedial sign-off, PDFs, and signatures that trace back to the same underlying history — not assembled manually from separate files.

Audit trail checklist

Use this to spot gaps
before the next audit

Five areas — each a potential break in the chain. If any link is missing, the audit trail stops being trustworthy. Check them before generating outputs, not after a client questions them.

Five things every door record needs

01

Door identity

Stable door IDs, a consistent location hierarchy, and tag identifiers if used on site.

Unique, stable, human-readable ID
Consistent location string (Site/Block/Floor/Area)
Tag/QR identifier if used
02

Inspection evidence

Pass/fail outcomes, consistent fail reasons, photos, and notes — all attached to the door record, not stored in separate folders.

Pass/fail + severity in a field
Standardised fail reasons
Photos + notes attached to door record
03

Remedial proof

Tasks per door with before/after evidence, dates, and status changes — raised from the finding, not from a separate spreadsheet.

Task linked to the door that raised it
Before/after evidence attached
Status + completion date recorded
04

Exports

Branded PDFs and portal exports generated from the source record — so they trace back to the history and evidence that produced them.

PDF generated from live record
References door IDs and inspection dates
No "detached" manually assembled versions
05

Approval + signatures

Manager approval gates where needed, and signatures shown on PDFs — pulled from the assigned users on the record, not added as standalone images.

Inspector vs approver roles clear
Signature tied to inspection record + date
Approval visible in record, not just PDF
For the end-to-end story Explore use cases
Door record BKA-014 01 Identity BKA-014 02 Evidence 03 Remedial proof Before After ✓ Closed 04 Exports Report .pdf BKA-014 traces back 05 Approval + signatures Inspector J. Smith Approved 20 Jan 2026 Audit-ready All five links intact · chain complete
Repeatable process

Think of an audit trail as connected records,
not one final report

If any link breaks — renamed door, detached photo, sign-off over email — the story stops being trustworthy. Six steps that keep every link intact from the first visit to the issued output.

Six steps · keep every link intact

Step 01

Start with stable door IDs

Create one door record per physical door and keep the identifier stable across visits and projects. This is the anchor — everything else hangs off it.

Agreed before capture starts

Step 02

Record inspection outcomes

Capture checklist results, consistent fail reasons, and notes that describe what was observed. Severity in a field, not buried in free text.

Same wording across inspectors

Step 03

Attach evidence to the door

Keep photos and supporting notes on the door record — not in shared folders that get renamed, reorganised, or lost between visits.

Attached at capture, not later

Step 04

Convert findings into work

Raise remedials against the same door record so tasks inherit the full context — severity, photos, notes — without re-explaining it in the task description.

Raised from finding · not a separate list

Step 05

Close the loop with proof

When work is completed, attach before/after evidence and record who signed off. A task marked "complete" without evidence attached is a statement, not a proof.

Before / after + sign-off name + date

Step 06

Export from the source record

Generate PDFs and portal exports from the same underlying data so they trace back to history and evidence — not assembled separately in Word or a spreadsheet.

Live record → output · no manual assembly

What "audit-friendly" means in practice

Can you open any door and see its full history?
Can you show what changed after remedials, with evidence?
Can you show which PDF was issued and trace it back to the record?
Can you show who signed/approved and under what role?
1 Stable door ID BKA-014 2 Pass High Inspection recorded 3 Overview Close-up Attached 4 Finding Remedial BKA-014 5 Before After Signed 6 Source record PDF traceable Audit-ready All six steps · chain intact
Minimum evidence pack

The smallest set that tends to satisfy
client QA and third-party audits

Your contracts may require more. These six fields are the baseline — the point at which a door record can stand on its own in an audit without someone having to reconstruct the story from memory or emails.

01

Identity + location

Door ID, building, and stable location

Door ID, building name, and a stable location hierarchy — Site / Block / Floor / Area. The physical door must map to one record, consistently, across every visit.

BKA-014 Block A Fl 02

02

Outcome + reasons

Pass / fail, severity, and a short note

Pass/fail or grading, consistent fail reasons from a shared list, and a short note covering what was observed. Severity must be in a field — not buried in the notes column.

Fail High Closer inoperative

03

Photos

Enough to prove the finding and identify the door

Overview shot showing context, plus at least one close-up per issue. Photos must be attached to the door record — not saved to a shared folder that may be renamed later.

Overview Close-up Attached ✓

04

Remedial linkage

Tasks tied to the door that raised them

Remedial tasks linked to the exact door record — not a standalone spreadsheet row. When a task inherits the finding's context, it can be scheduled, prioritised, and closed without re-explaining the issue.

Finding Remedial · BKA-014 ← same door record

05

Before / after proof

Evidence that the remedial was completed and what changed

Before and after photos at the same angles, plus completion date and who signed off. This is the evidence that distinguishes "it was fixed" from "we said it was fixed".

Before After Signed · 20 Jan 2026

06

Outputs

PDFs generated from the same record

PDFs and portal exports generated from the source record — not assembled manually in Word or spreadsheet. The output should trace back to the same history and evidence that produced it.

Live record Report.pdf Traceable ✓

Quick QA checks

Before you share a PDF — four things to verify

Each fail has photo + note

At least one photo and one clear note attached to every fail outcome — not a blank note field.

Door IDs unique and consistent

No duplicates within the building, and IDs match any on-door labels or QR tags in use.

Remedials point to the right door

Each remedial item traces back to the exact door and inspection that raised it — not a separate standalone task.

PDF links back to record + date

The shared PDF is clearly linked to the same record, inspection date, and visit context — not an orphaned file.

Self-audit prompts

Five questions to test your audit trail before a third party does

Identity: Can you find "Door X" again on the next visit without guesswork — using just the ID and location in the record?

Evidence: Can you show the photos and notes that justify each outcome — without relying on personal memory or an email thread?

Change history: Can you show what changed after remedials, when it changed, and attach a before/after photo to prove it?

Outputs: Can you show which PDF was issued and demonstrate it traces back to the same record — not a separately assembled document?

Sign-off: Can you show who approved, when, and under what role — with the approval attached to the record rather than just mentioned in an email?

Audit-ready

Sign-off & signatures

Signatures are most useful when tied to the record,
not added to the PDF

A signed PDF is a statement. A signature pulled from the assigned user on the inspection record — tied to the door, the findings, and the date — is proof. The difference matters at audit.

Four sign-off rules that keep traceability intact

Keep roles clear

Separate who inspected from who approved — Inspector vs Manager, clearly labelled on the record. Mixed roles make it impossible to answer "who authorised this?" at audit.

Store signatures once

Save a signature image on the user profile so it appears consistently across every report generated for that user — not uploaded fresh each time or copied from a previous PDF.

Attach sign-off to the record

The record itself should show who approved and when — not just the PDF. If the PDF is the only place the approval lives, regenerating the report risks losing it.

Handle missing signatures explicitly

Keep the workflow visible when a signature is absent — a clearly blank field is better than a silently omitted one. Missing signatures should not be hidden in the output.

Inspection record BKA-014 20 Jan 2026 · Floor 02 Inspector J. Smith Manager · Approver M. Clarke Sign-off attached to record J. Smith · Inspector 20 Jan 2026 M. Clarke · Manager 20 Jan 2026 Report.pdf Traceable to record ✓ vs. missing signature — explicit, not hidden Signature: — Visible blank ✓ vs Signature: (none) Silently hidden ✗

Common sign-off pitfalls

Three patterns that break traceability at the last step

Signatures as standalone images

Signatures captured as loose image files with no link to a specific inspection record — they appear in the PDF but can't be traced back to who approved what, when, and for which door.

"Final" PDFs assembled in Word

PDFs manually assembled from screenshots, spreadsheet exports, and pasted signatures — the audit trail lives somewhere else (or nowhere), and the PDF can't be traced back to the source record.

Approvals over email

Sign-off communicated by email with no record of who approved, when, and in what role — an email thread is not an audit trail. If the inbox is lost or searched, the approval disappears.

Common failure modes

Most audit trail problems come from
broken links between steps

Four patterns that cause a previously coherent trail to become untrustworthy — usually discovered at the worst possible time. Each has a clear prevention.

Identity break

Door IDs change between visits

The same physical door gets multiple records across visits — because the ID was renamed, re-entered from memory, or duplicated when a new project started. History becomes fragmented and unfollowable.

Multiple records · one door History fragmented Filters break

Fix: lock the ID scheme before capture starts and never rename a live door ID — even between projects.

Visit 1 BKA-014 Visit 2 Door-14 Visit 3 Lobby D14 3 separate records 1 door ✗ BKA-014 · locked · never renamed → one record

Detached evidence

Evidence lives in shared folders

Photos stored in shared drives and named by date or job number — no stable link to the door record. When the folder is renamed, reorganised, or the naming convention changes, the evidence becomes unattributable.

Can't attribute at audit Folder renamed = lost No door-level link

Fix: attach photos and notes to the door record at the time of capture — not filed separately and linked later.

IMG_001 No door IMG_002 No door IMG_003 No door ? Which door? BKA-014 attached

Broken link

Remedials lose context

Tasks created manually in a spreadsheet or task manager — not raised from the door record. They may get completed but there's no evidence of which inspection finding they resolved, which door they relate to, or what changed.

No finding reference No before/after Unverifiable close

Fix: raise remedials from the finding on the door record — so tasks inherit severity, photos, and door ID automatically.

Task: Fix door closer Status: Done No door ID · no finding ✗ ? Remedial BKA-014

Detached output

PDFs are "detached" from the record

Exports manually assembled from spreadsheets, pasted screenshots, and email threads — stored in a shared folder with no reference back to the door IDs, tasks, or history that produced them. Impossible to verify at audit.

Can't verify at audit No source reference Version confusion

Fix: generate outputs from the source record so every PDF references the door IDs, dates, and history it came from.

v3 final No source ✗ v1? v2? v3-FINAL? Report.pdf BKA-014 ↗ Traceable

QR tags help keep the right door record in view on repeat visits — by opening the correct record instantly when scanned, they reduce the risk of inspectors creating a new record for a door that already has one.

See the QR tagging checklist
Common questions

Quick answers for teams moving
from spreadsheets and folders to a joined-up workflow

Four questions that come up when teams are building or tightening an audit trail for the first time. Deeper guidance is in the related guides.

What counts & what's needed

A door-by-door history that keeps identity, inspection outcomes, photos and notes, remedial tasks, completion evidence, and issued PDFs all linked to the same door record — so you can open any door and follow the story without having to reconstruct it from emails or separate files.

The key word is "linked". Individual pieces of evidence stored in separate places don't constitute a trail. The connection between findings, tasks, and sign-off is what makes it auditable rather than just a collection of documents.

One door · one record All links intact End to end

No. The audit trail comes from keeping door identity and evidence consistent inside your register — stable IDs, attached photos, linked remedials, and traceable exports. QR tags are a workflow tool, not an audit trail requirement.

Tags help inspectors open the correct door record instantly on repeat visits, which reduces the risk of creating a duplicate record. But if your IDs are stable and your evidence is attached, the trail is intact with or without tags.

No tags required Stable IDs + attached evidence Tags reduce duplicate risk
QR tagging checklist

Traceability & multi-team

Generate outputs from the source record rather than assembling them manually in Word or a spreadsheet. When a PDF is generated from the live inspection or project record, it inherits the door IDs, inspection date, and the evidence that produced it — so any auditor can trace it back without asking you to explain it.

The failure mode to avoid is a "v3-FINAL.pdf" stored in a shared folder with no reference to the specific inspection, doors, or history it summarises. That file is a statement, not a proof.

Generated from source References door IDs + date No manual assembly
Documents & PDFs platform

Two things together: role-based access so different people can only do what they're permitted to do, and activity history on the record so you can answer what changed, when it changed, and who made the change.

The failure mode is a shared login or a "admin does everything" model where individual actions can't be attributed. When three inspectors share one login, the history shows one actor — which is effectively no history at all at audit time.

Role-based access Per-user history No shared logins
Inspections platform

Quick facts

Audit trail at a glance

What it is

Door-by-door history: identity, outcomes, evidence, remedials, sign-off — all linked

Minimum pack

Stable ID + outcome + severity + photos attached + remedial linkage + traceable PDF

QR tags

Not required for the trail — useful for reducing duplicate records on repeat visits

Traceable PDFs

Generated from source record — references door IDs, dates, and history that produced them

Multi-team

Role-based access + per-user history — no shared logins that obscure who did what

Core test

Can you open any door and follow the story without asking someone to explain it?

Get started

Make your next audit boring

Keep everything attached to each door — inspections, remedials, sign-off, and exports all tracing back to the same record.

7-day trial No card required Cancel anytime
Get started

Prove the trail on a small pilot first.
Then scale the same structure site-wide.

Run a few doors end-to-end — inspection, remedials, completion evidence, and issued PDFs — and check every output still points back to the same door record.

7‑day trial No card required Cancel anytime