They should treat it as both, but safety governance must lead. In a connected vehicle, quality defects can affect driver attention, reliability, and the behaviour of features that are active on the road. That means release approvals, rollback plans, and compatibility checks belong in the same governance conversation as engineering standards.
Why this belongs in safety governance, not only engineering
Software quality in a vehicle is not just a codebase issue. If a defect changes braking logic, driver warnings, sensor fusion, update behaviour, or feature availability while the vehicle is active, it can affect safety outcomes directly. That is why automakers need governance over release criteria, rollback authority, and field compatibility, not only engineering standards for coding and testing.
The practical distinction is accountability. Engineering teams can define how software is built, but safety governance decides whether a release is acceptable to ship, under what operating conditions, and what evidence is sufficient when behaviour changes could affect occupants or other road users. In connected vehicles, those decisions often have to cover software, firmware, dependencies, and update channels together.
That governance lens also matters because software quality failures are often latent. A defect may look minor in a lab build yet become material when the vehicle is under load, offline, or interacting with older components. The right question is not whether quality is “an engineering issue,” but whether the quality issue can change the safety case for the product.
How product engineering still fits into the control model
product engineering remains responsible for making the software fit for purpose. That includes requirements, design reviews, testing depth, defect triage, and compatibility checks across model years, trims, and regional variants. Without that discipline, safety governance becomes a paper exercise because it lacks reliable evidence about what the software actually does.
The key is that engineering produces the facts, while governance interprets their safety significance. A good release process separates routine defects from safety-relevant defects, then escalates the latter to the people who own product risk, homologation, and safety sign-off. Release management should therefore treat regression evidence, update blast radius, and fallback behaviour as part of the decision record.
Automakers also need to think beyond one vehicle function at a time. Modern vehicles are software platforms with shared services, over-the-air update paths, and interdependent modules. A compatibility failure in one component can create a system-level issue even when the original defect seems isolated to engineering.
What good governance looks like for connected-vehicle software
Good practice is to define safety-relevant software quality as a governed risk domain with explicit entry and exit criteria. That means release gates, post-release monitoring, and rollback readiness are owned as part of the safety case, while development teams remain accountable for implementation quality and defect prevention. A release should not advance solely because testing passed; it should advance because the residual risk is understood and accepted.
Where the software can affect vehicle motion, warnings, control interfaces, or availability of a feature in use, quality assurance should be traced to the operational context in which the vehicle is driven. The most useful evidence is not test volume alone, but evidence that the relevant failure modes were exercised, observed, and either mitigated or accepted with clear constraints.
For broader control design, frameworks like NIST Cybersecurity Framework 2.0 help structure governance, protection, detection, and recovery around software-dependent systems, while ISO/IEC 42001:2023 AI Management System Standard is a reminder that safety-impacting software decisions need accountable management processes, not only technical checks. For release integrity and secure build practices, NIST CSF 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls support the idea that configuration control, change approval, and system integrity are governance obligations, not optional engineering extras.
Risk and Threat Considerations
When software quality is treated only as a development concern, automakers can miss failure modes that become safety issues after deployment. The main risk is that a defect passes technical validation but still changes how the vehicle behaves in the field, especially after updates, under degraded connectivity, or across mixed hardware generations.
Failure mechanism: A release introduces an unintended interaction, compatibility break, or update regression, and the problem only appears once the software is running in real conditions with active safety-relevant features.
Impact: The vehicle may misbehave, reduce driver trust, create distraction, or require urgent rollback or service intervention, all of which increase operational and safety risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Software quality that can affect vehicle safety needs governed risk acceptance and release decisions. |
| PR.PS-01 — Baseline Configuration of Technology Assets | Connected-vehicle software quality depends on controlled builds, versions, and compatibility baselines. | |
| RC.RP-01 — Recovery Plan Execution | Rollback and recovery are central when software defects affect active vehicle behaviour. | |
| Recommendation — Define release risk criteria for safety-impacting software and require acceptance before deployment. Enforce approved baselines for vehicle software and block unreviewed configuration drift. Maintain and test rollback procedures for safety-relevant vehicle software releases. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Release approvals and compatibility checks are change-control issues for vehicle software. |
| SI-2 — Flaw Remediation | Quality defects in vehicle software need tracked remediation before they become safety issues. | |
| Recommendation — Require formal change control for software updates that can affect vehicle safety behavior. Prioritise remediation of defects that can alter safety-relevant vehicle functions. | ||
Practitioner Guidance
What to prioritise: Separate ordinary defect management from safety-relevant quality decisions. If a defect can alter feature behaviour on the road, treat it as a governed release risk rather than a routine engineering ticket.
What to verify: Check that every safety-relevant release has a documented rollback path, compatibility assessment, and clear evidence of what was tested under realistic vehicle states. If those cannot be shown, the release is not ready for safety sign-off.
Practitioner takeaway: Automakers do not need to choose between safety governance and product engineering, they need engineering evidence to feed a governance decision that can stop or constrain a release when software quality affects real-world vehicle behaviour.
Related resources from NHI Mgmt Group
- Should organisations treat infotainment testing as part of broader software assurance governance?
- Should security and IT leaders treat service quality as part of identity governance?
- Should organisations treat extension review as part of software supply-chain governance?
- What makes agentic AI an NHI governance issue?