The Guardian of Technical Safety: Independent Safety Assessor (ISA)

Achieve SIL4 compliance with an Independent Safety Assessor. Discover how ISAs validate technical safety for railway software and hardware against CENELEC standards.

December 11, 2025 8:30 am | Last Update: March 22, 2026 12:24 pm

⚡ IN BRIEF

The 2009 Zuidlaren Signalling Failure: In December 2009, a signalling system on the Dutch high‑speed line HSL‑Zuid failed to detect a train, causing a near‑miss at 250 km/h. The root cause was a software logic error that had not been subjected to an independent safety assessment. The incident accelerated the mandatory requirement for an Independent Safety Assessor (ISA) for all safety‑critical railway products in Europe.
ISA vs. AsBo – A Critical Distinction: The ISA focuses on the technical safety of a specific product (e.g., an ETCS onboard computer) against CENELEC standards (EN 50126/128/129), verifying that it meets a defined Safety Integrity Level (SIL). In contrast, an Assessment Body (AsBo) assesses the system‑level risk management under the Common Safety Method for Risk Evaluation (CSM‑RA). Confusing the two can lead to incomplete safety cases.
Software Safety Assessment (EN 50128): For SIL 4 software, the ISA must verify that all code has 100% structural coverage (modified condition/decision coverage – MC/DC), that there are no dead code, and that the software architecture follows a deterministic, hierarchical design. The ISA reviews 100% of safety‑related requirements traceability and witnesses unit, integration, and system tests.
Hardware Safety Assessment (EN 50129): The ISA calculates or validates the hardware reliability metrics: PFH = Σ λ_D (probability of dangerous failure per hour) for SIL 4 must be < 10⁻⁹ /h. This requires detailed failure modes, effects, and diagnostics analysis (FMEDA) and evidence of component quality (e.g., ISO 26262 for electronic components).
Independence Criteria: An ISA must be independent of the design, manufacturing, and supply chain of the product. The CENELEC standards require organisational independence (separate reporting lines), financial independence (no project‑based bonuses), and technical independence (no involvement in design decisions). Many ISAs are accredited by national bodies (e.g., UKAS, DAKKS) to ensure impartiality.

On a cold December evening in 2009, a high‑speed test train on the Dutch HSL‑Zuid line hurtled toward a section where the signalling system had silently failed. A software logic error in the interlocking controller—a seemingly minor oversight—had allowed the track ahead to be reported as clear when, in fact, another train was already occupying the section. Only a last‑second intervention by the train driver, using emergency braking, prevented a collision that would have occurred at 250 km/h. The investigation revealed that the manufacturer had performed internal testing and a “safety review,” but no independent, third‑party assessment had been mandated. The error, buried in a safety‑critical algorithm, had escaped detection because the design team had not been required to prove its work to an external, critical eye. That near‑miss became a watershed moment. In the years that followed, European legislation (through the CSM‑RA and the Interoperability Directive) solidified the role of the Independent Safety Assessor (ISA)—a guardian of technical safety who scrutinises every line of code, every component failure mode, and every argument in the safety case. The ISA does not design, build, or manage; its sole purpose is to verify that when a train stops or a signal turns red, the system behind it has been engineered to a standard that leaves no room for hidden failure.

What Is an Independent Safety Assessor (ISA)?

An Independent Safety Assessor (ISA) is a third‑party entity (either an individual or an organisation) responsible for auditing, verifying, and certifying that a specific railway product, subsystem, or system meets the required technical safety standards, primarily the CENELEC railway standards: EN 50126 (RAMS – Reliability, Availability, Maintainability, Safety), EN 50128 (software for railway control and protection), and EN 50129 (safety‑related electronic systems for signalling). The ISA performs an independent, objective assessment of the safety case presented by the developer, validating that the hardware and software have been developed to the claimed Safety Integrity Level (SIL), up to SIL 4. Unlike a Notified Body (NoBo) which verifies conformity with Technical Specifications for Interoperability (TSIs) for cross‑border operation, or an Assessment Body (AsBo) which assesses system‑level risk management under the Common Safety Method (CSM‑RA), the ISA drills into the technical engineering details: it reviews software code metrics, analyses failure modes of hardware components, verifies that all safety requirements are traced through the V‑model lifecycle, and often witnesses critical tests. The ISA’s output is an Independent Safety Assessment Report, which forms a key part of the safety case submitted to the railway undertaking, infrastructure manager, or safety authority. ISAs are typically accredited by national accreditation bodies (e.g., UKAS, DAKKS, COFRAC) to ensure competence and impartiality, and many are certified to ISO 17020 (inspection bodies) or ISO 17065 (certification bodies).

