Is satelite data personal data? It is in the news that artificial intelligence (AI) has been applied to aerial photography to identify homeowners who have made unauthorised additions of swimming pools to their properties in France. This has allowed them to be taxed. The UK ICO defines personal data as: Personal data only includes information relating to natural persons who: can be identified or who are identifiable, directly from the information in question; or who can be indirectly identified from that information in combination with other information. It would seem that this technique has demonstrated that individuals are identifiable from this sort of aerial photography. Does this make the various forms of satellite imaging available online subject to the GDPR?
Personal data is any information relating to an identifiable person, even if that person is only identifiable with the help of additional data and/or third parties. Making inferences about a particular person, for example whether that person might have performed unauthorized construction, sounds very much like processing of personal data to me. In this scenario, the information is used to verify the tax assessment for a particular person, so the information clearly relates to a data subject. The owner for a piece of land is certainly identifiable with the help of the land registry, if one exists in the country. Similar registries might also exist with tax authorities or a postal service. Here, it is the tax authority itself doing the processing, so they probably already have tax records about the owners at the address. But just because it's processing of personal data doesn't mean that it is illegal. Satellite data and aerial photography providers can probably rely on a legitimate interest to collect, sell, or otherwise publish their data. Homeowners can reasonably expect that their property will be included in low-res aerial photography. It might not be necessary to notify the data subjects if an exception in Art 14(5) applies. A public authority using aerial photography to find building code violations or to levy correct taxes may be able to base this processing activity on authorization via some law. If the public authority would have the right to inspect the buildings, then it might be possible to argue that the public authority can use aerial photography to decide which inspections/audits to prioritize. Of course, decisions producing significant legal effects must not be based on “AI” alone, due to the Art 22 GDPR right to not be subject to unchecked automated decision making (unless specifically authorized by a suitable law).
Question 1. Are technical identifiers personal data? Yes. If they identify a person. For example an IP Address is considered personal data, because a person or household can be identified by an IP. Yes, I know that technically there are a lot of exceptions. But in general, if you have an IP, you can identify the subscriber given the right databases. So if your identifier, lets say a generated GUID, identifies a customer or something the customer can be linked to, it is personal data. Question 2. Can technical identifiers be stored in measurement devices? Just because something is personal data, does not mean you are forbidden from using it. As long as you need it to do your job, you can store it. The internet would not work, if everybody was forbidden from storing any IP address. So to summarize it: yes, it is personal data since it identifies a subscriber. However, it is needed for the job your subscriber asked you to do. So for as long as the job takes, it is legal to store it. Once your job is done, you would be required to delete it. But consent trumps everything. If your subscriber consents to you keeping all data of such incidents to improve your network and handle future incidents better, then it's legal. Just let them sign it with your other legal paperwork. Done. No problem. You could just periodically delete all records that have no consent for long term storage beyond the current incident. Lets say every 24h or 48h. You should get the details on the wording of the paperwork and the period that it is legal to keep the data as &quot;current incedent related&quot; from your data protection officer or legal department.
Personal data is any information relating to an identifiable person, whether that information is public or not. The student website is definitely processing personal data of faculty. Any website is also necessarily processing personal data of visitors due to technical reasons, even though hosting has been outsourced to a third party. There's always a server, you just might not be managing it yourself. Thus, GDPR applies. Just because it processes personal data doesn't mean that the student website would be illegal. It just means the students are responsible for GDPR compliance of that website. Since the website is controlled by students and not by the university, the university DPO has no say here and the university can't demand the website to be hosted in a particular manner. Nevertheless, the DPO's suggestions might be quite sensible. Typical GDPR compliance steps include: having a clear purpose for which the personal data is being processed having a legal basis for that processing (here, probably a “legitimate interest” which will require a balancing test), see Art 6 providing transparent information to the data subjects providing a privacy notice to website visitors, see Art 13 notifying faculty per the requirements in Art 14 GDPR preparing to fulfill data subject rights such as access, rectification, and erasure when using a legitimate interest, there's also a right to “object” (opt-out) implementing appropriate technical and organizational measures to ensure security and compliance of your processing activities, see Art 24+32 making sure that third parties to which you outsource processing activities are contractually bound as “data processors” to only use the data as instructed by you, see Art 28 if you transfer data to non-European countries, having appropriate safeguards in place Does this sound complicated? It can be complicated. The point is that the internet is no longer the lawless Wild West. Just because you can easily publish a site with personal data, doesn't mean that you should. The GDPR is about requiring data controllers to find an appropriate balance with the rights and interests of the affected persons. Of course there are countries with less regulation, but there are also countries with fewer taxes and that isn't necessarily good for society. The easiest way to avoid these responsibilities will be to stop publishing the site as students – and instead taking up the university DPO's offer to have the university run the site. Which is less fun, of course, but the adult thing to do. If this motivates you further: note that the data controller (the people responsible for the site) must publish their contact information in the privacy notice, typically name + email + street address. The GDPR contains no exceptions that would help here. There is an exception for purely personal or household activities. But if the website would be available to the general public, it would be difficult to argue that this is purely personal. There's also case law such as the Lindqvist case requiring a narrow interpretation of that exception. In Art 9, the GDPR does mention that some restrictions are lifted if the data subject made the information public themselves. But that isn't relevant here, because Art 9 is only about extra-protected sensitive data, e.g. health information, union membership, or sexual orientation.
The company would likely require explicit consent for using facial recognition algorithms. The GPDR considers certain activities to be processing of “special categories” of personal data (Art 9 GDPR). One of these categories is “biometric data for the purpose of uniquely identifying a natural person”. Such processing activities are prohibited unless an exception applies. Facial recognition uses biometrics to identify a person, so it's prohibited by default. There are, of course, many exceptions. Art 9(2) GDPR contains a list of general exceptions which allow special categories data to be processed. In UK law, specific conditions for these situations are given in Schedule 1 of the Data Protection Act 2018. Whether any exception could apply depends a lot on the purpose for applying facial recognition, e.g. if it is necessary in a medical context or if it is truly necessary in an employment context. The most interesting exception in the context of video surveillance would be Art 9(2)(f): processing is necessary for the establishment, exercise or defence of legal claims However, necessity is a fairly high bar to clear. This exception cannot be used to pre-emptively scan a database of images in the hopes that it might find something. In contrast, it might be permissible to use facial recognition to confirm a suspicion. But here, there's a big caveat in that most facial recognition software cannot provide reliable results for less than ideal pictures (i.e. anything other than a well-lit frontal portrait of the face), and that such software is known to produce biased results. Thus, the use of facial recognition by private companies is still questionable. If none of the exemptions in the GDPR/DPA clearly applies, then only the Art 9(2)(a) exception is left over: the data subject has given explicit consent to the processing of those personal data for one or more specified purposes A notable example of a company illegally performing facial recognition is Clearview AI. Multiple data protection authorities have announced fines, including the UK's ICO: in late 2021, the ICO announced the intent to issue a GBP 17M fine for, among other things, failing to meet the higher data protection standards required for biometric data. This answer applies to private-sector data controllers, i.e. ordinary companies. Different rules can apply in the public sector, in particular for law enforcement agencies.
See Art. 17(2) GDPR: Where the controller has made the personal data public and is obliged pursuant to paragraph 1 to erase the personal data, the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data. So the controller must tell all other controllers (like google) to delete the data. The privacy policy must include the fact that data is made public.
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.
Are my assumptions correct? Yes, this is precisely the sort of thing that would fall under the purview of "the purposes of the legitimate interests pursued by the controller or by a third party", as it fundamentally enables you to deliver the service to the data subject, and its also difficult to argue that "such interests are overridden by the interests or fundamental rights and freedoms of the data subject" given its a fundamental part of delivering the service before any consent can be given. Its not the intention of the GDPR to solely require a direct relationship between the data controller and data subject, its intention is to allow the data subject to control more of the relationship than they did previously - in some cases, that control remains with the data controller, which is why not all of the lawful basis for processing rest on consent. So long as you ensure that the CDN provider has a relevant privacy policy and is identified as a data processor in your privacy and data policy then you are good to go. In my mind, this is similar to the issue of how the data subjects packets get to you from their computer - we aren't including all of the network providers who carry the packets between the data subject and the processor (despite the fact that those providers will have access to much of the same information as the CDN, such as IP address, source, destination etc), even though in many cases we don't know that information (for example which route it will take over the internet). The only difference here is that as the data controller, you know about the CDN and can include it in your policies, so you should.
No. While UK data controllers must register with the ICO, they only have to provide general contact details. The ICO does not provide a public registry of data controllers. Outside of the UK, there is no requirement to register with the Supervisory Authority unless a DPO is appointed. Per Art 13 GDPR, every privacy notice must disclose the contact details of the controller, and of their DPO (if applicable). The GDPR does not require controllers to have a specific email address for data subject requests. Controllers have to fulfill the request regardless of the channel through with the request is made, so that normal channels for support or contact should be appropriate. The ICO writes in its guidance to controllers on the right to access requests: Are there any formal requirements? No. The UK GDPR does not set out formal requirements for a valid request. Therefore, an individual can make a SAR verbally or in writing, including by social media. They can make it to any part of your organisation and they do not have to direct it to a specific person or contact point. Of course, if a controller does not make contact details available or otherwise refuses to accept a valid data subject request, you can ask the ICO for assistance.