IAPP CIPM – From Small & Medium Enterprise (SME) to Multinational examples Part 3

9. US Multinational – Data Transfers

Hi guys. Here we are, the final section of our country. multinational example, and we’ll discuss data transfers. Let’s start with the BCR, which are binding corporate rules. EEI needs to have a set of binding corporate rules for its personal data transfers from the European Economic Area that stay within its corporate group. These rules must contain a description of the personal data that is transferred, the types of data subjects involved, and the types and nature of the processing of the personal data. a description of how compliance with these rules, observing the Data Protection Principles and data subject rights, is complied with and what the role of the DPO is in monitoring this compliance. In addition, liability for noncompliance must be established, as well as acceptance of liability for non-EU entities by EU entities. Rule violations must also include a list of the third countries involved, so deter must compare a list of legal entities within the corporate group to the third countries listed in the rules.

There should be a statement outlining how the laws of these third countries may affect the enforcement of data privacy principles and data subject rights. He must also review how adherence to the rules is independently audited within the group and any audit report that is produced. EEI would be subject to the BCR. Controllers and dealers should refer to the Recent Working Party 29 table of the elements that these BCR should contain within the two processors used by EEI. They may use sub processors within the same corporate group and so be subject to the Coprocessors, so Data should inquire about that with the processors and their adherence to the Recent Working Party 29 table of the elements.

Finally, Data should review the DPA’s approval of all applicable BCRs regarding SCC’s standard contractual clauses. EEI needs to enter into the controller-processor agreements for its personal data transfers from the EEA that go outside its corporate group. They are for transfers to its data mirroring and business continuity vendor in the Philippines, which is Quickbuck, and to Indian Processor for software application or for software appliHyperbad may only receive personal data periodically to be used to test software application changes, while Quickback would receive the full amount of personal data given.

Its role is to provide a data mirroring service and the ability to provide a seamless backup website that could handle customer business if there are any service interruptions with the primary websites or other corporate services. Data should be investigated to determine why personal data used for application testing was not anonymized and why real data records are required. Besides reviewing the controller-processor provisions, the dieter should determine whether the agreement contains the standard contractual clauses for transferring data outside the European Economic Area space.He should assert whether type one or type two is being used, and that is the SEC. For transfers from a European Union controller to non-European Economic Area processors, all relevant sections should have been fully completed, and no sections should be missing, as it must follow the SEC exactly. It is important to ensure a rigorous description of the categories of personal data and purposes for the transfer and to match this against the processing that is evidenced in the data and processing inventory. The data subject’s third-party beneficiary rights are very important and should be noted. Any commercial clauses that have been added should be reviewed as well. Deter should review the Philippine and Indian Data Protection Laws to understand if there are similar protections under those laws. If there are any requirements for data localization, if there are any restrictions on freely moving certain types of data outside the country, and the powers of the local DPAs to assist if security, incident, or other issues arise with these activities.

DJ and Helen have now performed an initial high-level assessment of EEI’s compliance with the GDPR, including information security and data breach assessments and data transfer mechanisms, and so can make their reports to establish a baseline level of GDPR compliance. They should have discussed remediations as they went along, training the various owners and specialists how to be compliant and preparing them for future audits, where they will need to see not only policies, procedures, and contractual provisions, but also documented evidence of the effectiveness of the various measures to demonstrate the organization’s compliance with GDPR and all relevant staff, statutes, and policies. Deter and Helen must stay involved with all aspects of data protection, including new risks, while continuing to monitor for compliance with the GDPR and handling inquiries from data subjects regarding their data privacy, rights, and freedoms.

10. Chrome Browser – GDPR case study

Hi, guys. In this lesson, we will look at the Chrome browser and the changes made by Google as a result of the GDPR. Case Study With the growing pace of cloud service development and the Internet of Things (IoT), ordinary users are increasingly at odds with their understanding of how technology works, and vendors must be aware of this.

The lines between what is local and what is remote are getting really softer. The latest release of a major web browser, which is Chrome 69, drops another stone here, let’s say, and when you log into a Google service like Gmail or So, Google Chrome is effectively logging you into the browser, and it looks like that picture on the right from the slide. This change apparently solves the hypothetical issue of user confusion. Am I logged into the system or into the browser, and at the same time, am I creating others? Logging in is made consistent between the web and the browser. While some people are finding it problematic and confusing, let’s trust Google. Chrome has thought it through. Well, we can trust Google, as Chrome is the most secure browser out there, and maybe the future will allow for better tailoring of ads in the future.

