Cyber security and data protection are often the biggest concerns for organisations when contracting with ICT suppliers. Security breaches can have major financial, business and reputational impacts. Following the well-publicised ransomware attack on the Waikato DHB in 2021, the Ministry of Health is investing an additional NZ$75.7m over three years on cyber security. The Reserve Bank was subjected to a significant cyber-attack in early 2021. The bank estimated that its response cost approximately NZ$35m and used 17,500 hours of people's time.
However, despite the importance of these issues, in practice, we find that they are often not addressed in contracts between customers and suppliers with the rigour that might be expected. Undoubtedly a key reason for this will be that security issues are exceptionally complicated and involve engaging with a lot of technical detail.
Engage early to set expectations
Often organisations will try to keep it simple and avoid getting into too much detail by simply including general obligations, such as a requirement for one party to "comply with X standard".
However, failing to engage on the detail can cause problems later down the track. Buddle Findlay has recently come across contracts for critical systems and outsourced services with serious mismatches of expectation between customers and suppliers about their security responsibilities. This has left customers vulnerable because of assumptions about what suppliers were doing (but in fact were not), and suppliers at risk of disputes where a customer's expectations aren’t met, despite the supplier potentially having done all that was strictly agreed. To achieve real security and certainty for both parties, these mismatches need to be identified and addressed.
While a "comply with X standard" provision may appear a reasonable and pragmatic approach, for a variety of reasons, these may actually provide little legal protection. For example, requiring a supplier to simply "comply with the Privacy Act" often doesn't work well in New Zealand as many of the obligations under that Act will likely fall on the customer and cannot be transferred to the supplier in such brief terms. Similarly, an obligation, in a Government context, on a supplier to "comply with NZISM" doesn't work well when there are various ways to achieve compliance to different levels and again, the compliance obligations rest with the customer and not the supplier. More importantly, this approach often means both parties may also gloss over security at a technical level. Easy agreement to one-liner obligations typically won't identify mismatches in expectations about what will be done by whom at a practical level - potentially leaving a critical system vulnerable.
On the other hand, being too prescriptive in terms of a supplier's security obligations may be unhelpful if the customer is expecting the supplier to ensure that a system is secured in accordance with industry security practices – which may move over time.
Avoid security breaches through clear responsibilities
Striking an appropriate balance often takes some time and energy. And while parties may be reluctant to invest this time if they just want to "get on with the job", contractual compliance will of course come into sharp focus if a security incident occurs and people seek to establish who is liable for what. While some contractual breaches may be resolved by payment, many security breaches will have wider implications that can't be fixed with money, such as reputational damage or sensitive information (whether personal or business) becoming widely known. It's usually better to put the time into ensuring that the parties are clear about what their responsibilities are to ensure breaches don't occur, rather than relying on contractual remedies after a cyber incident has occurred.
The risks of not engaging on the detail have become very apparent to us when recently acting for several clients on business-critical systems. While these did not involve security breaches, it has highlighted how this could be a contributing factor in the future. Sometimes these critical systems have been in place for years and the customer has thought the supplier has been applying various security controls, which in fact it has not. When expectation and reality have met, it has been an unpleasant surprise for both parties and resulted in substantial remediation projects to uncover what has been happening, and then agree what to do and who will pay.
No shortcuts to achieving real security
Our big takeaway has been that there are no shortcuts to achieving real security. Whether it is from a technical or legal perspective, if you want to ensure your system is as robust as you intend, both parties must engage on the detail.
In our view, it's also to a supplier's advantage to get into the detail and ensure that the parties are on the same page. If security is the number one issue for customers, or very high on the list, it will be a competitive advantage to demonstrate good security measures and give customers that assurance. A supplier is unlikely to make customers happy if a critical system is shown to be vulnerable by saying "but we did everything that was required under the contract". That is of course easier said than done in the face of a customer wanting its project underway now and finished as cost effectively as possible but is likely to be worth the effort in the long run.
Only real engagement will ensure customers and suppliers are on the same page about their security obligations, rather than finding the system is not as secure as expected because one or both parties assumed the other was taking care of the issue.
