The first seven months of 2017 have featured an impressive number of highly-mediatised security breaches that took their toll on a significant number of customers and end-users. But you don’t have to be a large technology company or industry behemoth to bear the risk of being hacked; plus, multiple handling of databases of users’ data (that are available online or purchased by means of a company-wide transaction) results in liability being harder to attribute in case of major leaks. Faced with so many uncertainties, here are some ways for companies to protect themselves in face of potential breaches, in relation with their end-users or commercial partners.
1. Set clear expectations about what’s being delivered
Often, the largest problems arise from unclear, interpretable or too general terms and conditions and contractual provisions related to what a client or end-user expect to receive. When designing a product or service, its intended use is straightforward for the producer / provider, but not may be so for the entity using it. Clearly describing what the product can and cannot do, and what the results of service may and may not be used for, limits the possibility of a contracting party to claim damage for any type of security mishap. Fear the legal over-drafting and stick to real-life cases which may arise, based on your industry experience. Also, make sure you refer to any limitations that your product or results of service may have, and whether (and when) certain uses may need prior authorization from you as a vendor / producer.
2. List people involved in data processing and handling
Your contracting party will assume that their point of contact in your company is the person in charge for a specific product or service. For every client deployed, the team in charge must be clearly specified in the client agreement. It is also good practice to mention who will have access to the data provided by the client, for how long and what security measures will be taken to limit access to such data to the extent that is needed to provide the services or deliver the product. Internally, make sure you are aware of the security of the devices, protocols and software used by the team working on the project, to access client’s data, and limit use (or duration of use) of such terminals outside of the working environment used to access client data.
3. Integrations with third-party components
You should normally not be responsible for faults and breaches arising from a specific deployment or integration with a third-party product or service. To the extent possible, clarify what integrations your product supports and what kind of integrations are already bundled into the product being offered. There are cases when integrations are intertwined with core assets in your product, so making a clear split between what belongs to you and other third-party products is complicated; in such cases, a technical route to limiting liability is being able to isolate faulty parts as soon as a potential breach is notified to you, without affecting uptime of the product (which could entail damages to the user because of inability to use product). This leads to the idea of designing security as part of initial product development.
4. Maximum caps and types of damages that can be claimed
These can be used separately or in conjunction: while limiting damages means setting a threshold beyond which your company cannot be held liable for any loss, deciding on what type of damage – direct or indirect, actual or potential – to incur refers to consequential effects. It used to be recommendable to clarify that liability arises only in cases of direct damages (i.e. damages which can be clearly attributed to a breach provoked by a company’s actions or products). Since court practice started to re-qualify certain damages as direct, companies have started to set hard caps, regardless of type of damage incurred by their clients or end-users. This comes in conjunction with the cyber insurance policies that have become standard practice: the hard cap should follow the maximum value insured on the policy.
5. Inactions and negligence
Most security breaches do not come from an intended action, so it should be clear if your company will be responsible for inactions and effects arising from negligence. If not performing an action came because of an extraordinary situation which could not have been foreseen according to the normal delivery of the contract (or your company’s experience in the field), then a limitation of liability should be attempted. Similarly, if negligence does not come as a result of an expected situation that arises during contract execution then you should push for some form of liability exclusion.
…Part II of the Digital2Law guest post coming up soon. Stay tuned!