1. The CENELEC Standards Foundation: EN 50126, EN 50128, EN 50129

ISA assessments are built upon the triad of CENELEC railway standards. Each defines a specific layer of safety engineering:

EN 50126 (RAMS): Defines the overall lifecycle for railway systems, from concept to decommissioning. It introduces the concept of Safety Integrity Level (SIL) and mandates that safety requirements be defined, allocated, and traced. The ISA ensures that the developer has followed a robust RAMS process and that the safety plan is comprehensive.
EN 50128 (Software): Specifies the processes, techniques, and documentation required for software development for railway control and protection systems. It classifies software by SIL (0 to 4) and prescribes mandatory techniques. For SIL 4, the standard requires, among others: formal methods, static analysis, 100% modified condition/decision coverage (MC/DC) testing, and code inspections by independent experts.
EN 50129 (Hardware): Covers safety‑related electronic systems, such as interlocking controllers and ETCS onboard units. It requires a detailed safety case that includes a quantitative reliability analysis (e.g., failure rates, PFH), analysis of systematic failures, and evidence of component quality. The ISA verifies the hardware safety case, including the FMEDA (Failure Modes, Effects, and Diagnostic Analysis) and the compliance with the required SIL.

The following table summarises key SIL 4 requirements across these standards:

Standard	Key SIL 4 Requirements	ISA Verification Focus
EN 50126 (RAMS) – overall process	Formal hazard log, safety requirements traceability, independent validation of safety case	Audit of lifecycle process; verification of hazard closure; check of independence in validation
EN 50128 (Software)	Formal methods, MC/DC coverage, static analysis, probabilistic failure rates < 10⁻⁹/h for systematic failures	Review of architectural design, code review, test coverage reports, tool qualification
EN 50129 (Hardware)	Quantitative analysis: PFH < 10⁻⁹/h, diagnostic coverage ≥ 99%, component reliability per IEC 61508	FMEDA review, reliability block diagrams, stress testing, environmental testing records

2. The ISA Role in the V-Model Lifecycle

The ISA is involved from the earliest concept phase through to final approval, ensuring that safety is built in, not tested in. The standard V‑model (as per EN 50126) defines phases, and the ISA intervenes at each gate:

Concept & System Definition: The ISA reviews the Safety Plan, Quality Assurance Plan, and the initial hazard identification. It ensures that the proposed SIL for the system is justified and that the development process will be compliant.
Requirements & Architecture: At this stage, the ISA audits the traceability of safety requirements from the hazard log to the system requirements. It verifies that architectural choices (e.g., 2oo2 voting, diversity) are adequate for the target SIL.
Design & Implementation: For hardware, the ISA may review schematics, component selection, and FMEDA results. For software, it conducts code inspections (often using static analysis tools) and ensures that coding standards are followed. It also verifies that all safety‑related code is properly documented and that critical algorithms have been mathematically proven.
Validation & Testing: The ISA witnesses key validation tests (e.g., type tests, EMC tests, environmental tests) to confirm that the test environment and procedures are adequate. It does not perform the tests itself but checks that the coverage meets the SIL requirements (e.g., 100% MC/DC for SIL 4).
Safety Case & Final Assessment: The ISA reviews the complete safety case, including the hazard log, the safety requirements traceability matrix, test results, and the independent validation report. It then issues the Independent Safety Assessment Report, which may state that the product is “certified as compliant with the required SIL” or may list open points that must be resolved before service entry.

By intervening at every phase, the ISA prevents the common failure mode where safety is only considered late in the project, leading to costly redesigns or unsafe compromises.

3. Software Safety Assessment Under EN 50128

For safety‑critical railway software (e.g., ETCS onboard software, interlocking logic), EN 50128 imposes strict requirements that the ISA must verify. Key areas of focus include:

Software Architecture: For SIL 4, the software must be deterministic and hierarchical. The ISA checks that there are no uncontrolled loops, that time‑critical tasks are scheduled appropriately, and that there is clear separation between safety and non‑safety functions (often via hardware partitioning).
Development Tools: The ISA verifies that all tools used (compilers, static analyzers, test harnesses) are either qualified to the required confidence level (typically through tool qualification per EN 50128 Annex D) or that their outputs are manually verified for safety‑critical components.
Testing Coverage: For SIL 4, the standard requires 100% modified condition/decision coverage (MC/DC) for unit tests. The ISA reviews the test reports and may perform spot checks on the test harness to ensure that the coverage metrics are genuine. It also checks that integration and system tests cover all safety requirements.
Static Analysis & Formal Methods: The ISA looks for evidence that static analysis tools (e.g., Polyspace, Coverity) have been used to prove the absence of run‑time errors (division by zero, out‑of‑bounds access). For the most critical functions, formal methods (e.g., model checking, theorem proving) may be required; the ISA evaluates the rigour of such proofs.
Code Review & Configuration Management: The ISA audits the code review process, ensuring that independent reviewers (not the original authors) have signed off on each change. It also checks that configuration management is rigorous, with every software version traceable to a set of requirements.

