Continued airworthiness
ICA package evidence review for software assurance teams
This review checks that an ICA package actually covers the configuration it will be issued against. A certification engineer reads the maintenance tasks, airworthiness limitations, parts data, and configuration coverage in the ICA, then confirms each element matches the approved design and the modification the certification introduces. Assurance teams run it before the ICA goes out with an STC or TSO approval, in a finding response, or when a design change outpaces the maintenance data. You receive a gap list, an evidence map, and a closure sequence keyed to the approved configuration.
When this review is needed
- An ICA package is nearly ready to accompany an STC or TSO approval and has never been read against the final configuration.
- The authority questioned whether an airworthiness limitation traces to the safety analysis behind it.
- A late design change altered a part or interface and the maintenance data may not yet reflect it.
- The ICA was drafted against an early configuration that has since moved on.
The problem
The ICA is usually finished last and updated least. Design and verification get the attention, and the maintenance data gets written against a configuration that keeps changing underneath it. By the time the package is assembled, a task can reference a part that changed number, a limitation can lag a revised safety analysis, and the coverage can miss an interface the modification introduced, all while the certification data itself looks complete.
What gets reviewed
- Maintenance tasks and their intervals against the modification the certification introduces
- Airworthiness limitations and their trace to the safety analysis that set them
- Parts data, including part numbers and applicability, against the approved configuration
- Configuration coverage across every effectivity the approval applies to
- Consistency between the ICA and the approved design data it must reflect
- Currency of the ICA against the final, not an interim, configuration
What gets validated
- Each airworthiness limitation traces to the safety analysis or certification basis that established it
- Maintenance tasks reference part numbers that match the approved configuration
- Configuration coverage spans every effectivity the approval names, with none omitted
- The ICA reflects the final configuration, not an earlier draft the design has since passed
- Task intervals and limitations are consistent with the assumptions the certification relied on
Evidence normally required
- The ICA package including maintenance tasks and airworthiness limitations
- The approved design data and configuration for the modification
- The safety analysis that set the limitations
- The parts data and applicability for the affected configuration
- The change history if a late design change prompted the review
Common discrepancies
- An airworthiness limitation that no longer matches a revised safety analysis
- A maintenance task citing a part number the final configuration superseded
- Configuration coverage that omits an effectivity the approval applies to
- An ICA section drafted against an interim design the program has since moved past
What is at stake
An ICA that does not match the approved configuration leaves the field with maintenance data that cannot be relied on, which is both an airworthiness exposure and a finding the authority will not let pass. Correcting it after issue means a revision cycle and re-distribution, and in service it means operators working to instructions that do not fit the aircraft in front of them.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Anchor to the final configuration
Establish the approved configuration the ICA must cover before reading a single task.
Trace the limitations
Confirm each airworthiness limitation traces to the safety analysis or basis that set it.
Check tasks and coverage
Verify part numbers, tasks, and effectivity coverage against the approved design data.
Sequence the updates
List the mismatches and order the ICA revisions before the package issues with the approval.
What the buyer receives
Who uses the output
- Assurance leads confirming the ICA is ready to issue with the approval
- Certification leadership answering a finding on an airworthiness limitation
- Engineering leads updating maintenance data a late change left behind
How the work fits into the transaction or program
The ICA is the bridge from certification into service, carrying the maintenance data operators will use for the life of the modification. Reading it against the final approved configuration before issue keeps the field from inheriting instructions that lag the design, and keeps the authority from holding the approval over a maintenance-data gap.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both require ICA with an approval, and both treat the airworthiness limitations section as approved data, but they differ on format expectations and on how limitations are called out and controlled. The review notes where an ICA structured for one authority would need adjustment before it accompanies an approval from the other.
Regulatory limits
This review reads the ICA for coverage and consistency against the approved configuration. It does not author the ICA, approve the airworthiness limitations, or make a compliance finding. Approval of the ICA and its limitations rests with the authority.
What this review does not cover
- Writing or revising the maintenance tasks or limitations
- Approving the airworthiness limitations section
- Any compliance finding on the ICA package
Specific to this review
- The ICA is the artifact most likely to lag the design, because it is finished last and rarely re-checked when the configuration moves.
- Airworthiness limitations are approved data, so a limitation that no longer matches the safety analysis is a hard finding, not an editorial one.
- An omitted effectivity in the coverage is easy to miss on a multi-configuration approval and surfaces in service rather than at review.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Federal Aviation Administration. STC application process, certification basis, and continued airworthiness obligations of an STC holder.
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
Frequently asked questions
Why review the ICA separately from the rest of the certification data?
Because it is written last and against a moving configuration, the ICA drifts in ways the design data does not. It also carries approved airworthiness limitations that go straight into service, so a mismatch here has consequences the other packages do not.
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.