Skip to main content
← Back to resources
Reporting & DocumentationService reportsBS 5839-1DocumentationMaintenanceCompliance6 min read

Fire Alarm Service Report Template: What to Include

What a fire alarm service report should contain to stand up later: scope, findings, limitations, disablements and recommendations, separated so nobody has to guess.

By Incognito Fire & Security · Updated August 19, 2026

Editorially reviewedVersion 2medium confidence

Last updated August 19, 2026.

Sources used

3

Review sources and evidence basis

Source labels describe the evidence basis; current manufacturer documents and licensed standards remain authoritative. Professional disclaimer

Most service reports are written in the last ten minutes of a visit, in a van, with the customer waiting for a signature. That is exactly why the structure matters. If the format prompts you for the right things, the report survives contact with a fire officer, an insurer or a solicitor eighteen months later. If it does not, you are relying on memory that will not be there.

This is what a fire alarm service report needs to contain, and — just as important — how the parts should be separated.

Who this is for

Service engineers writing reports, technical managers standardising them across a team, and responsible persons who have to read them and act. It assumes familiarity with routine servicing of commercial fire alarm systems.

Experience level

Competent engineer. The judgement calls here — what counts as a limitation, how firmly to word a recommendation — come with time on site.

What the report is for

Three audiences, and they want different things.

The responsible person needs to know whether the system is doing its job, what is wrong, and what they are being asked to authorise. Under the Regulatory Reform (Fire Safety) Order 2005 the duty to keep fire safety measures in efficient working order sits with them, and GOV.UK guidance is explicit that maintaining appropriate measures is their responsibility. Your report is the information they act on.

The next engineer needs to know what was found last time, what was left disabled, and what has already been tried.

The investigator — after an incident, a claim or an enforcement visit — needs to know what was actually verified on a given date and what was not. This is the audience nobody writes for and the one that matters most when it arrives.

The structure that works

1. Identification. Premises, address, system reference, panel make and model, engineer name, date and times on and off site. Ambiguity here undermines everything below it.

2. Scope of this visit. What this visit was: a routine service, a call-out, a re-test, part of a phased inspection. State clearly what portion of the system was covered on this occasion, because periodic servicing is normally spread across visits and a reader should not have to infer that.

3. Tests carried out. What was tested, how, and the result. Panel functions, detection devices by zone or address, manual call points, sounders and beacons, cause and effect operation, power supplies and batteries, and any interfaces and transmission equipment.

4. Findings. What you observed. Factual, dated, specific: zone, loop, address, device type and location. "Detector at L1/047, ground floor store, no response on test" is a finding. "Some detectors faulty" is not.

5. Limitations. Everything you could not verify, and why. See below.

6. Disablements and temporary measures. Anything left off, isolated or bypassed, who was informed, and what the arrangement is for restoring it.

7. Recommendations. Your professional judgement on what should be done, prioritised, kept clearly separate from findings.

8. Statement of the system's condition and sign-off. Whether the system was left in normal operation, in fault or with disablements, plus the signatures and the distribution.

Recording limitations honestly

This is where reports most often fail. Locked rooms, occupied bedrooms, live production areas, sterile areas, high-level devices with no access equipment, a tenant who would not let you in — these are normal, and none of them is a problem provided they are written down.

Name the area, state why it could not be accessed, state precisely what could not be verified as a result, and record who at the site was told. A limitation recorded on the day is a managed risk transferred to the person who can do something about it. The same limitation left off the report is, in effect, a silent claim that the whole system was checked.

Disablements and temporary measures

Anything left disabled must be on the report in plain language, not buried in a comments box. Record what is disabled, why, when it was disabled, who was informed at the premises, and what the plan and timescale for restoration are. If the disablement affects the protection of an area, say so explicitly. BS 5839-1 sets out how disablements should be managed and recorded; the report is where that management becomes visible.

Wording traps

  • "Tested and found satisfactory" applied to a whole system, when only part of it was covered on the visit.
  • "Recommend" used for something that is actually a defect requiring action — be clear which it is.
  • Passive constructions that hide who did what: "the panel was reset" invites the question by whom, and when.
  • Absolute claims the evidence does not support. If a fault was intermittent and did not recur, say that, rather than "fault cleared".
  • Copy-forward text from the previous visit's report, which is how a limitation from two years ago ends up asserted as this year's finding.
  • Jargon and abbreviations the responsible person cannot reasonably be expected to decode.

Making it repeatable across a team

Individual engineers write good reports. Teams write inconsistent ones. The practical fixes are a fixed section order that cannot be skipped, mandatory fields for limitations and disablements so they must be answered rather than left blank, a controlled list of device and fault descriptions so the same condition is described the same way, and a quick second read before issue on anything involving a disablement or an unresolved defect.

Relevant standards

BS 5839-1 is the code of practice covering routine testing, periodic inspection and servicing of fire detection and fire alarm systems in non-domestic premises, and it is the reference for what servicing records should contain. The Regulatory Reform (Fire Safety) Order 2005 creates the underlying legal duty on the responsible person. The standard is a recommendation for meeting that duty rather than legislation itself, and the current edition should always be the one consulted.

When not to rely on a template alone

A template stops you forgetting a section. It does not stop you writing a finding you cannot evidence, or wording a limitation so softly that nobody acts on it. Read the report back once as though you were the person who has to act on it, and once as though you were reading it out in two years' time.

Related documentation

Consider this alongside the guidance on fire alarm certificate types, on testing and maintenance requirements, and on managing disablements — the three areas where reporting most often goes wrong.

Professional disclaimer

This page is engineering support only. It is not legal advice and not a substitute for the applicable standards, the manufacturer's instructions or the responsible person's procedures. The specific content and retention of records for a given installation should follow the current edition of BS 5839-1 and any contractual or insurer requirements that apply.

Frequently asked questions

What should a fire alarm service report contain?

As a minimum: who attended and when, the system and premises identified unambiguously, the scope of what was tested on this visit, what was found, anything that could not be tested and why, any disablements left in place, and clear recommendations separated from statements of fact. The detailed content of servicing records is set out in BS 5839-1.

Is a service report a legal requirement?

The Regulatory Reform (Fire Safety) Order 2005 requires the responsible person to keep fire safety measures in efficient working order and to have appropriate arrangements in place; records are how that is evidenced in practice. The specific form and content of servicing records is a recommendation of BS 5839-1 rather than a clause of the Order itself.

How should areas I could not access be recorded?

Explicitly, on the report, at the time. Name the areas, say why access was not possible, state what could not therefore be verified, and record who was told. A limitation that is written down is a managed risk; the same limitation left unwritten becomes the engineer's problem later.

Should recommendations and findings be in the same section?

No. A finding is what you observed and can evidence. A recommendation is your professional judgement about what should happen next. Mixing them makes it impossible for the responsible person to see what is confirmed fact and lets a recommendation quietly read as a completed action.

Who should receive the service report?

The responsible person or their nominated representative, promptly, and a copy should go into the site record so the next engineer starts from the same information. A report that only exists in a contractor's back office is not doing the job it was written for.