BLOG

How to Choose a Functional Safety Consultant: A Buyer's Guide for Industrial Operators

Choosing a functional safety partner is one of the higher-consequence procurement decisions an industrial operator makes. The provider you select shapes how your Safety Instrumented Systems are specified, how your risk reduction targets are set, and whether the documentation you hand a regulator three years from now actually holds up under scrutiny.

The difficulty is that the functional safety market looks far more uniform than it is. Open five provider websites and you will find the same service names on all of them: HAZOP facilitation, SIL determination, Safety Requirement Specifications, Functional Safety Assessments. The labels match. What sits behind them varies enormously, and the differences only surface once you are mid-engagement.

This guide breaks down the four types of functional safety provider operating in the market today, the seven criteria that genuinely separate them, and the one question most operators do not think to ask until it is too late to matter.

A note on why this matters more than it used to: IEC 61511 Edition 2 formally brought cybersecurity into the functional safety standard, requiring that security risks to Safety Instrumented Systems be identified and addressed within the safety lifecycle rather than handled separately by an IT function. Source: IEC 61511-1 Edition 2. That single change redrew the map of what a competent functional safety partner needs to be able to do.

The Four Types of Functional Safety Services Provider

Almost every provider in this market falls into one of four categories. Each has a genuine strength and a structural constraint that comes with it. Knowing which category a provider sits in tells you more about the engagement you are about to buy than any capability list on their website.

1. Certification Bodies

Organisations whose core business is certifying products, personnel, and processes against IEC 61508, IEC 61511, and related standards. They bring assessment rigor and recognised credentials, and their reports carry weight with regulators.

The constraint is independence. A body that certifies your system frequently cannot also design or implement it, which means you need a second provider for the engineering work. The handoff between the assessor and the implementer is precisely where requirements get lost, and lifecycle documentation develops gaps.

2. Automation Vendors

Control system manufacturers offering functional safety services alongside their own DCS, PLC, and logic solver hardware. They know their products in depth, and for a facility standardised on a single vendor platform that knowledge is real.

The constraint is a conflict of interest that becomes acute during SIL verification. When the conclusion of an assessment may point toward hardware replacement, an assessment conducted by the company that sold you the hardware is difficult to treat as independent, and some regulators will say so.

3. Independent Process Safety Consultancies

Specialist firms focused on process safety and functional safety, usually staffed by chemical and process engineers. They tend to be strong on lifecycle depth, LOPA methodology, and regulatory alignment with frameworks like OSHA PSM.

The constraint is that most have no operational technology cybersecurity capability at all. Under IEC 61511 Edition 2 that is no longer a peripheral gap, because cyber risk to a Safety Instrumented System is now a functional safety concern that the standard expects the safety lifecycle to address.

4. OT Cybersecurity Firms

Providers focused on ISA/IEC 62443, network segmentation, and industrial threat detection. They understand how an attacker moves through a control network and how to stop it.

The constraint is the mirror image of the previous category. Most treat the Safety Instrumented System as one more asset to protect rather than a safety function carrying its own integrity requirements. Few can run a SIL determination, and fewer can conduct a Functional Safety Assessment that a regulator will accept.

Provider Type	Core Strength	Structural Constraint	Best Suited To
Certification body	Assessment rigor and recognized credentials	Independence rules limit implementation work, creating a handoff gap	Final-stage third-party assessment
Automation vendor	Deep product-specific knowledge of their own platform	Conflict of interest during SIL verification and hardware decisions	Platform-specific engineering support
Process safety consultancy	Lifecycle depth, LOPA methodology, regulatory alignment	Typically no OT cybersecurity capability in the team	Classic process safety with no connected systems
OT cybersecurity firm	Network segmentation, threat detection, IEC 62443	Cannot perform SIL determination or a defensible FSA	Securing the control network around the SIS
Integrated safety and security practice	Full safety lifecycle plus native OT cybersecurity in one team	Smaller field of providers; verify both capabilities are genuinely in-house	Connected plants where cyber risk reaches the SIS

Seven Criteria That Actually Separate Providers

