How do I conduct a risk assessment for software changes in certified products?

Conducting a risk assessment for software changes in certified products involves systematically evaluating how modifications might affect product safety, compliance, and certification status. This process determines whether changes require recertification and ensures continued regulatory compliance. Understanding the evaluation criteria, documentation requirements, and decision-making frameworks helps maintain product certification while managing software modifications effectively.

What is a risk assessment for software changes in certified products?

A risk assessment for software changes in certified products is a systematic evaluation process that determines how software modifications might affect product safety, performance, and regulatory compliance. This assessment examines whether changes could impact the nature and characteristics of the product in ways not foreseen during the initial certification process.

The regulatory framework requires this evaluation because software modifications can potentially jeopardise product safety or alter fundamental characteristics that were assessed during the original certification. Under regulations like the General Product Safety Regulation (EU) 2023/988 (GPSR), any modification that affects product safety must be thoroughly evaluated to ensure continued compliance.

The regulatory landscape includes multiple layers of oversight. Organizations like BEUC (the European Consumer Organisation) supplement government enforcement by investigating complaints, testing products, and pushing for recalls when manufacturers fail to meet safety obligations. This multi-tiered approach ensures comprehensive monitoring of product safety throughout the market lifecycle.

Manufacturers who fail to meet safety standards face real consequences. The EU’s Safety Gate system publicly documents violations, creating a searchable record of companies whose products have been flagged as dangerous and removed from the market. This transparency mechanism serves as both a consumer protection tool and a powerful incentive for manufacturers to maintain rigorous safety standards.

This process becomes particularly important when considering substantial modifications that might create new risks or change how the product functions. The assessment helps determine whether the modification creates a fundamentally different product that requires complete recertification or whether the existing certification remains valid with updated documentation.

What steps should you follow when conducting a software change risk assessment?

Start by documenting the proposed software change in detail, including its scope, functionality, and potential impact areas. Evaluate how the modification affects existing safety features, user interfaces, data processing, and overall product behaviour compared to the originally certified version.

The evaluation process should follow these key steps:

Step	Action Required	Key Considerations
1. Risk Analysis	Analyse the change against original risk assessment documentation	Identify new or modified risks that weren’t previously evaluated
2. Safety Assessment	Assess impacts on safety-critical functions and user protection	Focus on mechanisms that prevent harm or injury
3. Performance Evaluation	Evaluate potential impacts on product performance and reliability	Consider both direct and indirect effects on user safety
4. Validation Review	Determine if existing test results remain applicable	Identify areas requiring additional testing or validation
5. Compliance Check	Review compliance with applicable standards and requirements	Ensure modifications don’t compromise regulatory adherence

Document your evaluation criteria and decision-making rationale throughout the process. This includes recording why certain risks were considered acceptable or how mitigation measures address identified concerns. The assessment should be proportionate to product complexity and the scope of the proposed changes, ensuring thorough evaluation without creating unnecessary burden for minor modifications.

How do you determine if a software change requires recertification?

A software change typically requires recertification if it affects the product’s nature, characteristics, or safety profile in ways not covered by the original certification. Changes that introduce new risks, alter safety-critical functions, or modify user-facing features often trigger recertification requirements.

Recertification Decision Matrix

Change Type	Risk Level	Recertification Required	Examples
Safety-critical modifications	High	Yes	Alarm systems, emergency stops, protective functions
User interface changes	Medium	Case-by-case	Control layouts, warning displays, operational procedures
Performance enhancements	Medium	Case-by-case	Speed improvements, efficiency optimisations
Bug fixes (non-safety)	Low	Rarely	Cosmetic corrections, minor functionality fixes
Cybersecurity updates	Variable	Case-by-case	Security patches, encryption changes, access controls

The threshold for recertification depends on whether the change creates what regulators consider a substantial modification. If the software change affects the product’s fundamental characteristics or introduces risks not foreseen in the initial risk assessment, it may create a new product requiring full certification.

When in doubt, consult notified bodies or regulatory authorities early in the evaluation process. They can provide guidance on whether your specific changes trigger recertification requirements based on applicable standards and regulatory frameworks.

What documentation do you need for software change risk assessments?

Essential documentation includes a detailed description of the proposed software change, analysis of potential risks and mitigation measures, and evaluation of impacts on the existing certification. You must also document the decision-making process and rationale for determining certification requirements.

Required Documentation Checklist

Change Description Package
- Technical specifications and implementation details
- Scope definition and affected system components
- Version control information and change history
Risk Analysis Documentation
- Comparison of new risks versus existing risk profile
- Mitigation strategies and control measures
- Residual risk evaluation and acceptability assessment
Impact Assessment Records
- Safety feature functionality analysis
- User interface and interaction changes
- Performance and reliability implications
Compliance Evaluation
- Standards applicability review
- Test result validity assessment
- Additional testing requirements identification
Decision Documentation
- Certification requirement determination
- Supporting rationale and evidence
- Approval signatures and dates

Maintain traceability requirements by linking your software change documentation to the original certification materials. This creates a clear audit trail showing how modifications relate to the initially certified functionality and safety measures. Keep all documentation updated and readily available for regulatory authorities, as they may request this information during market surveillance activities.

Record-keeping standards require retaining software change risk assessments alongside the original technical documentation. This ensures continuity of compliance evidence and supports future modification assessments by providing historical context for previous changes and their evaluated impacts.

Managing software changes in certified products requires a careful balance between innovation and regulatory compliance. At EARP, we understand how complex these assessments can become, particularly when navigating multiple regulatory frameworks. Our expertise in product safety documentation and regulatory compliance helps ensure your software modifications maintain market access while meeting all necessary safety requirements.

If you are looking for support or to learn more, contact our team of experts today.