{"id":186086,"date":"2026-02-10T10:08:00","date_gmt":"2026-02-10T15:08:00","guid":{"rendered":"https:\/\/testing.news-you-need.com\/index.php\/2026\/02\/10\/when-safe-isnt-secure-why-iec-61511-mandates-cybersecurity-for-sis\/"},"modified":"2026-02-10T10:15:09","modified_gmt":"2026-02-10T15:15:09","slug":"when-safe-isnt-secure-why-iec-61511-mandates-cybersecurity-for-sis","status":"publish","type":"post","link":"https:\/\/testing.news-you-need.com\/index.php\/2026\/02\/10\/when-safe-isnt-secure-why-iec-61511-mandates-cybersecurity-for-sis\/","title":{"rendered":"When safe isn\u2019t secure \u2013 why IEC 61511 mandates cybersecurity for SIS"},"content":{"rendered":"

When safe isn\u2019t secure \u2013 why IEC 61511 mandates cybersecurity for SIS<\/a><\/p>\n

http:\/\/www.hazardexonthenet.net\/article\/220333\/When-safe-isn-t-secure-why-IEC-61511-mandates-cybersecurity-for-SIS.aspx<\/a><\/p>\n

Publish Date: 2026-02-10 10:08:00<\/a><\/p>\n

Source Domain: www.hazardexonthenet.net<\/a><\/p>\n

Author: <\/a><\/p>\n

Using an unordered list, summarize the following article with between 4 and 8 key points. Author : Denrich Sananda, Managing Partner, Arista Cyber10 February 2026For years, process safety professionals have taken comfort in a familiar equation: if a Safety Instrumented System (SIS) meets its required Safety Integrity Level (SIL), then the risk is under control. HAZOPs are complete, layers of protection are verified, proof tests are planned, and the compliance box is ticked. But that equation no longer holds.Image: Arista(Click here to read article in digital edition)As operational technology (OT) systems have become more connected, more digital, and more accessible, the idea that a system can be functionally safe \u2013 without it also being cyber secure \u2013 has been quietly undermined. Much of the industry has missed the formalisation of this point. Ten years ago, the second edition of IEC 61511 introduced Clause 8.2.4, a requirement that many still overlook or misunderstand, which mandated a Security Risk Assessment (SRA) specifically for the SIS. Not as optional guidance or as best practice. But as a requirement. That short clause represents one of the most important shifts in process safety thinking in decades. It recognises that cybersecurity weaknesses can act as credible initiating causes of major accidents, in the same way as mechanical failure, human error, or poor design. In practice, this is still an area where many plants rely on assumptions made years ago, before today\u2019s levels of connectivity, but cyber risks must be treated with the same seriousness as any other. The digitalisation of safety When IEC 61511 was first written, most SIS architectures were physically isolated. Engineering access was local, communications were simple, and cyber risk, at least as we understand it today, barely featured in plant design. Fast forward to today, and the landscape looks very different. Modern SIS platforms use Ethernet-based communications. Engineering workstations run commercial operating systems with widely known vulnerabilities. Remote, often persistent vendor access is common. Safety systems exchange data with asset management tools and, in some cases, even cloud-based services. The traditional perimeter is, for all intents and purposes, disappearing. These developments bring real operational benefits, but they also introduce new ways for things to go wrong. A compromised engineering laptop can introduce systematic errors into safety logic. A misconfigured network could allow unintended commands to reach final elements. Weak access controls can blur the boundary between the BPCS and the SIS. None of these failures involve broken hardware, yet each can directly undermine a SIL claim. IEC 61511 Edition 2 acknowledges the uncomfortable truth: cyber-enabled failures are no longer somebody else\u2019s problem, and they are far more than a straight IT issue. They sit squarely within the safety lifecycle, because they directly affect the ability of the SIS to perform when it needs to. Clause 8.2.4: small words, big implicationsImage: Arista The widely overlooked clause 8.2.4 is brief, but its meaning is clear. It requires that vulnerabilities of the SIS to both intentional and unintentional security threats are identified, assessed, and mitigated. Because it sits within Clause 8, which covers hazard and risk assessment, cybersecurity must be considered alongside overpressure, loss of containment, runaway reactions, and ignition sources. This is not a parallel IT exercise. It is not optional. And it means that claiming compliance with IEC 61511 without first addressing SIS cybersecurity is increasingly difficult to justify. Crucially, the clause recognises something regulators increasingly emphasise: intent does not matter. An accidental misconfiguration, an uncontrolled firmware update, or weak access management can be just as dangerous as a deliberate cyberattack. The consequence to safety is the same. Cyber-related failures can manifest in many ways. Sensor values may be frozen or manipulated, leaving the SIS blind as the process drifts into a hazardous state. Logic parameters can be altered without alarms, changing trip points or disabling safety functions altogether. Final elements may be forced to change state via unsecured communication paths. Trusted engineering tools can become vectors for systematic failure. From a process safety perspective, the result is familiar: the safety function does not operate when required. That is why regulators and incident investigators increasingly view cybersecurity weaknesses as credible initiating events, not theoretical concerns. Although the threat is digital, the outcome is physical and very real. What a \u201cgood\u201d SRA for SIS looks like One reason the industry still struggles with this topic is that cybersecurity is often approached through a traditional IT lens. That rarely works. A proper SRA for a SIS is not a box-ticking exercise about software patches or abstract threat scores. It is about asking a much simpler question: how could a cyber issue lead to a dangerous situation on this plant? A good assessment starts by clearly defining the SIS boundaries: logic solvers, I\/O, engineering tools, networks, remote access, and interfaces with the BPCS. From there, realistic threat scenarios are developed based on how plants operate. This means facing the realities of shared credentials, vendor laptops, poor segmentation, or uncontrolled remote access. Consequences are then assessed using process safety criteria, highlighting potential outcomes like loss of a safety function, increased likelihood of ignition, or escalation of a hazardous event. Done properly, the SRA becomes a natural extension of LOPA, not a disconnected cyber study. The result is a set of Security Level requirements that translate into practical controls. These will vary depending on the organization, but in general revolve around instituting segmentation, authentication, access governance, configuration management, and lifecycle assurance.Denrich Sananda, Managing Partner and Senior Consultant, Arista Cyber From paper exercise to lifecycle discipline Perhaps the most important and most overlooked aspect of Clause 8.2.4 is that it is not a one-off exercise. Cybersecurity controls must be verified during FAT and SAT, maintained during operation, and reassessed whenever the SIS is modified – whether that change is hardware, software, networking, or access-related. In other words, cybersecurity now follows the same lifecycle discipline as functional safety itself, which is exactly what regulators expect to see when uncomfortable questions are asked after an incident. The industry should be asking itself candid questions. Are SIS security requirements clearly defined? Are Security Levels justified and documented? Are changes managed with the same rigour as safety modifications? If those questions cannot be answered confidently, SIL claims may be far weaker than they appear on paper. Safe is no longer enough IEC 61511 did not suddenly turn into a cybersecurity standard in 2016, but it did formally recognise a reality that can no longer be ignored: in a connected plant, a system that is not secure cannot be assumed to be safe. Clause 8.2.4 is the standard\u2019s quiet but firm message that process safety and cybersecurity are now inseparable. Treating them as separate silos is no longer technically, and certainly not ethically, defensible. After ten years, the clause is no longer new. What is new is the growing gap between what the standard requires and how widely it is applied. The industry has been warned. Now it needs to act, before the next incident makes the point far more clearly than any standard ever could.About the author: Denrich Sananda is Managing Partner and Senior Consultant at Arista Cyber. Denrich is a Harvard Business School alumnus and holds many cybersecurity certifications and positions including being a member of committees working on ISA99 WG2 focusing on the description of an effective cybersecurity management system in the ISA-62443-2-1 standard and is a Member Board Of Directors – ISA Toronto. With a career built on pioneering work in automation and critical infrastructure security, he has led high-profile initiatives across North America and the Middle East.Contact Details and Archive…
<\/p>\n","protected":false},"excerpt":{"rendered":"

When safe isn\u2019t secure \u2013 why IEC 61511 mandates cybersecurity for SIS http:\/\/www.hazardexonthenet.net\/article\/220333\/When-safe-isn-t-secure-why-IEC-61511-mandates-cybersecurity-for-SIS.aspx Publish Date:…<\/p>\n","protected":false},"author":1,"featured_media":186087,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/www.hazardexonthenet.net\/global\/showimage.ashx?Type=Article&ID=236862&Min=200","fifu_image_alt":"","footnotes":""},"categories":[15],"tags":[24],"class_list":["post-186086","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cybersecurity","tag-cybersecurity"],"_links":{"self":[{"href":"https:\/\/testing.news-you-need.com\/index.php\/wp-json\/wp\/v2\/posts\/186086"}],"collection":[{"href":"https:\/\/testing.news-you-need.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/testing.news-you-need.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/testing.news-you-need.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/testing.news-you-need.com\/index.php\/wp-json\/wp\/v2\/comments?post=186086"}],"version-history":[{"count":1,"href":"https:\/\/testing.news-you-need.com\/index.php\/wp-json\/wp\/v2\/posts\/186086\/revisions"}],"predecessor-version":[{"id":186088,"href":"https:\/\/testing.news-you-need.com\/index.php\/wp-json\/wp\/v2\/posts\/186086\/revisions\/186088"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/testing.news-you-need.com\/index.php\/wp-json\/wp\/v2\/media\/186087"}],"wp:attachment":[{"href":"https:\/\/testing.news-you-need.com\/index.php\/wp-json\/wp\/v2\/media?parent=186086"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/testing.news-you-need.com\/index.php\/wp-json\/wp\/v2\/categories?post=186086"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/testing.news-you-need.com\/index.php\/wp-json\/wp\/v2\/tags?post=186086"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}