Three things to know about the safety system you inherited

You've taken responsibility for a plant. The team is capable, production is steady, the safety record is clean. And somewhere in the back of your mind is the awareness that some of the safety instrumented systems on site were designed before IEC 61511 existed. Relay logic. Hardwired trip circuits. Early programmable controllers. They've run reliably for fifteen or twenty years, and nobody has ever asked you for formal IEC 61511 evidence for them.

Sooner or later, somebody will. A regulator on a site visit. A corporate safety review. A capital project that triggers a safety case refresh. An insurance audit or a new framework agreement asking for SIS lifecycle evidence.

When that question lands, most teams give the wrong answer — not through incompetence, but because the instinct is to retrofit the whole legacy estate to modern standards, panic at the cost, and quietly hope the question goes away. There's a better path: defensible under scrutiny, proportionate to actual risk, and far cheaper than full retrofit. It comes down to three things.

1. 'Legacy' isn't about age. It's about the evidence base.

Most leaders think about legacy SIS in terms of hardware age. That's the wrong lens. A system built in 1995 and one built in 2010 can both be legacy under IEC 61511 — the defining feature isn't when it was installed, it's whether the standard was the governing basis when the design decisions were made.

IEC 61511 requires specific evidence: a documented hazard and risk assessment setting the SIL target, a Safety Requirements Specification, formal SIL verification using accepted reliability data, structured Functional Safety Assessment at defined stages, and a record trail from design intent through operational test results. Legacy SIS, by definition, don't have most of that. The system was designed to 'good engineering practice' before the standard codified what that practice should look like. The equipment may be entirely fit for purpose — the evidence base behind it is what's missing.

That distinction tells you what work actually needs doing. Stop thinking about 'bringing the system up to standard' and start thinking about 'building a current evidence base.' The hardware probably doesn't need replacing. The documentation around it almost certainly does. I've watched teams scope a months-long hardware refresh, costed against modern equipment, when the real gap was documentation — a current hazard picture, a clear statement of what the system is meant to achieve, and evidence that it does. That work is a fraction of the cost, and it's what the standard actually requires.

2. The law doesn't ask for full compliance. It asks for a defensible position.

Once you understand the evidence problem, the second mistake usually appears: assuming the answer is to make the legacy system fully IEC 61511 compliant. That assumption creates paralysis — the cost balloons, timescales stretch, and the work rarely completes because the budget gets cut once people see the number.

It also misreads what the regulator requires. UK functional safety regulation, under the Health and Safety at Work Act and its supporting frameworks, requires duty-holders to manage risk As Low As Reasonably Practicable. The principle is proportionality: effort and cost commensurate with the risk being controlled. Full retrofit of a legacy SIS to modern standards is almost never reasonably practicable — and the law doesn't ask for it.

What it asks for is a documented, evidence-based argument: that you understand the risks, that existing controls are doing their job, that you have a maintenance and test regime sufficient to keep them doing it, and a prioritised plan for closing any genuine gaps. That's the defensible position. It's achievable, it costs a fraction of full retrofit, and it satisfies the regulator. And if the scope still feels overwhelming, triage it — highest-consequence systems first, the rest on a defined schedule. Documented, prioritised, and progressing is the position the law actually wants.

3. The management gaps are bigger than the technical ones.

If you take one thing from this, take this: the technical assessment of a legacy SIS is the easier half of the work. Establishing whether a hardwired trip system achieves a given probability of failure on demand is standardised methodology — the maths works whether the equipment is two years old or twenty.

The harder part is everything around the equipment. The functional safety management system that should wrap the hardware. The competency records for the people operating, testing and maintaining it. The Management of Change records that should track every modification since installation. The proof test procedures that should be updated against current operational reality. Most legacy systems I've reviewed have substantial gaps in this management layer even when the engineering is solid — maintained but with inconsistent records, modified but with partial documentation, a proof test procedure signed off as current but last updated in 2009.

These aren't the failures that cause an immediate hazard. They're the failures that stop you demonstrating the system is being managed under control — and under the standard, that's the same problem. Assess the management system with the same rigour as the engineering. A documented-but-unmanaged system isn't defensible; a managed-but-undocumented one isn't either. You need the documentation, the records, and the active management chain, all aligned around the system as it operates today.

The common thread

Legacy SIS create disproportionate anxiety not because the underlying risk is necessarily higher, but because the lack of evidence makes any potential failure feel more exposing. You're not just worried about the system failing — you're worried that if it does, you won't be able to show you were managing it properly.

The three points above resolve that: legacy means missing evidence, not failing hardware; build a defensible, ALARP-based position, not full retrospective compliance; and assess the management system as rigorously as the engineering, because that's where the gaps usually are.

Three things you can do this week: pull the inventory and document what's installed and when; pick the highest-consequence system and check whether you have a current hazard analysis for it; and look at your FSMS — not the technical work, the management system — because if it doesn't exist or doesn't cover legacy systems, that's the foundation everything else builds on.

That last one is where the ROAK Engineering FSMS Templates come in — IEC 61508 / 61511-aligned procedures, templates and registers designed to plug into your existing QMS rather than replace it. The Project-Ready tier covers the procedures most relevant to legacy assessment: hazard analysis, SIL verification, management of change, proof test, and the SIF register. And if you need dedicated help with a specific legacy assessment, that's the independent technical authority role I do directly — book a call and we'll talk it through.