The latest episode (S1E18) of the Kenexis Functional Safety Podcast is now available on Spotify and Apple Podcasts

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E18 TRANSCRIPT (Markdown)
Cleaned & reflowed for web publication and AI crawlability.

The JSON-LD block below is schema.org structured data. If your CMS lets you
add raw HTML to a post, paste it into the page (or anywhere in the
body — crawlers read it either way). Fill in PLACEHOLDER_EPISODE_PAGE_URL
once the post exists. Everything from the "# Kenexis Functional Safety
Podcast…" heading down is the transcript body — paste it into your post.
–>

"`html

"`

# Kenexis Functional Safety Podcast — Season 1, Episode 18: IEC 61511, Clauses 8.2.2–8.2.4 (BPCS Failure Limits, Traceability, and Security Risk Assessment)

—

## Introduction and Disclaimer

The basic process control system begins to complicate our risk analysis starting all the way in hazard and risk assessment.

Welcome to the Kenexis Functional Safety Podcast. I'm your host, Ed Marszal, President and CEO of Kenexis. Kenexis is a technical safety consultancy that helps chemical process industry companies to analyze risk and design engineered safeguards like safety instrumented systems and fire and gas detection systems. Kenexis also provides the industry-leading suite of software tools, including our best-in-class Vertigo software for SIS safety lifecycle management.

In this first season of the podcast, we are going to focus on the IEC 61511 standard, doing a deep dive into the standard, including more depth of information on what the standard means and how to apply it, brought to life with personal war stories and behind-the-scenes discussions of the committee members as we develop the standard in ISA 84 and IEC SC 65.

Before we start, a little disclaimer. I will be providing my opinion on technical and engineering topics. This information is provided on a best-effort basis and is of a general nature. The information presented in this podcast might not be applicable to your specific application. It is the obligation of every engineer to thoroughly analyze any system that they are designing and not blindly rely on any general advice presented in this podcast.

## Clause 8.2.1 Recap and H&RA Outputs

Okay, so when we left off last week, we were in Clause 8, which is Hazard and Risk Analysis. So let's do a little bit of recap before we continue on.

So Hazard and Risk Analysis is the first of two parts you can consider. The first of two parts to end up with that list of safety functions and the targets for how good those safety functions need to be, the SIL targets. In Clause 8, Hazard and Risk Analysis, we're identifying the hazard scenarios, looking at consequences and likelihoods, and identifying those scenarios where there's a gap between where risk should be, the tolerable risk, and where it actually is.

And once we identify those gaps, we're then going to be able to close those gaps with independent protection layers, which may or may not include safety instrumented functions.

So Clause 8, we're going to define what the gap is, and then Clause 9 is where we're going to close the gap. And once again, these clauses are really geared toward laying out what the instrumentation and control engineer needs to do their job, to do the rest of the safety lifecycle that comes out of the hazard and risk assessment, as opposed to informing the PSM people how to do their job. So Clause 8.2.1, and we spent the entire episode last week basically covering that clause. I'm going to summarize once again what is contained inside those clauses.

So if you look at Clause 8.2.1, it says H&RA shall be carried out on the materials, processing equipment, and it shall result in six bullet points. So what those bullet points are again, number one, a description of each identified hazardous event and the factors that contribute to it. Bullet point two, a description of the likelihood and consequence of each hazardous event. Bullet point three, a consideration of other operating modes like normal operations, startup shutdown, maintenance, process upset, and emergency shutdown.

Bullet point four, the determination of any additional risk reduction necessary to achieve the required functional safety. Next bullet point, a description of or references to information on the measures taken to reduce or remove the hazards and risks. The next bullet point being a detailed description of the assumptions made during the risk analysis, blah, blah, blah. And then finally, the last bullet point being an identification of those safety functions applied as SIF.

So if we kind of boil down all of last week's discussion, coming out of the hazard and risk assessment, we need a list of the hazardous events, specifically the ones where safety instrumented functions are or might be used, might be considered to be a safeguard to get you to a tolerable level of risk. For all those events, and we need them for all modes of operation, we need to identify the hazardous events where there's a gap between where risk is now and where risk eventually needs to be. Because the purpose of clause nine, when we get there, is going to be to close that gap.

