Can a company actually become GDPR compliant? Is there such a thing? (This question could be expanded to other auditing procedures too) How do huge multinational companies that want to become GDPR compliant start off this? I mean, I guess one has to read the regulation, correct? But what if you misunderstood a point? Do companies usually call in an external party like an auditing company or consulting firm specialized in GDPR? Say you read and understood all the necessary things to be GDPR compliant. You do the privacy impact assessment then implement features within your solution/product to achieve this (Eg: purge user data on demand, opt-in full cookies by default, don't have any &quot;sign me up&quot; box checked by default, etc). Who then decides whether this set of features that should have been implemented is &quot;complete&quot; or not? Do auditing firms or whoever says &quot;You are compliant&quot; offer some sort of insurance in case there's a lawsuit and the company has to pay for failing GDPR? Or they just tell the company &quot;The probability of paying in case of a GDPR lawsuit has been minimized&quot;?
The GDPR consists largely of principles instead of concrete rules. It's possible to reasonably believe that you are fully compliant, but then have a court rule against you. Thus, a company might mitigate risks by getting experienced compliance consultants, and by not toeing the line of what is and isn't allowed. But at some point, working to reduce the remaining risk is not worth the effort. This will depend very much on the business. E.g. an adtech business will likely want to tolerate more risk than a bank. As the interpretation of the GDPR evolves, compliance efforts must adapt. For example, the Schrems II judgement that invalidated the EU–US Privacy Shield shifted our understanding on the legality of international transfers. This judgement was not necessarily surprising for anyone who paid attention, so to some degree it was possible to prepare in advance. But that judgement was the kind of shift in jurisprudence where you can't fix your compliance by filling out one extra form, but rather have to rethink all international transfers of personal data – a blow to US SaaS providers and European SMEs that depend on them. Some parts of the GDPR are geared to assist with a compliance process. For example, larger data controllers must create a Records of Processing Activities (ROPA) register. This lists all processing activities and their legal basis, which helps spotting potential compliance gaps. Risky processing activities require an Impact Assessment (DPIA) where the controller has to weigh different factors against each other and determine appropriate safeguards. While the GDPR doesn't necessarily say whether something is allowed or not, it frequently provides factors that must be considered in an analysis. In addition to the GDPR itself, there's a lot of guidance available. Data protection authorities publish guidelines and can also be consulted directly. In fact, that's sometimes explicitly required. In the EDPB, the different authorities coordinate with each other and publish a series of EU-wide guidelines. Sometimes the subject is very specialized, sometimes the guidelines touch on a very general matter such as the concept of “consent”. These guidelines are an effectively–binding interpretation and thus bring welcome clarity to a compliance process.
However, if a website is based in the US and the terms of service say that the law governing the terms is US law, how can GDPR have any affect? It is unlikely that the EU will be able to enforce financial penalties against a company with no presence in the EU. But they could for example block your website in the EU, depriving you of your EU user base. The actual measures that they could or would take against such a company are still unclear, since the GDPR is quite new, and there has been no action under the GDPR against foreign companies. I'm not a lawyer, but I've signed many contracts in my life and nearly all of them have some form of "governing law" clause. The governing law clause in a contract identifies the law that will be used to interpret the contract and to resolve any disputes arising from the contract. The law identified in the clause does not become the sole law governing every aspect of the relationship between the parties, however. For example, a business in New Jersey could have a contract with a client in New York with a clause specifying New Jersey law as the governing law of the contract. But that does not mean that New York's consumer protection law doesn't apply to the transaction.
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.
In the question, you write: The GDPR requires consent of the subject for collection or storage of personal data (in this case, IP addresses in a log file). No, it does not. To quote Miss Infogeek: GDPR DOES NOT MAKE CONSENT A MANDATORY REQUIREMENT FOR ALL PROCESSING OF PERSONAL DATA. Consent (Article 6 (1)a) is indeed one of conditions that can be used to comply with the GDPR requirement that processing must be lawful, but it is not the only condition available to the controller to ensure lawful processing &ndash; there are alternatives (before the list of conditions it says that "at least one of the following" must be satisfied). All the conditions for lawfulness of processing are spelled out in Article 6 of the GDPR. One of alternatives are Article 6 (1)f. It says says it is legal to process personal data if 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. (my emphasis) As noted in the question, logging IP addresses for the purpose of security is an extremely widespread practice. It is a legitimate interest to comply with standard security practices. It is the default, and most (all?) web-sites do this. I.e. it is legal to do this without consent (if this is not the case, I am pretty sure the outcry had been heard all over the Internet by now).
If you operate from outside Germany but within the EU, it is generally sufficient to satisfy your own country's regulations. This is a foundational principle of the EU single market, though it's not quite realized yet and has exemptions for consumer protection purposes. However, the German TMG law which includes the Impressumspflicht explicitly enshrines this principle. So from the German Impressumspflicht perspective, you're good to go. However, you will not be able to operate anonymously, because of your country's laws. GDPR requires you to clearly state your identity and contact details in your privacy notice. If you engage in internet-based commerce, the EU eCommerce Directive will have caused your EU member state to pass legislation that requires you to disclose: your name the geographic address where you are established contact details incl an email address if applicable, registration numbers from trade registers or similar if applicable, your VAT ID Note that you must have a VAT ID for cross-border B2B sales within the EU. You state that you are not selling anything via your website, and are instead collecting payments via another website. What the consequences of this are would depend on the laws and caselaw in your jurisdiction, but you will have to make these disclosures on at least one of the two websites. About Germany going after bloggers who show ads: income from ads is taxable income, and operating a business requires registration. However, the German Impressumspflicht is rarely enforced by the state. Instead, other market participants (competitors) trawl the internet for potential violations and then send a cease-and-desist letter. They can do this because skirting legal obligations distorts the level playing field, which harms those competitors. There is a thriving cease-and-desist industry built around this, but it only affects businesses that operate within Germany.
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.
The GDPR gives controllers a lot of latitude. They must decide on the correct course of action taking into account the possible risks to data subjects. Specifically, no notification of the authority is necessary if “the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.” In your scenario 1, you suggest that there is no breach because there is no evidence that the data was improperly accessed. This analysis is faulty: the controller is aware that the data was not properly secured, and cannot rule out that the data was improperly accessed. I would argue this fits the description of a “breach of security leading to the accidental or unlawful … unauthorised disclosure of … personal data” (compare the definition of a data breach in Art 4(12)). Thus, a data breach has happened. The question whether the supervisory authority has to be notified of that breach is more debatable. The controller must assess the likelihood of risks to the data subjects. Here, they can perhaps argue that the risk of disclosure is low. However, the nature of the breached data would also be relevant. If in doubt, the controller should make the notification. The goal of the GDPR is not to punish unlucky companies that suffer a breach, but to protect personal data. Thus, fixing mistakes and cooperating with the supervisory authorities is likely the best approach for most companies. In your second scenario, the data is sensitive – its disclosure has a high risk for data subjects. However, the risk of someone intercepting this data is debatable. Does the risk of interception balance out the sensitivity of the data? That's the data controller's call, but I don't think so. A notification would seem appropriate here. As a technical remark, simply offering HTTPS is not sufficient to prevent MitM attacks – users must be forced to use encrypted connections. If a controller sees MitM as a risk, they are required by Art 24 to take appropriate technical measures. Here HSTS and HSTS preload would prevent the connections from being downgraded to HTTP. Instead of offering insecure connections, the site would become inaccessible. A complementary strategy is to not serve content over HTTP, but have the HTTP server only issue a permanent redirect to the HTTPS URL.
If you merely provide software for your client to use, you are not processing personal data on behalf of the client. But if you have access to systems that store personal data, then you must consider the GDPR. Or more accurately: your client must consider the GDPR. Under what legal basis can they give you access to the data in these systems? The easiest way to solve this is indeed if you act as the client's processor. Processor status is never the default, but requires a binding contract with the data controller. This contract will require you to only process personal data as explicitly instructed by the client, and may require you to take certain security measures as a precaution. Without such a contract you aren't a data processor, but possibly a data controller of your own (with all the compliance obligations that implies).