Why Certification Projects Get Delayed and How to Avoid It
12 Oct, 2026When people think about functional safety certification, they often focus on the engineering challenge. They think about requirements, software development, testing, and system design.
Those things are important, but in many certification projects they’re not what causes the delay.
More often than not, delays occur because organisations struggle to demonstrate compliance. The work may have been completed, testing may have been carried out, and the product may be technically ready, but when an auditor asks to see the evidence, the information is incomplete, difficult to find, or lacks the traceability needed to support the safety argument.
The result is additional audit findings, unplanned engineering effort, delayed certification, and potential delays to product launch.
The good news is that most of these problems are avoidable if they’re addressed early.
Certification is about evidence, not just engineering
A common misconception is that certification is purely a technical exercise.
In reality, certification also involves demonstrating that the requirements of a safety standard have been met. That means being able to provide objective evidence across the entire safety lifecycle, from planning and requirements through design, implementation, verification, and final reporting.
Delays often come back to a handful of recurring issues:
- Missing or incomplete evidence
- Poor traceability between requirements, design, code, and testing
- Audit findings that require rework
- Failure to understand and implement Assumptions of Use (AoUs)
- Defects discovered late in the project that trigger re-testing and re-assessment
The challenge is often demonstrating, after the fact, that the work was completed.
What auditors actually look for
Auditors don’t simply review documents one at a time.
A typical audit might start with a high-level safety requirement. An auditor will then ask how that requirement flows through the rest of the development process.
They may ask:
- Where does this requirement appear in the system design?
- How was it implemented?
- Which tests verify it?
- What happens if this requirement changes?
- Which other artefacts would be affected?
If the answers rely on searching through multiple documents, manually linking information together, or trying to explain gaps, audits quickly become more difficult.
As soon as an auditor identifies an area where evidence is unclear, that area often receives closer scrutiny.
Strong traceability makes these conversations much easier. An auditor should be able to follow a clear path from a requirement through design, implementation, and verification without needing extensive explanation.
Why many projects lose time before the audit even starts
One of the most common mistakes is treating certification as something that happens at the end of development, when they think they’re ready for assessment.
Unfortunately, that’s often when gaps begin to appear.
Documentation may be incomplete. Verification records may be missing. Traceability may not be fully established. This can quickly become several weeks or more of additional engineering effort as teams recreate evidence, repeat testing, or revisit decisions made months earlier.
A more effective approach is to build audit readiness throughout the project.
Requirements should be traced as they are created. Verification evidence should be captured as testing takes place. Integration decisions should be documented when they are made. This reduces risk and helps avoid last-minute surprises.
The importance of safety manuals and Assumptions of Use
For organisations using third-party software components, one document deserves particular attention: the Safety Manual.
The Safety Manual explains the Assumptions of Use established during the component’s development and certification. It describes how the component should be integrated, identifies any constraints that apply, and clarifies where responsibility passes from the supplier to the integrator.
These assumptions are not optional recommendations. They form part of the safety case.
An auditor is likely to ask how those assumptions have been addressed within the final system. If a team cannot demonstrate that the relevant assumptions have been reviewed, understood, and implemented correctly, additional questions and audit findings are likely to follow.
On the other hand, when Assumptions of Use are considered early in the project and their implementation is documented, the assessment process becomes significantly smoother.
What good certification evidence looks like
Good certification evidence is complete, relevant, traceable, and easy to navigate.
Typically, strong certification packages include:
- Evidence specific to the processor and compiler being used
- Documentation covering the entire safety lifecycle
- Clear traceability between requirements, design, implementation, and testing
- Safety Manuals and integration guidance
- Access to subject matter experts who can explain the evidence
Most importantly, the evidence should tell a coherent story. An auditor should be able to begin with a requirement and follow it all the way through to the verification activities that demonstrate compliance.
Reducing certification effort through evidence reuse
Another way organisations can reduce certification effort is by making effective use of existing certification artefacts.
Requirements documentation, design records, verification results, hazard analyses, and Safety Manuals can all provide a strong foundation for a certification project.
Rather than creating everything from scratch, engineering teams can focus on demonstrating how existing evidence applies to their specific application.
This becomes even more valuable when the evidence is accompanied by clear traceability, supporting guidance, and documentation that helps answer auditor questions quickly and consistently.
Conclusion
Certification delays are most commonly caused by missing evidence, weak traceability, incomplete audit preparation, or a failure to address Assumptions of Use early enough in the project.
The organisations that achieve certification most efficiently tend to treat audit readiness as an ongoing activity rather than a final-stage exercise. By maintaining traceability throughout development, addressing Safety Manual requirements early, and building evidence continuously, teams can reduce certification effort, avoid unnecessary delays, and approach assessments with far greater confidence.
Reduce Certification Effort with the SAFERTOS® Design Assurance Pack
The SAFERTOS® Design Assurance Pack (DAP) can save organisations several years of certification effort by providing a substantial body of certification evidence that would otherwise need to be generated internally.
The DAP delivers comprehensive lifecycle evidence together with the guidance needed to apply it, helping engineering teams focus on developing their application rather than recreating certification artefacts.
Author
James Stanley, Engineering Manager
Back to News