Where this sits in the series
Part one covered why DO-326A/ED-202A exists and who it applies to. This part covers what complying with it actually produces. If you've ever wondered what a certification authority physically receives when an aircraft is declared compliant, this is that answer, and it's more concrete than most people expect.
One naming note before we start. The standard's most recent revision is DO-326B/ED-202B, and everything in this series applies to it. We use the DO-326A/ED-202A name throughout because it's still the name most of the industry reaches for.
Compliance is proven on paper
Certification runs on evidence. An authority can't sit in on every design meeting or watch every test, so the whole system works through documents that capture what was decided, what was assessed and what was proven. Airworthiness security follows the same rule. DO-326A/ED-202A defines a set of 14 documents, and producing them well is what compliance means in practice.
14 sounds like a lot. It becomes far less intimidating once you see the shape of the set. The 14 are two halves of the same story told at two levels of detail, held between a plan at the start and a summary at the end.
How the 14 break down
Two open and close the process. The first is the plan, where you set out to the authority what you intend to assess, how deeply, and what evidence you'll bring. The last is the closing summary, where you show what you actually did, explain anywhere you departed from the plan, and present the final picture. Everything else lives between those two.
The remaining twelve split evenly across two levels. Six describe the whole aircraft, and six describe each individual system on it. That mirroring exists because a claim that the aircraft is protected is only believable if someone has also shown that every system contributing to the protection holds up on its own.
Within each level, the six play the same roles. One defines what you are protecting, drawing the fence around the systems, connections and people in scope. Two assess what could go wrong, first as an early look while the design is still moving, then as a final judgement once the design has settled. One records how you protect it, capturing the security architecture and the measures built into the design. One proves those measures actually work, through verification against the threats you identified. And one tells the people who will operate or integrate the aircraft what they must keep doing in service for the protection to hold.
Why it loops rather than queues
The 14 are produced in cycles rather than in a straight line. The framework keeps returning to one question - are the security risks acceptable? When the answer is no, the design changes, and the assessments that fed that judgement are revisited until the answer becomes yes.
The documents also feed each other. You can't finish the plan at the very start without early scope and architecture work already in hand, which is why programmes that treat these documents as end-of-project paperwork end up reconstructing months of decisions nobody wrote down. The order in which everything gets produced is agreed with the authority, programme by programme, inside the plan itself.
Get the next session in your inbox
One email per post, for the length of the series. Nothing else.
What this means for your programme
Three practical things follow.
- Start the documents when the programme starts, because they're records of a process that has to run during development rather than reports written about it afterwards.
- Give each one an owner, because the set spans safety, security, design and operations, and unowned documents are the ones that stall certification.
- Treat the set as living, because a modification later in the aircraft's life reopens the parts it touches, which is a subject this series returns to near the end.
If you can name the 14 and say what each one is for, you already understand the shape of DO-326A/ED-202A. The depth of each document is where the real work lives, and several of the posts ahead go inside the most important of them.
In this series
- Why DO-326A/ED-202A exists, and whether it applies to you
- The 14 documents that prove an aircraft is compliant (this post)
Where this sits in the series
Part one established the applicability and rationale of the standard, now at revision DO-326B/ED-202B. This series keeps the better-known DO-326A/ED-202A name, and everything in it applies to the current revision. This part covers what the framework generates, the artefact set that forms the evidence backbone of the AWSPAirworthiness Security Process. The seven-step process DO-326A/ED-202A defines, running from the certification plan through risk assessment and security development to the final communication of evidence..
The process produces evidence
The AWSP is composed of seven steps in three bands. Certification activities open and close it, with the PSecACPlan for Security Aspects of Certification. The opening artefact, defined by the applicant and agreed with the Authority, setting out the security scope, activities, methods and evidence for the programme. at step one and the PSecAC SummaryPSecAC Summary. The closing artefact, presenting the completed activity, the final risk picture and any justified deviations from the plan. at step seven. Security risk assessment occupies steps two to four, ending at the gate that asks whether the risks are acceptable. Security development occupies steps five and six, and the process iterates back through assessment after every architecture change until every risk passes the gate.
The output of those seven steps is 14 artefacts. Two are the opening and closing certification documents just described. The remaining twelve are six document types produced at two levels, aircraft and system, because the aircraft-level claim rests on the system-level evidence beneath it.
The set, role by role
Scope. The ASSDAircraft Security Scope Definition. Defines the aircraft security perimeter, the operational environment, the assets under protection and every interface into them. and SSSDSystem Security Scope Definition. The system-level equivalent, defining what each system protects, its boundaries, and every way in and out. draw the fence. Perimeter, environment, assets, interfaces, trust relationships. Everything downstream depends on this pair being right, which is why scope gets a post of its own later in this series.
Preliminary risk. The PASRAPreliminary Aircraft Security Risk Assessment. The early aircraft-level assessment of threat conditions and scenarios, performed while the design can still respond to what it finds. and PSSRAPreliminary System Security Risk Assessment. The system-level preliminary assessment, feeding the aircraft picture. identify threat conditions and threat scenarios early, at a stage where the findings can still shape the architecture rather than merely document it.
Final risk. The ASRAAircraft Security Risk Assessment. The final aircraft-level assessment, closing the loop with an evidence-based judgement on the remaining risks. A core input to the PSecAC Summary. and SSRASystem Security Risk Assessment. The final system-level assessment against the as-built configuration. close the loop with an evidence-based judgement once the configuration is final. Outstanding risks are acceptable, provided they are identified, assessed and either accepted or mitigated through architecture change.
Architecture and measures. The ASAMAircraft Security Architecture and Measures. Turns the scope and risk findings into a practical, validated aircraft security design that can be implemented and maintained. and SSAMSystem Security Architecture and Measures. The security blueprint for one system, aligned with the aircraft-wide design in the ASAM. turn the scope and risk findings into a validated security design, covering the architecture, the protections needed, encryption, access control, monitoring, and the allocation of each measure to a system, process or operator guidance.
Verification. The ASVAircraft Security Verification. Shows compliance with security requirements and evaluates the effectiveness of the security measures at aircraft level. and SSVSystem Security Verification. The system-level verification, testing against the threat scenarios from the risk assessments. produce the evidence that the design actually protects. Build checks, testing against the threat scenarios, tracked weaknesses, and results feeding the final risk assessments.
Guidance. The ASOGAircraft Security Operator Guidance. Instructions for operators covering security features, responding to alerts, updates and maintenance across the aircraft's service life. and SSIGSecurity Integrator Guidance. Instructions for whoever integrates a system, covering secure installation, configuration, operation and repair. carry the knowledge out of the programme and into service. These two exist so that the people running and integrating the aircraft know what they must keep doing for the protection to hold, and they are kept current as measures, risks and instructions change.
The same set exists under the European numbering through ED-202B, and DO-356A/ED-203A provides the lookup between the two document families alongside the methods for performing the assessments. DO-356A/ED-203A itself is where a later part of this series goes.
Iteration and interdependence
The artefacts are produced in loops. The acceptability gate at the centre of the process is defined by the applicant and agreed with the Authority unless regulation provides it, and a failed gate sends the programme back through development and reassessment. The walkthrough order we teach is a teaching order rather than a production order, because the artefacts feed each other. Delivering a PSecAC already requires scope, architecture and preliminary assessment work in hand, and the real production sequence is agreed programme by programme with the Authority, in the PSecAC itself.
Get the next session in your inbox
One email per post, for the length of the series. Nothing else.
Programme implications
Three follow directly.
- The artefacts are lifecycle outputs of a process the Authority audits, so they start when the programme starts, with the trail of scope agreed early, assessment informing design and measures verified as built.
- The set spans safety, security, design and operations, so each artefact needs a named owner or it becomes the document that stalls the certification.
- The set is living, because change impact analysis on a modification reopens the artefacts it touches, which is the subject of the final part of this series.
Later parts go inside the most load-bearing of the 14. The PSecAC, the scope definitions, the risk assessment scoring, the acceptability judgement and the communication of evidence each get a post of their own.
In this series
- Why DO-326A/ED-202A exists, and whether it applies to you
- The 14 documents that prove an aircraft is compliant (this post)