There are good reasons for using the browser, and let’s assume the feature is needed. The problem lies elsewhere. For some reason, the information about this change is not reflected in the official release notes of Chrome 69, nor in the note about loading the user interface upgrade. The change simply appeared to come out of the blue. Things work very differently than, let’s say, in Chrome 68. According to Google Chrome’s Privacy Policy, signed in Chrome mode works differently than the basic, non-signed mode. Accordingly, your personal browsing data is saved on Google servers and synced with your account. This type of information can include browsing history, bookmarks, passwords, and autofill information. Other browser settings, like extensions installed in accordance with the Privacy Policy, could make this the case. However, data synchronisation appears not to happen by default. In practice, it seems this behaviour is not accounted for by the privacy policy, which means either the policy is obsolete or the mechanics may be subject to change in the future. There is indeed a justified concern that currently browser signings happen without the user’s knowledge, consent, or advance awareness or consent.

This may well be seen as a regression in terms of privacy and user interface. While I do not intend to argue that this is proof of privacy, as a normal citizen, you could imagine, for example, displaying information to the user upon the first launch of an updated browser, not to mention the principle of least surprise for such a dramatic change in mechanics. This has not happened with Chrome 69, which means that the change of the operating method for a key technology has been made abruptly, leading to millions of users’ mistaken synchronization. Furthermore, during testing, we were successful at deliberately negative synchronising my settings to the cloud simply by clicking on sync where I could click and do, but the information page encouraged me to first look into the settings. However, by clicking on settings, I was unable to click undo. The user interface happily assumed that yes, in fact, I wanted to first upload my data, and suddenly, instead of last time syncing in, I don’t know, 2017, 2018 I saw the following last time:

Today, it looks like setting a special flag for Chrome to disable might solve the problem for concerned users. The flag is quite oddly documented, and this is a fascinating example for a GDPR case study. However, I will not go into details about whether GDPR articles concerning consent were affected. In this case, consent is overrated, and instead I focused on two less known but specialised items. First, data privacy impact assessment Article 35 of the GDPR requires making an assessment taking into account the fundamental rights and freedoms of an individual. Now, I’m not sure Chrome has a DPI at all. Projects made prior to GDPR do not need to have one. However, the data protection impact assessment must be updated when significant changes in the system are introduced. In this case, pregPR projects effectively need to have one made. While I do not want to debate whether Chrome 67 or 68 introduced such changes, I would say version 69 may have crossed the threshold. If a data protection authority decides there is a need to see the DPI, it can formally request the vendor to deliver the document. GDPR says that an infringement in relation to DPI requirements is in the award region of €10 million, or 2% of total worldwide annual turnover, whichever is higher.

And second, data protection by design This is another interesting superpower introduced by GDPR, and the software needs to be designed with consideration of data protection. Article 25 of the GDPR is rarely seriously and meaningfully discussed in practice, not least because almost no one knows what “data protection by design” even means. However, the infringement is similar to the DPI. The case of the Chrome login discussed might be one of the best examples for a case study. It has a high impact, lots of user concerns, expectations, and defaults, and is about changing how things work. The clarity of the user interface, what the user expects, and what actually happens are the key elements. I’m afraid there may be an issue here yet. Perhaps Google has designed the new login feature well, considering the user’s privacy under the hood but not in the user interface. However, we are unable to know about this. Of course, it is not explained anywhere, but the best place where one can find it could be the data protection impact assessment. It would therefore be very interesting if Chrome made its DPI public. However, this would not only allow for clarification of the aforementioned points; it would also be an intriguing and trust-building move. I often advise organisations to make their privacy impact assessments public. I believe doing so might be too good for everyone in this particular case.

11. Top concerns for Hotels Online Businesses

Hi guys. In this lesson, we’ll discuss the top concerns for hotels’ online businesses. And this lesson is also applicable to businesses that involve websites.

So, if we discuss the hotel business that they have on their website and that they perform their online bookings on that specific website, then these lessons, advices, and questions that we will discuss right now will be really suitable and will apply perfectly to any other business that will run in the online environment and will have a website to run the business in. As a result, GDPR applies to all data about individuals in the European Union, including four hotels, both guests and employees. Hotels should document what personal data they hold, where it came from, and with whom it is shared. Hotels may need to organise an information audit. Personal data is any data about an identifiable person. A person can be identified by their name,  phone number, email address, reservation number, IP address, or any other information that allows them to be uniquely identified. The GDPR provides additional protection for sensitive data, which includes any of the following: union membership, which may be revealed by event attendees’ biometrics for the purpose of uniquely identifying someone, such as a fingerprint stored for opening doors. Hull status, which might be disclosed in guest requests; sexlife or sexual orientation, which may also be disclosed in some guest requests; and the following, which are less likely to show up in hotel systems but should still be understood to be sensitive in case they do show up.

genetic data, racial or ethnic origin, political opinions, and religious or philosophical beliefs. All of the above are types of sensitive data that can only be handled with explicit consent. If this kind of data is collected incidentally, it should be removed immediately to avoid taking on new obligations for the protection of that data. All rules that hotels must follow also apply to the software they use. If a hotel uses a product to process its data, that product must adhere to all the same obligations that the hotelier has.

