Functional Safety Assessment (FSA) vs. Audit: What’s the Difference?

Last updated June 15, 2026

A functional safety assessment (FSA) and a functional safety audit get treated as the same thing in conversation, in scopes of work, in audit findings. They are not. The two are easy to confuse, and the mix-up is common, but they answer different questions, happen at different points in the life-cycle, and carry different obligations under IEC 61511.

An FSA is a design and engineering activity that judges whether the required functional safety was actually achieved. An audit is an operations activity that checks whether you followed your own procedures. Confuse them, and a facility can pass one while wrongly believing it has satisfied the other.

What a functional safety assessment is

A functional safety assessment is an evidence-based investigation that judges the functional safety achieved by a safety instrumented system (SIS) and any other protection layers it relies on. It confirms the engineering was done properly and the required risk reduction was actually reached. In IEC 61511 it lives at Clause 5.2.6.1.

An FSA is a design and engineering activity, and most of the effort lands in the design and installation phases, where the SIS is being built and an independent look has the most leverage. The question an FSA answers is about the result: was the required functional safety achieved, and does the evidence behind it hold up.

There are five FSA stages spanning the life-cycle, from just after the hazard and risk assessment (H&RA) through to decommissioning. Each happens at the boundary between blocks of work rather than continuously.

Two things sit at the center of a credible FSA:

Competence. The team has to be competent for the application, carrying the technical, application, and operations expertise the system demands. This is the requirement companies most often back with formal functional safety certification, a TÜV functional safety engineer certificate or a Certified Functional Safety Expert (CFSE) credential, as documented evidence the assessor is qualified.
Independence. The assessment has to be led by someone senior who was not part of the team that did the work. Independence does not mean a third party by default; in practice it scales with the risk. A highly standardized change at a low safety integrity level (SIL) can be judged by someone from elsewhere in the organization, while a high-SIL or first-of-a-kind design pushes toward a fully independent or third-party assessor.

Independence is where many operators get stuck. Small and mid-size firms often do not have enough qualified people to assemble a team genuinely separate from the one that did the design or runs the plant. That is why facilities so often hand both their FSAs and their audits to an outside consultancy: a firm like SIL Safe sits outside the project and operations teams by definition, which is the cleanest way to clear the independence bar, particularly on higher-SIL or first-of-a-kind work.

Companies may split a stage into two where it helps, an early Stage 1 around the first P&IDs and a later one once supplier details firm up, or a Stage 3 split across installation and site acceptance testing. That adds assessments; it does not change the five-stage framework.

What a functional safety audit is

A functional safety audit, usually just called an audit, is a systematic, independent examination of whether your functional safety procedures match the plan, are being implemented, and are working. In IEC 61511 it lives at Clause 5.2.6.2. In practice an audit reviews documents and records to confirm your functional safety program is in place, current, and being followed.

If you have sat through an ISO 9001 quality audit or a nuclear program audit, you already know the shape of it. Someone independent checks that you have the procedures, that they say what you claimed they say, and that you are doing what they describe. They are not judging whether the design is any good.

An audit does not judge whether functional safety has been achieved; that judgment belongs to the FSA. An audit also cannot run until the procedures exist to audit against, which makes it an operations-phase activity, working from training and competency records, management of change, proof-test records, and maintenance logs.

The standard sets no fixed audit interval. How often you audit is generally the program’s decision, set in the functional safety management program. Some jurisdictions impose a floor: in the US, OSHA Process Safety Management (PSM) and EPA Risk Management Program (RMP) require a program compliance audit at least every three years, and the functional safety one usually rides along with it. Other regimes, COMAH in the UK and Seveso across the EU, set their own expectations.

On a large program, audits scale by splitting rather than swelling: one auditor takes the training program, another management of change, another proof-test records, instead of one monolithic pass.

Assessment vs. audit: the core difference

Take the functional safety assessment first, since it comes earlier in the life-cycle:

An FSA evaluates the work products and conclusions. Is the result actually safe? Did the H&RA and layer of protection analysis (LOPA) classify the risk correctly? Does the analysis hold up? It answers “did you get the right outcome?”
An audit evaluates the process. Did you follow the defined steps, in order, with the right inputs, outputs, and competencies? It answers “did you work the right way?”

The two overlap in operation, where assessing a phase is largely a matter of examining whether procedures are being followed. What keeps them distinct is the question each ultimately answers, and the fact that the independence requirement attaches to the FSA.

Dimension	FSA	Audit
What it examines	Whether the required functional safety was achieved (the result)	Whether your procedures are being followed (the process)
Core question	Has the required functional safety been achieved?	Are the procedures being followed?
Primary life-cycle window	Design and installation	Long-term operations
Independence basis	Senior competent person off the team that did the work; third party scales with risk	Independent person not working on the SIS
Frequency	Tied to life-cycle milestones	Program’s decision (US regulations: at least every three years)
Typical evidence	Safety requirements specification (SRS), SIL verification, validation results	Records, procedures, competency, change logs

Where each sits in the life-cycle

Both activities sit under the management of functional safety in IEC 61511, Clause 5, but they enter the life-cycle at different points and for different reasons.

Functional safety assessments

Each functional safety assessment sits at a phase boundary. A block of work, design, installation, or commissioning, is finished, an independent assessor judges it, and only then does the project move to the next phase or to startup. The five stages, by the phase each one follows:

