Most teams first encounter this plan as one more document on a certification checklist. It is actually the document that tells the certification authority what software is being proposed and how the team plans to show compliance—before most of that work is done.
Short answer: A Plan for Software Aspects of Certification (PSAC) is the applicant’s software-specific certification plan. Submit it early enough for the certification authority or authorized designee to review the proposed life cycle, software level, data, tools, and special methods before the approach hardens—typically as the controlled planning baseline for the first software planning review.
By AeroCert Institute — a federally recognized 501(c)(3) nonprofit organization founded by aviation safety professionals with FAA credentials. Reviewed August 2026.
The PSAC is the software certification plan
The PSAC explains how an applicant intends to satisfy the software aspects of an aircraft, engine, propeller, or equipment certification project. It connects the proposed software work to the wider certification basis, system safety assessment, product architecture, and project schedule.
That makes it more than a table of contents. A useful PSAC gives the Federal Aviation Administration (FAA), or an authorized representative acting within an assigned scope, enough information to understand what the software is, which assurance approach applies, and what evidence the project intends to produce.
The PSAC is also not the entire product certification plan. The product-level plan identifies the applicable regulations, certification basis, means of compliance, and broader certification activities. The PSAC summarizes the parts that matter to the software showing and explains how the software processes fit inside that larger plan.
Nor does the PSAC replace the other software plans. The Software Development Plan, Software Verification Plan, Software Configuration Management Plan, and Software Quality Assurance Plan contain the detailed processes for their areas. The PSAC provides the top-level software certification story and shows how those plans work together.
One of its most important inputs is the assigned software level. That level comes from the installed system’s safety analysis—not from the PSAC author’s preference. If the basis for the level is not settled, review What decides your DO-178C design assurance level? before treating the planning baseline as complete.
Reviewing or accepting the PSAC does not approve the finished software. It establishes the proposed route for producing the compliance evidence that will be assessed throughout the project.
What a useful PSAC needs to explain
RTCA DO-178B and DO-178C identify the expected PSAC content in section 11.1. The article-level summary below is deliberately in plain language; it does not reproduce the standard.
A reviewer should be able to understand:
- what system and software are in scope, including the software components and their functions;
- how the software fits into the system architecture and interacts with hardware and other systems;
- the certification basis and proposed means of compliance relevant to the software;
- each software level and the safety assessment that supports it;
- the software life cycle, processes, plans, standards, transition criteria, and organizational interfaces;
- the software life-cycle data the project will produce, control, submit, or make available;
- the development and verification environments, including software tools and any planned qualification;
- major milestones and the proposed certification-review schedule;
- supplier responsibilities and how the applicant will oversee delegated development work; and
- additional considerations such as reused software, commercial off-the-shelf software, field-loadable or user-modifiable software, alternative methods, and applicable DO-178C supplements.
The PSAC does not need to duplicate the aircraft certification plan’s complete regulation list. It should summarize the software-relevant basis and point to the controlled source that carries the authoritative detail. Copying a long list into two documents creates another place for the project to become inconsistent.
Specificity matters most where the proposed method changes the evidence. Consider one project that intends to use a code generator and take credit for its output without independently verifying everything the tool produces. Listing the tool name is not enough. The PSAC should identify the intended use, the qualification rationale and approach, the affected objectives and data, and the planned coordination with the authority.
This does not create a universal tool-qualification rule. It shows the PSAC’s job: expose consequential choices while they can still be reviewed as plans rather than discovered later as surprises.
Submit it before the approach becomes expensive to change
There is no single calendar date that applies to every certification project. The required channel, recipients, review method, and disposition depend on the project, the certification office, the use of designees, and the agreed level of involvement.
The timing principle is more durable: submit the PSAC early enough for meaningful certification liaison before the project has substantially executed the approach it proposes.
In the familiar Stage of Involvement (SOI) workflow, the PSAC is central to SOI 1, the planning review. The FAA’s Software Review Job Aid describes that review as occurring shortly after the software planning process, when the plans and standards are fairly mature and under configuration control. If SOI terminology is new to your team, read What Happens When the FAA Looks at Your Software? SOI Reviews, Explained.
“For SOI 1” does not mean “write it the night before SOI 1.” Reviewers need time to understand the proposed life cycle, compare the PSAC with the supporting plans and standards, identify missing information, and decide which issues need coordination.
The PSAC must therefore be mature enough to review. The software scope, levels, life cycle, key methods, tools, data, responsibilities, and milestones should be credible and mutually consistent. Some details may still evolve, but open decisions that could change the compliance approach should be visible, not disguised as settled facts.
Coordinate the actual submission milestone early. Confirm who receives the PSAC, which supporting plans and standards accompany it, whether a desk or on-site review is expected, which designee authorizations apply, how comments and findings will be recorded, and what constitutes the project’s accepted or approved planning baseline.
If your team begins implementation first and asks for agreement later, the PSAC becomes a report about decisions already made. That is exactly the rework pattern described in Why DO-178C Costs More When Compliance Starts Late.
What reviewers are checking
A planning review is not a grammar review. The question is whether following the proposed plans and standards would give the project a credible path to satisfying the applicable DO-178B or DO-178C objectives.
Reviewers look for consistency across the planning set. The software level in the PSAC should agree with the safety assessment. The development and verification plans should implement the life cycle the PSAC describes. The configuration-management and quality-assurance plans should control the same data, baselines, reviews, and change processes. Tool decisions should agree across every plan that depends on them.
They also look at interfaces. Software does not assign its own system requirements or safety objectives. The plans need workable paths for receiving system and safety inputs, communicating derived requirements, handling hardware dependencies, coordinating suppliers, and resolving changes that cross organizational boundaries.
Special approaches deserve direct treatment. Reuse, novel methods, qualification credit, alternative means of compliance, and technology-specific supplements can change the review strategy and required evidence. Hiding those choices in a lower-level procedure defeats the purpose of early certification liaison.
The strongest PSAC is executable by the team, not merely acceptable to a reviewer. Engineers should be able to recognize the life cycle they are expected to follow. Verification, configuration management, quality assurance, suppliers, and program leadership should see the same responsibilities and milestones.
A simple internal test helps: ask each affected lead to explain what the PSAC commits their function to do. If their answers conflict, the document is not yet one plan.
Keep the PSAC aligned with the program
Submission is not the end of PSAC ownership. The document describes a proposed approach, and the program must keep that description aligned with what it actually does.
A material change may require a PSAC revision and renewed coordination. Triggers can include a change in software scope or level, system architecture, life-cycle model, supplier responsibility, verification strategy, tool qualification approach, reuse claim, supplement, means of compliance, or certification schedule.
Not every engineering change rewrites the PSAC. The test is whether the controlled plan still accurately describes the software, its certification considerations, and the processes and evidence the project will use. If it does not, leaving the document unchanged creates a gap between the planning baseline and project reality.
Follow the project’s change-control and certification-liaison process for revisions. Determine whether the change stays within delegated authority, requires direct FAA coordination, affects scheduled reviews, or changes data that has already been submitted. Do not assume that approving an internal document revision completes the external coordination.
At the end of the project, the Software Accomplishment Summary (SAS) closes the loop. It explains what was actually built, summarizes the compliance results, and identifies justified deviations from the PSAC. A vague PSAC makes that comparison difficult; a precise PSAC gives the final showing a clear baseline.
The takeaway: submit the PSAC when the software plan is mature enough to review but still early enough to change—then keep it aligned with the program you actually execute.
As your next step, use AeroCert’s free public-tier checklist library and select the combined PSAC/SAS checklist. It checks the system and software overview, levels, life cycle, planned data, schedule, special considerations, suppliers, final accomplishment summary, and consistency between what the project planned and what it delivered.
Primary sources
- FAA AC 20-115D, Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( ), especially paragraphs 1, 4, 6, and 8 for the recognized means of compliance, applicant responsibilities, life-cycle data, and PSAC treatment of DO-178C supplements.
- FAA Order 8110.49A, Software Approval Guidelines, Chapter 2, for certification liaison, software-review objectives, early review planning, and authority/designee involvement.
- FAA Software Review Job Aid, Revision 1, Part 3 section 3.1, dated January 16, 2004, for the typical SOI 1 planning-review timing and data reviewed. This archived aid uses DO-178B terminology; coordinate current project practice with the applicable authority.
- RTCA DO-178 software standards, with the PSAC framework in DO-178B/DO-178C sections 9.1 and 11.1. The standards are copyrighted and available from RTCA; no proprietary text is reproduced here.
This article is educational guidance, not a project-specific compliance finding. Coordinate the certification basis, PSAC content, submission schedule, review path, and document disposition with the responsible certification authority and authorized representatives.
Leave a Reply