Overview
Fire stopping defects often reappear because nobody can tell:
- what was sealed
- where it was sealed
- what system was used
- what to do when services change
The problem documentation solves
Fire stopping fails in real life when someone later asks:
- “Which penetration was sealed?”
- “What system was used?”
- “Can we add another cable/pipe here?”
If the answer is “we don’t know”, the building drifts back toward repeat defects and you lose defensibility during audits.
The close-out pack: a simple structure that works
Think of the close-out pack as a link between defect → fix → evidence.
Close-out pack structure (table)
| Section | What it contains | Why it matters |
|---|---|---|
| Register | defect IDs, locations, status | tells you what exists and what’s done |
| Evidence | before/after photos, notes | proves work at the exact location |
| System references | system approach / product references where relevant | supports future reinstatement |
| Exceptions | no access, design constraints, exclusions | prevents false confidence |
What your defect register should include
Treat the register as the “index” that everything else attaches to.
Defect register fields (table)
| Field | Example | Why it matters |
|---|---|---|
| Defect ID | FS-R2-L1-006 | stable reference |
| Location | Riser 2, Level 1, north wall | find it again |
| Service type | cable tray / plastic pipe / mixed | drives system selection |
| Status | open / in progress / closed | programme control |
| Priority | P1/P2/P3 | triage and sequencing |
| Notes | access constraints / assumptions | governance |
Location references: treat them like door IDs
The biggest win is using stable identifiers so the same penetration can be found again.
Practical approaches:
- riser ID + level + bay (e.g.,
Riser A / L3 / Bay 04) - room number + wall reference
- grid reference on a marked-up plan
If the building has repeated layouts, stable references are what stop everything becoming “the third penetration on the left”.
What to record for system IDs (without overcomplicating it)
You don’t always need a full technical dossier, but you do need enough information for a competent person to understand what was installed.
Useful fields to capture (table)
| Field | Example | Why it helps |
|---|---|---|
| Defect ID | FS-R1-L2-014 | ties everything together |
| Substrate | blockwork / plasterboard / concrete | system selection depends on it |
| Service type | cable bundle / plastic pipe / mixed | prevents wrong assumptions |
| System approach | “tested system for mixed services in wall” | supports reinstatement |
| Installer notes | constraints / access issues | explains exceptions |
Photos that actually help later
Photo packs are only useful if you can tell what you’re looking at.
A practical photo set (table)
| Photo | What it should show |
|---|---|
| Wide context | room/riser + reference marker |
| Close-up before | defect condition |
| Close-up after | completed seal/system detail |
| Label/ID | defect ID visible in shot where possible |
File naming that prevents chaos
When you have dozens (or hundreds) of penetrations, naming discipline matters.
Simple naming examples (table)
| Type | Example |
|---|---|
| Defect register | 2026-07_site-a_fire-stopping_register.xlsx |
| Photo pack | 2026-07_site-a_photos_fs-r1-l2-001-to-050.zip |
| Close-out summary | 2026-07_site-a_fire-stopping_closeout.pdf |
Exceptions: how to keep them visible (so they don’t get forgotten)
If you can’t access an area or a design decision is needed, record it as an explicit exception rather than letting it disappear.
Practical rule:
- exceptions stay open in the register with a next action and owner
This prevents the false impression that “all defects are closed”.
A simple follow-on works process (so evidence doesn’t become obsolete)
Change workflow (table)
| Trigger | What to do | Update |
|---|---|---|
| New service added | reinstate the penetration to the same system approach | new after photo + register note |
| Service removed | make good and close the void (don’t leave an opening) | register update + photo |
| Boxing altered | check junctions and reinstate sealing | note constraint + close-out |
Keeping the documentation “alive” after handover
The close-out pack isn’t just for filing. It’s a maintenance tool.
If you want to reduce repeat defects:
- require reinstatement after every service change through a compartment line
- keep the register as the single source of truth
- update status and photos when follow-on works modify a penetration
Who uses this (and what they need)
Different stakeholders look for different things. A good pack satisfies all of them without becoming a 200‑page PDF.
Stakeholder needs (table)
| Stakeholder | What they need from the pack |
|---|---|
| Facilities / maintenance | stable IDs, locations, and “what to do when changed” |
| Auditors / compliance | proof of completion + exceptions list |
| Contractors | clarity on system approach and constraints |
| Responsible Person | governance: programme status and risk visibility |
Minimum vs “nice to have” (keep it practical)
Documentation tiers (table)
| Tier | What it includes | When it’s enough |
|---|---|---|
| Minimum | register + photos + close/open status | small scopes, low churn areas |
| Strong | minimum + system approach notes + exceptions ownership | most portfolios |
| Best | strong + mapped plans + clear change-control process | high churn sites (care, large estates, frequent fit-outs) |
FAQs
Do we need product data sheets for every penetration?
Not always. But you should be able to describe the system approach, the service type, and the substrate so reinstatement is possible.
What’s the biggest documentation mistake?
Photos with no location reference. If you can’t find the penetration again, the evidence isn’t usable.
How do we make audits easier?
Keep a single register with stable IDs, and make sure every “closed” item has evidence attached (photo + note).
Where should we store the pack?
Anywhere your teams can actually find it: a shared drive, asset management system, or platform. The important part is consistency (one “source of truth”) and access for whoever will manage follow-on works.
What if we only have partial access during works?
Record it clearly as an exception with a next action (revisit date, access plan, owner). Partial access is common — the mistake is pretending it’s closed.
A practical close-out checklist
- location references (plans, riser IDs, room numbers)
- defect register (open/closed)
- photos before/after where practical
- system/product references where relevant
- exceptions list (items awaiting access or design)
Related pages
Note
This article is general information. Align documentation to your fire strategy, stakeholder requirements, and competent guidance.