Understand Process Safety, barriers, HAZID, HAZOP, LOPA, SIL, SIS, integrity, PSSR, MOC, indicators, and governance throughout the life cycle.
Check it out!
Process Safety is the engineering and management discipline focused on preventing low-frequency, high-consequence events associated with loss of containment, energy release, fires, explosions, runaway reactions, and other failures capable of causing major accidents. Unlike occupational safety, which focuses primarily on individual exposure during work activities, Process Safety addresses the behavior of the technical and organizational system throughout the entire facility life cycle.
In practice, it combines process knowledge, hazard identification, risk analysis, barrier definition, asset integrity, safety instrumented systems, operating procedures, management of change, startup readiness, emergency response, and learning from incidents. The expected result is not merely a collection of documents: it is a prevention architecture in which requirements, responsibilities, evidence, and decisions remain traceable from concept through operation.
What Is Process Safety?
Process Safety is the systematic management of hazards inherent to processes involving hazardous materials, severe pressure and temperature conditions, significant energy, or operations in which loss of containment can produce catastrophic consequences. The concept is especially relevant to chemical, petrochemical, oil and gas, power, mining, pulp and paper, food facilities with large inventories of fuels or refrigerants, terminals, storage facilities, and other process installations.
The focus is to prevent the sequence that transforms an abnormal condition into a major accident. Therefore, the discipline is not limited to inspection, maintenance, or automation. It needs to integrate process, mechanical, electrical, instrumentation, automation, operations, maintenance, safety, emergency response, supply chain, and management.
The Center for Chemical Process Safety — CCPS approach organizes Risk-Based Process Safety into four major pillars: commitment to Process Safety, understanding hazards and risk, managing risk, and learning from experience. This organization is useful because it makes clear that sustainable performance depends on both technical controls and governance.
Process Safety Is Not the Same as Occupational Safety
The two areas complement each other, but they have different objects. An occupational-safety program may reduce falls, electric shocks, exposure to agents, and task-related accidents without necessarily controlling loss-of-containment scenarios adequately. Likewise, a plant can have sophisticated protection systems and still present occupational-safety failures.
The distinction matters because major accidents commonly involve interactions among design, integrity, process, automation, operating decisions, and organization. They are rarely explained by a single individual behavior.
Instead of asking only whether a person performs a given activity safely, Process Safety asks whether the system remains within its safe operating envelope, which scenarios can breach that envelope, which barriers exist, and what happens when one or more of them fail.
Process Safety in the Brazilian Context
In Brazil, NR-20 establishes minimum occupational safety and health requirements against accident risk factors arising from activities involving flammables and combustibles. The standard includes requirements for design, facility records, risk analysis, operational safety, maintenance and inspection, leak prevention, emergency response, and contractor management.
NR-20 should not be treated as directly equivalent to international Process Safety Management frameworks. It is a Brazilian regulatory reference with its own scope. Structures such as CCPS Risk-Based Process Safety and OSHA Process Safety Management can be used as technical and governance references when applicable, but they do not replace analysis of the Brazilian legislation and standards applicable to the facility.
Why Process Safety Must Be Treated as a System
If a facility has scattered studies, inconsistent documentation, or fragmented responsibilities, the first step is to structure a maturity assessment and governance proportional to risk.
An industrial facility does not become safe merely by having individually certified equipment. Performance depends on how requirements, designs, installations, procedures, people, and controls interact over time. An isolation valve can be suitable and still fail as a barrier if the actuator is incorrectly sized, the logic has been changed, a bypass remains active, or periodic testing cannot reveal a particular failure mode.
This systems view changes the question from “does the equipment work?” to “does the protective function remain capable of reducing risk in the scenario for which it was designed?”. The same logic applies to alarms, interlocks, dikes, ventilation, gas detection, procedures, inspections, and instrumented systems.
Governance is necessary precisely because conditions change: production increases, feedstock changes, suppliers alter components, control logic is revised, assets age, and operating practices adapt. Without a formal process, these changes degrade the original assumptions of the risk analysis.
From Threats to Prevention and Mitigation Barriers
A practical way to structure Process Safety is to think in scenarios. Each scenario has causes, a hazardous event, consequences, and barriers. Barriers may act in prevention — reducing the probability of occurrence — or in mitigation — limiting consequences after the event.
Examples of preventive barriers include basic process control, alarms with operator action, independent interlocks, mechanical protection, critical procedures, and safety instrumented systems. Mitigating barriers may include secondary containment, detection systems, suppression, drainage, isolation, ventilation, passive protection, and emergency plans.
Not every safeguard should receive the same credit. For a layer to be considered independent in a LOPA, independence from the initiating event and other layers, effectiveness, auditability, and performance appropriate to the scenario need to be verified. This care prevents overestimating risk reduction.
Hazard Identification: HAZID, HAZOP, and Other Techniques
Process Safety begins with structured understanding of hazards. In early phases, HAZID is useful for identifying broad hazards, interfaces, external conditions, layout characteristics, energies, materials, and relevant scenarios before the design is detailed.
HAZOP deepens the analysis when the process is sufficiently defined. It uses nodes, parameters, and guide words to investigate deviations such as higher pressure, lower flow, incorrect composition, reverse flow, or elevated temperature, relating causes, consequences, safeguards, and recommendations.
The technique should be selected according to the degree of project definition. An overly detailed analysis performed too early creates false assumptions; a superficial analysis in an advanced phase leaves relevant risks untreated.
Quality of Input Data
The quality of the analysis depends directly on the documents used. PFDs and P&IDs, balances, datasheets, cause-and-effect matrices, control philosophy, specifications, equipment lists, layouts, hazardous-area classification, substance information, and procedures need to be mutually consistent.
In brownfield facilities, the challenge increases. Outdated documentation, unrecorded changes, and differences between P&IDs and field conditions are common. In these cases, document verification and field surveys themselves become part of risk-analysis preparation.
From Qualitative Analysis to Protection-Layer Assessment
HAZID, HAZOP, and LOPA create value when recommendations, criteria, and barriers are followed through implementation and effectiveness verification.
HAZOP and equivalent techniques identify scenarios, causes, and consequences, but they do not always quantify risk reduction sufficiently. When it is necessary to assess whether existing safeguards are sufficient, LOPA — Layer of Protection Analysis provides a semiquantitative structure relating initiating-event frequency, conditional modifiers, and performance of Independent Protection Layers — IPLs.
LOPA is especially useful when a team needs to determine whether residual risk remains above the defined criterion and whether a safety instrumented function should be specified. It also requires documentation of the credit assigned to each layer, preventing every safeguard listed in HAZOP from being treated as equivalent to an IPL.
The analysis should preserve traceability among scenario, initiating event, consequence, IPLs, assumptions, frequency, PFD, and decision. Without this, future process changes can invalidate the conclusion without the organization noticing.
SIL, SIF, and SIS in the Process Safety Context
When the analysis establishes the need for risk reduction through an instrumented function, the relationship among SIF, SIL, and SIS emerges. The SIF — Safety Instrumented Function is the specific function that detects a condition and brings the process to a safe state. SIL represents the required integrity level of that function, not a generic label for a PLC.
The Safety Instrumented System — SIS brings together sensors, the logic solver, and final elements responsible for the SIFs. Its engineering needs to be supported by a Safety Requirements Specification — SRS that translates each scenario into verifiable requirements.
A common error is to select a platform or architecture before consolidating requirements. The more robust technical sequence starts from risk and only then defines the solution.
Asset Integrity as a Permanent Barrier
Process Safety cannot depend solely on automation. Vessels, piping, valves, flanges, pumps, compressors, structures, supports, electrical systems, overpressure protection, and rotating equipment need to maintain the integrity required for service.
An integrity program should consider degradation mechanisms, criticality, inspection, maintenance, testing, materials, spare parts, history, and intervention criteria. Periodicity should not be defined only by the calendar; it should reflect risk, condition, failure mechanism, and regulatory requirements.
Integrity also depends on installation and replacement quality. Replacing an item with an “equivalent” component without checking material, pressure class, chemical compatibility, dynamic response, or certifications may introduce a significant change disguised as maintenance.
Alarms, Interlocks, and Basic Control
The BPCS — Basic Process Control System — keeps the process within its operating range. Alarms communicate conditions requiring action. Interlocks prevent or command actions under defined conditions. SIFs perform safety functions with specific integrity requirements.
Mixing these categories creates confusion over responsibilities. An alarm can only be treated as a protection layer when there are clear criteria for detection, available response time, expected action, training, alarm load, and sufficient independence. An interlock implemented in the same system that causes the deviation may also fail to provide the required independence.
Process Safety engineering should document which functions belong to normal control, which are operating permissives, which are interlocks, and which are safety instrumented functions.
Operating Procedures and Safe Limits
Procedures should not be viewed merely as administrative instructions. They are part of the risk-control architecture when they describe normal conditions, startup, shutdown, emergency conditions, operating limits, consequences of deviations, and corrective actions.
An effective procedure needs to match the actual condition of the facility. Changes to setpoints, valves, sequences, logic, recirculation lines, or feedstock may make previous instructions inadequate. Therefore, procedures are directly linked to management of change.
It is also necessary to distinguish an authorized operating condition from a temporary deviation. Operating outside the established envelope without formal analysis is equivalent to accepting a new risk condition without reviewing the assumptions supporting the barriers.
Startup Readiness: PSSR
Before introducing hazardous inventory into a new or modified facility, the organization needs to verify that design, construction, documentation, procedures, training, and controls are ready. This verification is addressed by PSSR — Pre-Startup Safety Review.
PSSR should confirm that the facility matches approved documents, critical open items are resolved, procedures exist, training has been completed, relevant recommendations have been closed, and changes have been incorporated into the documentation.
PSSR does not replace commissioning. Commissioning demonstrates that systems and functions meet technical and performance requirements; PSSR verifies integrated readiness to introduce the process into service. The two processes complement each other.
Management of Change as a Central Element
A facility does not remain identical to its original design condition. Changes in process, capacity, equipment, logic, software, feedstock, procedures, organization, and facilities can alter risk. Management of Change — MOC — exists to prevent apparently simple modifications from invalidating existing analyses and barriers.
A robust MOC evaluates technical basis, safety impact, affected documentation, procedures, training, authorization, time period, need for risk analysis, testing, PSSR, and closure. OSHA 29 CFR 1910.119 uses formal management of changes other than simple replacement in kind as a principle within covered processes.
In the Brazilian context, this framework should be used as a technical reference when relevant, without being confused with an automatic Brazilian legal obligation. The need for MOC also arises from sound engineering practice itself and from the need to maintain traceability of design and operating conditions.
Engineering Change Management vs. Management of Change
The A3A site already has specific content on Engineering Change Management — ECM. ECM controls changes to scope, documents, requirements, interfaces, and configuration during project development.
MOC, in Process Safety, has a different primary intent: to assess whether a physical, operational, technological, or organizational modification changes facility hazards and risks. There is overlap in traceability and configuration control, but the safety objective is distinct.
A mature project integrates both workflows. An engineering change may require MOC; an MOC may generate document revisions and configuration-management actions. Keeping the processes conceptually distinct prevents a simple document revision from being confused with a risk assessment.
Process Safety in Greenfield Projects
In new projects, the opportunity for risk reduction is greater because fundamental decisions can still be changed. Layout, inventory, process philosophy, technology selection, materials, segregation, drainage, overpressure protection, and automation can be defined before they become physical constraints.
The strategy should distribute studies across project phases. HAZID can support Conceptual Engineering; HAZOP and LOPA gain precision as P&IDs and philosophies mature; SIL and SRS feed automation engineering; verification and design reviews accompany detailed design; FAT, SAT, commissioning, and PSSR close implementation.
Performing every analysis only at the end turns Process Safety into late correction, which is more expensive and less effective.
Process Safety in Brownfield Facilities
Existing facilities require attention to divergence between documentation and field conditions. Historical modifications, discontinued components, altered logic, recurring bypasses, production changes, and informal practices may have accumulated risk without an integrated review.
Before applying advanced techniques, it is often necessary to reestablish the information baseline: confirm P&IDs, equipment lists, cause and effect, setpoints, specifications, interconnections, and actual operating conditions.
Brownfield projects also need to consider shutdown windows, cutover, rollback, interfaces with operating systems, and temporary risk during transition.
Contractors, Vendors, and Technical Responsibility
A large share of the information supporting Process Safety is produced by vendors, integrators, and maintenance contractors. Datasheets, certificates, calculations, I/O lists, logic, drawings, test procedures, and manuals need technical review and incorporation into the owner’s records.
Delegating supply does not eliminate the need for governance. The owner needs to define requirements, acceptance criteria, interface responsibilities, and compliance evidence. This is where Owner’s Engineering and Project Assurance reduce the risk of fragmented decisions among contracts.
Procurement and Process Safety Requirements
Procurement needs to translate risk requirements into verifiable specifications. If a valve, detector, PLC, or protection system must perform a particular function, the requisition should indicate process conditions, performance, interfaces, testing, documentation, applicable certifications, and acceptance criteria.
Technical Procurement needs to preserve traceability between requirement and supply. Commercial substitutions, equivalencies, or value engineering cannot silently alter safety assumptions.
An adequate Technical Bid Evaluation does not compare only price and datasheet. It verifies compliance with critical requirements, deviations, exceptions, responsibilities, and impacts on the protection architecture.
Commissioning and Validation
Commissioning is one of the main mechanisms for turning design requirements into performance evidence. Inspections, loop checks, functional tests, FAT, SAT, interlock tests, cause-and-effect testing, and function validation need to demonstrate that the installed system responds as specified.
For SIS, Functional Safety validation has its own scope and should not be reduced to SAT. IEC 61511 structures the life cycle and differentiates verification, validation, management, operation, and modification.
Test evidence should record the initial condition, stimulus, expected response, observed response, acceptance criteria, instruments used, responsible parties, and treatment of deviations.
Process Safety Indicators
Measuring only accidents that occurred is insufficient. Major events are rare, so an organization may go years without a serious accident even as barriers progressively degrade.
Process indicators should combine outcomes and precursor conditions. Examples include demands on safety systems, active bypasses, overdue tests, overdue critical recommendations, integrity failures, recurring critical alarms, MOC deviations, PSSR open items, and loss-of-containment events.
The objective is not to generate excessive dashboards, but to identify degradation before it becomes an event.
Incident Investigation and Learning
Incidents, near misses, and barrier failures need to feed back into the system. A mature investigation does not stop at immediate human action; it seeks technical, organizational, design, maintenance, competence, information, and management causes.
Recommendations should be traceable through closure and verified for effectiveness. An administratively completed action that does not reduce the underlying cause of risk does not represent effective learning.
Learning can also come from external events. Manufacturer alerts, incidents at other companies, regulatory changes, and new failure mechanisms should be assessed when applicable to the asset.
Culture and Competence
Process Safety Culture is not merely a communication campaign. It appears in how production, maintenance, schedule, and investment decisions address high-consequence risks. A mature organization avoids normalizing deviations, accepts technical escalation, and distinguishes operational urgency from authorization to change safety assumptions.
Competence also needs to be managed. Facilitating HAZOP, performing LOPA, specifying SIL, reviewing SIS, or approving a critical change require different knowledge. The responsibility matrix should associate each decision with the required level of competence and independence.
How to Structure Process Safety Governance
A governance structure should define scope, processes, roles, records, and gates. There is no single model applicable to every facility, but several elements recur:
- policy and risk criteria;
- process knowledge management;
- HAZID, HAZOP, and risk analysis;
- barrier and integrity management;
- MOC and configuration control;
- procedures and competence;
- contractor management;
- PSSR and startup authorization;
- investigation and indicators;
- audits and performance review.
Depth should be proportional to complexity and risk. The CCPS RBPS approach itself emphasizes risk-based application rather than uniform bureaucracy.
Role of Engineering Consulting
An Engineering Consulting firm can support governance without necessarily supplying every plant system. The value lies in organizing requirements, reviewing evidence, facilitating analyses, coordinating interfaces, and preserving independence between those who supply and those who technically accept.
Possible deliverables include a maturity assessment, Process Safety plan, responsibility matrix, HAZID/HAZOP/LOPA standards, MOC governance, PSSR criteria, SIS requirements, Design Review procedures, evidence matrix, and gap audit.
Engineering Technical Consulting and Engineering Risk Management can serve as contracting structures for this type of support, provided the scope and required competencies are clearly defined.
Owner’s Engineering and Independence
In projects with multiple vendors, the owner’s technical independence helps preserve Process Safety requirements across design, Procurement, installation, testing, acceptance, and operation.
When different vendors participate in a project, the owner needs an integrated view. The automation integrator optimizes its solution; the valve manufacturer is responsible for its equipment; the contractor delivers installation; the operator needs to receive a safe and documented system.
The Owner’s Engineering function is to verify whether the whole meets the owner’s requirements. In Process Safety, this includes reviewing interfaces, changes, documents, tests, open items, and acceptance criteria without automatically assuming the specific technical responsibilities of each vendor.
Scope and Responsibility Boundaries
Process Safety includes activities that may require specialized professionals, disciplines, and competencies. A consulting firm should not generically promise SIL certification, independent validation, consequence calculation, quantitative risk analysis, or detailed SIS design without having the necessary competencies and resources.
The scope should clearly state what will be facilitated, developed, reviewed, verified, or approved and who remains responsible for detailed engineering, operation, and the final decision.
This care is part of governance itself: ambiguous responsibilities are a source of systemic failure.
Final Considerations
Process Safety is more effective when it stops being treated as an isolated study and begins to operate as a technical management system. HAZID and HAZOP identify hazards; LOPA assesses layers; SIL and SIS address instrumented requirements; integrity and procedures maintain operating conditions; PSSR controls entry into service; MOC preserves assumptions after changes; indicators and investigation close the learning cycle.
For Engineering Consulting, the highest-value space lies in governance of these interfaces. The objective is not to replace specialists from each discipline, but to create a structure in which decisions, requirements, evidence, and responsibilities remain connected to the risk that originated each protective measure.
Maturity appears when the organization can answer, for a critical scenario, which barriers were planned, why they were considered sufficient, who maintains each one, how their performance is verified, and what happens when the facility changes. This traceability turns documentation into real prevention capability.
Technical references
[1] BRAZIL. Ministry of Labor and Employment. NR-20 — Safety and Health at Work with Flammables and Combustibles. Latest modification indicated by MTE: Ordinance MTE No. 60, January 21, 2025. Available at: https://www.gov.br/trabalho-e-emprego/pt-br/acesso-a-informacao/participacao-social/conselhos-e-orgaos-colegiados/comissao-tripartite-partitaria-permanente/normas-regulamentadora/normas-regulamentadoras-vigentes/norma-regulamentadora-no-20-nr-20
[2] CENTER FOR CHEMICAL PROCESS SAFETY — CCPS. Guidelines for Risk Based Process Safety. New York: AIChE/Wiley, 2007. Available at: https://ccps.aiche.org/publications/books/guidelines-risk-based-process-safety
[3] CENTER FOR CHEMICAL PROCESS SAFETY — CCPS. Risk-Based Process Safety — Overview. Available at: https://ccps.aiche.org/overview
[4] UNITED STATES. Occupational Safety and Health Administration — OSHA. 29 CFR 1910.119 — Process Safety Management of Highly Hazardous Chemicals. Available at: https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.119
Frequently asked questions
Occupational safety primarily addresses the occupational risks of work activities and worker exposure. Process Safety focuses on loss-of-containment scenarios, energy release, and other high-consequence events arising from interactions among process, design, integrity, automation, operations, and management. The two disciplines are complementary.
No. HAZOP is a technique for identifying and analyzing deviations. Process Safety also requires barrier management, asset integrity, procedures, competence, management of change, PSSR, protection systems, emergency response, investigation, indicators, and governance throughout the life cycle.
It is a technical or organizational measure capable of preventing a hazardous scenario or mitigating its consequences. Barriers may include control, alarms, instrumented systems, mechanical protection, containment, detection, procedures, and other mechanisms. The credit assigned to each barrier depends on effectiveness, independence, and management appropriate to the scenario.
LOPA can be used to estimate the additional risk reduction required when existing layers are insufficient. When this reduction must be provided by an instrumented function, the result supports determination of the required SIL for the SIF, which then needs to be specified, designed, verified, and validated.
PSSR is the Pre-Startup Safety Review, a readiness review before startup of new or modified facilities. It verifies that construction, documentation, procedures, training, recommendations, and other necessary conditions are adequate before introduction of the hazardous process.
Management of Change is the formal process for assessing and controlling changes in process, technology, equipment, procedures, logic, operating conditions, and other characteristics that can alter hazards or risk. MOC ensures technical analysis, authorizations, documentation updates, training, testing, and closure.
No. It is especially well known in chemical and petrochemical industries, but the principles apply to facilities where process, energy, or containment failures can produce severe consequences, such as oil and gas, power, mining, terminals, storage, and other industrial operations.
Yes. A consulting firm can support diagnosis, governance, study facilitation, requirements, Design Review, technical Procurement, Owner's Engineering, gap audits, test criteria, and commissioning oversight, provided responsibilities and competence boundaries are clearly defined.
Supplementary technical materials
Related solutions
Related services
- Engineering Technical Consulting: diagnosis, strategy, and decision support
- Engineering Risk Management: identification, analysis, mitigation, and contingency
- Owner’s Engineering
- Industrial Automation Design
Key content on the topic
- HAZID in Engineering: Hazard Identification methodology and application
- HAZOP in Engineering: methodology, guide words, and process deviations
- LOPA: Layer of Protection Analysis, independent layers, and risk reduction
