Further References on Privacy Law
FTC and Voluntary compliance
The FTC does not require businesses to post privacy policies. In 2012, the FTC published a report recommending best practices for privacy policy practices.
Industry groups recognize that if they adopt these practices they may reduce the likelihood of more direct regulation. Regional trade associations like the Better Business Bureau have required that their members post privacy policies. These groups provide guidance to their members on the content of the privacy policy.
California Law
California requires that any commercial website or online service that collects personally identifiable information through the Internet about individual customers residing in California must have a posted privacy policy on its website.
The privacy policy required by California known as CalOPPA includes the following clauses:
1) What type of personal information is collected and what third parties this information may be shared with;
2) How users can request changes to any of the personally identifiable information that was collected;
3) Describes how the website operator will notify users of changes the privacy policy;
4) Sets out an effective date of the privacy policy;
5) Discloses how the website operator responds to “Do Not Track” requests from users; and
6) Discloses whether other third parties may collect personally identifiable information about users through the website services.
Here is link on more information about CalOPPA including how personal identifiable information is defined.
GDPR:
The GDPR, which becomes effective May 25, 2018, requires privacy policies to include the following:
1. Identity and contact details (and if applicable the Data Protection Officer or DPO)
2. Purpose of the processing and legal basis for processing
3. Legitimate interests of the controller or 3rd party (where applicable)
4. Categories of personal data
5. Any recipient (or categories of recipients) of the personal data
6. Details of transfers to 3rd country and safeguards
7. Retention period or criteria used to determine the retention period
8. Existence of each data subject’s rights
9. Rights to withdraw consent at any time
10. Right to lodge a complaint with a supervisory authority
11. Source of personal data and whether it was a public source
12. Did the personal data come from a statutory or contractual requirement or obligation and possible consequences of failing to provide personal data
13. Existence of automated decision making, including profiling and information about how decisions are made, the significance and the consequences.
Supplemental Privacy Shield’s 16 principles:
Sensitive data
Journalistic exceptions
Secondary liability
Performing due diligence and conducting audits
Role of the data protection authority
Self-certification (see specifics below)
Verification (must demonstrate self-assessment or outside compliance reviews)
Access
Human resources data
Obligatory contracts for onward transfers (see specifics below)
Dispute resolution and enforcement (see specifics below)
Choice – timing of opt out
Travel information
Pharmaceutical and medical products
Public record and publicly available information
Access requests by public authorities
ICO (UK’s DPA) guidance on what is needed in contracts under GDPR can be found here.
Areas of gaps between Model Clauses and GDPR requirements (and references):
1. Duration of processing – need to add clause
Article 23 (3)
2. Confidentiality – need to add representation about confidentiality by DI
Art 28 (3) (b)
3. Responding to data subjects – need to add cooperate with DC in responding to requests by data subject
Art 28 (3) (e)
4. Data breach notification – need to add more timing requirements
Art 28 (3) (f)
33-34
DC: 72 hours
DP: without undue delay
5. DPIA – need to add assist DC with creation of DPIA IF DC initiates a DPIA.
Art 28 (3) (f)
35-36
6. Audit right – need to add more GDPR requirements
Art 28 (3) (a)
46
7. Cross border transfers – need more about DI’s obligation to disclose further onward transfers to additional countries outside EEA
Art 28 (3) (a)
46
Further Resources on DPIAs:
Article 35 of the GDPR:
https://gdpr-info.eu/art-35-gdpr/
UK’s DPA ICO’s view:
This article has a helpful graphic illustrating what the DPIA requires:
https://www.i-scoop.eu/gdpr/dpia-data-protection-impact-assessments/
Code of Conduct:
Written Security Plan Topics
​
1. Access controls:
How is the system accessed in order to provide or access data? What types of password protocols are used?
2. Technical and Organizational measures (TOM):
What is the standard in your industry?
(a) Data encryption: Is data encrypted in transit?
(b) Pseudonymization: Does this make sense for your business?
3.Intrusion detection:
How are you monitoring your system to detect malicious attacks?
4. Incident management:
Assuming an intrusion occurred, how can it be isolated, neutralized and any damage to system quickly remediated? Restore normal service, intervene before incident causes more damage. This is also referred to as an incident response plan. Remember an incident is not the same as a breach, which triggers certain notification requirements to regulators and possibly individuals affected by the breach.
5. Physical security:
What are your systems physical vulnerabilities both internally and externally to the organization? External: natural disasters, power grid. Internal: employees theft.
6. Testing:
Is there regular testing of the integrity of the system by trusted third parties (e.g. penetration testing)?
7. Reliability & Backup:
What is Plan B? Can data be accessed in case of disaster from another location?
8. Disaster recovery:
Have various scenarios been mapped out and rehearsed?
A written security plan should also include single point of failure (SPOF) analysis. Are there any single points of failure (SPOF) in your digital systems? This could be a faulty switch or an ISP outage.
What should be included in a SPOF analysis?
-
Does your hardware have backup and failover to protect system in case of hardware failure?
-
Do you have a backup internet provider in event of ISP failure?
-
Is your SPOF overreliance on one IT person who if they left or had emergency you would not know how to manage your system?
The written security plan should include (or be based upon) a SPOF audit of the company and its systems. This should include a network diagram and identification of all points of risk and the appropriate redundancies in case of failure. An experienced IT provider either internal or external to the organization can carry out the task but it should be managed and overseen by the senior management of the company.