Every single vendor who receives personal data from a hotel must share a data processing agreement with the hotelier to confirm that the vendor is compliant with the rules of GDPR. The DPA must dictate the purposes for which the processor is processing the data. And by “DPA,” I mean the data processing agreement rather than the authority. If a hotel is using software given to it by its brand or flag, it may not have complete control over how the gathered information will be used. In that case, as joint controllers of the data, the hotel and its brand would need to draw up a contract that explicitly states their relationship with regards to managing data. Both parties would need to communicate their relationship to both guests and employees. Can hotels in the European Union use software from vendors or software hosted on servers outside the EU? Yes, but there are limits to how data can be transferred outside the European Union, and we discussed this in the first section. Most major cloud service providers and many other companies have systems in place to address these rules. To confirm that the cloud service is compliant with GDPR, hoteliers need to make sure they have a data processing agreement in place.

There is a lawful basis for transferring the data, and the transfer is mentioned in the hotel’s privacy policy, along with the purpose of the transfer is explained. What do hotels need to do about their vendors? For each vendor that processes guests’ personal information, a hotel needs to do the following: Determine the type of data the vendor processes, then determine the purpose for which the processing is happening. Obtain a processing agreement if the vendor is outside the European Union, sign the standard contractual clauses, usually part of the data processing agreement, or confirm that the vendor is a member of the privacy shield. For example, mention the vendor in the hotel’s privacy policy along with the purpose of the vendor and how the data will be used, and in the end, confirm that the vendor can handle data rights requests with an SLA under one month, for example, 25 days. How should a hotel communicate privacy notices to guests? You should review your current privacy notices and put a plan in place for making any necessary changes. You should review how you seek, record, and manage consent and whether you need to make any changes. Refresh existing consents now.

If they don’t meet the GDPR standard, hoteliers may need to speak with customers at check-in. If explicit consent is required for any forms of data collection that require it, such as consent to marketing communications, All loyalty programmes need to be examined for similar requirements. If data is used in a way that requires consent, do hoteliers or vendors need to encrypt their databases? Well, it depends. The GDPR recommends that companies take steps to protect their personal data, but it does not specify what those steps have to be. Instead, companies are asked to identify the risks to personal data and do what is appropriate for those risks. Encryption is one of many options available to protect data, but it is not specifically required by the GDPR. Article 32 of the GDPR gives the following options, none of which are strict requirements but which should be considered for the benefits to your guest’s data privacy: cell dynamization, obscuring identities, and encryption of personal data. Second is the ability to ensure the ongoing confidentiality, integrity, availability, and resilience of processing systems and services. Third is the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident, and last is a process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing. How can hoteliers make sure they are able to honour requests for data portability, correction, or erasure, aka the right to be forgotten?

Customers, employees, or anyone whose personal data is stored at a hotel may request that their data be erased. They can also ask for a copy of all of their data—this is the right to data portability—or for their data to be corrected. There are cases in which this does not need to be honored, for example, if there is an ongoing contractual or legal requirement to retain the data. But in most cases, the request will need to be honored. Section 59 of the GDPR requires this request be answered within one month. This period can be extended under exceptional circumstances by requesting another month. In order to be able to handle this request in time, hotels need to plan in advance how requests can be honored. Each location where data is stored should be mapped out with a plan for how to address the right request for data at that location. Each vendor also needs to be vetted to confirm they have a similar plan in place. Vendors should have an SLA that is less than a month in order to give time for communication between you and the vendor on each end of the process. When a request for data portability occurs, the law requires the data to be given to the customer in a standardised format for transfer to other companies. Since at the moment there is no industry standard for this kind of data to be transferred from a hotel, you must use a generic but easily transferable format, such as text files with headers and comma-separated values. How should hotels handle children’s data? Within the European Union, a child is defined as someone younger than a country-defined age between 13 and 16.

For most cases, hotels will not need to rely on children’s or parents’ consent to process guest information since the primary basis for data processing is handling reservations. However, in cases where consent is the basis for data processing, for example, for marketing purposes, children’s data needs to be handled with extra care. You should start thinking now about whether you need to put systems in place to verify individual identities and obtain parental or guardian consent for any data processing activity. Children’s data can only be handled with explicit consent. When consent is required, best practise is to avoid collecting and storing data about children unless it is legally required or absolutely essential for handling a reservation. Do hotels need to hire a data privacy officer or protection officer? You should designate someone to take responsibility for data protection compliance and assess where this role will sit within your organization’s structure and governance arrangements. And if you are not formally required to have a DPO, you should consider whether you are required to formally designate a DPO, and this designation depends on the volume and sensitivity of the information. At the chain and large group level, a DPO is almost certainly required, but for individual hotels, the law is not yet clear, and you should seek guidance from your local council as to whether it is required.