ETSO authorization
Verification traceability support for an ETSO authorization
This review examines verification traceability for an EASA European Technical Standard Order authorization: the evidence side of the chain, where test, analysis, inspection, and design-review results are supposed to close the requirements assigned to them. A certification specialist confirms that a requirement marked verified actually points at a result that demonstrates it, at the right conditions and the right revision. It runs as verification results accumulate, before the accomplishment summary is cut. You receive a gap assessment of requirements claimed met without supporting evidence, an evidence map tying each requirement to its verifying result, and a closure plan for the gaps.
When this review is needed
- Verification results are accumulating and the supplier wants them checked before the summary is cut.
- A requirement is marked verified by test and the linked result must be confirmed to cover the tested conditions.
- Analysis results were used to close requirements and the assumptions behind them need confirming against the design.
- The program is approaching submittal and needs to know which requirements are genuinely closed.
The problem
By the time verification is running, requirements start getting flipped to closed, and the pressure to show progress makes that flip optimistic. A result gets linked to a requirement it only partly covers, a test that ran at one temperature is cited for a requirement written at another, or a requirement is marked verified on the strength of a result that is still draft. The trace shows a wall of closed items, but some of those closures do not survive a careful read of the evidence they cite.
What gets reviewed
- Each requirement marked verified checked against the result linked to close it
- Test results confirmed to cover the conditions and limits the requirement states
- Analysis results checked against the assumptions and the design they rely on
- Inspection and design-review evidence confirmed to address what it claims to close
- Requirements marked met that link to draft, partial, or superseded results
- Consistency between the verification trace and the compliance matrix
Scope this review
Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.
Identify what is missing against the means of compliance.
What gets validated
- Every requirement marked verified links to a released result, not a draft one
- A requirement closed by test cites a result covering the stated conditions and limits
- An analysis used to close a requirement rests on assumptions the design supports
- Inspection and review evidence addresses the full requirement, not part of it
- No requirement is marked met against a result that has since been superseded
Evidence normally required
- The verification traceability data at its current revision
- The test reports, analyses, inspection records, and review minutes cited
- The requirement set the verification is closing against
- The verification plan and its pass or fail criteria
- The compliance matrix that reports the verification status
Common discrepancies
- Requirements marked verified against results that are still draft
- Test results cited for conditions the test did not actually run
- Analyses whose assumptions no longer match the current design
- Requirements closed by evidence that covers only part of the requirement
What is at stake
A requirement closed against evidence that does not cover it reopens the moment the authority reads the result, and it takes the accomplishment summary with it. Worse, a verification gap found near submittal can mean re-running a test or re-scoping an analysis, which needs equipment and schedule the program had already released, pushing the authorization date out.
How the work runs
Pull the closed set
List every requirement marked verified and the result each one links to for closure.
Open the evidence
Confirm each result is released and actually covers the conditions and scope of its requirement.
Test the analyses
Check that analysis closures rest on assumptions the current design still supports.
Flag the false closures
Deliver a gap assessment and a closure plan for the verifications that do not hold up.
What the buyer receives
- A gap assessment of requirements claimed met without adequate evidence
- An evidence map tying each verified requirement to the result that closes it
- A closure plan for the requirements whose verification does not hold
Who uses the output
- Certification leads deciding which requirements are truly closed before summary
- Compliance managers reconciling verification status to the matrix
- Engineers re-running or re-scoping the verification the review flagged
How the work fits into the transaction or program
Verification traceability is where requirements turn into demonstrated compliance, and the accomplishment summary is cut from it. Reading the evidence before the summary is frozen means the closures that reach the authority are ones that survive scrutiny, so the summary reports real completion rather than an optimistic count that unwinds under review.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
EASA reads verification evidence against the conditions the requirement states and the standard invokes, and a result that would be accepted loosely elsewhere is checked here against that stricter reading. The review confirms each closure at the conditions EASA expects for the ETSO, so the trace holds under the authority that will actually read it.
Regulatory limits
The review evaluates the supplier's verification evidence. It does not perform the verification, accept the results on EASA's behalf, or determine that a requirement is met in the authority's judgment. Acceptance of the evidence remains with EASA.
What this review does not cover
- Performing or re-running the verification activities
- Accepting verification results on the authority's behalf
- Cutting the applicant's accomplishment summary
Specific to this review
- A test result is only valid for the conditions it was run at, so citing it for a requirement written at other conditions is a common and quiet failure.
- Analysis closures depend on assumptions that the design can move out from under, so an analysis that was valid at issue can silently stop supporting its requirement.
- Requirements closed against draft results look identical to real closures in the trace until the evidence is opened, which is why released status is checked per link.
Sources
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
RTCA. Environmental qualification test categories and procedures referenced by TSO and equipment qualification.
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
Frequently asked questions
How is this different from a requirements traceability review?
Requirements traceability confirms every requirement has a design and a verification assigned. This review goes to the evidence itself and confirms the verification result actually closes the requirement at the right conditions, rather than simply being linked to it.
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.