And then once we know all the events, we know the gaps, we're going to want information about how the PHA team came to their decisions about consequence and frequency. Specifically, kind of a breakdown of what the causes are, frequencies will happen in layer protection analysis. But the causes and the safeguards and any other factors that kind of develop into the overall risk.

And then finally, the last thing that you need is, if we are showing safety instrumented functions on the drawings, if we're showing safety instrumented functions that might be required to achieve tolerable risk, we need to make a list of what those safety functions are because we need to assign targets to those things. And that is all part of the hazard and risk analysis process.

## Clause 8.2.2 BPCS Failure Rate Limit

So now let's move on to the next clause. So we've talked about everything that the hazard and risk analysis needs to do. And we have all, you know, come up with a list of what we should have when it's done. There is one clause that we're going to get to next that kind of puts some handcuffs on what the hazard and risk analysis team is allowed to do. So as I mentioned previously, we don't really tell the PSM group how to do a HAZOP, how to do hazard and risk analysis. That is their area of expertise. We are the instrumentation and control people after all.

But we do place one limit on how they do what they do. So clause 8.2.1 tells us what we expect the outcome to be or what we expect the study to yield so that we could do our jobs. But in clause 8.2.2, we're going to put the clamp on the hazard and risk analysis process to make sure that they don't take excessive credit for something that is in our purview, which is the basic process control system. So clause 8.2.2, it's just one sentence, but the ramifications ripple out through industry every time anyone does a layer of protection analysis. This assumption gets questioned. It gets maligned.

Well, let's start off with, well, what is this requirement? So clause 8.2.2 states, the average frequency of dangerous failures of a BPCS as an initiating source shall not be assumed to be less than 10 to the minus 5 per hour.

Seems benign enough. But what does it really mean? Okay, so first off, let's take a look at that number. So 10 to the minus 5 is approximately once every 10 years, putting it into numerical terms that the PHA team is more used to dealing with. We don't, when we're doing a HAZOP, when we're doing LOPAs and risk analysis, we're generally not dealing with hours. We're generally dealing with years because we have human beings in these studies, and that's the time frame that they're going to be most comfortable with and makes the most sense when we're having these discussions.

Actually, there are 8,760 hours in a year, and the limit here is 10,000 hours, so it's actually a little bit more, or I'm sorry, 100,000 hours, which is a little bit more than 10 years. It's actually closer to 11 years. But most operating companies use that nice round number of 1 in 10 chance per year. So we're saying that the average frequency of dangerous failures of a BPCS shall not be assumed to be less than 10 to the minus 5.

So let's unpack a little bit more of this. What we're really talking about is there are a lot of hazards that are initiated by basic process control system failure. So if a control loop fails and that makes a valve go closed and the closure of that valve creates a hazard, that's an initiating source. That's an initiating event. So what we're saying is that when the risk analysis team looks at this initiating event, they're not allowed to say, oh, that control loop's only going to fail about maybe once in 50 years or once in 100 years.

There's a limitation of once in 100,000 hours or about once in 11 years. Let's call it once in 10 years for nice round numbers.

Number one, is that number realistic? It's really pessimistic, to be honest. If every control loop that you have in your plant failed once every 10 years. So let's say you have 100 control loops in your plant, which would be a really small plant. That means you're going to have 10 failures per year. So once every month or so, you're going to have a control loop failure that's going to cause your plant to shut down. Is that actually what's happening in your plant? That seems a little bit on the pessimistic side. So it's conservative for sure.

So that might be not 50% confidence limit, but maybe 90% confidence limit or 99% confidence limit. So number one, we're putting in a very conservative assumption for how often control loops fail.

The other factor that goes, all right, so first factor was, well, we want to be conservative when we're limiting how much credit they can take for a basic process control system. We're saying, well, don't be overly optimistic about how good your control loops are. Of course, we kind of might have erred on the other side.

## BPCS Safety Critical Control Loop Implications

