Certification plan
Certification-plan evidence review for software assurance teams
This review checks a software certification plan against the data package it commits to produce, so the plan does not promise coverage the evidence will not deliver. It runs before the plan is submitted, during a finding response, or when a change alters what the software has to demonstrate, and it is done by or with the software assurance team that owns the plan. The work examines the certification basis the plan cites, the areas it says the change affects, and the review and evidence commitments it makes, then flags every commitment the emerging data package cannot yet meet. You receive a gap list, an evidence map linking each plan commitment to its intended evidence, and a closure sequence for software assurance leadership.
When this review is needed
- A software certification plan is going to the authority and the team wants its commitments checked against what the package can deliver.
- A finding questions whether the plan's stated affected areas match the change actually being made.
- A change to the software scope has outrun the plan, which now describes a different effort than the one underway.
- The plan was written early to secure agreement and the data package has since drifted from it.
The problem
A certification plan is a promise made before most of the evidence exists. It fixes the basis, scopes the affected areas, and commits to a set of reviews and objectives, and the authority holds the applicant to it. But the plan is written when the change is least understood, and as the work proceeds the real scope shifts: an area thought unaffected turns out to be touched, a review the plan commits to is quietly dropped, an objective the plan claims will be met by analysis ends up needing test. When the package arrives, the mismatch between plan and evidence is what a finding lands on.
What gets reviewed
- The certification basis cited in the plan confirmed against the agreed basis of record
- Affected areas in the plan checked against the change actually being implemented
- Review and objective commitments checked for evidence the package will actually contain
- The claimed means of meeting each objective checked for feasibility given the emerging data
- Stage-of-involvement and coordination commitments checked against the program's real cadence
- Plan references confirmed against the applicable software level and its objectives
What gets validated
- The certification basis the plan states matches the agreed basis without an unstated deviation
- The affected-area scope in the plan covers everything the change actually touches, with nothing understated
- Each committed review and objective has an evidence path the data package is on track to deliver
- Objectives the plan says are met by one means are not, in practice, going to need another
- The plan's coordination cadence reflects how the program is actually engaging the authority
Evidence normally required
- The software certification plan in its current draft
- The agreed certification basis and applicable software level
- The change definition or scope the plan is meant to cover
- The emerging data package and its planned evidence set
- Any prior findings or agreements touching the plan
Common discrepancies
- An affected area the change actually touches that the plan scopes out
- A review the plan commits to that the current program cadence has effectively dropped
- An objective the plan says analysis will satisfy that the emerging evidence shows needs test
- A basis reference in the plan that diverges from the agreed basis of record
What is at stake
A plan the data package cannot honor forces a choice between amending the plan late, which reopens the agreement with the authority, and delivering evidence that does not match what was promised, which draws a finding. Either path costs schedule at the point where it is scarcest, and a plan that repeatedly overcommits erodes the credibility the applicant needs the authority to extend on later judgment calls.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Anchor the basis and scope
Confirm the plan's certification basis and affected areas match the agreement and the real change.
Test each commitment
Check that every committed review and objective has a deliverable evidence path.
Compare plan to package
Set the plan's promises against the emerging data package and flag what will not be met.
List and order the gaps
Record each undeliverable commitment and sequence scope and basis fixes before dependent ones.
What the buyer receives
- A gap list naming each plan commitment the data package cannot yet meet
- An evidence map linking each commitment to the evidence intended to satisfy it
- A closure sequence ordered so scope and basis corrections precede the commitments that depend on them
Who uses the output
- Software assurance leadership confirming the plan is deliverable before it is submitted
- Assurance engineers reconciling the plan's commitments with the evidence actually being produced
- Certification leadership deciding whether to amend the plan or realign the package to it
How the work fits into the transaction or program
The review runs while the plan is still shapeable, before it is submitted and before the authority holds the applicant to it. It confirms the plan matches the change and the emerging evidence, and its gap list drives the scope, basis, and commitment corrections that keep plan and package aligned.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both treat the software certification plan as the agreement that governs the effort, but they run their own stage-of-involvement and coordination expectations against it. The review notes where a plan drafted for one authority's engagement model needs restated commitments to serve as the governing plan for the other.
Regulatory limits
The review checks that the plan's commitments are deliverable and its scope is honest. It does not approve the plan, agree the certification basis, or accept the stage-of-involvement arrangement. Approval and agreement remain with the applicant's authorized representatives and the authority.
What this review does not cover
- Authoring the certification plan or negotiating the basis with the authority
- Approving the plan or its stage-of-involvement arrangement
- Producing the software evidence the plan commits to
Specific to this review
- A certification plan is written when the change is least understood and enforced when it is best understood, so scope drift between the two points is the defect the review targets.
- The most expensive mismatch is an objective the plan credits to analysis that the evidence forces to test, because it lands late and can reopen the agreed plan.
- Understated affected areas are the quiet failure: the plan reads clean while the change reaches into scope the plan never claimed.
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. FAA type certification process, certification basis establishment, and compliance findings.
Federal Aviation Administration. STC application process, certification basis, and continued airworthiness obligations of an STC holder.
Frequently asked questions
The plan was already agreed with the authority. Why review it now?
An agreed plan is a fixed promise, and the review checks whether the evolving work can still keep it. Catching a commitment the package will miss before submittal lets you amend on your terms rather than answer a finding on the authority's.
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.