A safety instrumented system passes through many hands, hazard study, requirements, design, installation, before it ever protects anyone, and each handoff is a chance for an error to slip through unnoticed. A functional safety assessment is the formal, independent check that catches those errors at defined points in the lifecycle. It is a judgement that the system actually meets its safety requirements, made by people independent enough to say no, and carried out at stages chosen so problems are found before they become expensive. It is distinct from ongoing safety management and from a pre-startup review, though it overlaps with both.
Functional safety assessment (FSA) in one line: A functional safety assessment (FSA) is a formal, independent judgement, made at defined stages of the safety lifecycle, that a safety instrumented system meets its functional safety requirements. It is carried out by people with an appropriate degree of independence from the design, and it is broader and more judgement-based than a routine procedural audit.
The purpose of a functional safety assessment is to reach an informed judgement about whether a safety system, at a given point in its life, has been developed correctly and will do what it is supposed to. That is a broader question than checking boxes. The assessor examines whether the hazards were properly understood, whether the safety requirements captured what the hazards demanded, whether the design and implementation faithfully deliver those requirements, and whether the evidence, the calculations, tests, and records, actually supports the claims being made.
Independence is central. An assessment carried out by the same people who did the design tends to reproduce their blind spots, so the standards require a degree of independence proportionate to the risk. For lower-consequence systems, an independent person within the same team may suffice; for higher-consequence systems, independence extends to a separate department or an outside organization. The point is that the assessor must be free to raise objections without their own work or reputation being on the line.
An FSA produces findings and a judgement, not just a signature. It documents what was examined, what gaps or concerns were found, and what must be resolved before the system can proceed to the next stage. Because it is a judgement, the competence of the assessor matters as much as their independence; the assessment is only as good as the person's ability to recognize a weak reliability calculation or an unjustified assumption when they see one.
The standards describe several assessment stages spread across the lifecycle, and the value of an FSA comes largely from doing it at the right moments rather than only at the end. A common set of recommended stages runs roughly as follows: after the safety requirements have been developed, to confirm they correctly reflect the hazard and risk analysis; after the design is complete, to confirm the design meets those requirements; before startup, to confirm installation, commissioning, and validation were properly done and the system is fit to operate.
The lifecycle does not stop at startup, and neither do the assessments. A further stage is recommended after the system has accumulated operating and maintenance experience, to check that the assumptions made during design, failure rates, test intervals, demand rates, are holding up in reality and that the system is being maintained as intended. And any significant modification triggers an assessment of the change, because a modification can undermine the integrity that the original assessments established.
Not every project performs every stage as a separate formal event; the standards allow the stages to be combined or scaled to the risk and complexity of the system. What matters is that the intent is met: that an independent judgement is made at the points where errors are most likely and most consequential, and that no safety system reaches operation without at least the pre-startup assessment confirming it is ready. Spacing the assessments across the lifecycle is what lets problems be caught while they are still cheap to fix.
It is easy to confuse a functional safety assessment with the related activities around it, but they answer different questions. A functional safety audit checks whether procedures were followed, a compliance question: did the team do the steps the management system requires? An FSA is a judgement about the outcome: regardless of whether procedures were followed, is the resulting safety system actually adequate? An audit can pass while an assessment fails, if correct procedures still produced a flawed system, and vice versa.
Functional safety management, or FSM, is the overall framework of planning, competence, procedures, and records within which safety work happens; the FSA is one activity that FSM plans for and requires. A pre-startup safety review, or PSSR, is a broader operational readiness check covering the whole facility before startup, of which safety-instrumented-system readiness is only one part. The pre-startup FSA stage feeds into that review but is narrower and deeper on the safety system specifically.
For an operator, the practical distinction is about what evidence each activity consumes and produces. An assessment leans heavily on the accumulated record of the system: the requirements, the verification results, the test histories, the operating experience. A cloud SCADA platform that has been capturing demands, trips, proof-test results, and maintenance events across the operating life supplies exactly the operating-experience evidence the later-stage assessments need, turning the after-experience FSA from a reconstruction exercise into a review of records already in hand.
An audit checks whether procedures were followed, a compliance question. An assessment judges whether the resulting safety system is actually adequate, an outcome question. A system can pass an audit yet fail an assessment if correct procedures still produced a flawed design, so the two activities catch different kinds of problem and are not interchangeable.
Commonly recommended stages are after the safety requirements are developed, after the design is complete, before startup, after the system has gathered operating experience, and after any significant modification. The stages can be combined or scaled to the risk and complexity of the system, but the pre-startup assessment confirming readiness to operate should not be skipped.
Someone with appropriate competence and a degree of independence proportionate to the risk. For lower-consequence systems that may be an independent person within the same team; for higher-consequence systems it extends to a separate department or an outside organization. The assessor must be free to raise objections without their own work being on the line.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.