Now, the other thing that's baked into this is the definition of safety critical control loops. So the IEC 61511 standard does talk about preventive safety instrumented functions, but the standard is also written such that you can use this standard to design a safety critical control loop or a controller that must be reliable because if the control loop fails, that control loop failure will cause a consequence. So we can design safety critical control loops to achieve SIL targets just like safety instrumented functions.

And it just so happens that the lower limit of a SIL-1 safety critical control loop is 1 times 10 to the minus 5 per hour.

So from a very technical perspective, we're saying, hey, if you're crediting your control loop to be better than having a failure rate of better than 1 times 10 to the minus 5 per hour, you're actually claiming that it is a SIL-1 or greater safety critical controller. And if it's a SIL-1 or greater safety critical controller, you need to design it that way. You need to follow all the requirements of the IEC 61511 standard for that loop.

You can't just assume that a controller is as good or better than a SIL-1 safety critical controller without doing the work to prove it. And without doing all of the administrative controls and the documentation of meeting and achieving compliance with the rest of the standard. So the limitation here, number one, we're kind of telling the PSM group a little bit of their business in terms of limiting how much credit they're going to be able to take. But we're also staking a claim to say, hey, if you're claiming better than 1 times 10 to the minus 5 per hour, that's a safety critical controller.

And you had better be following the IEC 61511 rules for how to design, maintain, operate, and test that safety critical control loop.

Okay, so that's the background there. Now, another item to look at is that word assumed. That's a very important, that's a very loaded word. Now, if you look at a typical LOPA, you're going to have a corporate standard, and that corporate standard is going to say, okay, for this control loop, or any time a basic process control loop fails, the probability or the frequency at which it's going to fail is X. And that is in the corporate standard.

Well, that corporate standard picked 0.1 per year, number one, to be compliant with this clause in the standard, but number two, to have a generic assumption for the performance of all control loops.

So when the corporate people put together that 0.1, they weren't specifically looking at one control loop, what its application is, what its service is, what the failure rates of the components are, how it's designed. Nobody did that. So when you're using that 0.1 that comes out of the LOPA standard, you're assuming that that control loop is going to be able to achieve that level of performance. And based on actual statistics and looking at random hardware failures, that assumption is usually quite conservative. Ninety-nineth degree of confidence on that number.

But another thing to think about when you're doing your hazard and risk analysis is that basic process systems are not very well controlled. Generally, you don't need to follow management of change procedures to implement a change to a basic process control loop. So the human factor failures are higher. Putting something in the manual, if it's a control loop, for instance, is something that's not controlled by MOC, but that could cause a dangerous failure of your system if there's a process upset. So there's a lot to consider in this.

And basically, most of industry has agreed that, yeah, 0.1 is probably an excessively pessimistic number. But considering the definition of a SIL-1 safety instrumented function, considering that there's a lot of management system issues with basic process control systems, we're generally willing to accept that number.

And if we're not willing to accept that number, we're not just going to assume a better failure. We're going to prove it with more detailed risk analysis. And we're also going to look at the design of any of these safety critical control loops to make sure that they're compliant with the IEC 61511 standard and designed and operated like a safety critical controller. So 8.2.2 probably gets more questions, more complaints is looked at more than any other clause in the standard. Because every time you do a LOPA, somebody's going to go, oh man, that control loop doesn't fail once every 10 years.

That's ridiculous. And, you know, you have to basically acknowledge that the person who made that statement is right. But we're going to use 0.1 because we have to account for human failures. And if we want to claim that it's better than that, we have a lot of work to do to prove that it's better than that, up to and potentially including nominating it as a safety critical control loop and designing it to a SIL target. All right. That's clause 8.2.2. One sentence resulted in about 15 minutes of discussion. So that's how important that one clause is.

## Clause 8.2.3 Traceability Requirements

Moving on to clause 8.2.3, which still we're talking about HNRA. So let's read clause 8.2.3, which says, the hazard and risk assessment shall be recorded in such a way that a relationship between the above items is clear and traceable. And when this sentence says the above items, we mean the bullet points in clause 8.2.1 primarily, but also 8.2.2 discussion of basic process control loop as an initiating event in your hazard and risk analysis.

