Should I have a privacy policy on my personal website? Assuming I have a personal website that I maintain, without offering users the possibility to log in, nor giving them the option to post any content of their own, should I design a privacy policy? The website would mainly be used as an online resume of sorts, mainly for personal purposes and intended only for companies that I'm applying to to view. In such circumstances, the only "personal" information that I use from them are IP addreses that the server uses to keep an open connection with their computers (and even those, the server discards automatically once the connection closes, except for special cases when technical failures records these addresses in error logs). Is it necessary for me to make such a policy just for mentioning this?
As you are not collecting or using an private information, I don't see that such a policy is required, although you could post one if you choose to.
Every website needs a terms of service and a privacy policy. A simple Google search will find you plenty of TOS/PP generators. Then, you just a need to place an easy-to-find link to your TOS/PP on all the pages of your website. No matter what kind of site you run, it is also a very good idea to register as an official copyright infringement agent. It costs about $140, but it could save you a LOT of hassle in the future. Other than that, it's hard to say much more since you haven't revealed much about your website. You should be more specific if you want more information.
You quoted the definition of personal data from Art 4(1) GDPR. This definition of identifiability is further explained in Recital 26: […] To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. […] If the user ID is unique, then the hashed user ID will be unique as well. Thus, the hashed ID will enable “singling out”, and would still count as identifying in the sense of the GDPR. You also claim that there's no way to reverse the hash. This is not quite correct. Assuming that the hash function itself is secure, then the only way to crack the hash is to brute-force the input. The difficulty of brute-forcing depends only on the entropy of the input data, not on the size of the output hash. It is thus comparatively easy to crack hashes of short low-entropy strings like sequential integer user IDs, IPv4 addresses, or weak passwords. In contrast, it would be difficult to crack long random user IDs, such as UUID version 4 identifiers created from a cryptographically secure RNG (CSPRNG). Even if the hashes can't be cracked, they are not anonymous – you can link them to the original user ID, after all. The GDPR only considers data anonymized if there are no “reasonably likely” means to re-identify the data subject. If this de-identification is reversible, it's called pseudonymization instead. If storage allows, a better technique to generate pseudonymous IDs is to create a table that maps the true ID to a CSPRNG-random ID. Unlike a hash, the random ID cannot leak extra information about the original ID. This pseudonymization technique could perhaps also be turned into irreversible anonymization by deleting the ID mapping, assuming that no “singling out” can happen. Pseudonymization is a very good security measure. It is explicitly mandated whenever appropriate in Art 32 GDPR. So you should probably use it. It's just that GDPR continues to fully apply to processing of the pseudonymized data. Since the pseudonymized data is the data subject's personal data, you may be required to delete it when receiving an Art 17 request for erasure. You may also be required to forward the request to others with whom you shared the data. However, the right to erasure has many conditions and exceptions. If you actually need to keep the data for a particular purpose, chances are good that you can keep it.
Generating a list of all possible numbers doesn't sound like it would constitute personal data any more than listing all dates for the last hundred years as a "possible date of birth" would. However, the moment anyone linked even one of the numbers with any other personal data - for example a name - they would be bound by GDPR and would need to show a Lawful Basis for processing the data. [If you linked your own name you could presumably argue Consent, but anyone else's would need to have an associated Lawful Basis.]
If you are purely a designer (and not contracted for the daily operation of the site), the answer is "no". GDPR Article 4 defines the "roles" responsible for complying with GDPR, and there are two: Controller and Processor. The Controller is the one who calls the shots. In particular: Decides what personal data to process. This is usually the owner of the web site. The Processor is the one that actually does the processing. This is usually some company providing some sort of data processing service (e.g. SaaS, PaaS, etc.). The relationship between the Processor and the Controller must be contractual. The contract is called a DPA (Data Protection Agreement or Data Processing Addendum). As a designer, you don't fit into any of these roles. If your contract with the client is silent on liability for GDPR compliance, then you have no liability. This goes for projects completed both before and after the May 25 deadline. Of course, if there are GDPR clauses in your contract, then you must fulfil them just as have to fulfil any other contractual obligation. But unlike the controller and the processor, there are no automatic legal liability for a designer or programmer.
Yes, phone numbers would generally qualify as Personal Data under GDPR. It would be so irrespective of whether you have also stored other information along with the phone numbers or not, since also information that indirectly could identify a natural person is Personal Data (provided that there are, somewhere else, public or not public, a register of who holds the specific phone number). See Article 4(1) GDPR. (One could possibly argue that the phone numbers would not be considered personal data if there is no actual register of who owns a specific phone number with any other party. Or if such register is in practice not available for anyone. It might be so in some cases, although I would not rely on it.) Whether you have the right to process the phone numbers must be assessed based on its lawfulness (see Article 6 GDPR). It could be based on consent, performance of contract, legitimate interest or any other ground set out therein.
Your confusion might be caused by the fact that even with a contract, only the data necessary for that contract is covered under the GDPR. So yes, while there might be an &quot;execution of contract&quot; under the T&amp;C, this would only cover necessary data. That means you can't ask arbitrary signup data under the guise of a contract. If you need to deliver a physical product, you can store a physical address. If it's an online service, you can store an email address or similar handle. But you can't mix the two. A physical address is unnecessary for the execution of a contract that's not physical in nature. Now, you mention &quot;consent&quot;. Under GDPR, this is a distinct justification besides &quot;execution of contract&quot;. You might have consent to store a physical address in addition to an online address, e.g. if you offer a customer to physically mail a password request form. This consent is additional to the contract. Also note that the bit above only covers the lawful reasons for the processing of personal data (article 6). You also have to obey the other GDPR rules, e.g. fully inform the user, make sure that consent is freely given, etc.
As Rick mentioned in comments this would most definitely be considered processing of personally identifiable information (PII) under the UK GDPR. You mention &quot;advertising&quot; and &quot;marketing purposes&quot; so it's pretty clearly not for your own personal household/family use and that means you would have to comply with the GDPR. That means you're going to need what's called a &quot;Lawful Basis&quot; for processing this data. There's six different ones: (a) Consent: the individual has given clear consent for you to process their personal data for a specific purpose. (b) Contract: the processing is necessary for a contract you have with the individual, or because they have asked you to take specific steps before entering into a contract. (c) Legal obligation: the processing is necessary for you to comply with the law (not including contractual obligations). (d) Vital interests: the processing is necessary to protect someone’s life. (e) Public task: the processing is necessary for you to perform a task in the public interest or for your official functions, and the task or function has a clear basis in law. (f) Legitimate interests: the processing is necessary for your legitimate interests or the legitimate interests of a third party, unless there is a good reason to protect the individual’s personal data which overrides those legitimate interests. (This cannot apply if you are a public authority processing data to perform your official tasks.) You haven't provided enough information for to hazard a guess at what your basis would be but the ICO has an on-line tool which would give you a starting point. It's a very good idea to make sure you have all your i's dotted and all your t's crossed before you start processing any PII - and that includes documenting the process. Otherwise, what consequences may I face if I do so? In some ways the consequences of non-compliance are &quot;what have you done?&quot; coupled with &quot;how much have you got?&quot;, the maximum penalty is £17.5m or 4% of your annual turnover (whichever is greater) and fines issued under the UK GDPR to date have ranged from mere pocket change to almost enough to buy a tank of petrol. Widen it to the EU and small property owners association got a €500 slap on the wrist and Amazon managed to net themselves a €746m fine.