WHAT TO ADD?

Article 30 (records of processing activities) adds new requirements for controllers and processors to document their operations. Most importantly there are now rules for categorising the types of data collected by controllers, recording the recipients for which the data is disclosed, and specifying an indication of the time limits before the personal data is erased.
Article 35 calls for data protection impact assessments (DPIAs) before the controller initiates new services or products involving the data subject’s health, economic situation, location, and personal preferences — and more specifically data related to race, sex life, and infectious diseases. The DPIAs are meant to protect the data subject’s privacy by, among other restrictions, forcing the controller to describe what security measures will be put in place.

The new breach notification rule probably has received the most attention in the media. Prior to the GDPR, only telecom and ISP service providers had to report breaches within 24 hours under the e-Privacy Directive.11
Modelled on this earlier Directive, the GDPR’s Article 33 says that controllers must tell the supervisory authority the nature of the breach, categories of data and number of data subjects affected, and measures taken to mitigate the breach.
Controllers are required to notify the appropriate supervisory authority of a personal data breach within 72 hours (at the latest) on learning about the exposure if it results in risk to the consumer. But even if the exposure is not serious, the company still must keep the records internally.
Per the GDPR, accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data is considered a breach.
Article 33 also requires that a data processor has to notify the controller of a breach upon discovery.

Article 34 adds that data subjects must also be told about the breach but only if the breach results in a high risk to their “rights and freedoms”. If a company has encrypted the data or taken some other security measures that render the data unreadable, then they won’t have to inform the subject.
Article 17 (right to erasure and right to be forgotten) has strengthened the DPD’s existing rules on erasure and then adds the controversial right to be forgotten. This article explicitly states that if the data subject withdraws consent, the personal data should be erased without delay.

There’s now also language that would force the controller to take reasonable steps after “taking account of available technology and the cost of implementation” to inform third-parties of a request to have personal data deleted that was made public. This is the new right to be forgotten. It means that in the case of a social media service that publishes personal data of a subscriber to the Web, they would have to try to remove not only the initial information but also contact other websites that may have copied the personal data. This would not be an easy process! And by the way, it won’t apply if the processing is necessary for “freedom of expression”.

Finally, a requirement that has received less attention but has important implications is the new principle of extraterritoriality described in Article 3 (territorial scope). It says that even if a company doesn’t have a physical presence in the EU but collects data about EU data subjects — for example, through a website — then all the requirements of GDPR are in effect.
This is a very controversial idea especially in terms of how it might be enforced. As we pointed out earlier, it has already been applied in the more limited case of search engine processors under the existing DPD.
CONCLUSIONS AND RECOMMENDATIONS: GDPR COMPLIANCE CONSIDERATIONS
Going into the final negotiations that began in 2015, the parties — the EU Council, Parliament, and Commission — still had differences on some key issues. These included the GDPR fine structure, data privacy officers (DPO), and breach notification reporting. We’ve already mentioned the breach rules, so let’s cover the other two.

The GDPR has a tiered fine structure. Article 83 (general conditions for imposing administrative fines) says that a company can be fined up to 2% of global revenue for not having their records in order (Article 30), not notifying the supervising authority and data subject about a breach (Articles 33, 34), or not conducting impact assessments (Article 35).

More serious infringements merit up to a 4% fine of global revenue. This includes violation of basic principles related to data security (Article 5) and conditions for consumer consent (Article 7) — these are essentially violations of the core Privacy by Design concepts of the law.
Since the EU GDPR rules apply to both data controllers and processors, that is “the cloud”, the huge cloud providers are not off the hook when it comes to GDPR fines.
Coming into the negotiations, there were also differences over whether companies had to appoint a data protection officer who would be responsible for advising on and monitoring GDPR compliance, as well as representing the company when contacting the supervising authority.
With the final GDPR, many companies will likely need a data protection officer or DPO (Article 37). If the core activities of a company involve “regular and systematic monitoring of data subjects on a larger scale”, or large-scale processing of “special categories” of data — racial or ethnic origin, political opinions, religious or philosophical beliefs, biometric data, health or sex life, or sexual orientation — then they’re required to have a DPO.
In general, there is some room carved out for micro, small, and medium-sized businesses in the GDPR. Most under-250 employee companies will likely not need to have a DPO, keep records, notify a supervising authority about a breach, or carry out a DPIA.

For EU companies and their US and other foreign subsidiaries that are currently under the existing DPD, the new GDPR will be viewed as an evolution of the existing regulations. Although the breach notification, the new documentation requirements, and the steep fines will mean that they will have to up their compliance game.

For companies, particularly US, caught in the extraterritoriality net, the GDPR will come as something of a shock. This is especially true for web-based services that are not regulated under existing US financial or medical data security laws.
For companies with existing IT data security standards in place — SANS 20, PCI DSS, ISO 27001 or NIST 800-53 — compliance with the EU’s GDPR should be readily achievable
Our overall recommendation is that any company affected by the new law should focus on these following points:
Data classification — Know where personal data is stored on your system, especially in unstructured formats in documents, presentations, and spreadsheets. This is critical for both protecting the data and also following through on requests to correct and erase personal data.
Metadata — With its requirements for limiting data retention, you’ll need basic information on when the data was collected, why it was collected, and its purpose. Personal data residing in IT systems should be periodically reviewed to see whether it needs to be saved for the future.
Governance — With data security by design and default the law, companies should focus on data governance basics. For unstructured data, this should include understanding who is accessing personal data in the corporate file system, who should be authorized to access and limiting file permission based on employees’ actual roles – i.e., role-based access controls.
Monitoring — The breach notification requirement places a new burden on data controllers. Under the GDPR, the IT security mantra should “always be monitoring”. You’ll need to spot unusual access patterns against files containing personal, and promptly report an exposure to the local data authority. Failure to do so can lead to enormous fines, particularly for multinationals with large global revenues.

For the ICO guide on GDPR, click here.

ARE YOU READY FOR GDPR?
CLICK HERE