Once you know which category a provider belongs to, these seven criteria will tell you whether they are the right fit for your facility. Ask each one directly during evaluation, and note that several of them are uncomfortable questions. That is the point.

1. Independence from the hardware being assessed

If the provider assessing your Safety Instrumented System also sells the logic solver inside it, the assessment carries a conflict. Ask whether the provider has any commercial relationship with the equipment in scope, and how they manage it.

2. Coverage across the full safety lifecycle, not a single stage

Many providers are excellent at one stage. They facilitate a strong HAZOP, or they run a rigorous SIL determination, and stop there. Every handoff between providers is a place where requirements get lost in translation. Ask which lifecycle stages the provider covers directly with its own staff, from hazard identification through Safety Requirement Specification, validation, proof test procedures, and Functional Safety Management documentation.

3. Verifiable personnel competence

IEC 61511 expects demonstrable competence from the people performing safety lifecycle activities. Ask for named certifications held by the specific engineers who will work on your site, not the credentials of the firm in general. A certified functional safety expert on the sales call and an uncertified junior on site is a common and avoidable outcome.

4. Cybersecurity capability inside the same team

This is the criterion the market has not caught up with. Ask who assesses cyber risk to your Safety Instrumented System, and whether that person sits in the same team as the safety engineers or in a separate practice that will be engaged under a separate contract. The answer tells you whether safety and security findings will ever be reconciled with each other.

5. Documentation designed for audit, not for the shelf

Functional safety documentation has one real test: it must be defensible to a regulator or third-party assessor years after the engagement ends. Ask to see a redacted sample deliverable. Look for traceability from hazard to safety function to requirement to verification evidence. If you cannot follow that chain in the sample, your auditor will not follow it in yours.

6. Sector experience matched to your process

Functional safety in a refinery, an automated production line, and a remote mine site involve different hazards, different regulatory expectations, and different operational constraints. Ask for engagements in your specific sector, not adjacent ones.

7. Knowledge transfer built into the engagement

The strongest indicator of a good partner is whether they leave your team more capable than they found it. Ask whether the engagement includes structured handover, training, and documentation your own engineers can maintain, or whether the deliverable is a report that only the provider can update.

The Question Most Operators Forget to Ask

Of those seven criteria, one is consistently overlooked, and it is the one where the market has shifted fastest.

Who is responsible for cyber risk to my Safety Instrumented System, and do they sit in the same team as my safety engineers?

For most of the history of this discipline the answer did not matter much. Safety systems were air-gapped, proprietary, and largely unreachable. That is no longer the environment most operators run. IT and OT convergence, remote vendor access, and connected historians have put routable pathways into places that were previously isolated.

The Triton attack made the consequence concrete. It targeted safety controllers directly, with the potential to disable the exact protective function a plant relies on when a process goes out of control. A cyberattack that defeats a Safety Instrumented Function is not an IT incident with an operational side effect. It is a functional safety failure delivered through a different route.

IEC 61511 Edition 2 responded by bringing cybersecurity inside the functional safety standard, requiring security risks to safety systems to be identified and managed as part of the safety lifecycle. In practical terms, that means an operator running a combined safety and security program is not going beyond the standard. An operator running them as two disconnected workstreams is falling behind it.

Yet the market remains split. Process safety consultancies rarely staff OT cybersecurity engineers. OT cybersecurity firms rarely employ certified functional safety practitioners. When both are engaged, they are usually separate contracts producing separate reports on separate timelines, and nobody owns the space between them.

Five Red Flags During Evaluation

A capability list with no named people. If a provider cannot tell you which certified engineer will lead your assessment, you are buying a brand, not a competence.
Safety and security quoted as entirely separate engagements. This usually signals two teams that do not work together, and findings that will never be reconciled.
No sample deliverable available, even redacted. Providers confident in their documentation will show you what it looks like.
A fixed methodology applied regardless of process. LOPA, risk graphs, and quantitative methods each suit different situations. A provider who always uses one has stopped choosing.
Deliverables your own engineers cannot maintain. If updating the SIL calculation next year requires re-engaging the provider, you have bought a dependency rather than a capability.