A typical ISA software assessment for a SIL 4 product can take 3–6 months and involve reviewing tens of thousands of lines of code and hundreds of test cases. The ISA’s findings are documented in the Independent Safety Assessment Report, which is a prerequisite for safety approval.

4. Hardware Safety Assessment & Quantitative Reliability

For electronic hardware (e.g., an axle counter, a safety relay, a vital processor), EN 50129 requires a quantitative reliability analysis. The ISA’s tasks include:

FMEDA (Failure Modes, Effects, and Diagnostic Analysis): The ISA reviews the FMEDA, which lists each component, its failure modes, the effect on the system, and the diagnostic coverage. The key output is the probability of dangerous failure per hour (PFH). For SIL 4, the PFH must be < 10⁻⁹ /h. The ISA verifies the assumptions (e.g., component failure rates from databases like SN 29500 or IEC 62380) and checks that the diagnostic coverage calculations are realistic.
Reliability Block Diagrams (RBD): The ISA checks that the architecture (e.g., 2oo3 voting) is correctly modelled in the RBD and that common‑cause failures are accounted for (β factor). For SIL 4, β is often required to be ≤ 2%.
Component Qualification: The ISA verifies that all critical components (processors, memory, power supplies) are qualified to the appropriate standard (e.g., IEC 61508 for electronic components) and that they have been subjected to environmental tests (temperature, vibration, EMC) per EN 50155.
Systematic Failure Analysis: Even with perfect random failure numbers, systematic failures (design errors) can still occur. The ISA checks that the development process includes measures to prevent systematic faults, such as reviews, testing, and formal verification.

A sample PFH calculation for a SIL 4 system might be:

PFH = Σ λD × (1 – DC)

where λD = dangerous failure rate per component, and DC = diagnostic coverage (0 to 1).

For a 2oo3 architecture: PFH = 6 × λD × (1 – DC) × β × Ttest (simplified).

The ISA must be satisfied that the hardware meets the target SIL through both quantitative and qualitative evidence.

ISA vs. AsBo vs. NoBo – Clarifying the Roles

Railway professionals often confuse the Independent Safety Assessor (ISA) with other assessment bodies. The table below clarifies the distinct roles based on legal framework, scope, and output:

Aspect	Independent Safety Assessor (ISA)	Assessment Body (AsBo)	Notified Body (NoBo)
Primary legal basis	CENELEC EN 50126/128/129 (voluntary contract, but mandated by TSI and CSM‑RA)	CSM‑RA (EU Regulation 402/2013)	Interoperability Directive (EU 2016/797) + TSIs
Scope	Technical safety of a specific product (e.g., ETCS onboard unit, interlocking)	System‑level risk management for a change or operation (e.g., introducing new train type)	Compliance with TSIs for cross‑border interoperability (e.g., TSI CCS, TSI LOC&PAS)
Output	Independent Safety Assessment Report (ISA Report) – product‑level safety conclusion	Safety Assessment Report (SAR) – system‑level risk assessment	EC Certificate of Verification (for subsystems), EC Type‑Examination Certificate
Mandatory for	SIL 3/4 products; often required by infrastructure managers (e.g., DB Netz)	Any significant change to the railway system (CSM‑RA Article 6)	New rolling stock or infrastructure placed on TEN‑T network
Independence level	Organisational, financial, technical – must not have been involved in design	Organisational independence from the applicant	Independence from design and manufacturing (per EU regulation)
Example	A company certifies that a new axle counter meets SIL 4	The same axle counter is assessed for safe integration into a specific station interlocking	The axle counter is verified to be TSI CCS compliant for use on ERTMS lines

Editor’s Analysis: The Capacity Crunch and the Future of Independent Assessment

The ISA role has become indispensable, but the industry is facing a severe shortage of qualified assessors. With the surge in ERTMS deployment, CBTC (Communications‑Based Train Control) projects, and new rolling stock, the demand for ISAs has outpaced supply. A 2023 survey by the European Union Agency for Railways (ERA) found that the average waiting time for an ISA to start a new assessment was 4 months, and 30% of projects experienced delays due to ISA unavailability. This capacity crunch is partly due to the high barrier to entry: an ISA must have deep knowledge of multiple CENELEC standards, software and hardware engineering, and domain‑specific safety principles. Moreover, the independence requirements prevent assessors from being drawn from the same pool as developers, limiting the talent pool.

