Hi Mark, Happy to discuss. Send me an email via firstname.lastname@example.org and I can talk about the principles I use.
In my view I don't believe, as a community, we have fully bottomed out all the risks associated with these types of engagement.
• Nokia Solutions and Networks Australia Limited
For a very good, concise review of the principles and issues of cloud agreements generally, covering most of your points above (my view anyway), you might also check out David W. Tollen's book "The Tech Contracts Handbook" online or via this website:
Hi there. I have submitted and forwarded your question to Daniela Badescu, who is the practitioner in charge of the IACCM Community of Interest "Data Privacy and Data protection", and who has recently delivered a webinar on GDPR. Daniela will be back to you on this. Thanks
• Willis Towers Watson
This is a very interesting point. Thank you for raising the question.
As all is still new with GDPR, it's hard to say what the actual practice is.
One aspect to consider is that the administrative fines are tiered, with the first being up to 2% of the turnover or 10M Eur (whichever is higher) and the second tier up to 4% or 20M Eur (whichever is higher).
Let's assume a consultant provides a set of recommendations and implementation guidelines. GDPR consultants could argue that following that advice is the company's business decision and that applying and maintaining the processes to remain compliant is the company's responsibility.
Also, holding a consultant liable for up to 4% of their customer's turnover may be more than what they can/are willing to cover. Ie. assume an organisation has 10M EUR turnover - this mean the consultant's liability would be up to 400,000 EUR. How does this measure against the consulting fee?
To set up a liability coverage, I believe it may make sense to look at fines in the context of specific contractual obligations and see if based on that, the fines qualify as direct or consequential damages.
It may be different for contracts where there is a continuous service to design, maintain and review the GDPR related processes. Still, the level of liability remains subject to negotiation and I would rather expect it to be tied to the actual contract value and not on fines or other operational costs that may result from non-compliance.
What type of contracts are you looking at? It would be great if you can share what you have seen.
thank you for your kind response!
It seems it is becoming practice for companies seeking GDPR consultants to require liability for administrative fines and related costs incurred.
You have asked about the contracts, these are service/consulting contracts between GDPR consultant and SME company (client) which intends to source out the GDPR management/compliance to an external consultant. The services would typically include investigation of readiness for GDPR, preparation of guidelines the company should comply with with regards to GDPR, impact assessment and gap analysis.. The value of such contracts is a fraction of the administrative fines which might be implied upon the client by the authorities in case of GDPR breach. GDPR consultants who refuse to accept full liability for the administrative fines often loose their opportunities and clients.
I do not fully understand your paragraph on direct and consequential damages. Could you please kindly explain?
Thank you again for your time and help.
• NISSAN Europe (Alliance Renault)
Please share any market trends regarding "super caps" instead of unlimited liability in case of data and/or security breaches for SAAS, PAAS and IAAS contracts, Thanking you in advance, Hubert
Hubert - this wasn't SaaS, PaaS, IaaS specific - but on most recent contracts relating to ICT managed services I've worked on (network and apps support) customer took an approach of requesting unlimited liability, then relaxing back to super cap between £15 - £25m (depending on bargaining power).
Sabine, a very interesting question! I am sending this to a few members who will certainly know the answer. I also wonder how much this provision differs from requirements by other regulatory authorities - for example in US or UK - and will research that point as well - plus how the banks are then handling it.
Many thanks, Tim. Looking forward to your and others' feedback on this point. Best, Sabine
Sabine, here is a reply from Jihong Chen at Zhong Lun law firm:
It is really a hottest topic among multinational IT companies. The story is very long. One latest update is China Banking Regulatory Commission released a new circular on Feb, 12, 2015, which clarifies that:
1) The implementing rules for recording of source code is still under research. CBRC will solicit comments from all sides and then implements;
2) As to the requirement for independent IP for pre-installed software, it only requires IP certificate or legitimate source document;
3) There is no country difference.
Escrow of source code might be acceptable by CSRC as the final solution.
And another ....
Look at the link below for some background and additional context on the issue.
Also- according to UK Financial Times report on 25 Feb, companies in Europe and US have gathered together requesting government taking actions against the CBRC guideline on secured and controllable technology.
And to add to the series, this excellent outline of issues and status has been provided to us by law firm Baker & McKenzie:
The following notices on "secure and controllable" technology has been issued thus far:
1. Notice Concerning the Use of Secure and Controllable Information Technology to Strengthen Internet Security and Informatization in Relation to Banks (Yinjianfa No. 39 of 2014 ((2014) 39 ) ("CBRC Notice No. 39")
2. The China Banking Regulatory Commission ("CBRC"), National Development and Reform Commission ("NDRC"), Ministry of Science and Technology ("MOST") and Ministry of Industry and Information Technology ("MIIT") jointly issued CBRC Notice No. 39 on 3 September 2014. Although the scope of addresses does not expressly include Chinese branches of foreign banks, the document is required to be delivered to banks and financial institutions which are independent legal persons. We are of the view that if the foreign invested bank is a registered legal person in China, it is likely to be subject to CBRC Notice No. 39.
CBRC Notice No. 39 sets out policy statements by the CBRC, concerning the use of "secure and controllable" information technology in the banking industry. The key points in CBRC Notice No. 39 pertaining to cyber-security are as follows:
* CBRC Notice No. 39 requires that from 2015, the proportion of "secure and controllable" information technology over the total information technology products and software used by each bank should increase at least 15% each year, and reach a minimum of 75% in 2019. The "secure and controllable" information technology products and technologies newly added in 2014 may be included in the calculations for the increase used in 2015.
* CBRC Notice No. 39 appears to suggest that in the selection of information technology products and technologies by banks, at least one "secure and controllable" domestic product or technology has to be considered in the selection and testing process where one exists.
3. Guideline on Advancing the Application of Secure and Controllable Information Technology in Banking Industry (Yinjianbanfa No. 317 of 2014 ( (2014) 317 )) ("CBRC Notice No. 317")
CBRC Notice No. 317 was jointly prepared by the General Administrative Offices of the CBRC and MIIT and circulated on 29 December 2014. As with CBRC Notice No. 39, this document is likely to apply to any foreign invested bank which is a registered legal person in China.
The document contains, inter alia, an annex which sets out the scope of the requirements for "secure and controllable" information technology products and technologies across various product categories, as follows:
* Computer equipment
* Network equipment
* Storage equipment
* Security equipment
* Common software
* Specialized software
* Automated equipment
* Terminal equipment; and
It appears that similar requirements for "secure and controllable" information technology have been introduced to banks in the past. However, these requirements were not closely adhered to due to the lack of implementation details. Given that CBRC Notice No. 39 sets forth formal requirements and CBRC Notice No. 317 provides for implementation details and procedures, banks may now feel more compelled to take the necessary actions to comply with the "secure and controllable" requirement.
With regard to enforcement measures, the CBRC conducts annual audits on banks (at least to the level of State-owned banks and joint-equity commercial banks) to evaluate all aspects of the banks' operation and risk control, and issues audit reports requesting a written response from banks addressing each issue and indicating correctional measures. In addition, the CBRC conducts a larger scale audit on banks every 3 or 4 years. The banks' implementation of the requirements for "secure and controllable" information technology will now be included in such audits for review and assessment.
On 12 February 2015, the CBRC issued a clarification document which provides that the research on how to proceed with the recordal of source code is still ongoing. The mode and process of recordal will only be implemented after the opinions of relevant stakeholders have been sought.
We understand that there have been discussions regarding the promulgation of umbrella laws or regulations relating to internet verification and testing. It is unclear when these umbrella laws or regulations will be issued. However, if it is to be issued as a law, this will require promulgation by the National People's Congress ("NPC") or its standing committee.
If however the umbrella rules will be issued by way of regulations by the State Council or a Ministry, the amount of time required to promulgate the new rules will take a shorter period of time, as it will not need to undergo the legislative process required in the case of passing of laws by the NPC.
It is unclear what these umbrella rules will encompass. However, we expect the umbrella rules to provide more details as to the (a) scope of products subject to the "secure and controllable" requirements; (b) nature of the testing and recordal requirements; (c) type of entities that will be required to purchase "secure and controllable" products and technologies.
Based on the CBRC Notices above as well as the press articles, we anticipate that the umbrella rules are likely to include encryption testing requirements as well as recordal requirements for source codes. We expect these rules will apply to banks (since these are already covered by the CBRC Notices discussed above). However, it is also not beyond the realm of possibility that the "secure and controllable" requirement will also apply to products and technologies purchased by government bodies, the army, key State-owned enterprises, and potentially academic and research institutes in sensitive areas.
Please note that there is no draft regulation at this time available to the public and our views above are based on the ongoing discussions in the press and from our review of the CBRC Notices, as well as our understanding of the cyber-security regulatory environment in China.
China's impending cyber-security measures have not been well-received by U.S. businesses. In a letter addressed to Chinese cybersecurity officials and signed by U.S. associations including the U.S. Chamber of Commerce, these standards were described as overly broad and discriminatory. The stricter cyber-security standards could thereby limit the range of US products available to Chinese businesses. The groups have implored the Chinese authorities to delay the implementation of the measures and grant an opportunity for discussion between interested stakeholders and the agencies responsible for the initiatives.
Additionally, the business lobbies have also sent a letter to American officials, including Secretary of State John Kerry, requesting the White House to work with Chinese officials to reverse China's new cyber-security regulations. In response, President Obama has pledged in the National Security Strategy to take necessary actions to protect U.S. businesses and defend U.S. networks against cyber- theft of trade secrets for commercial gain by the Chinese government.
• New Zealand Defence Industry Association (NZDIA)
See my answer to other post on IP clauses.
In addition to the issues listed above, be sure to consider any proprietary background IP, methods, know-how, or expertise you are contributing to the results. You want to give the client the ability to use the project results while still protecting anything you want to be able to use again on future projects for other clients. For example, you may give the client a license but not ownership of the IP, or limit their use of the IP to a specific field or geographical area so you do not unduly limit your future business opportunities.
• Innovation Fixer
1. BACKGROUND IP - what are you bringing to the table? What is the other party bringing? Does the commercial outcome need cross-licensing? You should ensure this licensing does not restrict your continued use in other applications in any way, unless that is part of the trade/partnership. You may wish to define the field of use quite specifically, and limit use and licensing to this area. Will your ability to sub-license the IP to other parties be limited? Again, this is a concession that's worth something.
2. ARISING IP - who will own any IP generated in the collaboration? Try to avoid joint ownership; instead one party should own and the other have licensing rights. One option is for one party to own, and the other to have exclusive rights to a field of use. Will use be limited to the parties, a so-called semi-exclusive? Will one or both parties have the right to sub-license?
The owners of any IP in a collaboration should be obliged to maintain the IP and defend it against challenge. If they decide to let e.g. a patent lapse, there should be a reversion clause which allows the licensee to take over ownership of the IP.
This is just a start.....!
• T. Mackey Enterprises, LLC
To Whom It May Concern:
I think that there are several things to be concerned about in a R&D Contract. Whether you are contracting with a Government or another business entity, here is a list of terms, (in order of importance), that I think should be clearly described:
1) Statement of Work: Clearly describe what will be researched/develop.
2) Period of time that the research will be conducted.
3) Who, (key personnel/researchers), in your company will conduct the research.
4) The contract value of the research in the monetary unit applicable to your country.
5) The frequency of research progress reports that will be submitted to the Buyer, (Schedule of Deliverables), the format that the progress reports will be in, and the monetary value of each Progress Report in relation to the Total Contract Value/Price so that your company can submit invoices for incremental payments until the Period of Performance/R&D Contract is completed. Usually progress reports are delivered on a quarterly schedule.
6) Ownership of any Inventions or patents during the research by your company's researchers.
7) Use Rights for any Technical Data, S/W, or any Intellectual Property OTHER THAN INVENTIONS OR PATENTS, which is created during the performance of the contract retained by your company.
8. The ability to terminate the contract if it's apparent to both parties that the research is futile.
9. The type of contract: Fixed Price, Cost Reimbursement, Time & Material, etc.
In my understanding, the DP liability is entirely to the DC - which is logical, since the DP might not have any physical presence in the UK. I find the following guide very useful http://ico.org.uk/for_organisations/data_protection/~/media/documents/library/Data_Protection/Detailed_specialist_guides/outsourcing_guide_for_smes.ashx
The DP would indemnify the DC if the DP was in breach of the UK Data Protection Act. it is very important for DCs to ensure that their DPs have adequate data security in place especially DPs who are abroad and that DP clauses exist in commercial contracts.
In terms of the 8 different payment schemes I was specifically referring to what we call 'payment curves' (see attached graphic) as opposed to payment regimes such as cost+ (time and material), fixed price, cost + fixed fee, etc. In this light these are grouped into 5 main families with a couple of variations inside each. These are as follows:
- 'all or none' payment curves
- Linear payment curves
- Non-linear payment curves
- Alternative payment such as demerit point and visual payment curves
- Matrix payment curves
The intent of this discussion is to simply highlight that the choice of payment curve, similar to the choice of performance measure and level, can have a significant impact on the success (or otherwise) of the overall performance management framework. My blog (www.performancebasedcontracting.com) has 3 posts specifically on this topic including the graphics.
I hope this helps and answers your questions. However, please let me know if you have any further questions.