Safety assessment evidence
Safety assessment evidence review for quality teams
This review reads a safety assessment as a connected chain, confirming that the hazards, the derived safety requirements, and the verification that closes them actually tie together. A certification specialist works through the FHA, PSSA, and SSA and their feedback into requirements with your quality function, and finds where a safety result never became a requirement or where a closed requirement lacks verification. It runs before submittal, during a finding response, or when a change reopens hazards or safety requirements already assessed. You receive a gap list, a map from each safety result to its requirement and verification, and a closure sequence for quality leadership.
When this review is needed
- A safety assessment is heading to submittal and quality wants its results confirmed to trace into requirements and verification.
- A finding questions whether a hazard's mitigation actually became a requirement and was then verified.
- A change reopens a failure condition or a safety requirement the assessment already treated as closed.
- The FHA, PSSA, and SSA were produced at different phases and no one has read them as one continuous chain.
The problem
A safety assessment is built in stages across the program, and the links between those stages are where it comes apart. The FHA names failure conditions, the PSSA derives protections, the SSA is meant to confirm them, but a derived safety requirement gets stated in the assessment and never crosses into the requirement set, or a mitigation the SSA credits was never actually verified. Quality inherits three documents that each read complete and a chain between them that has quiet breaks.
What gets reviewed
- Failure conditions from the FHA traced to the derived safety requirements meant to mitigate them
- Derived safety requirements confirmed to have crossed into the requirement set rather than living only in the assessment
- Mitigations the SSA credits confirmed to be implemented and verified, not assumed
- Development assurance levels assigned by the assessment reconciled with the levels the design data was built to
- Assessment feedback into requirements checked so the loop from hazard to requirement to verification is closed
- Failure conditions or requirements touched by a change checked for re-assessment against the current design
What gets validated
- Each failure condition traces to a derived safety requirement that carries its mitigation
- Every derived safety requirement in the assessment exists in the requirement set and is traceable there
- Each mitigation the SSA credits resolves to verification evidence, not to an assumption of implementation
- The assurance levels the assessment assigns match the levels the software and hardware data were actually built to
- Failure conditions reopened by a change carry a re-assessment rather than a stale prior result
Evidence normally required
- The FHA, PSSA, and SSA at their current revisions
- The requirement set the derived safety requirements should appear in
- The verification records that close the safety-driven requirements
- The development assurance level assignments the assessment produced
- Change records for any failure condition or safety requirement altered since the assessment was compiled
Common discrepancies
- A derived safety requirement stated in the assessment but absent from the requirement set
- A mitigation the SSA credits that was never implemented or never verified
- An assurance level assigned by the assessment that the software or hardware data does not actually meet
- A failure condition reopened by a change while the SSA still carries the pre-change result
What is at stake
A safety result that does not close to a verified requirement is the failure a reviewer treats most seriously, because it touches the safety argument directly. They trace a failure condition to its mitigation and find the mitigation was assumed rather than implemented and verified, and the assessment that read finished reopens along with any requirement and verification it should have driven. A broken safety chain can unwind work well outside the assessment itself.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Read the chain end to end
Follow each failure condition from the FHA through the PSSA and SSA so breaks between the stages surface.
Confirm requirements crossed over
Check that each derived safety requirement in the assessment exists in the requirement set and is traceable there.
Confirm mitigations were verified
Confirm each mitigation the SSA credits resolves to real verification, not an assumption of implementation.
Sequence the closures
Order the gaps so requirement gaps close before the verification that depends on them.
What the buyer receives
- A gap list naming each safety result that does not close to a requirement and verification
- A safety-to-evidence map tying each failure condition to its requirement and verification
- A closure sequence ordering the gaps so requirement gaps are closed before the verification that depends on them
Who uses the output
How the work fits into the transaction or program
The safety assessment is the argument the rest of the certification data serves, so a break between a hazard and its verified mitigation weakens the whole package underneath it. This review runs before submittal, closing the loop from hazard to requirement to verification while the fixes are still tractable rather than after a reviewer pulls the safety thread and unwinds the work behind it.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both anchor the safety assessment to the same development assurance process, and the FHA, PSSA, and SSA structure is common to each. The acceptance path differs: FAA delegated findings against a project plan on one side, EASA review items and means-of-compliance acceptance on the other. The review reads the safety chain against whichever finding path the program is filing under.
Regulatory limits
This review reads your own safety assessment and reports where its chain to requirements and verification holds and where it breaks. It does not make an airworthiness determination, does not accept the safety case, and does not replace the authority's or the delegate's review of the safety data.
What this review does not cover
- Performing or re-performing the safety analyses themselves
- Authoring the missing safety requirements or verification the gaps call for
- Accepting the safety case, which the authority reserves
Specific to this review
- The safety assessment fails most often at its seams, where the FHA, PSSA, and SSA were produced in different phases and a result in one never crossed into the next.
- A derived safety requirement that lives only in the assessment and never enters the requirement set is a common and serious gap, because the mitigation exists on paper and nowhere in the design.
- The assurance levels the assessment assigns are a contract with the software and hardware data, so a mismatch there invalidates the level those data sets were built to.
- A mitigation credited in the SSA but never verified is the failure a reviewer weighs most heavily, because it reaches the safety argument directly.
Sources
SAE International. Safety assessment methods (FHA, PSSA, SSA, FTA, FMEA) supporting development assurance level assignment.
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Frequently asked questions
Do you redo the safety analysis, or check that it connects?
Check that it connects. The review takes your FHA, PSSA, and SSA as given and confirms the chain holds: hazards to derived requirements, derived requirements into the requirement set, and credited mitigations to verification. Where a link is missing it names it and sequences the fix, and your safety engineers do any re-analysis the gap requires.
Relevant glossary terms
Related pages
Where this fits
Talk to an engineer who has done this work
We will walk through your current state, the records or evidence involved, and a scoped first engagement.
Talk through the aircraft, records, evidence, deadline, and next useful step.