The solution may lie in a more modular approach: breaking large safety cases into smaller, independently assessable components, and using automated tools (e.g., model‑based verification) to reduce manual review time. However, the current standards still require extensive human judgment. The next revision of EN 50126/128/129 should consider allowing a “supervised” or “accredited” approach where less critical parts can be assessed by internal teams under an external auditor’s oversight, freeing up senior ISAs for the truly complex work. Until then, infrastructure managers and manufacturers must plan ISA engagement early—preferably at the concept stage—and accept that independent assessment is not a compliance checkbox but a critical resource that requires lead time and investment.

— Railway News Editorial

Frequently Asked Questions (FAQ)

1. Can the same company act as both ISA and AsBo for a single project?

Technically, yes, provided that the organisation maintains strict independence and that the contracts are separate. However, most safety authorities strongly discourage this to avoid any perceived conflict of interest. The ISA is supposed to be independent of the design and development, while the AsBo must be independent of the applicant (the entity implementing the change). If the same organisation performs both roles, it may be difficult to prove that the ISA’s product‑level assessment is not influenced by the system‑level risk assessment performed by the same company. In practice, most railway undertakings and infrastructure managers require separate entities for ISA and AsBo. The CENELEC standards also require that the ISA be “independent of the design and development teams,” which is easier to demonstrate when the ISA is from a different company.

2. How is the Safety Integrity Level (SIL) determined for a product?

The SIL is determined through a risk analysis process, typically described in EN 50126. The process begins with a hazard identification (e.g., using a hazard log). For each hazard, the risk is assessed in terms of frequency and consequence. The tolerable risk level is then allocated to the system, and the safety functions required to reduce the risk are assigned SILs. The target SIL for a function depends on the reduction needed. For example, if a hazard has a risk of 10⁻⁵ per hour and the tolerable risk is 10⁻⁸ per hour, a reduction of 10⁻³ is required, which corresponds to SIL 3 (reduction factor of 1000). The ISA does not determine the SIL; instead, it verifies that the process used to assign SILs is sound and that the product has been developed to meet that SIL. For SIL 4, the reduction factor is 10⁻⁵, requiring extremely rigorous development and testing.

3. What is the difference between a “safety case” and a “safety assessment report”?

A safety case is the document produced by the developer (or the applicant) that argues why the product or system is safe. It typically includes the hazard log, safety requirements, evidence of verification and validation, and arguments linking these elements (often using Goal Structuring Notation – GSN). The safety assessment report is the output of the ISA (or AsBo) after reviewing the safety case. The report states whether, in the assessor’s opinion, the safety case is valid and whether the product meets the required SIL. The safety case is the developer’s claim; the safety assessment report is the independent expert’s verdict. For a product to be accepted for use, both documents are typically required.

4. How does an ISA verify that software testing has achieved 100% MC/DC coverage?

MC/DC (modified condition/decision coverage) is a rigorous coverage metric required for SIL 4 software. It ensures that each condition in a decision has been shown to independently affect the outcome. The ISA does not typically run the tests itself but reviews the evidence. The developer provides a coverage report from a tool (e.g., VectorCAST, LDRA, or a custom test harness) that shows each line of code, each branch, and each condition has been exercised and that the independence of conditions has been demonstrated. The ISA checks that the test suite is exhaustive, that there is no dead code, and that the coverage reports are consistent with the requirements traceability. In some cases, the ISA may witness the execution of a subset of tests to verify that the tool’s coverage claims are accurate. For SIL 4, it is also common to require an independent verification of the coverage results by a separate team within the developer’s organisation, and the ISA reviews that independent verification.

5. Can an ISA be an internal employee of the manufacturer?

The CENELEC standards (EN 50126) require that the ISA be “independent of the design and development teams.” This does not necessarily require the ISA to be external to the company, but it does require organisational independence. For example, a large manufacturer may have a separate safety department that reports to a different directorate than the project team. That internal safety department can perform the ISA role if it has no involvement in the design and has a direct reporting line to top management. However, many infrastructure managers and safety authorities prefer an external ISA to avoid any appearance of conflict. In practice, for SIL 4 products (e.g., ETCS onboard computers), external ISA is almost always used. For lower SILs, internal ISA may be acceptable if the independence criteria are strictly followed. The key is that the ISA must have the authority to raise issues without fear of reprisal, and the developer must document how independence is maintained.