Privacy Policy if App&#39;s internal data, probably containing private data in terms of GDPR, is automatically backed up in Google Cloud If I develop an Android App, the per-default setting is that the App's internal data, probably containing private data in terms of GDPR, is automatically backed up in Google Cloud (unless the phone has blocked this feature). Should I mention this in my privacy policy with a link to Google's policy? Or is this done already somewhere in the Google Play Store when I submit the App?
You are responsible for any processing of data that happens under your control – but are you the data controller in this scenario? Since you have no meaningful influence over whether or not this backup happens on the operating system level, there could be a strong argument that you aren't a data controller for these backups. And if you aren't a data controller for that processing activity, you aren't responsible for compliance. However, if you were to integrate directly with relevant Google APIs in order to facilitate backups that could make you a controller. Then, Google would either have to be your data processor (won't be the case here), or you would need a legal basis for sharing the user's data with Google. For example, you could ask for the user's consent before activating such features.
For land ownership records and other similar scenarios such as business directors, the requirement for these to be public will be in legislation rather than a contract - this provides the legal basis, see GDPR Article 6(1c). Additionally when government departments are doing it they also have 6(1e) as lawful basis: "1. Processing shall be lawful only if and to the extent that at least one of the following applies: ... (c) processing is necessary for compliance with a legal obligation to which the controller is subject; ... (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;" -- GDPR, Article 6(1c,e). I'm not familiar enough with the specific legislation that will apply here but pretty sure this will be the case, and having said this you may well find public registries also become less public going forward. The reason ICANN has come under fire, is partly because under GDPR privacy is a protected fundamental right and therefore to comply personal data should be kept private by default and privacy never something you would be required to pay extra for. Any contract ICANN have in place with their registrars will not override legislation, it is in fact the other way around. "2. The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons." -- GDPR, Article 25(2). This doesn't stop ICANN from maintaining a register of domain name owners (registrants), but it does mean they can't just publish all records upon request to anyone anymore - whether people will be granted access to personal data will now depend on if they have a lawful basis for this, and in these cases their processing of the personal data will be limited to those purposes. Being nosey doesn't count! "When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of the contract." -- GDPR, Article 7 (4) - Conditions for consent. What this means essentially, is that if the consent is conditional for the contract it will not be treated as freely given, and therefore not valid - it will no longer be acceptable to contractually bind the provision of a product or service with consent to publish personal data or any other form of processing such as marketing mailing lists. Looking now at the specific points you have raised: "GDPR article 6 allows for processing of personal data on a contractual basis (section 1b)" Whilst this is true, this is only part of it - it doesn't allow for unlimited processing for any purpose and sharing it with any people, if you look at Article 5(b) it states that the information is collected for specific explicit legitimate purposes. Each purpose requires its own legal basis and needs to be compatible with the principles of GDPR. Without consent, ICANN currently does not have a legal basis to make the WHOIS records public for EU citizens and should have adopted some technical controls to require them to opt-in if they wish to be included in the public register. They're coming under fire for non-compliance having been given 2 years to prepare and change their systems/processes. "processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;" Again whilst this is true, not all processing is necessary for the performance of a contract. In the same way people must give consent to receive marketing communications, they must freely give consent for their information to be shared/published (separate to the contract for provision of service) in the absence of other lawful basis for this processing. "Also section 1c, processing is necessary for compliance with a legal obligation to which the controller is subject;" There is no legislation which requires them to publish the personal data of domain name registrants. In this paragraph 'legal obligations' refers to those required by legislation (i.e. statutory obligations), not contracts (or non-statutory obligations) which are covered under Article 6(1b). "And finally section 1e, processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;" ICANN has no official government-assigned authority, and publishing the personal data globally is not in the interests of the data subject's or others' welfare or well-being - this is what is meant by 'public interest'. As far as I can see what ICANN are actually doing to comply seems to be accepted by the European Data Protection Board, they are only 'under fire' as you say because they are late in doing so. The deadline was 25th May 2018 and they had 2 years to prepare like all other organisations.
The GDPR is wide in scope, and flexible in application. Therefore it is not possible to give an absolute yes/no as to whether masking text with asterisks is or is not lawful. We can gain a deeper insight by looking at the GDPR itself. Firstly, the definition of processing (Art. 4 lit. 2): any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction As mentioned by amon, the principles relating to processing of personal data (Art. 5) are highly relevant, insofar as the activity constitutes processing. In particular, purpose limitation: [Personal data shall be] collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes ...and data minimisation: [Personal data shall be] adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed I would argue that making available the personal data on an invoice is processing. There are two separate operations: Making the data available to authenticated users; and Making the data available to non-authenticated users The purpose of making it available to authenticated users may be different to the purpose of making it available to non-authenticated users. Again acknowledging amon, the necessity of making the data available to non-authenticated users must be examined, as too must the means by which a non-authenticated user gains access to an invoice: are they using a URL that contains a token of some kind? Is this unique in some way? It could be that the presentation of a token itself constitutes authentication and thus authorisation to view the entire invoice, in which case further redaction may not be necessary if there is a clear necessity to disclose the entire contents to such a user. Whether the token expires or is limited to a certain referrer would be part of complying with the integrity and confidentiality principle and Art. 32 (Security of processing) by implementation of technical measures. When considering pseudonymisation and anonymisation, you will note that the redaction of name and address data from a certain view of the invoice, while nevertheless displaying the invoice number, constitutes pseudonymisation, since it would be possible with unfettered access to the remaining data, to determine the name and address from the invoice number, but not for the non-authenticated user whose view is redacted. In such a case, I fail to see how or why the replacement of a string with the same number of asterisks, or starting with the real character is secure or even practical, when the entire field could simply be replaced with a fixed-width string of asterisks or other filler, thus providing the user with no right or necessity to view the personal data with no further insight into what the personal data may or may not be.
Yes, encrypted personal data potentially still is personal data, so some prior thought is necessary. But are you a controller who is processing this personal data? Possibly not. This hinges on what kind of metadata you process, and whether the encryption happens under your authority, e.g. by a software that you provision. If all you can ever get is the encrypted data but not the plaintext, then you can probably treat this similar to pseudonymous or anonymous data. A related example is a postal service. Letters might contain sensitive personal data. But the postal service is not processing the letter contents, and cannot be treated as a controller of this data. (The postal service is prevented by law from processing this data, you are prevented by the encryption). However, a postal service processes personal data like addresses on the envelope. You might want to create a Records of Processing document, which will help you understand what (potentially) personal data you will process. If you are processing patient data on behalf of a healthcare provider, you might want to look into whether you are a controller or a processor. Processor status is not automatic but requires a suitable contract with the controller. As a processor you still have to take appropriate security measures, but you are not responsible for determining the purposes of processing or for responding to data subject requests.
No. As long as you don't see and have no means to access this data, but it is under the control of the user at all times, you are neither the controller or the processor of this personal data, and the GDPR does not apply to you.
There is nothing in the GDPR requiring you to collect individual personally identifiable information. If the website has no need, and the website owner no desire, to collect such information, there is no requirement to do so. The GDPR requires that if such information is collected, that there is a lawful basis, and that it be handled appropriately and stored securely, and deleted when there is no longer a need to retain it, or on a proper request. If no such information is collected in the first place, all the rules about how to handle it do not apply. It is possible that some law of an individual country in the EU might mandate collection of some particular information, but I have not heard of any such requirement.
Any processing of personal data needs a legal basis, for example necessity for some contract or legitimate interest. If no other legal basis allows the processing, you need to acquire consent. Consent must be freely given. If something is gated behind consent without that consent being really necessary, this might coerce users and they would not be able to consent freely. The GDPR does not have a hard ban on this, but it explicitly calls out that this case must be considered when determining whether consent is valid. So what your company is trying to do is in a dark grey area. Not necessarily wrong, but likely so. Consent could be made free if users have an actual choice. For example, some online newspaper sites had success with a “pay or consent” wall. (Success in the sense that some data protection authorities allowed this). In your case, this could mean that users either consent to extra data collection, or that they buy some reasonably priced premium mode. But none of this is for you to decide. You can voice your doubts that the software would be compliant. You could also ask if the Data Protection Impact Assessment document for this proposed processing is available (creating such an assessment is likely mandatory in this case). But in the end, it is the company's obligation to be compliant, and this responsibility is largely shouldered by the company's data protection officer (to whom you can turn with further questions).
It is absolutely not the case that Providers are not allowed to keep PII without consent. Article 6 of the GDPR identifies six possible lawful bases for processing personal information. These are: (a) the data subject has given consent ... (b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; (c) processing is necessary for compliance with a legal obligation to which the controller is subject; (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Point (f) of the first subparagraph shall not apply to processing carried out by public authorities in the performance of their tasks. If a person requests services from an online service provider, basis (b) will apply, at least to some information. If there is evidence of criminal activity, basis (c) may well apply, as it also will for much routine record keeping. Any in many such cases, basis (e) or (f) will also apply. In short, article 6 does not create a &quot;haven for online criminals/hackers&quot;. In a comment on another answer the OP writes: The offender has the right to not be identifiable and he can't be denied this right That is simply not correct. Nothing in the GDPR says anything of the sort. It is true that consent may not be forced, but if a user requests a service that service may require the user to identify him- or herself. For example, one cannot order physical goods without giving a name and a shipping address. And the provider may retain PI and even PII when it has a &quot;legitimate interest&quot; in doing so, although if challenged it must justify that legitimate interest.