HIPAA Survival Guide® Newsletter February 2018: Issue 98
Your HIPAA Compliance Companion
This webinar discusses how to comply with the General Data Protection Regulation ("GDPR") regulations as promulgated by the European Union ("EU") Regulation EU 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons regarding the Processing of Personal Data, the free movement of such data.
Organizations who currently, or plan to, promote business with EU states must comply with this regulation.
Date and Time, including Time Zone
February 16, 2018 2:00pm EST
Effective May 2018 the General Data Protection Regulation ("GDPR") goes into effect. Organizations currently, or planning to, transact business with EU member states must comply.
This article describes the new GDPR regulations as well as new product offerings on the HIPAA Survival Guide that include:
GDPR Breach Notification, GDPR Model Security and Privacy Policies, and the GDPR Model Notice of Privacy Practices.
We hope you find this article helpful! Please contact us at support@3LionsPublishing.com if you have any questions.
The objective is to explain GDPR Compliance in simple terms, and provide you with guidelines and tools for implementing, refining and measuring policies and procedures. The GDPR is even more vague and descriptive than HIPAA. Although HIPAA does not provide covered entities and business associates "how to" guidance, it does a good job of describing the "what" at a reasonable level of detail. You're out-of-luck with the GDPR. Lawyers have to extrapolate best practices from reading "between the lines" because of what is there, but at such a high level that it will drive lawyers, consultants, compliance officers and laypersons nuts trying to decipher it.
WHO DOES THE GDPR APPLY TO?
Glad you asked! It applies to Controllers and Processors of Personal Data, or what we call in the states personally identifiable information ("PII"); something that the FTC regulates. The GDPR defines Personal Data ("PD") as follows:
PD means any information relating to an identified or identifiable natural person ('data subject'); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.
It's a really broad definition of PII. It also applies to an organization's employees, which of course share PII with their employers on a routine basis. But, first and foremost, the GDPR is interested in protecting the rights of consumers ("Data Subjects"). The EU treats privacy as a "fundamental right" like we treat "freedom of speech" or "freedom of the press." No really. The GDPR makes privacy a constitutional right in all EU member states, plus Norway, Iceland, and Switze
Well, that's nice, but why should U.S. entities care about EU law? Because the GDPR applies to ALL companies that target EU citizens with goods and services. So, if you want to sell into the EU then THIS MEANS YOU. What happens if you don't comply? Well, it may be hard for the EU to get jurisdiction over you to impose fines, BUT they can stop your operations in the EU! They can shut you down. That's No Bueno if the EU represents an important market for you.
NOTICE OF PRIVACY PRACTICES ("NOPP")
You GDPR NOPP is similar to covered entities NOPP under HIPAA, except you need to provide access to it in places where Data Subjects would expect to see it. What that means in practice must be determined on a business by business basis. If you are an online business, it probably means having it more widely available than buried somewhere in your "I Agree" terms of service. Of the four policies mentioned above, this is the only one that is "consumer-facing." Its primary intent is to inform Data Subjects (i.e. consumers for the most part) about their rights under the GDPR and your particular approach to safeguarding them. Here is a sample paragraph from our Model GDPR NOPP:
Data Subject's Bill of Rights
We take appropriate measures to provide information, at the point of access, pursuant to the following: our identity, and the identity of our GDPR representative, and Data Protection Officer; the lawful purpose for our Processing of your Personal Data (e.g. Consent); our legitimate interests, where applicable; the categories and potential Recipients of your Personal Data, and whether we intend to transfer your Personal Data. Further, we will provide you an estimated period that your Personal Data will be stored, and your rights pursuant to your Personal Data such as: (1) the right to access and correct; (2) the right to erasure ("the right to be forgotten"); (3) the right to restrict Processing; (4) the right of Data Portability; (5) the right to withdraw Consent of further use; (6) the right to know the lawful basis for Processing (e.g. Consent, contract, statutory, etc.); (7) the right to object to Processing (e.g. in the case where Personal Data is being used for direct marketing); (8) the right to receive Personal Data Breach Notification; (9) the right to know about Recipients; (10) the right to file a complaint; (11) rights to judicial remedies.
As always our annotated Model GDPR NOPP contains actual hyperlinked references to the law so that you can confirm why this paragraph is contained in the policy and also use it as an educational tool.
Surprisingly there is only one Article in the GDPR (Article 32) that deals directly with security. It's not that security is not important under the GDPR, it obviously is; rather, it's that the emphasis on Privacy dominates. Because the GDPR provides very little guidance (understatement) with respect to the "what" of security requirements, our Model GDPR Security Policy borrows heavily from industry best practices and from our experience with other compliance regimes. Under the GDPR, unlike HIPAA, a Risk Assessment need only be performed when your organization has identified PD Processing that puts Data Subjects at "high-risk." Where that is the case then you must perform a Data Impact Assessment (i.e. a Risk Assessment) and reduce all identified "high" risks to levels of "medium or low." If you can't reduce risk levels to medium or low then you have a date with the Supervisory Authority. Further, for any new Processing you have to perform this Data Impact Assessment before the new functionality ships. The GDPR is unclear as to how quickly you have to perform a Data Impact Assessment for existing high-risk Processing.
BREACH NOTIFICATION POLICY
The GDPR introduces Breach Notification into the EU for the first time. Given what we have witnessed under HIPAA (post the HITECH Act) Breach Notification will also emerge as the GDPR's 800-pound Gorilla. We are not going out on a limb here. It appears obvious, at least to us, that most high profile GDPR enforcement actions are likely to stem for large breaches. Why? Because the Supervisory Authority knows exactly who to audit when that happens. It will also likely use these occasions to send a message that there's a new sheriff in town. Unlike the HIPAA sheriff, who someone shot and has been lame ever since the GDPR sheriffs (there's a mandated Supervisory Authority for every state in the EU) are likely to be better armed and better protected.
Reporting and Tracking Security Incidents
Just like HIPAA, organizations that want to be GDPR compliant will need to start tracking "security incidents." A security incident ("Incident") means (to us--the term is not defined in the GDPR) the attempted or successful unauthorized access, use, disclosure, modification, or destruction of Personal Data or interference with system operations in an Information System. For the GDPR, an attempt will likely qualify as an Incident as well. All organizations are required to track and review Incidents to determine when Breach Notification is triggered. Why? Because if you are not tracking Incidents, how can you possibly know when there's been a Breach?
Notification may be required to both the Supervisory Authority and to Data Subjects but under different conditions. Notification to the Supervisory Authority is required when a Personal Data Breach is likely to result in a risk to a Data Subject's rights. However, Data Subjects need only be notified when the Personal Data Breach is likely to result in a high-risk to Data Subjects. The GDPR provides scant guidance as to how a Controller (or Processor) should differentiate between a risk and a high-risk.
Who Must Provide Notification
Following a Breach of PD, assuming the conditions discussed above are met, a Controller must provide notification of the Breach to affected stakeholders (i.e. the Supervisory Authority and Data Subjects). Under certain circumstances, notification may be required to U.S. regulatory authorities as well (e.g. if it's a U.S. entity that experienced the Breach and U.S. citizen's PD was also compromised). In addition, similar to HIPAA Covered Entities and Business Associates, Processors (or Sub-Processors) must notify a Controller (or Processor) when a Breach has occurred within an Information System under their control that contains the PD of Data Subjects. It is only a Controller that provides Notification. Sub-Processors must notify the Controller (or Sub-Processor) without undue delay.
Timeliness of Breach Notification
The general rule is that all notifications must be made to: (1) the Supervisory Authority no later than seventy-two (72) hours after discovery of the Breach; and (2) Data Subjects without undue delay after discovery of the Breach. A delay may be allowed for law enforcement, provided that a law enforcement official provides the required information on the record. In the case where such a request is made by law enforcement, the notification may be delayed accordingly. Depending on the facts surrounding the Incident, notice is provided to Data Subjects and the Supervisory Authority. The Notification must contain specific content in addition to being delivered in a timely manner.
The Notification must: (1) describe the nature of the Breach, including where possible, the categories and data attributes (where known), the approximate number of Data Subjects impacted, and the approximate number of records concerned; (2) contain the name and contact details for your Data Protection Officer; (3) describe the likely consequences of the Breach; and (4) describe the mitigation measures taken or proposed to be taken.
Privacy and Security of Personal Data is important to all individuals and organizations. The objective of this article was to provide a high-level overview of GDPR guidelines for implementing and complying with this Regulation. The following information will be presented in our Webinar but is shown here to provide guidance on how to begin implementation of a GDPR Plan.
THE 10 STEP GDPR IMPLEMENTATION PLAN
1. Develop a Data Landscape/Data Audit/Data Inventory
1.1. List all your mission-critical business applications ("Apps") by function (use our spreadsheet)
1.2. Provide a high-level description of the Processing the App performs
1.3. List all Personal Data ("PD") associated with/contained within/held by/ each App
1.4. List all uses & disclosures related to this App, especially those outside of the organization
(i.e. Identify Recipients)
1.5. List any inter-EU transfers of PD related to this App
1.6. List any transfer from this App outside of the EU
1.7. Create a process flow diagram for each App
2. Develop, Review, and Distribute Policies
2.1. Develop your initial policies (use our Model Policies)
2.2. Have the Executive Team review/modify each policy as required (awareness & accountability)
2.3. Distribute the policies to your workforce and have each member that touches PD sign the policy-store
the signed policies in your Compliance Repository (see below)
2.4. Modify and redistribute your policies as required due to changes in the GDPR or changes in your
3. Understand the Data Subject's Bill of Rights & Processes
3.1. Define the process required to allow a Data Subject ("DS") to access, correct, restrict, or erase PD from
each App captured above
3.2. Designate and train someone in the workforce that will own (i.e. be accountable for) each process
(preferably someone that is familiar with the App in question)
3.3. Response to the Data Subject must be accomplished within 30 days
3.4. Data Subjects may not be charged (i.e. requests are free") unless extenuating circumstances apply
4.1. Identify all high-risk PD processing across your Data Inventory
4.2. Perform Risk Analysis on all Processing identified as high-risk (use "GDPRized" Expresso® when
4.3. Mitigate all high risks to a level that is medium or low
4.4. If you can't mitigate a high risk, then you need to schedule an appointment with the Supervisory
Authority ("SA") for a review-something you definitely want to avoid
5. Identify the Low Hanging Fruit on an App by App Basis
5.1. Encrypt, wherever possible, all PD within the App in all "states"
5.1.1. PD at Rest
5.1.2. PD in Motion
5.1.3. PD Disposed
5.1.4. Data in Use (obviously can't encrypt here but there are other best practices to implement)
5.2. Identify members of your workforce to perform these tasks or seek help from consultants
5.3. Encryption and de-identification eliminate 95% of the liability-convince your management team
that this is the single most import GDPR investment they can make (well, in addition to everything
else in this 10 Step Plan)
6. Create your GDPR Compliance Repository (Folder Structure)
6.1. Data Subjects
6.2.2. Due Diligence
6.2.3. Processing Overview
6.3.3. Data Subjects or Categories
6.4. Risk Assessments
6.4.1. Risks Mitigated
6.4.2. Controls Implemented
7. Implement the Necessary Safeguards
7.1. Administrative (organizational processes)
7.2. Technical (hardware/software controls)
7.3. Physical (locks, cards, cameras, etc.)
8. Train Your Staff
8.1. Overview (everyone)
8.2. Data Subject's Bill of Rights Processes (subject matter experts)
8.3. Ensuring lawful Processing (legal, compliance, IT, c-suite)
8.4. Breach Notification (everyone)
9. Develop Breach Notification Tools & Processes
9.1. Methodology for understanding when Breach Notification is triggered
9.2. Ensure the C-suite understands the Breach Notification is the 800-pound gorilla of GDPR
9.3. Model letters to the SA, model letters to Data Subjects, model press releases, etc.
9.4. Response readiness-define contractual relationships with mission-critical partners, understand the
Team of Teams approach, assign a response General Manager (preferably a TSLF)
9.5. Desktop test the plan and revise accordingly
9.6. Notification to SA must be accomplished within 72 hours (no notification as to why delay is reasonable
and appropriate); IF high-risk to Data Subjects
10. Disaster Recovery Planning & Processes
10.1. Treat this exercise as an attempt to "Katrina Proof" your operational environment and therefore the
PD that it contains
10.2. Develop and Emergency Mode Plan
10.3. Assign roles and responsibilities to key players & make sure a robust "call list" is developed which
includes workforce members, partners, government agencies, etc.
Expresso® is an easy to use Risk Assessment software that allows you to detect risks, threats, security objects, and vulnerabilities to PHI and identify impacts and assign controls at a glance! Expresso® is available as part of our HIPAA Survival Guide® Subscription Plan or alone, as a monthly subscription.
Just click on the Act Now Button below and fill out the information and our Customer Service Staff will set up your Free 15 Day Expresso™ Test Drive and arrange a "Go To Meeting" session to review how you can do your HIPAA Risk Assessment in 3 hours or less.
Our "Quick Start Guide" and educational videos get you off and running to complete your first Baseline Risk Assessment. Expresso™ comes pre-populated with all the Risks, Threats, Vulnerabilities and Impacts necessary to a complete your Risk Assessment.
What is the new LinkedIn GDPR Survival Guide?
What is the HIPAA Survival Guide® Subscription Plan and what does it include?
What is The Contingency Framework?
HIPAA Requirements for Breach Notification including Policies and Procedures
HIPAA Requirements for a Business Associate Agreement including the essential terms of the agreement
How to prepare for a HIPAA Security Rule Audit
How to prepare for a HIPAA Privacy Rule Audit
How to prepare for a HIPAA Breach Notification Audit
How to prepare for a HIPAA Risk Assessment Audit