So what do we mean by clear and traceable? That means when we do our hazard and risk analysis, we're going to have a report that documents the result of that hazard and risk analysis. And that report is going to have a lot of important information in it. And we need to be able to do our work based on that report and not have to call together the hazard and risk analysis team to answer questions when we're doing subsequent steps of the safety life cycle.

So we need to document all our initiating events. We need to document all our protection layers. We need to document our consequences, our likelihoods. And we need to be able to trace the information back to other sources when that happens.

So if we are going to assume that a relief valve provides us with two orders of magnitude of risk reduction, we should be able to trace back where that number came from, whether it came from a corporate standard, whether it came from an outside risk analysis, or whether it came just simply from the discussion of the team members, which is absolutely another completely valid source of information to do your hazard and risk analysis studies.

Okay, so clear and traceable. That report should contain everything. And, you know, honestly, you and I both have probably gone and seen a lot of really, really bad PHAs. And I hate to cast stones at other people PHAs because that opens me up to the attack when other people say that my PHAs aren't really that good. And I will say, kind of in defense of everyone, putting together a really good PHA is hard to do. It takes a lot of work. It takes a lot of effort. So, you know, let's go easy on the PHA people and their reports. And, you know, if they need a little work, be kind. All right.

So, there are a couple bullet points. I'm sorry, a couple informative notes associated with this Clause 8.2.3 on traceability. Note number one states, The above requirements do not mandate that the safety integrity requirements have to be assigned as numerical values. Qualitative or semi-quantitative approaches can also be used. So, no one is supposed to interpret Clause 8.2.3 to state that we need to have traceability on numbers because maybe you're not using numbers. Maybe you're using credits. Maybe you're simply using yes or no information. It's valuable or it's not.

So, there is no implication in traceability that says there has to be numbers associated with what you document.

Note number two of the standard says, The safety integrity requirements vary depending on the application and national legal requirements. An accepted principle in many countries is that additional risk reduction measures can be applied until the cost incurred becomes disproportionate to the improvement in safety integrity achieved.

So, note number two is introducing something that we will later call the ALARP concept or as low as reasonably practicable. As low as reasonably practicable means you need to keep adding risk reduction until the cost of risk reduction becomes disproportionate with the benefit that you're achieving from that risk reduction. Okay? And what safety integrity level you get and how many protection layers you need varies depending on what your organization is and what country you're building your plant in.

So, some countries will have quantitative limits on fatal events or fatal accidents that impact third parties outside the plant. Other countries don't have any quantitative limits with the United States being one of those countries that doesn't have quantitative benchmarks and relies on the operating companies to make those kinds of decisions based on their judgment, their analysis of the situation.

So, yeah, that note kind of falls back to a deeper or a higher level concept of what is tolerable risk? How much risk can be tolerated?

So, if you want to know, if you want a good discussion of tolerable risk, I'm going to have to point you back to my layer of protection analysis book where there's a whole section that starts out with the philosophy of what makes risk tolerable and then goes into comparative techniques to compare activities that people participate in and start to quantify them and allow you to actually put some numbers on quantitative risk and kind of draw a line back to this is how we determine that this risk is tolerable based on basically an analysis of how society lives its life, basically, is something that you can use to make determinations of what is tolerable.

And what is not tolerable.

Okay, so those are notes one and note two that talk about how you record the HNRA and what the results look like.

## Clause 8.2.4 Security Risk Assessment Requirements

So, at this point in time, we are actually done with the hazard and risk analysis, kind of. Back in the 2003 version of the standard, we were done here. But when the 2016 version of the standard came out, a lot more emphasis was placed on hazard and risk analysis. And that additional emphasis is in terms of hazards that can manifest themselves due to deliberate attacks.

So, most of hazard and risk analysis, as we have always looked at it, has been based on random hardware failures or random human failures. But Clause 8.2.4 and the 2010s in general, industry placed a lot more, dramatically a lot more emphasis on cybersecurity and deliberate attacks. So, what we're trying to do in Clause 8.2.4 is extend our hazard and risk analysis process to include a security risk assessment.

