Why certification process problems are expensive to fix late

Certification process failures rarely announce themselves during development. They appear when a Software Development Plan does not reflect what the team actually did, when a Software Verification Plan commits to independence that was never maintained, or when a configuration management practice that seemed adequate cannot reconstruct the state of artifacts from six months ago. At that point, the options are limited, and the cost is high.

SafeCode Consulting helps programs establish a certification foundation that reflects the applicable standard accurately, matches actual development practices, and produces lifecycle evidence that holds up under formal review — whether that review is a DO-178C DER stage review, an FDA inspection, a notified body audit, or an independent functional safety assessment.

Why process architecture matters as much as engineering

Certification authorities and safety assessors do not just review what was built — they review how it was built, whether the process was planned and followed, and whether the objective evidence is sufficient to demonstrate disciplined development. A technically sound software product with poor lifecycle documentation will not survive formal review. The process discipline that makes certification evidence credible has to be established early and maintained consistently — it cannot be reconstructed convincingly after the fact.

Certification and process services

• Certification planning — Establishing the certification basis, applicable standards, lifecycle model, and plan structure before development begins.
• Plan development — Writing Software Development Plans, Software Verification Plans, Software Configuration Management Plans, and Software Quality Assurance Plans that accurately reflect the program's actual practices and satisfy the applicable standard.
• Process assessment — Evaluating whether current lifecycle practices are consistent with plan commitments and the applicable standard — before a formal reviewer does.
• Compliance readiness — Assessing program readiness for formal review, audit, or regulatory submission and identifying gaps requiring remediation.
• Program recovery — Stabilizing programs that have accumulated process departures, documentation debt, or traceability gaps before a critical milestone — DER stage review, FDA submission, notified body audit, or functional safety assessment.
• Transition support — Assisting programs moving from DO-178B to DO-178C, or incorporating technology supplements such as DO-330 (tool qualification) or DO-331 (model-based development).
• Quality management system alignment — For medical device programs, aligning software lifecycle practices with 21 CFR 820 design controls and the 2024 QMSR update.

For detailed coverage of certification support within each standard, see DO-178C airborne software certification support, IEC 62304 medical device software compliance, and IEC 61508 functional safety software.

Common questions

When should a program establish its certification strategy? Before development begins, if at all possible. The certification basis shapes requirements structure, architecture decisions, verification approach, and documentation from the start. Programs that defer certification planning typically discover the cost of that decision during integration — when correcting process departures competes directly with schedule pressure. SafeCode can help establish the strategy early or recover it when it has been deferred.

What is program recovery in a safety-critical context? Program recovery addresses the situation where a program has accumulated process departures, documentation that does not reflect current implementation, verification coverage that cannot support the claimed assurance level, or lifecycle gaps that must be resolved before formal review. The first step is an honest assessment of where the gaps are and what closing them will actually require. The safety-critical software gap scan is designed precisely for this situation.

What is the difference between a Software Development Plan and a Software Verification Plan? Both are foundational plan documents required under DO-178C, IEC 62304, and IEC 61508, and both must accurately reflect actual program practices rather than aspirational ones. Their specific content requirements and the independence obligations they carry are covered in detail in the individual support pages for DO-178C, IEC 62304 , and IEC 61508 .

What does a process assessment involve? A process assessment examines whether what the program's plans commit to is actually happening — whether lifecycle practices are consistent, documented, and producing objective evidence that a reviewer would find credible. It identifies specific gaps between plan commitments and actual practice before an auditor does. For programs that want a focused, time-boxed version of this assessment, the safety-critical software gap scan is the right starting point.

Can SafeCode help with tool qualification under DO-330? Yes. Tool qualification is required for development and verification tools that eliminate, reduce, or automate lifecycle activities under DO-178C. SafeCode can support tool qualification planning and evidence development under DO-330 as part of DO-178C program support.

How does the 2024 QMSR update affect software lifecycle planning for medical device programs? The FDA's 2024 Quality Management System Regulation, effective February 2026, aligns 21 CFR 820 more closely with ISO 13485. For software lifecycle planning, the practical effect is increased emphasis on risk-based thinking throughout the development process, tighter integration between software lifecycle plans and the broader quality management system, and alignment of design control records with ISO 13485 requirements. Programs whose Software Development Plans were written against the pre-2024 QSR should review them for alignment with the updated regulation.

Contact SafeCode Consulting to discuss your certification and process strategy needs.