No Drawings, No Cause & Effect, No Configuration Backup: Who Actually Owns the Risk?

Taking over maintenance of an existing fire alarm system is not always straightforward.

In an ideal world, the incoming contractor would receive a complete set of as-fitted drawings, current zone plans, a cause and effect matrix, commissioning records, configuration backups, modification records and a clear record of any interfaces to other life safety systems.

In reality, that information is often incomplete, outdated or missing entirely.

This creates a problem for both the maintenance contractor and the Responsible Person. A contractor may be expected to maintain the system, but the information needed to understand the original design intent may no longer exist.

The key point is simple:

Maintaining an existing system is not the same as retrospectively proving how it was designed.

Maintenance does not automatically prove design intent

A maintenance engineer can test devices, outputs, sounders, batteries, interfaces and fault conditions.

What they cannot always establish is whether the system is doing what it was originally intended to do.

For example, an engineer may activate a detector and observe that several outputs operate. Without an approved cause and effect matrix, there may be no reliable way of knowing whether:

• every required output operated;
• an output operated that should not have;
• a delay is intentional;
• coincidence logic should apply;
• different rules apply in different areas;
• smoke control should operate differently depending on fire location;
• lifts should return to different floors;
• selected doors should release;
• another system should also have received a signal.

The existing panel configuration can show what the system currently does.

It does not automatically prove what the system should do.

That distinction is important.

Who is responsible for missing information?

There is sometimes an assumption that once a new contractor takes over maintenance, they also take over full responsibility for the existing system and all of its history.

That is not really how responsibility works.

The Responsible Person retains duties under the Regulatory Reform (Fire Safety) Order 2005 for the management of fire safety at the premises.

A contractor can also have responsibilities, particularly for the work they carry out and matters within their control.

For example, a contractor is responsible for the quality of a replacement device they install, programming changes they make, and defects they identify but fail to deal with appropriately.

What a contractor cannot reasonably be expected to do is automatically know the undocumented design decisions made by a previous installer or contractor.

Responsibility for current work and knowledge of historical design intent are not the same thing.

Missing drawings are more than an inconvenience

Fire alarm drawings are not simply useful reference documents for engineers.

They can provide information about:

• device locations;
• zone boundaries;
• loop routing;
• interface locations;
• isolators;
• equipment controlled by the fire alarm;
• areas of responsibility between systems;
• inaccessible devices;
• previous alterations.

Without reliable drawings, the engineer often has to establish basic information by investigation.

This increases time on site, makes fault finding more difficult and encourages assumptions to creep into maintenance work.

An interface labelled "AHU shutdown" may appear clear enough, but there may still be unanswered questions.

Which AHU does it control?

Does it shut down one unit or several?

Should it operate from every fire condition?

Is feedback monitored?

Has the mechanical system changed since the interface was installed?

A label is useful, but it may not be enough to verify correct operation.

Cause and effect is critical

Cause and effect becomes particularly important on larger or more complex sites.

A modern fire alarm system may interface with:

• smoke control;
• AOV systems;
• mechanical extract;
• pressurisation;
• fire curtains;
• automatic doors;
• access control;
• lifts;
• gas suppression;
• sprinkler systems;
• HVAC;
• refuge systems;
• public address and voice alarm systems;
• remote monitoring;
• phased evacuation systems.

Where systems interact, testing becomes more than checking whether a relay changes state.

The engineer needs a reference against which the intended response can be checked.

Without that reference, an engineer can record observed operation.

They cannot necessarily prove that the observed operation is correct.

Existing behaviour is evidence of configuration. It is not evidence of design intent.

Configuration backups matter too

Configuration backups are often overlooked until a panel fails.

If the only current configuration exists inside the control panel, a hardware failure can create a significant problem.

On a basic system, rebuilding the configuration may be relatively simple.

On a large addressable network, the configuration may contain:

• hundreds or thousands of devices;
• output groups;
• delays;
• dependencies;
• network logic;
• phased evacuation rules;
• interface controls;
• site-specific programming.

Losing that configuration can turn a hardware replacement into a much larger engineering exercise.

Controlled backups should therefore be retained where possible, with clear version information and dates.

A folder containing files called:

FINAL

FINAL2

FINAL_NEW

FINAL_WORKING

does not amount to good configuration management.

There needs to be a reasonable level of confidence that the backup actually reflects the installed system.

A backup does not prove the programming is correct

It is also worth separating configuration backup from configuration verification.

A backup preserves what is programmed.

It does not prove that the programming is correct.

If an output was programmed incorrectly several years ago, downloading the database simply preserves the mistake.

Configuration backups are important for resilience and recovery.

They should not be treated as proof of correct design.

Incoming contractors should identify the information gap

When taking over an existing system, contractors should establish what information is available and what is missing.

This does not need to become a full retrospective commissioning exercise every time, but a basic review can prevent problems later.

An incoming survey may consider whether the following are available:

• as-fitted drawings;
• zone plans;
• cause and effect documentation;
• commissioning records;
• configuration backups;
• device schedules;
• interface schedules;
• system logbooks;
• previous modification records;
• relevant fire strategy information.

The physical installation should also be compared with the available documentation where reasonably practical.

If there are obvious discrepancies, they should be recorded.

Limitations should be documented properly

Missing information should not simply be ignored.

If a contractor cannot verify part of the system because the necessary information is unavailable, that limitation should be recorded clearly.

For example:

Operation of accessible detection devices and alarm warning devices was tested. Full verification of programmed cause and effect was not possible because no approved cause and effect documentation was available at the time of attendance.

That is much more useful than simply stating:

System tested satisfactory.

The first statement explains what was actually verified.

The second may imply a level of certainty that does not exist.

"No drawings" is not an excuse for poor maintenance

There needs to be some balance here.

The absence of drawings or cause and effect documentation does not remove the contractor's responsibility to carry out competent maintenance.

If a detector is visibly damaged, missing drawings are irrelevant.

If batteries fail testing, the lack of a cause and effect matrix does not prevent replacement.

If the panel reports an earth fault, the contractor should still investigate it.

Limitations should only be applied where missing information genuinely prevents something from being verified.

They should not be used as a blanket disclaimer.

Sometimes a separate survey is necessary

There is a point where normal maintenance is no longer enough to resolve the uncertainty.

At that stage, a separate survey or validation exercise may be appropriate.

That work could include:

• tracing circuits;
• mapping devices;
• producing updated drawings;
• identifying interfaces;
• retrieving panel configurations;
• reviewing programming;
• witnessing system responses;
• comparing operation against the fire strategy;
• reconstructing cause and effect documentation;
• identifying undocumented alterations.

This should be treated as engineering work in its own right.

It should not automatically be expected to fit inside a routine maintenance visit.

Reconstructed documentation needs to be clearly identified

If an incoming contractor recreates missing documentation, it should be clear what that document represents.

There is a significant difference between:

Approved design cause and effect

and:

Cause and effect reconstructed from observed system behaviour

A reconstructed document may be extremely useful, but unless it has been checked against the relevant fire strategy and design requirements, it should not automatically be treated as original design information.

The same applies to drawings.

A drawing produced during a survey should not necessarily be labelled "as-fitted" if it only reflects what could be observed during that visit.

A more accurate title may be:

Survey drawing based on accessible installation observed on 04/10/2026

That gives future engineers a much better understanding of what the document actually represents.

Provenance matters

One of the biggest problems with old fire alarm documentation is not always that it is missing.

Sometimes it exists, but nobody knows what it is.

An undated drawing called:

FIRE ALARM FINAL.pdf

may be:

• a tender drawing;
• a construction drawing;
• a commissioning drawing;
• a proposed alteration;
• an obsolete issue;
• an actual record of the final installation.

Without revision information, dates and proper document control, it may be difficult to rely on.

The same applies to panel databases and cause and effect documents.

Documents need context.

Clients should understand what they are buying

The absence of documentation also creates a commercial problem.

Two contractors may both quote for "annual fire alarm maintenance" while providing very different levels of service.

One may price for basic device testing.

Another may include:

• interface testing;
• documentation review;
• configuration backup;
• investigation of discrepancies;
• review of system limitations;
• detailed defect reporting.

Those are not necessarily equivalent services.

The cheapest maintenance quote may simply include less investigation and less verification.

Clients should therefore understand exactly what the contractor will and will not be checking.

The information gap is itself a risk

The broader point is that missing information should be treated as a real issue.

A fire alarm system may appear healthy and operate without faults, but if nobody knows:

• what the original cause and effect should be;
• which systems it controls;
• what has been altered;
• which configuration is current;
• where interfaces are located;
• what documentation can be relied on;

then the building has an information gap.

That gap becomes particularly important when the system is modified, fails or needs to be recovered after a major fault.

The system may work perfectly today.

The problem only becomes obvious when somebody needs to understand it.

So who actually owns the risk?

There is no useful answer that simply says "the contractor" or "the Responsible Person".

Responsibility depends on legal duties, contractual arrangements, control of the premises and the work being carried out.

From an engineering perspective, however, the position should be much clearer.

The Responsible Person should ensure fire safety is properly managed.

The contractor should competently carry out the work within their scope.

The engineer should clearly identify significant limitations and discrepancies.

Where information is missing, that should be documented and managed rather than ignored.

A maintenance contractor cannot recreate years of missing design information simply by taking over the service contract.

Equally, contractors should not quietly accept uncertainty and then issue reports that suggest everything has been fully verified.

The most useful conclusion may sometimes be:

There is currently insufficient information to fully verify the intended operation of this system.

That is not avoiding responsibility.

It is an accurate engineering statement, and it gives the Responsible Person something that can actually be acted on.