FENNECHow to Prepare for a Functional Safety Assessment: What NRTLs Actually Look For
What NRTLs actually check during a functional safety assessment, in the order they check it, so you can structure your documentation before the review starts instead of during it.
)
Most teams find out what an NRTL assessor actually checks by going through the assessment unprepared. That is an expensive way to learn. Reviews that should take weeks stretch into months. Gaps discovered during assessment become last-minute documentation sprints. And the assessor comes back.
This post covers what NRTLs look for, in the order they typically look for it, so you can structure your documentation before the assessment starts rather than during it.
What an NRTL Assessment Actually Is
Nationally Recognized Testing Laboratories, organizations like TUV Rheinland, UL, and Intertek, conduct third-party assessments to verify that a product’s safety lifecycle meets the requirements of applicable standards such as IEC 61508, ISO 13849, or IEC 62061.
The assessment is not a test of your engineering judgment. It is a documentation audit. The assessor is checking whether you can demonstrate, with objective evidence, that you did what the standard requires, in the right order, with the right rigor, and with traceable links between every step.
That distinction matters because many engineering teams prepare for an assessment as if they are defending design decisions. What they actually need to defend is process. If your process is documented and traceable, the design decisions follow.
What Assessors Check First: Traceability
The first thing an assessor looks for is a complete chain from hazard to test. That chain runs through your HARA (hazard analysis and risk assessment), safety requirements, design decisions, and verification evidence.
If any link in that chain is missing or inconsistent, everything downstream is in question.
Common traceability failures:
Safety requirements that reference hazards by name but not by ID, making the link ambiguous
Design documentation that describes mitigations without citing which requirements they satisfy
Test evidence that covers functions but cannot be mapped back to specific SIL-determined requirements
Hazards that appear in the HARA but have no corresponding requirement in the safety requirements specification
Assessors are not trying to find one missing link to fail you. They are trying to confirm that the chain is complete. If they can follow it without stopping to ask questions, that is good. If they have to ask, that is where delays start.
The Evidence Completeness Gap
The gap between what teams think they have and what assessors expect to see is usually not about the engineering work itself. It is about documentation completeness and format.
What Assessors Check | What Teams Typically Have Ready |
|---|---|
Traceable hazard-to-requirement links with IDs | Narrative HARA with informal references |
SIL determination rationale per hazard | Single SIL number in design spec, no derivation |
Safety requirements specification (SRS) | Requirements spread across multiple documents |
Architecture description with safety mechanism justification | Block diagram with no safety rationale |
Verification plan with requirement-level coverage | Test plan structured around features, not requirements |
Verification results linked to plan items | Test reports with pass/fail, no requirement mapping |
Validation evidence for the safety function | Acceptance test results in a separate folder |
Tool qualification documentation (if applicable) | None, or incomplete vendor documentation |
Safety case with explicit argument structure | Engineering summary document |
The right column is not wrong engineering. It is incomplete documentation. Assessors need the left column.
Tool Qualification: The Overlooked Requirement
If your safety lifecycle uses software tools to generate, analyze, or verify safety-relevant outputs, those tools may require qualification under IEC 61508 Part 6, Annex D (or equivalent). T2 is the category most teams encounter: tools whose output could contain errors that propagate into the safety case without detection.
Most teams either do not know this applies to their tools or discover it during the assessment. Either way, the result is the same: retroactive validation work that delays certification.
Fennec's specified ASAP tools are qualified by TÜV Rheinland as Tool Class 2 (T2) offline support tools under IEC 61508-3:2010, Clause 7.4.4. The qualification documentation supports review of the named tools and versions. It does not eliminate project-specific validation or assessment work.
If you are using unqualified tools for any safety-relevant task in the lifecycle, your assessor will ask about it. Having the answer ready is significantly better than discovering the gap during the review.
What a Safety Case Argument Structure Looks Like
A safety case is not a summary of your engineering work. It is a structured argument, with claims, evidence, and reasoning, that your system is acceptably safe for its intended use.
Assessors look for three things in a safety case argument:
Claims are explicit. Each safety property being claimed is stated clearly, not implied by the evidence.
Evidence is cited, not assumed. Each claim is supported by a specific document, test result, or analysis with a traceable reference.
Reasoning connects them. The argument explains why the evidence supports the claim. A list of documents is not a safety case.
The V-Model maps the lifecycle stages where safety case elements are generated. If your safety case is built as you go, each stage producing its corresponding evidence, the final argument is assembled from existing documentation. If it is written after the fact as a summary, the assessor will ask for the underlying evidence anyway.
The technical file is the container. The safety case is the argument inside it. Both need to be in order.
How ASAP Pre-Structures for Assessment
ASAP is built around the assumption that assessment is coming. The documentation structure follows what assessors expect to read, not what is convenient to produce during development.
Key structural choices that matter at assessment time:
Traceability is automatic. Requirements are linked to hazards by ID at creation. That link persists through design and into verification. The assessor can follow the chain without asking you to reconstruct it.
The T2 Tool Qualification is already done. Fennec's specified ASAP tools are qualified by TÜV Rheinland as Tool Class 2 (T2) offline support tools under IEC 61508-3:2010, Clause 7.4.4. The reports define the applicable tools, versions, and scope; no broader platform or lifecycle claim should be inferred.
The technical file is generated, not assembled. ASAP can generate a 500-page technical file with one click. Every required section, cross-referenced and indexed, structured the way assessors expect. Teams that build this manually spend weeks on compilation and formatting. That time goes somewhere else.
A structured technical file lets an assessor follow the chain from hazards through requirements and verification evidence without first reconstructing missing traceability. The assessment still includes project-specific review, working meetings, and resolution of open items.
That is the goal. Not an impressive binder. A review that moves.
Frequently asked questions
What is the difference between an NRTL assessment and a certification audit?
An NRTL assessment is conducted by a Nationally Recognized Testing Laboratory to evaluate conformance to a safety standard. Certification is the outcome if the assessment passes. The terms are sometimes used interchangeably, but technically the assessment is the evaluation process and certification is the result.
Do I need tool qualification if I'm only using commercial off-the-shelf tools?
It depends on the tool's role in the safety lifecycle. If a commercial tool generates, analyzes, or verifies safety-relevant content (requirements, fault trees, SIL calculations, test coverage reports) and errors in its output could affect the safety case without detection, the tool likely requires T2 qualification under IEC 61508. Vendor documentation alone is not sufficient for most assessors.
How far in advance should I start preparing documentation for an NRTL assessment?
Documentation preparation should happen throughout the lifecycle, not at the end. If you are starting from scratch at the end of development, expect six to twelve weeks minimum for a well-organized team, longer if traceability needs to be reconstructed. Teams using lifecycle tools with built-in traceability can compress that significantly.
What causes most assessment delays?
Incomplete traceability is the most common cause. Assessors find a gap between a hazard and its corresponding requirement, or between a requirement and its test evidence, and issue a finding. The team then has to produce documentation that should have been generated during development. That cycle can repeat several times before the assessment closes.
Can we use a pre-qualified toolset and still have assessment findings?
Tool qualification addresses one category of assessment evidence. The assessor still reviews the hazard analysis, requirements, architecture, verification evidence, tool use, and safety-case argument. Qualification of specified tools and versions does not eliminate project-specific findings or lifecycle documentation requirements.
)