Skip to content
TIFA Fire

Fire safety auditing for fire and rescue services

An audit workspace for protection officers. It helps with preparation, evidence, the audit record and routine letters. Decisions, enforcement and statutory notices stay with authorised officers.

A separate product from TIFA Fire Assessments, with its own workflow and screens. Shown with fictional data. Not deployed in any service.

Built around the officer’s audit

An audit under the Regulatory Reform (Fire Safety) Order 2005 is a different job from writing a fire risk assessment. The workspace follows the officer’s process.

  1. Step 1: Prepare from prior records

    Previous audits, outcomes and deficiencies the officer is authorised to see, with points to check on this visit drawn from them.
  2. Step 2: Capture evidence on site

    Observations by voice or text, photos and documents, tagged to the relevant article and location. Works without signal.
  3. Step 3: Build the structured audit record

    Observations are organised by article. Where an observation may be relevant to a deficiency, it is marked for the officer to consider, with legal and policy references to check.
A carpeted hotel bedroom corridor with doors either side
Officer capturing a photo and voice note against article 14 on a phone.
  1. Step 4: Record the officer’s decision and reasoning

    The officer chooses the outcome and writes their reasoning. Nothing is classed as a deficiency, and no outcome is set, until the officer does it.
  2. Step 5: Draft routine correspondence

    A notification of deficiencies or similar routine letter is drafted from the officer’s recorded findings, clearly marked as a draft for the officer to edit.
  3. Step 6: Supervisory review and issue

    The case goes to a supervisor for approval under the service’s own authorisation rules. The officer issues the letter and the follow-up is scheduled.

The workflow on film

An officer prepares for a hotel audit, captures evidence, reviews the draft audit record, records a decision and passes the case through supervisory review. This is a proposed workflow, not a deployed authority integration.

No sound. A proposed workflow, not a deployed authority integration.Download MP4, 1080p

What the software will not do

The service and its officers remain the decision makers. The software is designed so that this cannot be bypassed.

It will not decide enforcement outcomes

Outcomes are chosen by an authorised officer and approved through the service’s own review process.

It will not issue statutory notices

The software can hold the service’s templates, but it cannot issue an enforcement, prohibition or alterations notice.

It will not replace the officer’s judgement

Legal and policy references are offered for the officer to check. They are not a legal determination.

How it would connect to your systems

Services already hold their premises and case records in an existing system. TIFA Fire would sit alongside it, not replace it. Any integration would be agreed and approved with the service first.

Officer phone or tablet
Audit record, photos and voice notes. Works offline and syncs when signal returns.
TIFA Fire for Fire & Rescue
Briefing, audit record, drafting, officer decisions, supervisory review and correspondence.
Connector
Maps cases, premises and outcomes between systems under the service’s rules.
Proposed, not built
Case management system
The authority’s existing system of record, for example Civica CFRMIS.
Proposed, not built
Service sign-in
Officers sign in with the service’s own identity provider, such as Microsoft Entra ID.
Proposed, not built
Address and premises data
UPRN and gazetteer lookups so audits attach to the right premises.
Proposed, not built
Records and documents
Letters and evidence filed to the service’s records store under its retention rules.
Proposed, not built
TIFA Fire, in developmentProposed integration. None exists today.

Information governance

These are the commitments a pilot would be built on. They would be set out in a data processing agreement before any service data is used.

  • Officers see only the premises and records they are authorised to see.
  • Every observation, draft, edit, decision and approval is recorded with a name and time.
  • Drafted text is marked as drafted until an officer accepts it.
  • Retention follows the service’s own records policy.
  • Hosting region agreed with the service, with UK and EU options.
  • Service data is not used to train AI models.
  • Support for the service’s data protection impact assessment before a pilot.
  • Sign-in through the service’s identity provider where possible.

A controlled pilot

We would work with one protection team at a time, in stages, with the service deciding whether to move on at each one.

  1. Stage 1

    Discovery

    Understand the audit process, letters, policies and systems. Agree the data protection approach.

  2. Stage 2

    Configuration

    Set up the service’s audit structure, policy references and letter templates in a test environment.

  3. Stage 3

    Limited live use

    A small group of named officers use it on real audits alongside the existing process.

  4. Stage 4

    Evaluation

    Review quality, time and officer feedback together, then decide whether to continue.

Talk to us about a pilot

For protection managers and heads of prevention and protection. We’ll show the workflow and listen to how your audits run today.