How should organisations approach software liability when security flaws cause harm?

What liability should organisations assume when software flaws can cause harm?

Software liability is best treated as a governance and assurance issue because harm usually follows from predictable failures in design, testing, release, and maintenance. The key question is not only whether a defect existed, but whether the organisation took reasonable steps to prevent, detect, and correct it. That shifts attention to process evidence, not just legal theory.

When a flaw can affect users, systems, or data, the organisation needs a defensible story for why the risk was accepted, mitigated, or monitored. That story should be grounded in secure development practice, change control, vulnerability handling, and release discipline. Without that evidence, liability discussions quickly become arguments about avoidable negligence rather than bad luck.

What counts as reasonable precautions and due diligence?

Reasonable precautions are the controls and behaviours that show the organisation actively reduced foreseeable harm. In practice, that means code review, security testing, dependency management, patching, access control over release pipelines, and clear ownership for defect remediation. The standard is not perfection, but a credible control environment that matches the product’s risk.

Due diligence is strongest when it is repeatable and provable. Teams should be able to show secure development standards, testing records, remediation timelines, exception approvals, and release decisions. That evidence matters because liability exposure often turns on whether the organisation can demonstrate it identified the risk, weighed the impact, and acted before harm occurred.

The software supply chain is part of this analysis because many harmful flaws are introduced through third-party code, build dependencies, or insecure deployment practices. A liability posture is weaker when the organisation cannot show how it evaluates upstream risk, validates builds, or controls changes before release. Secure-by-design expectations increasingly extend beyond the codebase itself.

How should safe harbor be framed in practice?

Safe harbor should be treated as conditional, not assumed. It is most credible when the organisation can prove that testing found issues, remediation was timely, and the release process prevented known defects from shipping unchanged. That makes safe harbor a reward for disciplined engineering, not a blanket shield after harm has already occurred.

Safe harbor arguments are also stronger when the organisation can show that controls were proportionate to the product’s exposure. A consumer tool, enterprise platform, or safety-critical service will not support the same level of tolerance for known weakness. The more foreseeable the harm, the more important it is to show deliberate safeguards and clear escalation paths.

For organisations building or shipping digital products, the EU Cyber Resilience Act is a useful signal of where regulatory expectations are heading: secure-by-design, vulnerability handling, and lifecycle security are becoming baseline expectations rather than optional extras. In parallel, SLSA is a practical way to think about build provenance and artifact integrity when liability turns on whether insecure components were introduced upstream.

Risk and Threat Considerations

Liability risk increases when software defects are foreseeable, repeated, or left unaddressed after discovery. Harm can come from data exposure, service failure, unsafe automated behaviour, or a defect that amplifies a known operational weakness. The legal issue then starts to look like a control failure: the organisation lacked adequate evidence that it managed software risk responsibly.

Failure mechanism: The organisation cannot show that security testing, change control, dependency review, and remediation were consistently applied before release. That leaves a gap between what the product was expected to do and what the organisation can prove it did to prevent harm.

Impact: Claims of reasonable care or safe harbor weaken, while exposure rises to regulatory scrutiny, customer disputes, contractual claims, and reputational damage. If the same control gaps affected multiple releases or products, the liability argument becomes stronger because the failure pattern looks systemic rather than isolated.

Practitioner Guidance

What to prioritise: Build a release trail that shows who approved the change, what testing was performed, what was found, and how exceptions were handled. If you cannot reconstruct that trail for a harmful flaw, you will struggle to defend the quality of the decision-making that allowed it into production.

What to verify: Confirm that remediation SLAs, security gates, and rollback paths actually operate in practice, not just in policy. Evidence should include defect tickets, test results, and release approvals that tie directly to the version that caused the harm.

Practitioner takeaway: The organisations best positioned on liability are not those that promise flawless software, but those that can prove disciplined prevention, timely correction, and proportionate control over the path from code change to customer impact.

Related resources from NHI Mgmt Group

• Why does moving liability toward software vendors change the way organisations invest in security?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?