How 'reality checks' can tailor IT security obligations to specific projects

This is the first of a two-part series of Insights. You can find the second Insight here.

The advent of new technologies and the emergence of new cyber threats has led legislators to increase their focus on cybersecurity obligations. In recent years, European institutions have enacted various legal instruments in which they stress the importance of information technology security.

The most well-known legal instrument imposing security obligations is the General Data Protection Regulation (GDPR), which came into force on the 25th of May 2016. However, other security requirements are also imposed under the Cybersecurity Act of 17 April 2019 and the Security of Networks and Information Systems (NIS) Directive of 6 July 2016.

Although these legal instruments pursue a legitimate aim – the protection of IT infrastructure and Europe's digital society – the IT security obligations they set forth are sometimes ambiguous and have raised concerns among security professionals. All too often, the stakeholders, including security professionals, IT vendors, Data Protection Officers (DPOs) and legal counsels, are drowning in a constant debate over the security measures to be implemented and their conformity with specific legal obligations. These exchanges are on often triggered by a lack of understanding of IT or IT security.

If there is to be a meaningful debate over IT security and compliance with related legal or contractual requirements, it is indispensable to understand IT security and, more specifically, its limitations. Legal requirements can be demystified by addressing them from an IT security perspective rather than a legal perspective. Can IT security be considered an "obligation of result"?

'Obligation of result'

IT procurement contracts too often require providers to offer strict guarantees for the security of the solution they offer. In some cases, IT suppliers are even required to guarantee that the solution has no security vulnerabilities. Although these claims seem acceptable and reasonable at face value, their legal consequences are not.

From a legal perspective, an obligation of result is typically perceived as a binary exercise. If a party commits to an obligation of result and fails to comply with this obligation, non-compliance will automatically trigger the supplier's liability. The supplier can only be excused from liability if it can demonstrate that the non-compliance results from an event of force majeure.

In the context of IT security, this obligation implies that an IT vendor would be responsible for any security incident unless it can demonstrate that this resulted from an event of force majeure. From a practical perspective, complying with this requirement is typically very complex as it denies the existence of so-called "zero day" vulnerabilities and IT security is often a trade-off between "security" and "usability".

Zero-day vulnerabilities

A common issue in IT security is the existence of zero-day vulnerabilities, which are typically defined as "a flaw in software, hardware or firmware that is unknown to the party or parties responsible for patching or otherwise fixing the flaw", such as the software vendor.

Although a zero day implies that the vendor or the person responsible for the security patching is not aware of the vulnerability concerned, it nevertheless occurs regularly that these vulnerabilities are known and exploited by malicious hackers. The Internet and the dark web offer countless fora and marketplaces on which malicious hackers share information and exploits for zero-day vulnerabilities.
Since zero-day vulnerabilities are typically unknown to the persons responsible for the development and release of the security patches, it is extremely difficult, if not impossible, for third-party IT providers offering the vulnerable solution to adequately protect against zero-day attacks.

Consequently, obliging IT vendors to commit to an "obligation of result" on the security of an IT solution developed by a third party is rarely the most productive way to approach the issue. It essentially implies that an IT supplier would be required to take legal responsibility (and the resulting liability) for an IT component that is not under its control and for a security vulnerability of which it cannot reasonably be aware.

Security-usability trade-off

Historically, one of the most fundamental paradigms in IT security held that IT security is a trade-off between security and usability: the more security measures you implement to protect your IT systems (so-called "hardening"), the more you need to reduce the functionality of that system.

Although this paradigm is becoming outdated as newer IT security solutions aim to combine usability and security, there are IT solutions that require, by their nature this trade-off. This could be the case, for instance, when customers request:

• their IT supplier to support the customer's legacy IT systems, which are no longer supported by the initial IT vendor (for example, older operating systems);
• to place certain systems outside the so-called Demilitarized Zone or DMZ (being the perimeter of devices that are protected by a firewall), which by its nature poses a larger security risk.

When customers require their suppliers support solutions that are no longer supported by their vendor or inherently pose a security risk, it becomes more difficult for such suppliers to accept an absolute obligation of result regarding IT security.

Under the GDPR

To support their demand for an obligation of result in regards to IT security, customers, their procurement teams or DPOs often refer to the IT security requirements specified under the GDPR.

Essentially, the GDPR aims to protect an individual's privacy by imposing specific conditions under which a person may "process" personal data. In order to prevent the unlawful disclosure, altering, deletion or manipulation of personal data, the GDPR imposes generic security obligations on the processing of personal data, which are set out in Article 32 of the regulation.

Although the GDPR imposes security obligations, it does not imply a general obligation of result with regard to IT security. Section 1 of Article 32 only states that the security requirements to be implemented should be tailored to the specific needs of the project, thereby taking into account: "the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons."

Consequently, under the GDPR, ensuring the overall IT security is not an obligation of result but rather an obligation of means. Under the GDPR, the obligation of result on IT security lies in the adoption and implementation of security measures that are appropriate talking into the nature, scope, context and purpose of the data processing but it does not require an overall guarantee on IT security.

OC conclusion

A general obligation of result on IT security is often not appropriate given the technological constraints of a project. It is typically better to adopt a more balanced approach, which requires the contracting parties to understand the technical limitations of a project and the security implications, and tailor the obligations to the specific security needs.

Consequently, instead of including general and vague "obligations of result" in the agreement, it often makes more sense to perform a reality check by exploring a party's actual security needs and benchmarking these in light of the capabilities and technical limitations of the solution. In doing so, the parties can tailor their contractual security obligations to the specific project and allocate the roles and responsibilities of each stakeholder with regard to security.

Our following Insights in this series will address liability in terms of IT security and the hidden costs related to implementing IT security measures.