How Arista Cyber Is Structured

Arista Cyber was built as an integrated functional safety and OT cybersecurity practice, because the standards moved in that direction and the market largely did not follow.

Our functional safety services cover the full lifecycle rather than a single stage: HAZOP and HAZID studies, SIL assessment and determination, Safety Requirement Specifications, safety validation and verification, proof test procedures, RAMS studies, Functional Safety Management documentation, and Functional Safety Assessments across FSA 1 to FSA 5. We are independent of automation hardware vendors, so an assessment that concludes your logic solver needs replacing is not a conclusion we have a commercial interest in reaching.

The part that is harder to replicate is the second half. Our functional safety engineers and our OT cybersecurity engineers work in the same practice, aligning IEC 61511 with ISA/IEC 62443 in a single program. When a cyber pathway to a safety function is identified, it is assessed against the safety consequence, not filed as a network finding for a different team to interpret months later.

Every engagement is scoped to leave documentation your own engineers can maintain and defend, because functional safety is a lifecycle obligation rather than a project that finishes.

Evaluation Criterion	How Arista Is Structured Against It
Hardware independence	No automation hardware sold. No commercial interest in the outcome of a SIL verification.
Full lifecycle coverage	HAZOP and HAZID through SIL, SRS, validation, proof testing, RAMS, FSM documentation, and FSA 1 to 5.
Personnel competence	Certified functional safety practitioners named to each engagement, with TUV Rheinland-accredited training delivered in-house.
Cybersecurity in the same team	IEC 61511 and ISA/IEC 62443 run as one program. Cyber pathways to safety functions are assessed against safety consequence.
Audit-ready documentation	Traceable from hazard to safety function to requirement to verification evidence, built for third-party assessment.
Sector experience	Oil and gas, energy and utilities, manufacturing, pharmaceuticals, automotive, and mining.
Knowledge transfer	Structured handover and training so your engineers can maintain the safety case without re-engaging us.

Frequently Asked Questions

What should I look for in a functional safety consultant?

Look for independence from the hardware being assessed, coverage across the full safety lifecycle rather than one stage, named certified engineers assigned to your engagement, audit-ready documentation you can inspect before signing, sector experience matching your process, and cybersecurity capability inside the same team. That last point matters because IEC 61511 Edition 2 brought security risk to Safety Instrumented Systems inside the functional safety standard.

What is the difference between a certification body and a functional safety consultancy?

A certification body certifies products, personnel, and processes against standards such as IEC 61508 and IEC 61511, and independence rules often prevent it from also designing or implementing the systems it certifies. A functional safety consultancy delivers the lifecycle engineering work itself. Many operators need both, and the handoff between them is where lifecycle documentation most often develops gaps.

Should my functional safety provider also handle OT cybersecurity?

Under IEC 61511 Edition 2, cyber risk to a Safety Instrumented System is part of the safety lifecycle rather than a separate IT concern. Engaging separate providers is workable, but it produces two reports on two timelines with no body owning the space between them. A provider with both capabilities in one team reconciles safety and security findings against a single consequence model.

How do I verify a provider's functional safety competence?

Ask for the certifications held by the specific engineers assigned to your site, not the credentials of the firm. Ask for a redacted sample deliverable and trace the chain from hazard through safety function, requirement, and verification evidence. Ask for engagements in your specific sector. A certified functional safety expert on the sales call and an uncertified engineer on site is a common outcome that these questions prevent.

How long does a functional safety engagement take?

It depends entirely on scope and facility complexity. A single-system SIL assessment can often be completed in a few weeks, while a full lifecycle program across multiple safety systems runs considerably longer. Any provider quoting a fixed duration before understanding your process should be asked what assumptions that estimate rests on.

Talk to a Functional Safety Expert

If you are evaluating functional safety providers, we are happy to be one of the options you assess against the criteria above. A free 30-minute consultation with one of our senior safety engineers will give you a clear view of where your current safety lifecycle documentation stands and what a practical starting point looks like.

Book Your Free Consultation