Skip to content

ETSO authorization

Finding and action-item register support for ETSO authorization

This review reconciles the finding and action-item register that tracks open issues across an ETSO authorization program, confirming each item has an owner, an evidence link, and a closure state that the evidence actually supports. It is run by or for an equipment or avionics supplier as the register is driven toward zero open items ahead of formal review. It looks at whether items marked closed carry the document that closes them, whether closures introduced new configuration changes that were never captured, and whether the register accounts for every issue raised. You get a gap assessment, an evidence map per finding, and a closure plan for the items that are closed in status but open in fact.

When this review is needed

  • The register is being driven to zero before formal review and each closure needs the evidence that supports it attached.
  • A finding was closed by a design change that itself was never traced into the configuration or the compliance record.
  • Ownership of open items has become unclear after handoffs between engineering, quality, and certification.
  • An issue raised early in the program cannot be located in the current register and may have been dropped rather than closed.

The problem

A finding register accumulates status changes faster than it accumulates evidence. An item gets marked closed in a review meeting on the strength of a verbal commitment, a promised memo, or a fix that has not yet been documented, and the status sticks even though the closing artifact never arrives. When several people work the register across a long program, closures made on trust pile up, and the register reports a clean state that the underlying evidence does not back.

What gets reviewed

  • Each open item assigned a clear owner and a defined closure criterion
  • The closure status on each item reconciled against the artifact that actually closes it
  • Findings closed by a design change checked for a trace into the configuration and compliance record
  • The register cross-checked against review minutes and correspondence for issues raised but not logged
  • Status language normalized so a closed entry means the same thing across the register
  • Every issue raised in the program accounted for as open, closed with evidence, or withdrawn on the record

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

  • Each item marked closed is backed by a retrievable artifact that satisfies its stated closure criterion
  • A finding closed by a design change traces to the configuration update and the affected compliance evidence
  • No open item is missing an owner or a closure criterion
  • Issues raised in review minutes or authority correspondence all appear in the register
  • Closure language across the register is consistent, so a closed item means the same thing everywhere

Evidence normally required

  • The current finding and action-item register in whatever form it is maintained
  • Closure artifacts referenced by the register: memos, analyses, test reports, and design changes
  • Review minutes and authority correspondence that raised or discussed findings
  • The compliance record and configuration index the closures should map into
  • The ownership and workflow record for how items move through the register

Common discrepancies

  • An item marked closed whose referenced closure memo was never actually issued
  • A finding closed by a design change that was not traced into the configuration index
  • An issue raised in review minutes that never made it into the register
  • An open item with no owner after a handoff between engineering and certification

What is at stake

A register that reports closed items without closure evidence collapses under the authority's own audit, because each unsupported closure becomes a reopened finding at the worst possible moment. Findings closed by design changes that were never traced create a second problem: the fix exists but the configuration and compliance records do not reflect it, so the authorization rests on a state the paperwork does not describe.

How the work runs

01

Reconstruct the issue list

Cross-check the register against review minutes and correspondence so every raised issue is accounted for.

02

Test each closure

Confirm every closed item is backed by a retrievable artifact that meets its closure criterion.

03

Trace design-change fixes

Follow findings closed by design changes into the configuration and compliance records.

04

Plan the real closures

List items that are closed in status but open in fact and sequence the evidence needed.

What the buyer receives

  • A gap assessment of register entries whose closure status the evidence does not support
  • An evidence map linking each finding to the artifact that closes it
  • A closure plan for items that are closed in status but open in fact

Who uses the output

  • Certification leads confirming the register is genuinely at zero before formal review
  • Quality staff verifying that each closure carries a retrievable artifact
  • Engineers reconciling design-change closures back into the configuration record

How the work fits into the transaction or program

The finding register is the program's running account of what still stands between the article and its authorization, so its integrity determines whether the authority audits a clean state or a reported one. This review sits at the end of the closure push, catching status-only closures and untraced design-change fixes before the authority runs its own audit and turns each unsupported closure back into an open finding.

Start with a single asset

Reduce finding cycles by checking the package first.

Jurisdiction-specific considerations

EASA's review of an ETSO application will sample the finding register and expect each closure to stand on evidence the applicant can produce on request, so a status that outruns its artifact is a finding in itself. Where the program also feeds an FAA TSO effort, findings closed for one authority may still be open for the other, and the review flags where a shared register hides a divergence in closure state between the two.

Regulatory limits

The review reconciles the register against the evidence behind each closure. It does not close findings on the applicant's behalf, judge the technical adequacy of a fix, grant the ETSO authorization, or bind the certifying authority to accept any item as closed.

What this review does not cover

  • Performing the engineering work that closes an open finding
  • Making the technical adequacy judgment on a proposed fix
  • Any authority acceptance of the register or its closures

Specific to this review

  • Status outruns evidence on a finding register because items get closed in meetings on the strength of a promise before the closing artifact is ever produced.
  • A finding closed by a design change is a double risk: the fix may be real while the configuration and compliance records that should reflect it were never updated.
  • The register's worst gaps are issues raised but never logged, because a missing entry cannot be audited and only surfaces when the authority compares minutes to the register.

Sources

Frequently asked questions

What is the difference between an item being closed and being closed with evidence?

A closed status means someone judged the issue resolved; closed with evidence means the artifact that resolves it exists and can be produced. The authority audits the second, not the first, so a register that reports closures it cannot evidence reopens under review.

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.