Can DPO do an internal audit of information security according to ISO 27001? In one company, due to GDPR, a DPO was designated, who was later given additional role and a new task: to conduct an internal audit of information security according to ISO 27001. Is there a conflict of interest here or not? Is this combination of functions (DPO and internal auditor) correct? Will at some point such an auditor not audit his own work as a DPO?
It's not necessarily a conflict, since both roles will be aiming for compliance and they're not inherently adversarial. The best outcome for the company would be that non-conformities and observations were raised on audit, and these were addressed in a satisfactory way. [External auditors prefer to see evidence of issues being addressed than a clean bill of health.] I don't have access to a copy of ISO 27001, but there was a change in ISO 9001 at 2015. Previously this had said "Auditors shall not audit their own work", but it was generally recognised that this was impossible for smaller companies and sole traders. It now says that the organization shall "select auditors and conduct audits to ensure objectivity and the impartiality of the audit process". That sentence was there before, but the sentence that followed it has been removed. If the latest ISO 27001 has the earlier wording this could constitute a technical non-conformity, but external auditors were aware that this would sometimes be impractical.
What does your Data Protection Officer say? It’s their role to be aware of and assess if you policies, procedures and processes comply with the principles. For the particular application is it: “specified, explicit and legitimate purposes”? “adequate, relevant and limited to what is necessary” “kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed” “processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures” And can you clearly demonstrate compliance with the above? Just a personal observation: WTF are you using a spreadsheet for what is clearly a database problem? This is several dozen steps away from best practice data security.
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.
Term 1 isn't going to hold up, but that is not a GDPR matter. It's just a matter of basic consumer protection law in the EU. You can't offload responsibility for your mistakes. Looking at 2, Dale M. already pointer out that it's now how the GDPR works. You are the Data Controller. X,Y and Z are Data Processors. Article 28(1) of the GDPR is in direct conflict with your disclaimer. You accept zero responsibility, the GDPR says you are fully responsible. That's the exact opposite.
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.
Yes When personal data is processed in the context of an EU/EEA/UK establishment (for example, by a company with offices in the UK), then all these processing activities must fully comply with the GDPR, regardless of where the data subjects are located. For the UK GDPR: This Regulation applies to the processing of personal data in the context of the activities of an establishment of a controller or a processor in the United Kingdom, regardless of whether the processing takes place in the United Kingdom or not. For the EU GDPR: The GDPR applies to: a company or entity which processes personal data as part of the activities of one of its branches established in the EU, regardless of where the data is processed; or …
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.
No, you're not required to sign any contracts. But since you're offering a service, you do have to manage some compliance tasks. You are a data controller under the UK GDPR, regardless of whether you have a company. This brings with it various compliance requirements. For example, you MUST post a privacy notice in accordance with Art 13 GDPR that explains how you process user's information. You must sign data processing agreements with your data processors, such as your server providers. And you should reconsider transfers of data to the US, since such transfers are illegal or at least quite questionable in the wake of the 2020 Schrems II ruling. You now have prospective users that are asking you for an Art 28 data processing agreement (DPA). These are likely other organizations that are data controllers of their own. For them to use your browser extension, they either need to find a legal basis that allows them to share their user's/employee's data with you (controller to controller transfer), or they need you to act as their data processor (controller to processor transfer). The third alternative is not to use your plugin at all. Of these, a C2P arrangement is most convenient for these other orgs, but involves a bit of paperwork to set up first. If you want to act as their processor, this doesn't mean you'd have to create a company (though a corporation might be very desirable as a liability shield). Being a processor means that you're contractually bound to only use the personal data as instructed by the controller, and not for your own purposes. This restricts what you can do, and has some special compliance requirements. For example, you cannot engage new subprocessors without your controller's approval. However, processor status can also be convenient for you because you're not responsible for interacting with the controller's data subjects, e.g. you're not responsible for handling their data subject access requests. Note that it's possible to simultaneously be a controller for some users, and a processor for others. E.g. Google Docs is offered directly to users as a B2C product so that Google is a controller, but also as a B2B product as Google Workspace, where Google acts as a data processor. Personally, I'd rather not sign any contracts unless I'm doing it as a business, and adequately compensated for providing this service. GDPR is only one compliance aspect out of many, making it unwise to offer a SaaS product as a hobby. For example, copying other people's web content has copyright implications… A potential alternative for some of the organizations asking you might be to make it possible for them to self-host your backend, so that they are not required to rely on you as a data processor. If you have no plans to commercialize your software, making it Open Source could be a solution. But you're in no way required to do that if you don't want to.