Data Controller/Data Processor Contracts #2:
Regulatory Alignment

This is the second blog in an ongoing series examining the often-overlooked nuances of data controller/data processor contracts.

Regulatory alignment is one of the primary reasons regulations require contracts between data controllers and data processors. And, yet, despite its primacy, many contracts make the mistake of establishing this linkage with an overly simplistic clause stating that the processor must comply with “all relevant data protection regulations.”

From the controller’s perspective, it seems logical and safe, since it puts the onus on the data processor to determine what regulations are relevant and what is required for compliance. If there is a breach or other incident related to data processor noncompliance, the data controller is not at fault.

There are two problems with this logic, however. Firstly, the data controller is technically always responsible for their data processor’s compliance, and even more so when contracts are vague. This means that it is to the controller’s benefit to contractually define the applicable regulations, as well as what is required of the data processor to be compliant. Secondly, regulators and courts are all too aware that the compliance acumen of most data processors is limited (to put it generously) and thus would likely consider it unreasonable, if not outright negligent, for a data controller to be satisfied with a loose reference to “all relevant data protection regulations.”

It is also important to note that some regulations require very specific contractual alignment. Under HIPAA/HITECH, for instance, the business associate (data processor) must expressly commit to complying with HIPAA’s Privacy Rule and Security Rule, as well as the HITECH security breach notification requirement. Other regulations, such as the General Data Protection Regulation (GDPR) and emerging U.S. state regulations, also require detailed regulatory alignment, including breach notification, an agreement to numerous items under the category of data subject rights, and the assignment of a qualified compliance officer.

From the data processor’s perspective, a general reference to overall regulatory compliance is equally problematic.

As mentioned, many data processors possess what is best described as a vague understanding of what regulatory compliance is. They may well believe they are compliant; though they would be hard pressed to describe what that regulatory compliance entails. Executing an agreement to comply with all relevant regulations, without understanding exactly what those relevant regulations are, and what they require, falls under the definition of bad faith, and if something calls that compliance into question, it could lead to existential consequences, including a breach of contract lawsuit, a contract rescission, the paying of regulatory penalties, and civil or criminal liability.

This “bad faith” aspect of agreeing to non-specific regulatory compliance expectations is exacerbated by the number of state data protection regulations popping up across the U.S. and the rest of the world.

Starting with the EU’s GDPR in 2018 and continuing with the growing number of recent national and state data protection regulations, borders are irrelevant. These regulations apply to the citizens of these nations and states regardless of the location of the controller or the processor, and regardless of the area of the world to which those citizens have traveled. Technically, a hospital in Chicago caring for a European patient is required to comply with the GDPR, just as a hotel in New Mexico hosting a California resident is required to comply with the CPRA. If an Alaskan business acquires the personal data of European and Californian patrons, it is expected to comply with both the GDPR and CPRA.

As a result, it is a virtual certainty that all data processors have data controller clients that are subject to these new global and state regulations, and any processor agreeing to comply with “all relevant data protection regulations” is representing they are compliant with those regulations as well.

The fact that there is little near-term risk of getting caught does not alter the fact that the data processor has testified to their compliance in writing. It is not only unethical to sign a contract under false pretenses, but also imprudent. Doing so could provide grounds for the data controller to terminate the contract (regardless of their true motives) and, were regulatory liability to become an issue, hold-harmless clauses and other liability limitations could be nullified.

Fortunately, there are alternatives to overly simplified regulatory contract provisions.

1. Instead of a clause agreeing to comply with all applicable data protection regulations, the data controller could require the processor to possess certifications that align with regulatory compliance. When choosing this option, it is essential for both parties to ensure that the designated certification(s) can withstand global regulatory scrutiny. Many do not.
2. Modify the regulatory alignment clause to state that the processor is responsible to comply with specified regulations and specified requirements, e.g., breach notification and data subject rights. This agreement would necessarily include the right to modify these requirements when regulations change, as it is likely there would be regulatory changes over the term of any multi-year agreement.
3. A data processor may ask to reword the compliance commitment to state that they will make “all reasonable attempts” to comply with data protection regulations. The weak link in this being that either party could be required to explain and defend the extent of these “reasonable attempts.”
4. The contract keeps the onus of regulatory compliance on the processor, while also requiring the processor to have a robust internal capacity for determining and meeting its obligations. This may be the safest course of action from the controllers’ perspective since it puts the compliance onus on the data processor in a manner that would likely be deemed reasonable by regulators and courts. From the processors point of view, having this capacity would also be a powerful marketing tactic.