What Assessors Actually Want to See in Your Safety Technical File

You submit your technical file. Two weeks later, you get a list of questions. Some are clarifications. Most are requests for evidence you thought was already in there.

This cycle plays out on nearly every first submission. Not because the team didn’t do the work, but because the file wasn’t structured around what the assessor actually needs to evaluate.

How assessors actually review your file

They don’t read it cover to cover. They can’t. A 500-page technical file across a 4-week review window means they’re following threads, not reading prose.

An assessor starts at the hazard analysis. They pick a hazard. Then they trace it forward: through your safety concept to a safety function, from the safety function to a requirement, from the requirement to a design decision, from the design to the test evidence that validates it. If they can follow that thread without leaving the document or asking you a question, the review moves fast.

If the thread breaks, the review stalls.

Every gap generates a question. Every question adds days. A handful of gaps compound into weeks. And every week in review is a week your product isn’t shipping.

Five things that kill first submissions

These show up repeatedly across certification projects. Not edge cases. Patterns.

1. Traceability gaps. The hazard analysis exists. The requirements exist. The test evidence exists. But nothing connects them. The assessor can’t verify that requirement R-047 actually addresses hazard H-012 without manually cross-referencing three separate documents. That’s your job, not theirs.

2. Missing rationale. You chose PLd for a safety function. Why not PLc? Why not PLe? The standard requires a risk assessment that justifies the target. Many teams document the conclusion but skip the reasoning. Assessors don’t want to see just the answer. They want to see the logic that produced it.

3. Inconsistent naming. The hazard analysis calls it “Emergency Stop Function.” The requirements doc calls it “E-Stop Safety Function.” The test plan calls it “Emergency Shutdown.” Are these the same thing? Three different things? The assessor can’t tell. Naming drift sounds minor until someone flags 40 instances of ambiguity in a single review pass.

4. Orphaned test evidence. Test reports that don’t trace back to a specific requirement. Validation data that exists in the file but isn’t referenced anywhere in the safety case. It’s like a bibliography that nobody cites. The evidence is there, but it isn’t connected to the argument it’s supposed to support.

5. Undocumented assumptions. Every reliability calculation depends on assumptions. Failure rates, operating conditions, mission times, diagnostic coverage factors. When those assumptions aren’t stated explicitly, the assessor has to ask. When they’re stated but contradict other parts of the file, the assessor has to stop and investigate. Either way, the review slows down.

What good actually looks like

The technical files that move through assessment quickly share structural patterns that aren’t complicated. They’re just consistent.

Every hazard has a complete chain. Hazard to safety function to requirement to design implementation to test evidence. No gaps. No dangling references. The assessor can pick up any thread and follow it in either direction.

Rationale sits at the point of decision. The risk graph or risk matrix that determines the required performance level or SIL sits next to the hazard it evaluates. Not buried in an appendix. Not in a separate document the assessor has to request.

Naming is governed, not improvised. One name per artifact, used everywhere. If the safety function is “SF-003: Emergency Stop,” it’s called exactly that in every document, every table, every test reference. No synonyms. No abbreviations that only make sense to the person who wrote them.

Reliability calculations show their work. Component failure rates cite their source (manufacturer data, SN 29500, OREDA). Architectural constraints are stated. The calculation path from individual component reliability to the system-level performance level is traceable step by step.

A file built with structural traceability keeps the rationale and evidence connected. That lets an assessor follow the chain without first reconstructing missing links, while project-specific questions and conclusions remain part of the review.

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.

Structure beats volume

Teams often confuse thoroughness with page count. A 700-page file with poor structure is harder to assess than a 400-page file with clear traceability. Assessors aren’t counting pages. They’re following threads.

So the question isn’t “did we document enough?” It’s “can the assessor follow the chain from any hazard to its validation evidence without stopping to ask where something went?”

When safety documentation is generated as a byproduct of a structured process, the traceability exists because the work was done in sequence, with each artifact linked to its predecessor. When documentation is assembled after the engineering is done, the traceability has to be manually reconstructed. That’s where gaps appear. That’s where naming drifts. That’s where the assessor’s first question starts a cascade.

FAQ: Safety Technical File Assessment

What does an assessor actually look for in a safety technical file? Assessors follow threads, not pages. They pick a hazard and trace it forward: to the safety function it requires, to the requirement that addresses it, to the design decision that implements it, to the test evidence that validates it. A complete chain they can follow without asking questions is what moves a review forward. A broken chain is what stops it.

Why do most technical files fail first submission? Traceability gaps, not missing content. The engineering work exists. The documentation exists. But the connections between them weren’t built as the work progressed. Assessors can’t verify a requirement addresses a hazard if the link isn’t explicit. Manual reconstruction after the fact consistently produces gaps.

What is the most common documentation pattern that adds review time? Inconsistent naming. When the same artifact is called three different things across three documents, the assessor can’t confirm it’s the same artifact without stopping to ask. One name per artifact, used exactly the same way everywhere, removes a whole category of follow-up questions.

What does T2 Tool Qualification mean for an assessor reviewing your file? Tool Class 2 qualification applies to specified tools and versions. It does not qualify the entire platform, remove project-specific review, or predetermine an assessor's conclusions.

How do you build traceability that survives assessment? Traceability has to be generated as the work proceeds, not rebuilt afterward. When every hazard is linked to a safety function during the HARA, and every requirement to test evidence during V&V, the chain exists because it was built in sequence. Assembling it after the fact produces gaps. Assessors find those gaps.

This post covers general functional safety engineering principles and is for educational purposes only. It is not engineering advice. Consult a qualified functional safety professional and your applicable standards body before making safety-critical design decisions.

If your last assessment generated more questions than confirmations, the issue probably isn’t missing content. It’s missing structure. Fennec Engineering’s ASAP platform generates assessment-ready technical files with built-in traceability across the full V-Model lifecycle. See what that looks like for your system.