So, Clause 8.2.4 is all about security and cybersecurity. So, let me hit the bullet points with some discussion as I go along. Clause 8.2.4 states, a security risk assessment shall be carried out to identify the security vulnerabilities of the SIS. And it shall result in the following six bullet items.

So, you are obligated to do a security risk assessment. We need to look at the hazards of our plant specifically through the lens of deliberate attacks. So, how can deliberate attacks be accomplished? How are those deliberate attacks protected against? So, those are some of the things that we are going to need to look at when we're doing our hazard and risk analysis. All right. So, there are a lot of different methods. And when we get to the end of this section, I'll explain some of the different ways that you can execute of these risk analyses that are geared toward cybersecurity. Okay.

Bullet point number one. The security risk assessment shall result in a description of the devices covered by the risk assessment. So, kind of an inventory of what is the control equipment, if you will, that is going to be covered by my cybersecurity risk assessment. So, we had an inventory of the process equipment. We also need an inventory of the SIS equipment and other control equipment that's part of the scope. Second bullet point.

The security risk assessment shall result in a description of identified threats that could exploit vulnerabilities and result in security events, including intentional attacks on the hardware, application programs, etc. So, what are the ways that your instrumentation and control equipment, for instance, is vulnerable to a deliberate attack? Third bullet point. A description of the potential consequences resulting from the security events and the likelihood of these events occurring. So, you know, if there is a cyber attack, what can go wrong? Fourth bullet point.

States that the security risk assessment shall result in a consideration of the various phases of design, implementation, consulting, operation, and maintenance. So, you need to think about the entire SIS safety lifecycle and how you're exposed to attacks in these different timeframes.

Okay, and then the fifth bullet point is that the security risk assessment shall result in a determination of requirements for additional risk reduction. Now, oddly enough, this could be process safeguards in addition to cybersecurity countermeasures. I will talk about how that might be resolved in just a second.

And then, bullet point number six, a description of or references to information on the measures taken to reduce or remove threats. Okay, so basically, you look at those six bullet points and it tells you, hey, you did a great job in looking at random hardware failures, but maybe you didn't thoroughly consider deliberate attacks on the system and what the consequences of those attacks are. So, we're going to need to expand and or do another, potentially do another separate study that is focused on deliberate attacks.

And I will give you some ideas for maybe potentially a good way to do that, to look at that process. But before I do that, let me hit you with the four notes, the four informative notes that are included in this section for security risk assessment.

## Cybersecurity Standards and Assessment Scoping

Note one says, guidance related to SIS security is provided in ISA Technical Report 84.00.09. ISO 27001.00. And IEC 62443.00. So, those are, the IEC standard, the 62443 standard, is hands down the best resource for cybersecurity for your industrial control systems. That's what you really need to look at. That's what you really need to leverage to apply cybersecurity to your process. The Technical Report 84.00.09 kind of supplements the 62443 with kind of additional thoughts and additional considerations that are related to safety instrumented systems specifically.

And ISO 27001.00 is kind of a little bit of a motherhood and apple pie, not really geared toward industrial control systems, more geared toward general purpose computing systems. So, for instance, the Kenexis Integrated Safety Suite, our online tool for doing all things technical safety, we have done cybersecurity assessment and implemented safeguards in accordance with the IEC or the ISO 27001 standard. So, it's great for that application for SIS design, maybe not the best choice. Okay.

Moving along into note two, it says, the information and control of boundary conditions is needed for the security risk assessment are typically with the owner operating company of a facility, not the supplier. Where this is the case, the obligation to comply with 8.2.4 can be with the owner operator of the facility. So, cybersecurity risks are actually kind of hard to wrap your hands around because it's a combination of the control equipment and the equipment under control.

So, it's really hard for a supplier of control equipment to understand how a failure of their control equipment can result in a catastrophe of the plant. So, it's generally best that the operating company handles this assessment in a more holistic approach.

Okay.

Note number three states that the SIS security risk assessment can be included in an overall process automation security risk assessment. Bravo, kind of. So, when you're determining what cybersecurity countermeasures to employ, how to design your firewalls, how to implement restrictions in communications, communications, restrictions in what activities your different equipment items of your process plant perform, it's a really good idea