Stage 1: after the H&RA, once the protection layers are identified and the SRS is developed
Stage 2: after the SIS is designed
Stage 3: after installation, pre-commissioning, and final validation, the pre-startup FSA
Stage 4: after operating and maintenance experience has been gained
Stage 5: after a modification, and before decommissioning

Of these, only the pre-startup FSA at Stage 3 is a hard, point-in-time requirement, due before the identified hazards are present, which in practice means before the process material or gas is introduced. A periodic FSA during operation is also required, and a modification triggers its own. The rest, and the depth of each, are a planning decision.

Audits

An audit is not a gate the way a functional safety assessment is. It recurs through the operating life at whatever interval the program sets, and its findings feed back as improvements to the program.

Common mistakes

Merging the two concepts, treating one as if it discharges the other. A facility runs its functional safety assessments and assumes that covers the audit, or runs faithful audits and never commissions an FSA. They are separate obligations; doing one does not satisfy the other.
Not having the functional safety management plan (FSMP) define how FSAs and audits get done. The FSMP should be the thing that sets how your assessments and audits are run, at what stages, in what depth, with what independence, and how often, within a single project, across the projects in your program, and over the life of the SIS. When that is missing, each one gets scoped ad hoc, and the inconsistency is what an audit flags.
Treating the SIL verification calculation as the FSA. The probability of failure on demand average (PFDavg) and risk reduction factor (RRF) numbers are an input the FSA reviews, not the assessment itself.
Using reviewers who are not independent of the team that did the work. The reverse error shows up too: paying for a third-party assessor on a low-SIL, standardized change where a competent in-house reviewer would have met the requirement.

Common questions

Q1: An audit sounds a lot like a verification, and verification sounds like a validation. What’s the actual difference between an audit, an assessment, a verification, and a validation?

Four different things, and the quickest way to keep them straight is what each one looks at:

Verification is the per-phase check that the outputs of a phase meet the requirements set for it: did the design meet the SRS, does the SIL verification show the target is met.
Validation is the big end-to-end proof, done before startup, that the installed SIS does what the SRS says in every respect.
A functional safety assessment is the independent judgment that functional safety was achieved across the relevant phases, leaning on the verification and validation results as evidence.
An audit checks whether you followed your procedures, not whether the system is any good.

The first three judge the system; the audit judges the process.

Q2: Our SIS has run for 10 years with minimal changes and no real problems. We’ve kept up our audits but never done a functional safety assessment since the original design. Is that okay?

Likely not. The standard expects a periodic FSA during operation, not just audits. Your audits confirmed you were following your procedures, which is worth something, but nobody has stood back and judged whether the SIS still achieves its required risk reduction against ten years of actual proof-test results, real demand history, and field failures. That is what an operational FSA is for, and you are most likely overdue. “Minimal changes” is doing some quiet work in that sentence, too: any modification over those ten years should have triggered its own FSA at the time.

Q3: A consultancy we used ran our functional safety assessments and audits together as one exercise. You’re telling me they’re different things, so did we get it wrong?

It is probably fine. Running them together is common and usually sensible, for a couple of reasons:

The two genuinely overlap, especially once you are in operation, where assessing a phase is mostly a matter of checking that procedures are being followed.
IEC 61511 lets an audit be carried out as part of an FSA, so folding them into one mobilization is efficient rather than wrong.

The one thing worth checking is independence. It attaches to the assessment, so if what they called an “assessment” was really a procedure-conformance checklist run alongside your design team, you got an audit with an assessment’s label on it, and that falls short on the independence an FSA requires.

Q4: How much operating experience do we need before the first operational functional safety assessment, and how often after that?

There is no fixed number in the standard, and that is deliberate. The real gate is data, and data takes time to accumulate. An operational FSA earns its keep by testing the assumptions the design was built on, the demand rates, the failure rates, the protection-layer effectiveness, and you can only test those against what the plant actually produces: the demand signals the SIF has seen, and completed proof tests. Demands are usually rare, and proof tests only come around on the proof-test interval (TI), so you need enough operating time behind you to have a meaningful set of both. Run the first one too early, with almost no demands logged and barely a proof test done, and there is nothing to assess. After that, the periodic FSA tends to land somewhere around every one to three years, usually pinned to whatever audit or hazard-study revalidation cycle the site already runs, and it is also triggered whenever new hazards turn up or the system is modified.

Q5: We’re a small facility with only a handful of safety instrumented functions (SIFs). Do we really need all this assessment and audit overhead?

Yes, but scaled to your risk. The effort scales with the same planning parameters as everything else, so a small, low-SIL, standardized site does less, and does it with a documented rationale, rather than nothing. The pre-startup functional safety assessment and the periodic operational FSA still apply; they are just lighter in scope. At low SIL you can usually meet the independence requirement with a competent reviewer from elsewhere in your own organization instead of an outside firm. “Small” changes the size of the exercise, not whether you do it.

Q6: We inherited an old SIS that never had a formal functional safety assessment. Where do we start?

With an operational FSA, the Stage 4 kind, which reviews all the prior life-cycle stages at once for a system that is already running. You are not going to reconstruct a greenfield paper trail that was never created, and you do not need to. You assess what is actually in front of you against the design intent, demand rates, failure history, proof-test results, and how well the protection layers are performing, and you work the gaps from there. Guidance written specifically for installed and legacy systems, like the CDOIF functional safety management guideline, is built around exactly this situation.