SIF, SIS and BPCS: What Each One Is and Why Confusing Them Costs You at Assessment

Three acronyms that appear constantly in functional safety documentation and get used loosely in conversation. The distinction is not academic: it determines what you can claim as protection, and misapplying it is one of the most frequent reasons risk reduction credit gets removed during review.

In short: a SIF is a single protective function, a SIS is the system that executes SIFs, and a BPCS is the control system that runs the process normally. If you need the wider framework first, see our guide to functional safety standards.

 

The Three Defined

 

Term	What It Is	Example
SIF — Safety Instrumented Function	One protective function: a specific sensor, logic and final element acting to prevent one hazard	High pressure in a vessel closes the inlet valve
SIS — Safety Instrumented System	The system implementing one or more SIFs, including all sensors, logic solvers and final elements	The dedicated safety controller and its field devices
BPCS — Basic Process Control System	The control system that operates the process normally and holds it at setpoint	The DCS or PLC running day to day production

 

A SIL is assigned to a SIF, not to a SIS and not to a device. A statement that a system is SIL 2 is imprecise, and a device certified to SIL 2 is capable of being used in a SIL 2 function rather than conferring that rating on it. This precision matters at assessment.

 

Why the BPCS Distinction Costs Money

The BPCS runs the process. The SIS protects against the process going wrong, including when the BPCS is the thing that went wrong. Keeping them separate is the reason the architecture exists.

In LOPA, credit for an independent protection layer requires independence from the initiating cause and from other credited layers. Three errors recur:

• Crediting the BPCS when it is the initiating cause. If the hazard arises from a control loop failure, the same system cannot be credited as protection against it.
• Crediting the BPCS twice in one scenario. It is a single system with shared elements. Two control loops within it are not two independent layers.
• Crediting a vendor package as a protection layer. A packaged control system supplied without failure data or an integrity claim does not meet the auditable and known integrity criteria. This is a particular problem with battery management systems on energy storage projects.

Removing a wrongly claimed credit is not a paperwork correction. It changes the calculated risk gap, which can raise the SIL target for the function and occasionally across the facility.

 

Where the line gets blurred in practice Modern integrated control and safety systems present the BPCS and SIS through a common interface and sometimes share engineering tooling. That integration is permitted, but it makes the independence question harder to answer and easier to get wrong. If the same engineering workstation can modify both the control logic and the safety logic, the independence claim needs examining rather than assuming. This is also the pathway the TRITON malware exploited.

 

What This Means for Your Documentation

• Each SIF documented individually, with its own hazard scenario, SIL target, and verification calculation. A document covering the SIS as a whole is not a substitute.
• The safety requirements specification written per function, defining what each SIF does, its safe state and its response time. Covered by our SRS service.
• BPCS and SIS separation evidenced, through architecture documentation showing the boundary and what crosses it.
• Protection layer credits justified, each with a stated basis for independence and integrity.
• Integrity of the safety logic protected, which is where functional safety meets control system integrity.

 

Why Choose Arista Cyber

Arista Cyber works across both functional safety and OT cybersecurity, which is directly relevant here because the BPCS and SIS boundary is simultaneously a safety architecture question and a security one.

We assess protection layer claims against the criteria that will be applied at review rather than the ones that are convenient, which means fewer credits removed later. We deliver SIL determination and verification per function rather than per system, so documentation matches what assessors examine. And where the SIS shares engineering infrastructure with the BPCS, we can address the IEC 61511 and IEC 62443 requirements together.

 

Next Steps

If your documentation treats the SIS as a single unit rather than a set of individually specified functions, that will surface at assessment. Explore our functional safety services, read about how SIL targets are set, or contact the Arista Cyber team.

 

Common Questions

Can a BPCS ever be credited as a protection layer?

Typically once per scenario, and only where it is genuinely independent of the initiating cause. Where the hazard arises from a BPCS failure, it cannot be credited as protection against itself. Crediting it more than once in the same scenario is not independence, since it remains a single system with shared sensors, logic and final elements.

Is SIL assigned to a device or to a function?

To a function. A device can be certified as suitable for use in a function of a given SIL, which addresses its systematic capability and failure data, but the SIL belongs to the safety instrumented function as a whole: sensor, logic solver and final element together. Our guide to SIL verification covers how the loop calculation works.

Should the SIS be on a separate network from the BPCS?

Yes. Separation is both a functional safety and a cybersecurity requirement, and the interface between them should be strictly controlled so unauthorized commands cannot pass from the control layer into the safety layer. Our guide to IEC 61511 and IEC 62443 together covers the architecture.

 

Are your protection layer credits defensible? Arista Cyber assesses SIF documentation and protection layer claims against the criteria applied at review, not the convenient ones. Book a Free Consultation