DO-178C Software Certification Aerospace: What Engineering Leaders Need to Know Before They Hire
A practical explainer on DO-178C software certification for Engineering Directors and Heads of Software at UK aerospace and defence companies preparing to hire for airborne software programmes. The article reframes the standard not as a technical reference but as a hiring calibration tool, explaining what genuine DO-178C experience looks like at each Design Assurance Level, what artefacts a credible candidate should have produced, and why the talent pool narrows sharply above DAL B. Drawing on Vertech Group's direct placement experience in avionics and functional safety recruitment, it translates the standard's demands into concrete, practical guidance for writing an accurate job brief.
DO-178C Software Certification Aerospace: What Engineering Leaders Need to Know Before They Hire
Most engineering leaders treat DO-178C as a process burden that lands on their software team. That framing is wrong, and it quietly costs companies months of wasted recruitment effort. DO-178C software certification aerospace is not primarily a documentation exercise, it is a talent filter, and the pool of engineers who can genuinely satisfy its demands at the higher Design Assurance Levels is far smaller than most job briefs assume. This article explains what the standard actually requires, what credible experience looks like at each level, and how to translate that into a job brief that reflects reality rather than wishful thinking.
What DO-178C actually is and why it exists
DO-178C is the primary guidance document for the development of airborne software that requires civil airworthiness certification. It was jointly developed by RTCA in the United States and EUROCAE in Europe (published simultaneously as DO-178C and ED-12C) and is the document that civil aviation authorities including the FAA and EASA use to assess whether software in a certified aircraft can be trusted to behave as intended. Compliance with DO-178C is not mandatory in the sense of being a legal statute, but in practice it is the accepted means of compliance for airborne software under FAA FAR Part 25 and EASA CS-25, which means that if you are building certified avionics, you are working to DO-178C.
DO-178C replaced DO-178B in 2011. The revision was significant not because it changed the philosophical approach but because it introduced three technology-specific supplements: DO-330 for tool qualification, DO-331 for model-based development, and DO-332 for object-oriented technology. These supplements matter for hiring because they represent distinct areas of specialist knowledge, an engineer who has qualified a toolchain under DO-330 has a very different experience profile from one who has done structural coverage analysis on hand-coded C.
The reason this standard drives hiring decisions is straightforward: every software objective within DO-178C must be satisfied with evidence. Evidence means artefacts. Artefacts must be produced by people who understand what the objective is asking and how to demonstrate compliance. That is not something a competent generalist software engineer picks up in three months.
The five Design Assurance Levels explained
DO-178C assigns software a Design Assurance Level (DAL A through DAL E) based on the severity of the failure condition that would result if the software failed to perform its intended function. The level is not chosen by the software team. It flows down from the system safety assessment, typically conducted under ARP 4761, and allocated through the aircraft and system development process governed by ARP 4754A.
- DAL A, Catastrophic failure condition. Loss of the aircraft or multiple fatalities would result from a software failure. The highest number of required objectives: 71. Every objective requires independence between the developer and verifier. Examples: flight control laws, engine control software.
- DAL B, Hazardous failure condition. Severe injury or reduced capability of the crew to cope with adverse operating conditions. Significant verification rigour, including MC/DC structural coverage. Examples: navigation systems, certain communication systems.
- DAL C, Major failure condition. Passenger injury or significant increase in crew workload, but the aircraft remains controllable. Statement coverage required. A broader candidate pool than DAL A or B, but still meaningfully specialist.
- DAL D, Minor failure condition. Slight reduction in safety margins or slight increase in crew workload. Basic structural coverage. The candidate pool opens noticeably at this level.
- DAL E, No safety effect. Software whose failure would not affect operational capability or pilot workload. No DO-178C objectives apply. Standard software engineering practice suffices.
The critical point for any engineering leader calibrating a hire is this: each step up the DAL scale does not simply add more process. It dramatically reduces the number of engineers in the UK who have personal, artefact-level experience of working at that level on a live programme. DAL C experience is genuinely specialist. DAL B experience is uncommon. DAL A experience is held by a small number of engineers, most of them embedded in long-running programmes at primes or Tier 1 suppliers, and they are rarely actively looking.
What DO-178C compliance actually demands from a software team
DO-178C organises its requirements around five process areas: software planning, software development, software verification, software configuration management, and software quality assurance. Each area has defined objectives, and each objective must be satisfied with evidence appropriate to the DAL.
The planning process alone requires the production of several key documents before a line of code is written: the Plan for Software Aspects of Certification (PSAC), the Software Development Plan (SDP), the Software Verification Plan (SVP), the Software Configuration Management Plan (SCMP), and the Software Quality Assurance Plan (SQAP). These are not internal documents, they are submitted to the certification authority or their Designated Engineering Representatives and must be accepted before the programme proceeds.
Verification under DO-178C is substantive. At DAL A and B, it requires independence between the person who developed the software and the person who verifies it. This has a direct structural implication for team design: you cannot hire a single senior software engineer and expect them to both write and independently verify their own work. Programmes require distinct development and verification resource, and at DAL A, that independence must be demonstrable.
Structural coverage analysis (the demonstration that tests have exercised the code at a defined structural level) is one of the most technically demanding verification activities. DAL A requires Modified Condition/Decision Coverage (MC/DC). DAL B also requires MC/DC. DAL C requires Decision Coverage. These are not checkbox activities; satisfying them on complex software requires engineers who have done it before, using qualified toolchains, and have addressed coverage gaps systematically.
Configuration management and quality assurance functions are often underestimated by hiring managers. A DO-178C programme requires a functioning SCM system that captures baselines, controls changes, and supports problem reporting throughout the lifecycle. Quality assurance requires independent process audits. Both represent distinct roles or significant role extensions that need to be planned into team structure.
What good DO-178C experience looks like on a CV and in interview
Rob Haughian at Vertech Group has observed a consistent pattern across years of screening engineers for avionics software roles: a significant proportion of candidates who list DO-178C on their CV have worked on programmes that used the standard but have never personally owned a DO-178C artefact or had their work independently verified against objectives. The distinction is invisible on a CV. It is almost never probed in technical interviews run by managers who are not themselves DO-178C practitioners.
The difference matters enormously. An engineer who has been present on a DO-178C programme (writing code that fed into a compliant system) has useful exposure. An engineer who has personally authored a PSAC, maintained traceability through requirements changes, resolved coverage gaps in MC/DC analysis, or responded to DER review comments has a fundamentally different capability. The second engineer can contribute from day one on a certificated programme. The first will need structured mentoring and close supervision on every artefact they touch.
When reviewing CVs, look for specificity in the following areas:
- Planning documents: Has the candidate authored or substantially contributed to a PSAC, SDP, or SVP? Or have they worked to plans that someone else wrote?
- Traceability: Have they maintained bidirectional traceability between system requirements, software requirements, design, code, and test cases, and resolved gaps identified during review?
- Structural coverage: Have they performed or reviewed MC/DC coverage analysis? Have they used a qualified coverage tool such as LDRA Testbed, VectorCAST, or Polyspace?
- Review and independence: Have they participated as a reviewer on another engineer's work in a formal independence capacity? Have their own artefacts been reviewed and have they responded to findings?
- Problem reporting: Have they raised and resolved Software Problem Reports (SPRs) through a formal change control process?
In interview, the most effective probe is to ask a candidate to walk through a specific artefact they produced, not a programme they worked on. An engineer who owned their work can describe the document, the review it received, the findings it generated, and how those findings were closed. An engineer who was adjacent to the work will describe the programme.
Tool familiarity is not evidence of standard experience. Knowing that LDRA is used for structural coverage is not the same as having used it to achieve MC/DC on a DAL B programme and addressed the tool qualification data package.
Where DO-178C intersects with other safety standards your team may use
DO-178C does not operate in isolation, and engineering leaders at companies working across domains need to understand where the boundaries and interfaces sit.
ARP 4754A is the system-level guidance for aircraft and system development. It sits above DO-178C in the hierarchy. The DAL assigned to software is derived from the system safety assessment conducted under ARP 4754A using ARP 4761 methods. Engineers who work only at the software level may not have direct ARP 4754A experience, but they should understand that their software requirements, and the DAL itself, flow from a system-level process they did not own.
DO-254 is the hardware equivalent of DO-178C, governing the development of airborne electronic hardware, FPGAs, ASICs, and PLDs. On many avionics programmes, software and hardware development run in parallel and must interface at the requirements and verification levels. Engineers working on software that interacts closely with programmable hardware benefit from familiarity with DO-254 Design Assurance Levels and hardware/software integration test obligations.
IEC 61508 is the foundational functional safety standard for electrical, electronic, and programmable electronic systems, and it is the parent standard from which automotive (ISO 26262) and process industry (IEC 61511) standards are derived. Engineering leaders at companies operating across both aerospace and other safety-critical sectors sometimes conflate IEC 61508 SIL levels with DO-178C DALs. They are not equivalent. The process frameworks share philosophical DNA (both require evidence of systematic software development and independent verification) but the specific objectives, artefacts, and assessment processes are different. An engineer with strong IEC 61508 SIL 3 or SIL 4 experience has genuinely transferable rigour, and this is worth exploring when the DAL A/B pipeline is thin, but they will need programme-specific mentoring to translate that experience into DO-178C artefacts. Do not write a job brief that treats the two as interchangeable.
Practical hiring implications: what this means when you write a job brief
The single most common mistake engineering leaders make when writing a DO-178C job brief is specifying a higher DAL than the programme actually requires. The reasoning is understandable (if the candidate has worked at DAL A, they can certainly handle DAL B) but the effect is to filter out a substantial portion of the genuine candidate pool without improving programme outcomes. DAL A experience in the UK is concentrated in a small number of engineers, many of whom are not actively seeking roles. If your programme is DAL B, specify DAL B. You will reach more credible candidates, and the experience is genuinely appropriate.
Be specific about which process areas matter most for the role you are filling. A software developer role and a software verification engineer role have different experience requirements under DO-178C. A configuration management lead role requires different evidence again. Bundling all of these into a single requirement for a "DO-178C software engineer" produces a brief that excludes specialists who could fill one of those roles excellently.
For engineering leaders at companies where the DAL A/B pipeline is proving too thin, engineers from adjacent safety-critical domains deserve serious consideration. Strong IEC 62304 experience from medical device software development, or SIL 3 experience from rail or nuclear, indicates that a candidate understands the discipline of evidence-based software development under independent scrutiny. The domain knowledge gap is real but bridgeable. The artefact discipline is not something that can be manufactured quickly, and candidates who have lived inside a rigorous safety lifecycle carry that with them.
For further context on the broader avionics hiring landscape, see our article on Hiring Avionics Engineers in the UK: What Engineering Leaders Need to Know. If your programme sits at the intersection of software and functional safety across domains, Hiring Functional Safety Engineers UK 2026: Why You're Losing Candidates You've Already Found addresses the pipeline and retention dynamics that affect this community directly. If you are planning headcount and need to understand how long specialist hires realistically take, How Long Does It Take to Hire a Specialist Engineer? UK Benchmarks 2026 provides the context you need before committing to a programme milestone that depends on a new hire being in seat.
DO-178C compliance is not something a software team learns in parallel with delivery. It requires people who have produced the right artefacts, on live programmes, under independent scrutiny. Getting the job brief right before you go to market is the most effective thing an engineering leader can do to reduce time to hire and avoid the costly pattern of placing an engineer who cannot satisfy the certification authority's objectives. If you are building out a team for a certificated avionics programme and want a frank assessment of what the candidate market can realistically deliver at the DAL level you are working to, speak to Vertech Group.
Frequently Asked Questions
What is DO-178C and what does it require?
DO-178C, formally titled Software Considerations in Airborne Systems and Equipment Certification, is the primary international standard governing the development of software used in civil airborne systems. It is published by RTCA and accepted by aviation regulators worldwide, including the UK CAA and EASA, as the means of compliance for demonstrating that airborne software is safe and fit for certification. The standard defines a set of objectives (ranging from requirements capture and design through to testing and configuration management) that must be satisfied before software can be approved as part of a type-certificated aircraft or system. Crucially, the rigour of those objectives scales with the Design Assurance Level assigned to the software, meaning a DAL A application faces far more demanding evidence requirements than a DAL D one.
What is the difference between DO-178B and DO-178C?
DO-178B was the predecessor standard, published in 1992 and widely used across the avionics industry until it was superseded by DO-178C in 2011. The core structure and DAL framework remained intact in the revision, but DO-178C introduced three important technology-specific supplements: DO-331 for model-based development, DO-332 for object-oriented technology, and DO-333 for formal methods. These supplements addressed gaps that had become increasingly relevant as software development practices evolved over the two decades since DO-178B was published. For hiring purposes, engineers who hold genuine DO-178B programme experience remain largely relevant to DO-178C projects, but you should probe whether they have worked on programmes that have adopted any of the supplements, particularly if your own programme uses model-based design tools such as MATLAB Simulink.
What does DAL A mean in aerospace software development?
DAL A, the highest Design Assurance Level under DO-178C, is assigned to software whose failure would contribute to a catastrophic failure condition, one that would result in loss of the aircraft or fatalities. Examples include primary flight control software, engine control systems, and certain autopilot functions. At DAL A, DO-178C mandates the most extensive set of objectives, including modified condition and decision coverage (MC/DC) at the structural coverage level, which requires engineers to demonstrate that every independent condition in a decision has been shown to independently affect the outcome. The documentation, review, and independent verification burden at DAL A is substantial, and the combination of domain knowledge, toolchain experience, and familiarity with the regulatory evidence trail makes genuine DAL A practitioners among the most sought-after and scarcest engineers in UK aerospace.
How do I know if a candidate has genuine DO-178C experience?
The most reliable indicator is whether a candidate can speak fluently and specifically about the artefacts they personally produced or reviewed, not the programme they worked on, but their individual contribution to the evidence trail. Credible candidates should be able to describe their role in activities such as software requirements capture, low-level design documentation, peer reviews, test case development, structural coverage analysis, or participation in a Software Conformance Review. Vague references to having "worked on a certified programme" are a common signal of peripheral involvement; press candidates to name the specific objectives they owned and the tools they used. If your team lacks the internal expertise to assess this technically, consider structuring your interview process around a structured competence framework or engage a recruitment partner with direct DO-178C placement experience who can pre-qualify candidates before they reach your panel.
Do I need a DO-178C specialist to hire for a DAL C programme?
Not necessarily, though the answer depends on the maturity of your existing team and where the role sits in your development lifecycle. DAL C software, while subject to meaningful DO-178C obligations including decision coverage at the structural level, is considerably less demanding than DAL A or B in terms of the breadth and depth of required evidence. An engineer with strong avionics development experience, a solid grasp of safety-critical software practices, and exposure to structured development processes can often be brought up to speed on DAL C requirements with appropriate mentoring, particularly if your organisation has established processes and a qualified DER or independent V&V resource. Where it becomes riskier to compromise is in lead or principal roles where the candidate will be expected to own the planning documents, interface with certification authorities, or train less experienced team members on compliance obligations.
Can engineers with IEC 61508 experience work on DO-178C programmes?
Engineers with a substantive IEC 61508 background (particularly those who have worked at SIL 3 or SIL 4) bring genuinely transferable skills that are valuable on DO-178C programmes, including familiarity with rigorous requirements traceability, independence in verification, structured hazard analysis, and the discipline of producing auditable evidence. The conceptual frameworks are closely aligned; both standards treat software development rigour as a function of the consequence of failure, and engineers who understand why the process demands exist at SIL 3 will adapt more quickly to DAL B obligations than those whose experience is purely DAL D. That said, the specific objectives, terminology, toolchains, and regulatory interfaces differ meaningfully, and you should not assume a direct equivalence, candidates should be briefed clearly on the DO-178C context and assessed on their appetite to close the gap, rather than presented with a role that misrepresents the standard they will be working to.
How rare are engineers with DAL A software certification experience in the UK?
Genuinely scarce, and the talent pool narrows significantly when you require not just programme exposure but demonstrable ownership of DAL A certification artefacts. The number of UK programmes that have reached or are approaching DAL A software certification at any given time is small, and many of the engineers involved are either embedded within large primes under long-term contracts or are retained contractors with established relationships. Engineers who can evidence personal responsibility for DAL A planning documents, who have been through a certification audit, or who have interfaced directly with the CAA or EASA on software compliance matters represent a very thin slice of the UK avionics workforce. Hiring timelines for these roles should be planned accordingly, expecting to fill a senior DAL A software role in under three months is an unrealistic baseline in the current market, and a sourcing strategy that relies solely on active jobseekers will miss the majority of the available pool.