*[inaudible]*

during the security risk assessment and it be done in combination with what you're doing for the basic process control system.

So, attacking the SIS by itself is generally going to result in a whole lot of nothing. A hacker, in order to create a catastrophe, is going to need to hack into the basic process control system to generate the initiating event and also hack into the SIS to disable the SIS from performing its safety action. So, looking at everything all at the same time is not only a good idea, I would say it's critical, it's essential to think of everything at the same time when you're doing this assessment.

But that's kind of the secondary part of the analysis after you determine what the hazards are and what can go wrong, which is a slightly different process I'll talk about in just a second.

Note 4 states that the SIS security risk assessment can range and focus from an individual SIF to all the SISs within a company. Wow. I wouldn't agree with either one of those statements. Generally, when you look at the IEC 62443 standard, you're going to want to break your facility into zones and conduits. A zone is a collection of equipment that has all similar security requirements because they're all for the same purpose.

So a refinery might have a zone that is the hydrocracker complex, a zone that is storage tanks, a zone that is truck loading and rail loading, a zone that is the crude distillation unit complex, and so on. So those are zones and then you can have conduits which are basically the switches and routers and firewalls that are going to move data from one zone to another. So when you're doing your security risk assessments, you're going to look at process areas that are covered by a zone.

So you're generally going to want to do one zone at a time, one conduit at a time as you're doing these assessments, but sometimes, yeah, you're going to stack them together. You're going to look at everything all in one place. Okay, so those are the notes. You need to do a security risk assessment.

## Security PHA Review Methodology

So kind of, you know, where does the rubber beat the road? How do you do these risk assessments? Well, I'm going to point you to two places. Number one, I'm going to point you to ISA for a couple things. Number one, ISA has a lot of really good training classes on cybersecurity. So look at those ISA training classes on cybersecurity and those training classes on cybersecurity are going to apply across the board to a lot of different applications. Beyond that, specifically on this topic of risk assessment, I'm going to point you to a book called Security PHA Review that is published by ISA.

And that's really going to focus on hitting bullet point number two, three, and four. So the identified threats, the consequences of those threats in all the different modes of operation.

And actually, it's also going to cover bullet point number four. And maybe a little bit of one, maybe a little bit of six, but definitely points two through four. So what is security PHA Review? It is a process developed by some really top-notch engineers. And I'm not just saying that because those top-notch engineers are employees of Kenexis. And it's not just that they're employees of Kenexis. All right, I'll break down and let you know. It was me. I wrote the Security PHA Review book with the help of my co-author Jim McGlone, who is also a Kenexis employee.

He's kind of retired now, but he just really won't stay retired, and he ends up doing a lot of work for us anyway, even in his so-called retirement. But what we did is we looked at an approach where you can meet the requirements of Clause 8.2.4 for that really critical risk analysis phase without reinventing the wheel, without redoing a whole bunch of work. So if you look at that Security PHA Review book, what it's going to tell you is the best way to identify vulnerabilities in the process equipment is to look at your HAZOP.

Because the HAZOP, the PHA, the Hazard and Risk Analysis, basically looked at every combination of random failures that can result in a consequence. And you know what? It just so happens that those random failures can also be generated deliberately.

Which is why I like to say that you need to secure your PHA studies because your HAZOP study is basically an instruction manual for how to blow up your plant to the wrong people. You develop scenarios and you say, yeah, if this controller fails and this safeguard fails and this safeguard fails, I'm going to blow the plant up and look at how bad it's going to be. Imagine what happens when that information gets into the hands of the wrong people.

So with the security PHA review, you're basically going through all your PHA scenarios through the lens of can I deliberately make this happen. And to kind of summarize the book, if the initiating event is in a controller, in something that talks in a routable communication protocol on the internet or on an intranet, somehow it can communicate. It's a computer that can communicate with other devices. It's hackable.

So if the initiating event is hackable, meaning it's a control loop, and all of the protection layers are hackable because maybe I have an alarm that a hacker can change the set point of. Maybe I have a safety instrument or function that a hacker can put into bypass. Well, in that case, I can hack the initiating event. I can hack failure of all the safeguards. So I can hack that scenario all the way through from beginning to end.

