A security risk assessment (SRA) identifies how a safety instrumented system (SIS) could be compromised on purpose, rather than by random failure. We at SIL Safe treat it as the security twin of the hazard and risk assessment (H&RA): same life-cycle stage, same seat at the table, different threat. IEC 61511 requires one, and it asks a question the H&RA never does — who would want this system to fail, and what would they have to reach to make that happen?
Key Points
- An SRA covers the whole path to the SIS, not just the logic solver: engineering workstations, remote-access links, vendor connections, and any network shared with the basic process control system (BPCS).
- Findings feed the SIS design — network segregation, key switches, port locking, and controls over who can change application program logic.
- It is a life-cycle activity, not a one-time study. Re-run it whenever connectivity, remote access, or the surrounding control network changes.
Example
A plant runs an SRA on its burner management system and finds the safety PLC sitting on the same flat network as the BPCS, with a vendor support connection reaching both. Nothing has failed and nothing has been attacked. The SRA writes it up anyway, because one compromised path can defeat the BPCS and the SIS together — the two layers the risk study assumed were independent.
One thing makes this harder than an H&RA: the threat adapts. A failure rate holds still; a person who wants your product does not. The Haldia naphtha pipeline fire is the blunt version — illegal tapping at a spot where naphtha had been stolen before.
Go deeper: Hazard and Risk Assessment (H&RA): The Foundation of Functional Safety
See Also: cybersecurity, H&RA, TPI
Cited Sources
- IEC 61511-1:2016, Clause 8.2.4
- ISA-TR84.00.09, Cybersecurity Related to the Safety Life-cycle