ETSO authorization
Configuration management support for an ETSO authorization
This review examines the configuration management evidence behind an EASA European Technical Standard Order authorization, meaning the baselines, revision control, release records, and change history that fix exactly which version of the article and its data the authorization covers. A certification specialist confirms that the submitted evidence belongs to a single controlled configuration and that every artifact cited is at the revision the baseline defines. It runs before the package is frozen for submittal, while a mismatched revision can still be reconciled. You receive a gap assessment, an evidence map tying each artifact to its baseline revision, and a closure plan for the items that fall outside control.
When this review is needed
- The package is nearing freeze and the supplier wants the baseline confirmed before submittal.
- Multiple artifacts revised during development and the cited revisions must be reconciled to one baseline.
- A late change updated some data but not every artifact that references it.
- The article's software and hardware carry their own configuration indices that must agree with the top baseline.
The problem
A certification package is assembled from artifacts that each move on their own schedule, and configuration management is what pins them to a single agreed version. In practice the pins slip. A report is updated but the matrix still cites the prior revision, the software configuration index names a build the verification records do not match, or a change is released in one artifact and left pending in another. The package looks internally consistent until someone reads the revisions, and then it turns out to describe two or three different configurations at once.
What gets reviewed
- The top-level configuration baseline and the artifacts it should contain
- The revision of each cited artifact against the baseline it belongs to
- Release records confirming each artifact was released, not left in draft
- Change history showing every change reached all the artifacts it touches
- Software and hardware configuration indices against the top-level baseline
- Consistency between the configuration records and the compliance matrix citations
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 artifact in the package sits at the revision the baseline defines
- Each cited artifact has a release record and none is left in draft status
- A change released in one artifact reached every other artifact it affects
- The software and hardware configuration indices agree with the top baseline
- The compliance matrix cites the baseline revision, not a superseded one
Evidence normally required
- The configuration management records and the top-level baseline definition
- The release records for each artifact in the package
- The change history and the status of any pending changes
- The software and hardware configuration indices
- The compliance matrix with the revisions it cites
Common discrepancies
- A change released in one artifact but left pending in another it affects
- Cited artifacts still in draft with no release record behind them
- A software or hardware index naming a build the records do not match
- The compliance matrix citing a revision the baseline has since superseded
What is at stake
If the authorization is granted against evidence from mixed configurations, the applicant cannot cleanly show what was actually approved, and any later change has to start from a baseline that was never truly fixed. Discovered at submittal, a configuration mismatch forces a reconciliation pass across every affected artifact, which delays the freeze the whole schedule was built toward.
How the work runs
Define the baseline
Establish the top-level configuration baseline and the set of artifacts it should contain at fixed revisions.
Check the revisions
Confirm each cited artifact sits at its baseline revision and carries a release record rather than draft status.
Trace the changes
Follow each change through the artifacts it affects and flag any left pending in one of them.
Reconcile the package
Deliver a gap assessment and a closure plan for the artifacts and indices outside the controlled baseline.
What the buyer receives
- A gap assessment of artifacts outside the controlled baseline
- An evidence map tying each artifact to its baseline revision and release record
- A closure plan for the revisions and pending changes needing reconciliation
Who uses the output
- Compliance managers confirming a single baseline before freeze
- Certification leads deciding the package is ready to submit
- Configuration and engineering staff reconciling the mismatched revisions
How the work fits into the transaction or program
Configuration management is the last thing that has to hold before a package is frozen, because it decides which version of everything the authorization actually covers. Confirming one controlled baseline before submittal means the authorization attaches to a configuration the applicant can point to later, rather than a mix of revisions that unravels the first time a change has to be traced back to what was approved.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
EASA grants the ETSO authorization against a specific configuration, and the design organization's configuration management is expected to keep the approved baseline identifiable through later changes. The review reads the configuration records against that expectation, so the baseline the authorization attaches to is one the applicant can reproduce and amend cleanly under EASA's continued oversight.
Regulatory limits
The review evaluates the supplier's configuration management evidence. It does not operate the applicant's configuration management system, accept the baseline on EASA's behalf, or determine that the configuration is approvable in the authority's judgment. Those roles stay with the applicant and EASA.
What this review does not cover
- Operating the applicant's configuration management system
- Accepting the baseline on the authority's behalf
- Releasing or revising the artifacts the package contains
Specific to this review
- A package can be internally consistent in its content yet describe several configurations at once, because consistency of wording is not the same as consistency of revision.
- A change is only fully released when every artifact it touches has been revised, so a change pending in even one artifact leaves the baseline mixed.
- The baseline the authorization attaches to becomes the starting point for every future change, so a baseline that was never truly fixed complicates every amendment that follows.
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
Our documents are all under version control already. What does this add?
Version control tracks each artifact on its own. This review checks that the artifacts agree with one another, that a change reached every document it affects, and that the whole package cites a single baseline revision, which is where independently versioned files most often diverge.
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.