That's a problem. So for that scenario, you need to look at what the consequences and do the appropriate degree of safeguarding. Now, conversely, if I have a scenario that the cause is that the operator put in two bags of reactant instead of three bags of reactant, I can't hack that scenario, so I don't really need to worry about it that much. similarly, if I have a relief valve, a spring-loaded relief valve, a hacker can't make that thing fail with a remote attack through the internet. So I don't need to worry about that scenario either.

So this method really allows me to focus on, well, what scenarios are exploitable through a cyber attack and focus my resources there.

And then, based on what the consequence is, I need to employ safeguards. Now, maybe I might want to employ physical safeguards like a spring-return check valve or a completely electrical or pneumatic safety function that can't be hacked.

Or, if that doesn't make sense, it tells me that for this scenario, because the consequence is so large, I will want to implement higher security levels in accordance with IEC 615 or IEC 62443. So IEC 62443 defines four security levels and maybe a hackable scenario that results in a minor injury, you're okay with security level two. but if you have a consequence that is multiple fatalities, maybe I need security level three or security level four.

So that assessment tells you how big of a risk you have and it tells you how impressive, maybe it's not the wrong word, how reliable, how effective your countermeasures need to be.

and maybe those countermeasures can be physical things, maybe those countermeasures are controls, your traditional cybersecurity countermeasures like dual factor authentication, encryption, and so on. So basically, bullet points one through four are great for nailing down using a security PHA review. two and bullet point one is kind of covered there. You simply need to say, okay, well, for the area that I'm talking about, this is the control and BPCS equipment in that area.

The last bullet point, a description of the countermeasures, that security PHA review approach will tell you any physical countermeasures that the team would recommend and it will also tell you, you need to implement security level two, three, or four, but it's not going to tell you, well, because I'm at security level three, I need to use two-factor authentication.

That's kind of outside the scope of the security PHA review. And that's something that your cybersecurity team is going to need to look at that security level target and then use their engineering judgment to determine what countermeasures need to be implemented to get there.

## Summary and Preview of Clause 9

So, all right, with that, that is the end of this current discussion on cybersecurity, Clause 8.2.4, and that's the end of Clause 8. So, next week, we are going to pick it back up, but I should tell you that we're not really done with hazard and risk analysis.

we've identified the scenarios where we have gaps. We've identified the areas where we have a safety instrumented function that might need a SIL target assigned to it, but we haven't assigned any targets yet. That's going to be discussed in Clause 9, which is the allocation. So, in Clause 8, we determined what the gap is, but then in Clause 9, we're going to close the gap by assigning risk reduction to all of the independent protection layers, including, and most importantly, the safety instrumented function.

## Vertigo SIS Safety Lifecycle Tool

Now that you've heard some insights on technical safety, functional safety, and the IEC 61511 standard, let me tell you a little bit more about how to easily and effectively implement the safety lifecycle using the Kenexis Integrated Safety Suite and our SIS Safety Lifecycle Management Tool, Vertigo. Vertigo is a comprehensive tool set for performing assessment calculations, documenting, and maintaining the design of safety instrumented systems.

Analysis begins with importing or synchronizing a list of safety instrumented functions with their definitions and associated performance targets from our open PHA tool for HAZOP and LOPA documentation. Each safety function can then be analyzed by performing a SIL verification calculation, complete with a collection of tools for optimizing designs and a database of thousands of potential instruments to define failure rates and diagnostic coverage capabilities.

After the SIL verification calculations are defined, you can build an SRS by automatically generating a cause and effect diagram from the SIF definitions and other defined instruments.

Each SIS instrument will include a customizable data sheet and general requirements that are applicable to the SIS as a whole and can be entered individually or even bulk imported from customizable libraries. After the design phase, you can even use Vertigo to track and document testing throughout the entire life of the facility. Kenexis Vertigo is the most integrated, easy-to-use enterprise tool for allowing the development of SIS design basis information more efficiently and effectively than any other software application.