IEC 62304 Edition 2 (2026): Software Process Rigor Levels, AI/ML Provisions, and What Changes for Medical Device Manufacturers
A comprehensive guide to IEC 62304 Edition 2 — the 2026 update replacing safety classes A/B/C with rigor levels, expanding scope to all health software, adding AI/ML lifecycle requirements, integrating cybersecurity, and practical compliance timelines for medical device manufacturers.
Why IEC 62304 Edition 2 Matters
IEC 62304:2006+A1:2015 has been the backbone of medical device software development for nearly two decades. If you build software that runs on, in, or alongside a medical device — whether it is embedded firmware, a cloud-based diagnostic algorithm, or a standalone mobile app — this standard defines the processes, activities, and documentation your team must follow. It is recognized by the FDA, required under the EU MDR as a harmonized standard, and referenced by regulators worldwide.
But the software landscape has changed dramatically since 2006. Artificial intelligence and machine learning are now embedded in diagnostic tools. Cybersecurity threats have evolved from theoretical concerns to active attack vectors. Agile development has replaced waterfall as the default methodology. The original standard, even with its 2015 amendment, was not designed to address any of this.
IEC 62304 Edition 2 is the answer. Expected to be published by August 2026, it is not a minor amendment — it is a structural overhaul that redefines how software process rigor is determined, expands the scope beyond traditional medical device software, introduces explicit AI/ML lifecycle requirements, and integrates cybersecurity as a core design control. This guide covers every significant change, explains the practical implications, and provides a compliance roadmap for manufacturers.
Edition 2 at a Glance
| Aspect | Edition 1 (2006+A1:2015) | Edition 2 (2026) |
|---|---|---|
| Process rigor framework | Three safety classes (A, B, C) | Two Software Process Rigor Levels (I, II) |
| Scope | Medical device software (MDSW) | All health software (MDSW is a subset) |
| AI/ML coverage | Not addressed | New clause 5.1.15 plus Annex E |
| Cybersecurity | Not directly addressed | Integrated as design control; references IEC 81001-5-1 |
| Normative references | ISO 13485 and ISO 14971 mandatory | ISO 13485 and ISO 14971 removed as normative |
| Legacy software | Section 4 (normative) | Moved to Annex |
| Agile guidance | None | Annex F (informative), based on AAMI TIR45:2023 |
| Communication plan | Not required | New clause 5.1.16 |
Background: IEC 62304:2006+A1:2015 Recap
Before diving into what changes, it is worth establishing what Edition 1 requires — because Edition 2 builds on, rather than replaces, most of its process framework.
The current standard organizes software development into lifecycle processes: development planning, requirements analysis, architectural design, detailed design, implementation, verification, integration testing, system testing, release, maintenance, risk management, configuration management, and problem resolution. The rigor applied to each process depends on the software safety class:
- Class A: Software that cannot contribute to a hazardous situation — no injury possible. Minimal documentation requirements.
- Class B: Software that could contribute to a hazardous situation resulting in non-serious injury. Moderate documentation requirements, including architectural design, unit verification, and integration testing.
- Class C: Software that could contribute to a hazardous situation resulting in death or serious injury. Full documentation requirements, including detailed design, comprehensive traceability, and thorough unit testing.
Classification is determined through risk analysis, integrated with ISO 14971. The standard references ISO 13485 for quality management system context and has been the go-to framework for both FDA submissions and EU CE marking.
While this framework has served the industry well, three structural limitations became increasingly apparent. First, the three-class system created a significant compliance cliff between Class B and Class C, with no practical middle ground. Second, the standard's scope was limited to software already classified as a medical device, leaving a growing category of health software unaddressed. Third, technologies like AI/ML, adaptive algorithms, and connected cloud services introduced lifecycle challenges that the original process framework was never designed to handle.
Edition 2 addresses all three — and more.
Timeline: When Edition 2 Takes Effect
Understanding the timeline is critical for planning your compliance activities. The publication of a new edition does not mean the old one becomes invalid overnight.
Publication and Adoption Timeline
| Milestone | Expected Timing | What It Means |
|---|---|---|
| Committee Draft (CD) stages | 2024-2025 | Draft circulated for national committee review |
| Final Draft International Standard (FDIS) | Early-mid 2026 | Final ballot by IEC national committees |
| Publication | By August 2026 | Standard is officially published |
| FDA recognition | 12-24 months post-publication | FDA updates its Recognized Consensus Standards list |
| EU harmonization under MDR/IVDR | 24-36 months post-publication | European Commission publishes harmonization decision in OJEU |
| Practical compliance expected | 2028-2029 | Most regulators and Notified Bodies begin auditing against Edition 2 |
The key takeaway: you have time, but not unlimited time. Regulators typically take 2-3 years to formally adopt a new edition. EN 62304:2006+A1:2015 remains the currently harmonized standard under EU MDR/IVDR, and Edition 2 will need a separate harmonization process. The FDA will need to update its list of Recognized Consensus Standards.
However, manufacturers who wait until formal adoption to begin preparation will find themselves scrambling. Forward-looking companies should begin aligning their processes in 2026-2027, especially for new development projects.
Change 1: Software Process Rigor Levels Replace Safety Classes
The single most consequential change in Edition 2 is the elimination of the three-class safety classification system (A, B, C) and its replacement with two Software Process Rigor Levels.
The New Rigor Level Framework
| Aspect | Old System (Edition 1) | New System (Edition 2) |
|---|---|---|
| Number of levels | Three (Class A, B, C) | Two (Level I, Level II) |
| Level I equivalent | Class A | Low process rigor |
| Level II equivalent | Classes B and C combined | High process rigor |
| Basis for determination | Severity of potential harm | Severity of potential harm (unchanged) |
| Classification granularity | Three tiers with distinct requirements for each | Two tiers with distinct requirements for each |
Level I corresponds to the old Class A — software where no injury or damage to health is possible. The process requirements are lightweight: planning, requirements, system testing, release, maintenance, risk management, configuration management, and problem resolution.
Level II corresponds to both the old Class B and Class C — software where non-serious injury, serious injury, or death is possible. All Level II software is subject to the same set of process requirements, which include architectural design, detailed design, unit verification, integration testing, and comprehensive traceability.
Why This Change Was Made
The three-class system created a persistent problem in practice. Many manufacturers spent significant effort debating whether a software item was Class B or Class C, because the documentation burden jumped substantially between them. Yet the fundamental risk analysis question — "can this software contribute to harm?" — is binary: either it can or it cannot. If it can, the standard now requires a uniformly high level of process rigor.
By collapsing B and C into a single Level II, Edition 2 eliminates a classification boundary that generated more debate than safety value. The determination of whether software can cause harm remains risk-based and severity-driven, but once you cross the threshold from "no harm possible" to "harm is possible," you apply full process rigor regardless of whether that harm is non-serious, serious, or lethal.
Practical Implications
For current Class A manufacturers: Little changes. Your software maps directly to Level I, and your existing process should remain compliant.
For current Class B manufacturers: Your process requirements increase. You will need to meet the full Level II requirements, which include detailed design documentation and comprehensive traceability that were previously Class C-only. This is the group most affected by the change.
For current Class C manufacturers: Your process requirements remain essentially the same. Level II aligns closely with the old Class C requirements.
What Does Not Change
The risk-based determination of rigor level still follows the same fundamental logic as Edition 1. You still perform risk analysis. You still consider severity of potential harm. You still consider independent external risk control measures. The classification at the software item level is still permitted — within a Level II software system, individual items can be classified as Level I if the architecture properly segregates them and the risk analysis supports it.
Change 2: Expanded Scope to All Health Software
Edition 2 broadens the scope of the standard from "medical device software" to "health software." This is a fundamental shift in the standard's ambition and applicability.
The New Scope Hierarchy
Under Edition 2, the scope operates as a nested hierarchy:
- Health software (broadest category): Any software designed to address health needs, including wellness apps, clinical decision support tools, health informatics platforms, and software used in health research
- Medical device software (MDSW): A subset of health software that meets the regulatory definition of a medical device — standalone SaMD, firmware in medical devices, and software embedded in regulated devices
- Software in specific health hardware: Software embedded in health-related hardware products that may not themselves be classified as medical devices
- Health software with AI/ML algorithms: Any health software that incorporates machine learning, deep learning, reinforcement learning, large language models, or generative AI
Why the Scope Expanded
The original standard's limitation to medical device software created two problems. First, an increasing number of health software products exist in a regulatory gray zone — clinical decision support tools, wellness-to-clinical transition apps, and hospital IT systems that directly influence patient care. These products were not clearly covered by IEC 62304, yet they carried real safety implications.
Second, regulators worldwide began developing separate, sometimes inconsistent, guidance for health software outside the traditional medical device framework. By expanding the scope, IEC 62304 Edition 2 positions itself as a single, unified lifecycle standard for the entire health software continuum.
Practical Implications
If you build software that is already classified as a medical device, this change does not reduce your obligations. You still follow Level II process rigor, and you still need compliance with ISO 13485 and ISO 14971 as part of your regulatory submission strategy.
If you build health software that is not a medical device — for example, a clinical decision support tool that does not meet the regulatory definition of a medical device — Edition 2 now provides a lifecycle framework you can follow. This is significant because it gives such products a recognized process standard to reference, even if regulatory compliance is not formally required.
Normative References Change
One important consequence of the scope expansion: Edition 2 removes ISO 13485 and ISO 14971 as normative references. This was necessary because non-device health software manufacturers may not operate under a full ISO 13485 quality management system or conduct formal ISO 14971 risk management. Making these references normative would have effectively excluded the broader health software category from adopting the standard.
However — and this is critical — for medical device software, following ISO 13485 and ISO 14971 remains best practice and is still expected by regulators and auditors. The removal of normative references does not give medical device manufacturers permission to ignore these standards. It simply means the standard is now accessible to a broader audience that may not be operating under a full medical device QMS.
Change 3: AI and ML Software Lifecycle Requirements
The most technically significant addition in Edition 2 is the treatment of artificial intelligence and machine learning. The original IEC 62304 was written for deterministic software — code that produces the same output for the same input. AI/ML systems behave fundamentally differently, and Edition 2 introduces a comprehensive lifecycle framework for them.
New Clause 5.1.15: AI Planning
Edition 2 adds clause 5.1.15, which requires manufacturers to develop an AI plan when their software incorporates AI or ML components. The plan must cover:
- The type of AI/ML technology used (machine learning, deep learning, reinforcement learning, large language models, generative AI, or combinations)
- The intended function of the AI/ML component within the health software
- The data sources, data quality requirements, and data governance strategy
- The model development approach, including training, validation, and testing methodology
- Performance metrics and acceptance criteria
- Monitoring and retraining strategies for deployed models
- Bias evaluation and mitigation approaches
This planning requirement applies at the beginning of the development lifecycle and is maintained throughout the product's lifetime.
AI-Specific SDLC Activities
Beyond planning, Edition 2 defines a set of AI-specific activities that must be integrated into the software development lifecycle:
| Activity | Description | When It Occurs |
|---|---|---|
| Data collection and management | Defining data requirements, sourcing data, ensuring data quality, managing data labeling, establishing data versioning | Early lifecycle, ongoing |
| Model building and tuning | Selecting model architecture, training, hyperparameter optimization, evaluating model performance | Development phase |
| Verification and validation | Confirming the model meets its specified requirements and performs as intended in its operational context | Development and integration phases |
| Deployment | Transitioning the trained model to the production environment with appropriate controls | Release phase |
| Operation and monitoring | Tracking model performance in real-world use, detecting drift, managing retraining triggers | Post-release, ongoing |
| Real-world performance evaluation | Systematically collecting and analyzing performance data from clinical or operational use | Post-release, ongoing |
Annex E: Evolving Technology and Methodologies
Edition 2 includes Annex E, an informative annex focused on evolving technology and methodologies with particular emphasis on AI/ML. This annex provides guidance on:
- How to apply the IEC 62304 lifecycle framework to adaptive and continuously learning systems
- Strategies for managing the inherent uncertainty in probabilistic AI outputs
- Approaches to maintaining traceability when the "design" of a system is partially determined by training data rather than explicit specification
- Considerations for explainability and interpretability in the context of safety
While Annex E is informative (not normative), it represents the first time a major medical device software standard has provided structured guidance on AI/ML lifecycle management. Manufacturers developing AI-enabled devices should study it carefully, as Notified Bodies and FDA reviewers will inevitably reference it during submissions.
What This Means for AI/ML Device Manufacturers
If you are building an AI/ML-enabled medical device, Edition 2 provides something that was previously missing: a recognized standard framework for your entire development lifecycle. Previously, AI/ML device manufacturers had to extrapolate from general IEC 62304 requirements and supplement with FDA guidance documents, which left significant gaps in auditability. The new clauses and annexes close many of those gaps.
The key practical implication is documentation. You will need to maintain detailed records of your training data, model architecture decisions, validation methodology, and ongoing monitoring strategy — all within the structured lifecycle framework that IEC 62304 provides. This is a significant increase in documentation burden compared to the pre-Edition 2 world, but it also provides a clear roadmap for what regulators expect.
Change 4: Integrated Cybersecurity Requirements
Cybersecurity has been a growing concern in medical device regulation, but until now, it has been addressed through separate standards and guidance — IEC 81001-5-1:2021 for security architecture, FDA premarket guidance for cybersecurity, and various national requirements. Edition 2 integrates cybersecurity directly into the software lifecycle standard.
Security as a Design Control
Rather than treating cybersecurity as a late-stage pen-test or a separate compliance activity, Edition 2 positions it as a design control requirement. This means:
- Security architecture must be defined as part of the software architectural design process
- Threat modeling must be conducted as part of software risk management
- Security requirements must be specified alongside functional and performance requirements
- Security verification must be integrated into the verification and validation activities
The standard references IEC 81001-5-1:2021 for detailed security architecture guidance. This is a reference, not a normative requirement — but given that FDA and EU regulators already expect IEC 81001-5-1 compliance for connected devices, treating it as optional would be imprudent.
Practical Implications
For manufacturers of connected medical devices, this change formalizes what many already do. If you have been conducting threat modeling, defining security requirements, and performing security testing as part of your development process, Edition 2 simply codifies that practice.
For manufacturers of devices that were previously considered "not connected" or "low cybersecurity risk," this change may require a reassessment. Even devices that do not communicate over networks may have USB ports, Bluetooth interfaces, or update mechanisms that create attack surfaces. Edition 2's integrated approach means cybersecurity must be considered for all health software, not just internet-connected products.
Alignment with Regulatory Trends
This integration aligns with the direction regulators have been moving. The FDA's refusal to accept premarket submissions without cybersecurity documentation for devices that meet its connectivity criteria is well established. The EU MDR's requirement for cybersecurity consideration in device design is increasingly enforced by Notified Bodies. Edition 2 brings the standard in line with these regulatory expectations, making it easier for manufacturers to demonstrate compliance with a single, integrated framework.
Change 5: Legacy Software and Transition
Legacy software — software that was developed and released before the current edition of the standard — has always been a challenge under IEC 62304. Edition 2 addresses this with a significant structural change.
From Section 4 to Annex
In Edition 1, legacy software requirements were in Section 4, making them normative (mandatory). In Edition 2, legacy software guidance is moved to an Annex. This repositioning reflects a pragmatic recognition: legacy software cannot be retroactively made compliant with every requirement of a new standard edition.
Transition Requirements for Class B Software
The most important transition requirement concerns Class B software (now Level II under Edition 2). Manufacturers must update documentation to meet Level II requirements either:
- At the time of the next software update or modification, or
- On a risk-based approach, prioritizing the highest-risk software items
This means that if you have existing Class B software that was compliant with Edition 1 but does not meet the full Level II documentation requirements (detailed design, comprehensive traceability), you do not need to drop everything and re-document immediately. But you do need a plan for closing those gaps, and that plan should be risk-prioritized.
Practical Strategy for Legacy Software
For manufacturers with large installed bases of Class B software, this transition requires careful planning:
- Inventory your software: Identify all Class B software items in your portfolio
- Assess documentation gaps: Compare current documentation against Level II requirements
- Prioritize by risk: Focus on software items with the highest potential for harm first
- Integrate into release cycles: Close documentation gaps as part of normal maintenance and update cycles
- Document your transition plan: Auditors will want to see that you have a structured approach, even if gaps have not all been closed yet
Change 6: Agile Development Guidance (Annex F)
One of the most requested additions to IEC 62304 has been formal guidance on applying the standard to agile development methodologies. Edition 2 delivers this through Annex F.
Why This Matters
The original IEC 62304 used language and process descriptions that implicitly assumed a waterfall or V-model development approach. While the standard did not mandate waterfall — it has always allowed any development model that is documented, repeatable, and controlled within a QMS — the language made it difficult for agile teams to map their sprints, backlogs, and iterative cycles onto the standard's lifecycle processes.
Annex F, based on AAMI TIR45:2023 and ISO 12207:2020, provides that mapping.
Key Guidance Points
Annex F addresses several areas where agile practices and IEC 62304 requirements intersect:
Incremental delivery and documentation: How to maintain compliant documentation when requirements, design, and code evolve incrementally across sprints. The annex clarifies that documentation does not need to be complete before development begins — it needs to be complete and accurate at the time of release.
Sprint-level lifecycle processes: How to apply requirements analysis, design, implementation, and verification within iterative sprint cycles rather than sequential phases.
Backlog management as requirements management: How a well-maintained product backlog with appropriately detailed user stories and acceptance criteria can satisfy the software requirements analysis process, provided traceability is maintained.
Continuous integration and testing: How automated testing, CI/CD pipelines, and test-driven development can satisfy verification requirements, with appropriate documentation of test cases, results, and coverage.
Definition of Done: How a rigorous "definition of done" that includes documentation, review, and testing criteria can serve as a release gate consistent with IEC 62304's software release process.
What Annex F Does Not Do
Annex F is informative, not normative. It provides guidance, not requirements. It does not replace any lifecycle process — it shows how to implement them within an agile framework. And it does not reduce documentation requirements — it shows how to produce them iteratively rather than sequentially.
The standard remains methodologically neutral. Whether you use Scrum, Kanban, SAFe, or a hybrid approach, the requirement is the same: your development process must be documented, repeatable, and controlled within a quality management system. Annex F simply makes it clearer how agile teams can meet that requirement.
Impact on FDA Submissions and EU CE Marking
FDA Submissions
IEC 62304 is recognized by the FDA as a consensus standard. Compliance enables a Declaration of Conformity in 510(k) submissions, which can streamline review by allowing FDA reviewers to rely on the standard's process framework rather than evaluating your software lifecycle processes from scratch.
When the FDA recognizes Edition 2, manufacturers who comply with it will be able to declare conformity to the updated standard. This is particularly important for AI/ML-enabled devices, where the FDA's own guidance on Predetermined Change Control Plans and Good Machine Learning Practice aligns closely with the new AI clauses in Edition 2.
For manufacturers currently preparing submissions, Edition 1 remains the recognized standard until the FDA updates its list. However, submissions that already incorporate Edition 2 principles — particularly AI lifecycle management and integrated cybersecurity — are likely to be viewed favorably, as they align with the direction of FDA policy.
EU CE Marking
In the EU, IEC 62304 is a harmonized standard under the MDR (EN 62304:2006+A1:2015). Conformity creates a presumption of conformity with the relevant General Safety and Performance Requirements. Edition 2 will need to go through a separate harmonization process before it gains this status under the MDR or IVDR.
This harmonization process typically takes 2-3 years after publication. During that time, EN 62304:2006+A1:2015 remains the harmonized standard. However, Notified Bodies are aware that Edition 2 is coming, and many are already incorporating its principles into their audit expectations — particularly for AI/ML and cybersecurity.
Manufacturers pursuing CE marking should continue to comply with the currently harmonized edition while preparing for the transition. When Edition 2 is harmonized, manufacturers with existing CE certificates will need to demonstrate compliance as part of their next surveillance audit or certificate renewal.
Other Jurisdictions
Health Canada, TGA (Australia), PMDA (Japan), and other regulators that reference IEC 62304 will follow their own timelines for adopting Edition 2. MDSAP audit teams will likely transition to Edition 2 relatively quickly once it is formally published, as the MDSAP process tends to align with the latest versions of recognized standards.
Practical Compliance Strategy: What to Do Now
The transition to IEC 62304 Edition 2 does not need to be disruptive — but it does need to be planned. Here is a phased approach for medical device manufacturers.
Phase 1: Assess and Map (Now through Q3 2026)
Objective: Understand your current state relative to Edition 2 requirements.
- Reclassify your software portfolio: Map every software item from the old Class A/B/C system to the new Rigor Level I/II system. Class A becomes Level I; Classes B and C become Level II. Document this mapping.
- Identify Class B gaps: For software currently classified as Class B, identify the additional documentation and process requirements needed for Level II compliance. This will likely include detailed design documentation and comprehensive traceability.
- Catalog AI/ML components: Identify any software items that incorporate AI, ML, or adaptive algorithms. Even if you consider them "simple" algorithms, the new requirements may apply.
- Review cybersecurity posture: Assess whether your current software development process addresses cybersecurity as a design control, or whether it is treated as a separate activity.
- Read Annex F: If you use agile development, study Annex F and map your current agile practices to the guidance it provides.
Phase 2: Update Processes and Templates (Q3 2026 through Q2 2027)
Objective: Align your QMS procedures, templates, and work instructions with Edition 2.
- Update software development procedures: Revise your SOPs to reference Rigor Levels instead of Safety Classes. Update decision trees and classification workflows.
- Create AI/ML planning templates: Develop templates for the AI plan required by clause 5.1.15. Include sections for data governance, model lifecycle management, and real-world performance monitoring.
- Integrate cybersecurity into design controls: Update your design control procedures to include threat modeling, security requirements specification, and security verification as standard design activities.
- Create communication plan template: Develop a template for the communication plan required by clause 5.1.16, defining how you will communicate software-related information to users, regulators, and other stakeholders.
- Update risk management procedures: Ensure your ISO 14971 risk management process accommodates AI/ML-specific risks (bias, drift, adversarial attacks) and cybersecurity threats.
- Train your teams: Conduct training for software developers, quality engineers, and regulatory affairs staff on the key changes and new requirements.
Phase 3: Execute and Close Gaps (Q2 2027 through Q4 2027)
Objective: Bring active development projects into compliance with Edition 2.
- Apply Edition 2 to new projects: All new software development projects should follow Edition 2 requirements from inception.
- Close Level II gaps for Class B legacy software: Work through your prioritized list of Class B software items, updating documentation to meet Level II requirements as part of normal release cycles.
- Implement AI plans: For software items with AI/ML components, complete the AI planning process and begin integrating AI-specific SDLC activities into your development workflow.
- Validate cybersecurity integration: Verify that your updated design control process produces the expected cybersecurity documentation for at least one development cycle.
Phase 4: Validate and Audit-Ready (Q1 2028 through Q3 2028)
Objective: Demonstrate compliance to auditors and regulators.
- Conduct internal audits: Audit your updated processes against Edition 2 requirements. Focus on the areas of greatest change: rigor level classification, AI/ML lifecycle management, and cybersecurity integration.
- Update technical documentation: Ensure your technical files and design history files reflect the new terminology (Rigor Levels), new requirements (AI plan, communication plan, cybersecurity), and updated traceability.
- Prepare for Notified Body audits: If you are subject to MDR/IVDR conformity assessment, prepare your auditors for the transition by proactively communicating your Edition 2 readiness.
- Update regulatory submission templates: For 510(k), PMA, and CE marking submissions, update your software documentation templates to reference Edition 2 where applicable.
Compliance Roadmap Summary
| Phase | Timeline | Key Activities |
|---|---|---|
| 1. Assess and Map | Now - Q3 2026 | Reclassify software, identify gaps, catalog AI/ML, review cybersecurity |
| 2. Update Processes | Q3 2026 - Q2 2027 | Revise SOPs, create templates, integrate cybersecurity, train teams |
| 3. Execute | Q2 2027 - Q4 2027 | Apply to new projects, close legacy gaps, implement AI plans |
| 4. Validate | Q1 2028 - Q3 2028 | Internal audits, update tech files, prepare for external audits |
The Bottom Line
IEC 62304 Edition 2 is the most significant update to medical device software lifecycle standards in two decades. The transition from three safety classes to two rigor levels simplifies classification decisions but increases requirements for what was previously Class B software. The expansion to all health software broadens the standard's reach. The AI/ML provisions fill a gap that has existed since machine learning began appearing in medical devices. And the integration of cybersecurity brings the standard in line with modern regulatory expectations.
The standard does not mandate a specific development methodology, does not reduce documentation requirements, and does not give manufacturers a pass on established quality practices. What it does is provide a more practical, more comprehensive, and more modern framework for ensuring that health software — whether it is a Class III medical device or a clinical decision support tool — is developed with the rigor that patient safety demands.
Manufacturers who begin preparing now, follow a phased transition plan, and treat this as a process improvement opportunity rather than a compliance burden will find that Edition 2 actually makes their development lifecycle more coherent, more auditable, and better aligned with the regulatory landscape they face.