You may be wondering whether GDPR governs the handling of personal data which you collected before GDPR went into effect on May 25, 2018. The answer is both ‘yes’ and ‘no’.
Generally speaking, a law cannot be made retroactive. In the United States, for example, there is a constitutional prohibition against “ex post facto” laws, meaning laws that apply to acts that occurred before the law became effective.
We are unaware of any country – or region – which allows for retroactive application of laws passed after the fact, and this includes the EU.
So generally speaking, GDPR should not apply to data that was collected before GDPR’s effective date (25 May 2018). (NOTE: That said, the UK’s ICO – Information Commissioner’s Office – which says that it is “The UKâ€™s independent authority set up to uphold information rights in the public interest, promoting openness by public bodies and data privacy for individuals” – recommends “Refresh your consents if they donâ€™t meet the GDPR standard.” In other words, they recommend reconfirming.)
There are some aspects of GDPR that, while forward looking, apply broadly to all data that you may have under your control.
How can this be, if a law does not apply retroactively?
Because these sections of GDPR aren’t data-specific; rather they are event specific, and are applicable to all businesses that retain data.
An analogy would be this: A country may pass an omnibus vehicle safety law which includes a regulation about vehicle emissions, saying that cars manufactured after a certain year – say 1999 – have to meet a strict emissions standard. In that same law there may be a section that sets a new speed limit. All vehicles will have to adhere to that new speed limit, not just those manufactured after 1999.
GDPR contains a requirement that if personal data in your possession is breached, you are required to notify a supervisory authority of that breach within 72 hours of having become aware of the breach. This is (for some) a new standard, and it applies to all personal data in your possession.
Notification of a personal data breach to the supervisory authority
In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.
The other main area where GDPR is agnostic in terms of when the data was collected has to do with the responsibilities and liabilities as between data controllers and data processors. By way of example, when someone comes to your website and gives you their email address, you are a data controller. When you pass that email address to your email marketing service provider, so that they can send out your newsletter, they are a data processor. It’s possible (even common) for an organization to be both a data controller and a data processor.
GDPR lays out the responsibilities and liabilities of both data controllers and data processors. Among other things, a data processor has the responsibility to be GDPR compliant in terms of how they handle the data that data controllers entrust to them. They also have to make clear to the data controller that they are GDPR compliant, and also make clear to the data controller how they can check on this to ensure that the data processor is GDPR compliant. This does not depend on whether the data controller is passing pre- or post-GDPR acquired data.
This is why we advise all organizations to ensure that any data processors with which they do business have right in their contract assurances that the processor is GDPR compliant.
And, while we’re talking about those contracts, the precatory language of GDPR (which makes up the first 32 of the 88 pages of GDPR) says that if the data processor ends up not being GDPR compliant, and there is a data breach as a result, both the processor and the controller may be found to be liable.
Specifically, section 146 of the precatory language says:
The controller or processor should compensate any damage which a person may suffer as a result of processing that infringes this Regulation. The controller or processor should be exempt from liability if it proves that it is not in any way responsible for the damage. The concept of damage should be broadly interpreted in the light of the case-law of the Court of Justice in a manner which fully reflects the objectives of this Regulation. This is without prejudice to any claims for damage deriving from the violation of other rules in Union or Member State law. Processing that infringes this Regulation also includes processing that infringes delegated and implementing acts adopted in accordance with this Regulation and Member State law specifying rules of this Regulation. Data subjects should receive full and effective compensation for the damage they have suffered. Where controllers or processors are involved in the same processing, each controller or processor should be held liable for the entire damage.
For this reason, we also recommend that the contract between data controller and data processor contain language providing that the processor will indemnify the controller if there is a data breach owing to the processor either not being GDPR compliant or another factor within the control of the processor.
Nowhere in GDPR is there any language exempting pre-GDPR data from these two requirements.
ISIPP can help you with drafting the correct language to include in your contracts to reduce your risk of liability in these two situations. If you would like to discuss that with us, please email us here.
It is true that a great deal of how this all shakes out will almost certainly end up having to be decided in court.
Our job is to make sure that you are not a test case.