Strictly cybersecurity: strict liability in cybersecurity is coming

Pillar III of the new U.S cyber security strategy is to “Shape Market Forces to Drive Security and Resilience”.  This far reaching ambition makes sense in that it recognises the importance of cybersecurity to business and seeks to leverage market power and innovation to solve this major problem.

There is more to this, however. One of the key objectives of Pillar III is “Shifting liability for software products and services to promote secure development practice” and this means strict liability for developers is coming. And it’s not just in the US, the EU is following this path too.

The legal concept of strict liability is commonly used in product safety regulation (for the UK this is under the Consumer Protection Act, as based on the Pre-Brexit EU Product Liability Directive), which essentially sets out that certain businesses are responsible for ensuring that any physical product they place on the market is safe.  As a result, those businesses are subject to the concept of strict liability, which is a greater liability burden than that usually imposed by contract or tort (the law of negligence), and it can’t be avoided.

Under strict liability, a claimant needs only to show that a product is defective and has caused it damage (in terms of injury to person or to property), in which case the manufacturer/importer/own brander of the defective product will be strictly liable to compensate the claimant for the damage caused, irrespective of the lack of any commercial relationship between the parties.

Take a deep breath for now developers as, for the moment at least, a product (as covered by the CPA and PLD) does not include software which is not incorporated as part of a physical product (although that in itself can lead to difficult questions of delineation).  Also, the CPA imposes a burden of strict liability only in relation to claims by consumers.  However, the lead being taken by the U.S and by the EU in imposing strict liability for developers more widely means that UK may well follow suit.

When that happens, the likelihood is that, if a consumer (or potentially a business) suffers damage as a result of a cybersecurity incident (which in all likelihood will include financial damage given the nature of the beast), a developer of any cybersecurity related software (or any party own-branding such software) may be strictly liable if it can be shown that the software package (which would include any related instructions or warnings) is defective and that the software caused the damage by failing to do its job.   This could have a massive impact and result in developers facing substantial group claims at the very least.

These are early days and changes to any legislation will have to reflect the hydra-like nature of cyber security, where software developers are constantly reacting to the changing threat.   In this respect, the timing of when software was supplied and when the threat arose will be a key factor.  But whatever happens, developers (be the in the US, EU or UK) are soon going to be under more pressure than ever and they need to be ready.

We will place responsibility on those within our digital ecosystem that are best positioned to reduce risk and shift the consequences of poor cybersecurity away from the most vulnerable in order to make our digital ecosystem more trustworthy