Safety assessment
Safety assessment evidence review for hardware assurance teams
A safety assessment evidence review confirms that the functional hazard assessment, preliminary system safety assessment, and system safety assessment form a consistent chain and that their results trace to requirements and verification. It is run by a hardware assurance team before submittal, a finding response, or a change that affects the safety case. The review checks that each hazard's classification carries through to the derived requirements and that the SSA closes against verification that actually exists. You receive a gap list, an evidence map from safety result to requirement and verification, and a closure sequence for the assurance lead.
When this review is needed
- A safety assessment package is heading to submittal and its results have to trace to requirements and verification.
- A design change altered a failure condition and the safety chain has to be reworked to match.
- An authority finding questioned whether a hazard classification carried through to the derived requirements.
- The FHA, PSSA, and SSA were produced at different times and their consistency has never been checked end to end.
The problem
A safety assessment can be internally reasoned yet disconnected from the rest of the certification data. A hazard classified in the FHA drives derived requirements that never made it into the requirements set, or the SSA closes against verification the program descoped. Because the assessment is often written by a different team than the one that owns the requirements, the seams between them are where the safety argument quietly breaks.
What gets reviewed
- Failure conditions in the FHA checked for consistent classification through the PSSA and SSA
- Derived safety requirements traced from each hazard into the requirements set
- SSA closure evidence reconciled to verification results that actually exist
- Common-cause and independence claims checked against the design they rest on
- Requirement feedback from the assessment confirmed as captured in the requirements
- Design changes checked for consistent flow-through across the assessment chain
What gets validated
- Each failure condition classification in the FHA carries consistently into the PSSA and SSA
- Every derived safety requirement traces into the controlled requirements set
- The SSA closes against verification records that exist and are current
- Independence and common-cause claims are supported by the design as built
- A design change is reflected across the FHA, PSSA, and SSA rather than in one alone
Evidence normally required
- The functional hazard assessment with failure condition classifications
- The preliminary system safety assessment and its allocations
- The system safety assessment and its closure evidence
- The requirements set the safety requirements should trace into
- Verification records the SSA closure depends on
Common discrepancies
- A derived safety requirement that never entered the controlled requirements set
- An SSA that closes against a verification activity the program descoped
- A failure condition classified differently in the FHA than the SSA assumes
- An independence claim the as-built design does not support
What is at stake
A safety result that does not trace to a requirement or a verification record leaves the assurance argument incomplete, and an authority that finds the break can question the whole safety case. When a design change is not reflected across the FHA, PSSA, and SSA, the assessment argues for a system that no longer exists, which forces rework late in the program.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Walk the hazard chain
Follow each failure condition from the FHA through the PSSA into the SSA and check the classification holds.
Trace the requirements
Confirm every derived safety requirement reached the controlled requirements set.
Test SSA closure
Reconcile each SSA closure claim against verification records that actually exist.
Sequence the repairs
List the broken traces and order the work to close them before submittal.
What the buyer receives
Who uses the output
- Assurance leads confirming the safety case closes before submittal
- Certification leads answering a finding on a hazard classification or trace
- Engineering owners reworking the chain after a design change
How the work fits into the transaction or program
The review sits where the safety assessment meets the requirements and verification data, checking that the safety argument connects to the rest of the certification package. Its gap list drives the trace repairs and requirement updates that have to close, and its evidence map anchors the safety section of the submittal.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both accept the ARP4761A and ARP4754B framework, and each can expect the safety argument to be presented and substantiated in its own way. The review notes where a safety case satisfies one authority's expectation and where the other would ask for the classification rationale or independence argument to be shown differently.
Regulatory limits
The review checks the safety assessment for internal consistency and traceability. It does not perform the safety analysis, classify hazards on the program's behalf, or make an airworthiness or compliance determination.
What this review does not cover
- Performing or reworking the FHA, PSSA, or SSA analysis
- Classifying failure conditions or setting design assurance levels
- Determining airworthiness or acceptability of the safety case
Specific to this review
- The safety assessment is usually authored apart from the requirements set, so the seam between them is where derived safety requirements most often go missing.
- SSA closure is the point where a descoped verification activity does the most damage, because the closure claim outlives the test that was cut.
- A single design change can invalidate all three of the FHA, PSSA, and SSA, so change flow-through is checked across the whole chain rather than document by document.
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 if the trace breaks?
No. The review identifies where safety results fail to trace to requirements or verification and orders the repairs, but the analysis itself is reworked by the team that owns it. The output tells them precisely which links are broken and why.
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.