Top 30 Terms from Reddit GDPR
05k10k15ksay request time protection website case companies user business get people use privacy personal data
(Number of Rows)tokenbody
WordCloud Ops (GDPRS: SubReddit)
IT Ops Topic: Database
Showing 101 rows, 1 columns
body
score (Sum)
Others
337
A subject access request under Art 15 cannot be denied, and is not subject to any conditions. You must receive a copy of any personal data they have about you, and a bunch of general information as outlined in that article (for example, you must be informed of your right to lodge a complaint with a supervision authority). However: * They must take reasonable steps to verify your identity so that they do not disclose data to the wrong person. * They may charge reasonable fees for administrative costs if you issue repetitive requests or may refuse such requests. * Your right to receive a copy of your data shall not adversely affect the rights and freedoms of others. That means they can redact the data they give you to remove other people's personal data. That a credit card company denies a SAR with Art 10 “Processing of personal data relating to criminal convictions and offences” because their company or officers are under criminal investigation is a complete and amateurish misunderstanding of that article and it does not apply in this case. Art 10 basically just says that you cannot build a database of criminal convictions unless you are an official authority. This is a restriction on what kind of data may be processed in the first place. But once data is processed, you Article 15 access rights exist. In contrast, if you exercise your right to erasure that might legitimately be denied for now if that data is part of a criminal investigation (see Art 17 paragraphs 3(b) and 3(e)). They might have been confused if you asked for “the data concerting this incident”. You have no right to such broad data. You only have a right to a copy of your personal data that they hold, regardless of whether a breach occurred or not. You are likely not eligible for compensation under Art 82 – that article only specifies compensation for *damages* that you suffered, and you would have to take the company to court and prove your damages there. A refusal to fulfil you Art 15 access rights doesn't directly cause you any damages. In contrast, the compromise of the data may have caused damages. Here is what you can do: * Check your previous access requests to ensure that you clearly only asked for your own data under Art 15, and not for unrelated data. * Possibly, submit another request that explains succinctly, clearly, and professionally * that they apparently misunderstood your previous letters * that you are exercising your Art 15 rights to receive a copy of any personal data concerning you * that they have one month to fulfil this request (see Art 12(2)) * that Art 10 does not offer grounds for refusal of an access request (which you hope their legal department will confirm for them) * that in case of their failure to comply you will lodge a complaint with a supervision authority and will explore your options to sue them for compliance and for remedies. * If you are very serious about this, get a lawyer to write this letter for you. * If they continue to refuse to comply, lodge a complaint with your local supervision authority. Explain that they are unreasonably using Article 10 to refuse access to your personal data. Attach copies of your requests and their responses. * Independently of any complaints, you are free to exercise your rights under Arts 79 and 82 to seek judicial remedies, i.e. sue them. However, this may be costly if you do not have suitable insurance.
20
Each country has its own compliance body. The UK uses the ico. You can report illegal activity there. If a company isn't in the EU, their legal body is determined by where they have the most active offices in the EU, or their partners. If none of that applies then they're De facto outside EU juris diction. Currently the ICO are swamped, but report anyway - they always get back to me in the end. Also, thanks for the service. They can't do this all on their own, and people explaining to them the back end violations is probably quite useful. I'd also add that you're right, this doesn't need to be complicated, and companies can often easily just respect the 'no tracking requests' that browsers have built in. One more complication: AFAIK its actually legal to pull in all your cookies and then scrub identifying marks like your IP, so they end up with a database that says "people who like our product also like Facebook, cats, shopping for jewelry and are typically over 40". If nobody's identifiable with that database then there's no violation, so it's not always possible to tell compliance without access to their databases.
12
70% of your database is useless data if they don't respond so what are you losing by deleting it? It sounds a lot but that 70% are obviously not interested so it's no lost business for you.
5
He's a customer so his email will be in their database for legitimate reasons. He's just opted out of marketing emails.
5
> You have to be joking, right? This is a basic way banks and businesses function. Are you suggesting a thrice bankrupt delinquent should get the same mortgage rate as a responsible young professional? You think a society could actually function that way? Are you suggesting a landlord doesn't have the right to loan out a flat to someone more likely to pay rent? I don't think they should get the same rate. But they should be informed why their rate is higher and based on what data. That data could very well be flawed or even false, and the consumer should have the right to get insight into that to protect themselves. > No. If you're a responsible person, and you have some basic personal responsibility in regards to what information you choose to give out to what website, this is not a problem in the slightest. Also, if that's the only thing the GDPR did, I wouldn't have a problem with it. If they made it illegal to sell data without your permission: fine. But that isn't what it is... it redefines personal data \(some of which wasn't even classified as personal like IP addresses before this\) in a way that makes it impossible for the internet or the world to function freely. I do agree with the IP\-address being a bit of a flawed thing to include. Yes, it can be used to identify someone in some cases, but it is integral to the workings of the internet and security also. I am guessing that storing IP\-addresses will be one of the first things that are going to be moved to legitimate interest when it pops up in court. As for being a responsible person, this law should help with that. I can't be a responsible person if a company is allowed to hide what it does with my data. Plus, it is also being a responsible person to make sure your information is safe, which you can now force by having your data deleted from databases that might very well be breached.
4
" As a website owner, I don't want freeloading Euros visiting my sites and not paying for it in some manner." As a E.U. Resident i went just fine without knowing your site at all so far. If it is in YOUR interest to include 500million prospector clients in your company database you will comply, if not is ok to limit yourself to other markets. As a consumer i have other options. Good Luck to your enterprise
3
>How does that impact CCTV, such as in a business owners stores or government cameras in the public streets? Can you request that footage along with it's removal after? Or these are covered under a legitimate business case / legal basis, and are exempt from any explicit consent? You don't need consent. Also request of footage needs to be very specific, and is possibly impossible, depends on the circumstances. You cannot (succeed) at a deletion request. In all likelyhood if you do a request the data is saved way longer than normal. >What about as a tourist taking photos in public areas with people in the background. Isn't that capturing/recording PII data, thus requiring consent? Or does some part of the law make this activity exempt? There is an exception for strictly personal use. >Does a retail store need my consent as a visitor before a sales person approaches me to pitch their products/specials? No, unless it is through emails, then it can be different. >Does a mall need your consent before entering, that the third party stores inside acquire certain personal data with their own privacy policies and consent(but you're consenting that you're aware of this first as you'll be exposed to them via a first party), and that should any of the stores act in a malicious way or deviate from what the first party was aware of, the first party is still responsible/accountable in someway?(not quite accurate since there'll be actual contracts in place, something you can't always do with third party integrations/content online, nor always safeguard the user via some binding agreement prior). Mall visitors are going to ignore/walk past such caution/advice as quickly as they'd tick "I agree" to EULAs without reading. No, the mall doesn't need your consent. That people don't read EULA's or Privacy policies is not the problem of the organisation. >A real stretch, would be as an individual data controller/processor. Does a person's own senses(sight, touch, hearing, etc) require consent to your PII that they acquire and store/process within the brain? Do I have the right to erasure on their memories of me? (might seem silly atm, but I guess it's appropriate if in the future people were augmented in such ways that hardware was involved, and it's not all that different at that point?). So where exactly is the line here No, GDPR has a limited scope, it needs to be an (partly) automated proces, or if analog, the data needs to be stored in a organized database. See art. 2(1) GDPR >If you're attending an event where they insist you wear a badge or bracelet, have your skin stamped or similar form of identifier/categorization, if you choose not to give consent, can you continue to enter/attend the event without a "cookie" identifier(tracking/PII) to verify your right to access? This is not personal data under the GDPR, see last answer about the material scope. Also this proces would not be based upon consent if it would be changed so it is an automated proces. >The last example is probably not applicable. I was thinking of this in relation to accessing a site(can't be denied for not giving consent) and being tracked(opt-in consent, but not core to functionality), but technically it's a valid legal basis(to differentiate access rights, similar to login/account) and performance(fast validation that you have the rights to go ahead). Website (automated proces) is different from other non automated processes. Also still don't agree with the idea that denying access to a site would invalidate the consent.
3
+1. Storing any personal info on a blockchain is fundamentally at odds with GDPR. The only way that I saw (#NotALawyer) to make them compatible is to depend on a non-blockchain data source to convert from anoymized, key-lookup data in blockchain to non-blockchain storage. This allows you to handle rectification and erasure requests using non-blockchain storage. But then, begs the question as to what benefits you're getting from blockchain at that point vs a normal database.
3
1. Its not for this account 2. That account may contain personal details such as emails and links to my other profiles that uniquely identify me. Also how should i know how they store their data in the Reddit database, it may very well have other details assign to it such as IP records that can uniquely identify back to me 3. I have no access to that account to delete it, and even if I did have access and deleted it in that account it may still be flagged as inactive somewhere in a database that could then be later hacked, leaked or stolen. 4. A GDPR request shouldnt mean I have to jump through hoops to do it, also its not just for people on the internet you can also call, write or request in person a GDPR request
3
Backups. Backups are an area that really was not considered enough when creating the regulation. The biggest issue we are seeing is the methodology of erasing customer data from backups. If you are getting valid request from your end customer to erase their data, you have the responsibility to ensure it is erased from every location. Are you expected to somehow reload your historical archives to remove the data and then back it up again? Or if you are in a situation where you need to use your backups, have a process in place to erase all of the records you have requests for before going back into the live database? If you have a large amount of these it would easily be a hassle to manage and a few would fall through the gaps.
3
Good points both. With regards the Air France CEO, what if the data were, as is generally the case with CMS databases, more related to the role than the specific individual? i.e. prior communications with the person of that role rather with that individual? Of course if it said 'remember to ask about Sally and the kids' that'd be no good, but if it was 'remember to ask about the new 2018 offerings.', then that should be fine, no?
3
However, if the database does get stolen, you need to show, that you thought about the consequences and how secure the databases needed to be. It's in one of the last paragraphs in the GDPR - around article 80 I think. So, if the information is essential to the users, than you would need double down on security.
3
I agree with you. They clearly had a legitimate interest in storing the data of consenting users. And users who actively use the site would likely be willing to opt in post 25th of May. I'm speculating here but ... Looking at the screen shot and business model, it's probably a system that gets authentication to look at your contacts and friendlists and then suggests to mass mail / invite all your contacts to use the site so they can find the few people using crypto in that list. The personal data held is valuable and even if the message is that the site is making a loss, having (and being able to sell) a database of 10s or 100s of thousands of confirmed crypto users is something that is valuable and should not be sold at the same time. So whilst GDPR is annoying us all at these stages, IMHO this is a case of good riddance. now ... let the downoting frenzy begin.
3
I don’t get it - surely they have a legitimate business interest to collect PII and make it available/searchable in the Whois database ... as long as users are informed of this then that should be fine? What bit of the regulation am I missing here.
3
I have been thinking and concerned around this for some time. I would think that any user e.g. Dave uses linked in and uploads his contact list. Dave is the data controller (he has the contacts emails and numbers etc). He is then asking LinkedIn to process the details to find if they are on the database or notify when they do join (they are being data processor and then retaining and linking later data controllers as well). I think these kind of things have been dodgy for some time and GDPR may well finally be a stick to stop it from happening. The real question then is:- Is Dave now liable for millions of euros for breaking GDPR by sharing his mums email address with LinkedIn? Or is LinkedIn liable for asking to collect this data? Possibly both as Dave had no right to share the personally identifiable information.
3
I hope I have got this right, what you are basically asking: if a user of a website messages another user with personal details, in this case, a telephone number, should that message be deleted if a deletion of data is requested? This is a gray area but the short answer is, no. There are so many factors to consider, including the message storage type, for example, is the message encrypted (WhatsApp) or is it stored in a readable format (facebook)? A personal message sent via a social network is controlled by the user and, therefore, is not data directly held by the network in question in the user database. It would not be an unreasonable request to message the network in question and request this to be actioned but, depending on where you are located in the world, you may not receive the response you want. If you are in the EU, please check out GDPR, with special attention to Article 17. I am sorry this is a vague answer but the many considerations of each social and messaging system makes it difficult to try and provide a more accurate response.
3
I think I mirror /u/sniffles_snort, expanding on this though. I think that it means if you get your compliance state right, and keep your users properly informed, it will mean you will have a database of users that actively want you to engage with them in some way. A massive win for marketers and businesses as well as the individuals it protects. Now I think states outside of the EU including the US should work to mirror this legislation. International lines of commerce are slowly getting blurred and if you are dealing with EU citizens at all you will need to ensure compliance. However, I think it will be the citizens who will need to push for this change in their countries. To the point of national security, there is already provisos in GDPR that address this and the "need" for data collection by authorities and acknowledges that consent is not always possible in these circumstances but again people need to ensure they are electing representatives that will protect them in these matters. No use complaining if you are removing yourselves from the solution. I will also add that this is by no means a finished product and I expect that there will be challenges and amendments to it as enforcement and legal precedent is set against this legislation. TLDR; Yes it's good because it means a more informed customer and business. Yes, there should be mirroring in the US and other territories. Yes, there will be problems or issues that will need ironing out. Overall better than what we have now.
3
"Structured data is data that has been organized into a formatted repository, typically a database, so that its elements can be made addressable for more effective processing and analysis. A data structure is a kind of repository that organizes information for that purpose." Exactly, this goes nowhere, you obviously know better than everyone. To go back to the subject : To further strengthen the control over his or her own data, where the processing of personal data is carried out by automated means, the data subject should also be allowed to receive personal data concerning him or her which he or she has provided to a controller in a structured, commonly used, machine-readable and interoperable format, and to transmit it to another controller. Data controllers should be encouraged to develop interoperable formats that enable data portability. HTML is not really interoperable and does not really enable data portability. Good luck using those arguments where it does matter, and good luck with your control authorities if you try to use your wonderful arguments to defend that HTML is sufficiently structured to "enable data portability". XML works, yeah, but not HTML.
2
> No, GDPR has a limited scope, it needs to be an (partly) automated proces, or if analog, the data needs to be stored in a organized database. See art. 2(1) GDPR No. Even manual processing falls under GDPR. The full article reads : This Regulation applies to the processing of personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system. As per original question : as long as it's for personal use and not intended to be used by a business at any time, the data that cybers could collect would not fall under the scope of the law, as long as it's not going to be used by a business.
2
> This covers any file or database that has a person’s name or an ID in it. Not just files and databases but any organised storage mechanism. Not just name or an ID, but any information that relates to an identifiable individual directly or indirectly.
2
>(As an aside, I would personally recommend collecting the IP Addresses of the visitors for security purposes.) I don't disagree, but I believe that keeping data separate is a good idea. Making one database with only the necessary data for the project, and then putting things like information security data in another database.
2
A colleague runs a web site for booking court slots for tennis clubs. As part of log in procedure, user enters club ID number (from national database) and his site currently displays user name for confirmation purposes. A user recently complained about this. Should he change his process? Thanks for doing this - good AMA!!
2
About the fines: You don't just get fined out of the blue, so don't worry too much about that. The fact that you're asking for advice shows that you're thinking about it and you're taking it seriously. The GDPR is about responsible personal data handling. You can take a look at [article 83](https://gdpr-info.eu/art-83-gdpr/) to see how organizations can "win" the maximum fine. Basically: be intentionally negligent, make sure to endanger lots of important personal data, and don't cooperate when you are contacted by the regulators. About your service: Are you offering a (free) service that anyone can use? How do you attract users? If it's not a service that you're offering to anyone but rather a casual thing that you and your friends use then it's outside the scope of the GDPR, perhaps your bot is casual enough to be exempt as well. Check whether [article 2.2.c](https://gdpr-info.eu/art-2-gdpr/) applies to you. Can anyone store any message? If anyone can store any message then you should consider encrypting the messages while they're in your database because someone might be stupid enough to store important personal information. In turn your database might get hacked and suddenly you're responsible for leaking important information. Do users need permission of the message creator to view a message? If users need permission of the message creator to view the message then it shows you're taking their privacy seriously. Can anyone request to view all their stored messages? Can a message creator delete their messages? If a message creator can view and delete their messages at any point then you're giving them control over the information they store. You could also make a 'delete all' command to make it even easier for users to manage their stored data. Consider automatically deleting messages if a user has not used your service for a certain amount of time.
2
agreed 100%. Did the same thing with all my small business clients. i might have an additional quick question related to mailchimp though. if you have a client with very small email database (<2000), mostly from U.S, whereas the business is located in Europe ; would having an active opt-in form and email notification about being GDPR compliant with updated privacy policy enough or do you really have to create new segments and ask subscribers for a consent (which would result in huge email loses.)
2
At least one person gets it. Here’s an example. Two vast databases of personal information and a device database of billions all for sale to anyone who can pay. Wait till the end when someone asks how to get off the database if you’ve bought a second hand device: https://youtu.be/cZ762pJXA8c In this example the GDPR gives you a right of access to see what they hold, the right to correct inaccurate data and the right to erasure in some instances. It also requires a legal basis to process this information before they even start. The existing cookie regulation requires consent and GDPR requires informed or even explicit consent in some cases. The OP is obviously fine with all this.
2
Deleting an account doesn't necessarily mean Facebook has deleted your data from their databases and the databases of the people they sold your data to. It just means you no longer have a facebook account.
2
Every single story of abused people I've seen contained no data which could lead to identification. It's unreasonable to post said stories with first and last name of the abuser. GDPR or no, that is not allowed (potentially after the abuser was declared as such after a final verdict of the court case, but I don't know enough on the matter). Those stories also tend to have a changed name of the victim, and even if not, it's only first name (unless it's someone famous). Even if it's imperative to present full disclosure, GDPR has you covered. As long as no art. 9 data is involved, art. 6(1)(f) with legitimate interests could be used to justify publishing such story. And then, with art. 9, there is also a special exceptions for organizations. So no, you don't need any consent from the abuser if other grounds for processing are present. As long as his interests are overridden by the action at hand, the organizations will be fine. Also, I already told you - you are NOT a controller nor a processor in terms of Reddit (nor any other service you use as a regular user). You are merely a data subject. The only exceptions for a regular user would be if you're an admin of a subreddit or you own a Facebook page. You are, however, a controller, when it comes to the data you gather in the process of your business. So those records of payments, notes and stuff, you are a controller of that. Now I see what you struggle with - Gmail being a controller of all mails, and you being the controller of the data you have in mails on Gmail. But Gmail is the controller of all data they have, and you are only a controller of the contextualized data you have access to yourself. You are a controller of data that is contained on your mail account, but as long as you control data in private manner, this is out of scope of GDPR (personal and household use of art. 2(2)(c)). That changes when it's not your personal use, but work, as then it falls squarely under GDPR. So yes, in terms of all work-related data, you owe the data subjects the rights they have (access, deletion, restriction, etc.) Also, as I understand, you keep contacts as 'J Smith' and so. So if one of your databases is compromised, the invader won't know the full names and anything more. However, I assume that there is some other database or matching the contact names with actual names (e.g. the person's mail will indicate 'John Smith'), and maybe another one with phone numbers. If all databases are compromised, full data can be achieved. This is thus pseudonymization. It's a great mitigating factor, and this will certainly lower the fine you may hypothetically get, but that does not relieve you from the GDPR. Lastly, about notification, look at art. 33(1). You're obliged to notify the local data protection authority, *unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons*. You only have to notify the data subjects if there was a high risk to their rights of freedoms (art. 34). It may well be that the data you control is unlikely to result in any actual risk, so you don't really have to do anything.
2
First, please provide more detail on your application. Include details like if you're using any third party services such as AWS or APIs as well as if there is a database or DB-like component. Is it comprised of a single server or does it involve multiple hosts? What services are your servers running? It sounds like you're more concerned about apache/nginx logs than actual system logs captured by rsyslog and friends. Let's not even get started with the fact services/applications don't necessarily have to log to /var/log. The more typical approach to logging is to log to central server such that local host logs can't be deleted or tampered with (as would be the potential with a host intrusion). Second, your course of action in disabling system logging is very bad. Doing so presents a net and infosec oversight not to mention a very poor operations paradigm. Without visibility into what's occurring on your system(s), you are unaware when things go wrong until they've gone wrong. "Going wrong" can encompass any number of things. Service dies, host experiences hardware failure, an intrusion occurs, network issues, etc.. When something "goes wrong" it may be much harder than necessary to root cause and address due to lack of logging. Disabling host logging is not going to make you magically GDPR compliant. This is why I ask for more details. Unless your application is incredibly simple/limited, limiting data processing/storage is usually not going to be so straightforward.
2
Great, I took the data in this link and used the comments with some corrections and just sent it out to our sysadmin and big data team, they are going to try to get some stuff done with in terms of file server and database scanning.
2
Hahaha chill out my friend, there's no need to be so angry! First, we're talking about a European Regulation, not US law. Which means that "going to court" isn't as easy with the GDPR. The data subject would most likely have to file a complaint to his supervisory authority, which would in turn investigate to assert whether you are knowingly processing data from data subjects on EU territory. In that case, the proof kept in your database is a great start. There's also a recital (recital 23) in the GDPR which you might find interesting: *In order to determine whether such a controller or processor is offering goods or services to data subjects who are in the Union, it should be ascertained whether it is apparent that the controller or processor envisages offering services to data subjects in one or more Member States in the Union.* ***Whereas the mere accessibility of the controller's, processor's or an intermediary's website in the Union, of an email address or of other contact details, or the use of a language generally used in the third country where the controller is established, is insufficient to ascertain such intention*** *, factors such as the use of a language or a currency generally used in one or more Member States with the possibility of ordering goods and services in that other language, or the mentioning of customers or users who are in the Union, may make it apparent that the controller envisages offering goods or services to data subjects in the Union.*
2
Hi, You need to think about the security of the information you process, GDPR is not all about the list, it is very much about the company and how it protects the data entrusted to it. It is not called the General Data **Protection** Regulation by accident. I assume however you are wondering what lawful basis you should use with the data you process. 1\) Direct Workers \(Employees\), as an employer you need to process personal data to comply with your legal obligation to disclose employee salary details to HMRC. You should document this lawful basis in a Data Protection Policy. 2\) Indirect Workers \(Suppliers, Contractors, Advisors, Consultants\), you should consider using Legitimate Interest as the lawful basis for processing personal information on indirect workers. In both of the above examples, it is important to bear in mind both the rights and principles of the GDPR. For example, if a worker would like you to remove them from your database then you must, if you profile your workers in order to create a reliability score then you must inform them of this, if employees leave then you must remove information that is no longer necessary to perform your legal obligation as per your Data Protection Policy although you can keep certain information to help in the event of a future claim against you. Hope this helps I run [gdprcheck.com](https://gdprcheck.com), would you mind if I posted your question on my site to help others, the employee bit is a very common question. Duncan
2
I am in a similar situation. Article 11 Section 1 covers it. It basically says that if you are not keeping databases of private data, then you do not need to create one just to comply with the GDPR. I am not going to create a database just to manage proof of consent. I am going to store the consent on the device. If the user consents or does not consent, or has not chosen yet I will store this flag on the device in the usual way that I store other data. It will get deleted when the app is deleted. I will certainly not be creating extra databases or data to record this consent, the law clearly states that this is not what it is about.
2
I certainly agree with you that it doesn't have to be an email and it isn't a contract. It's just information. "A data subject is required to be informed". Updating your privacy policy on your website in many situations is not enough to be able to say "We have informed the data subjects" as a good portion of them may never visit your website, or do business with you ever again and will never see the privacy policy. In which case it cannot be said that they have been informed. At the end of the day, IF \(fairly big if, but the fines are also sizeable so the risk is worth implementing a countermeasure\) you are audited, can you prove that the data subjects have been informed? An email trail would help with any potential audit and that is one of the principle reasons \(well that combined with the fact that their databases contain millions of data subjects so the risk is BIG\) why companies are sending out email notifications with links to their privacy policies. Many companies are also asking for consent to send marketing communications and/or consent for processing \(where they can't / have decided not to use legitimate interest\) because they have taken the view that their original consent was not up to the spec' required by GDPR. I agree collectively it's a shitty customer experience, but if you do it now there is low risk of reputational harm \(and anyone holding a grudge against you in particular\) as there's just too many to remember.
2
I did the research myself, and as far as I know, there are 12 countries supervisory authorities that has a searchable registry on their website. Some sites has the a form to register, others I assume is just displaying company information from other databases. So far, from what I have seen, only UK and Ireland charges a fee to register. This is hard to research as most of these websites are poorly made.
2
I have reported it to Trustpilot & Thuiswinkel (dutch trustpilot kinda). I am not able to actually make a report to my GDPR authority because it isn't about MY data, so I can only tip them and not make a complaint... I am considering buying a product for 3 euro's than sending it back, just so my data is in the database & I can see if first my name (fake ofc) will pop up & so that I can fill in a complaint. Secondly I am typing up a message for their customer support at this moment but finding it hard to find the words.
2
it's not because you can highlight part of the text that it makes it a database or a "structured" file. And it's not because a text is separated by paragraph tags that by magic it becomes a structured document. Structured semantics does not mean CSV or table or any kind of structure. Even more when you quote a COMPLETE sentence : by denoting structural semantics for text such as headings, paragraphs, lists, links, quotes and other items. Very nice way to demonstrate exactly the point I was trying to make, thank you -> HTML is used to format text.
2
Well, try to use undocumented tags with HTML and see what happens. XML is designed to store DATA, not text, so you can document the structure of your data, with a schema, and use any tags you need to structure your data. So I maintain everything I've said since we started this useless banter as obvioulsy you are mixing up HTML and XML. HTML is designed to markup text using semantics / formatting tags. XML is what you are thinking of when you talked earlier of structured data. The point is moot : I would love to see you argue in court that HTML is structured, as XML or a database could be, and see the result. The portability of Steam data is insufficient as per GDPR requirements, HTML is not sufficient to allow anyone to import the ported data for further processing. XML would work, but it's not what they are doing. Enjoy your week-end, I'm done hitting that dead horse.
2
XML can be used to store databases and is used to transmit data. HTML not.
2
You do realize there is more type of data to be stuctured that doesn't fit in a table in a database. Have you never questioned the purpose of paragraphs and headings when reading an article? We use those structures in writing to break up and organize information to be processed and analyzed by us humans. HTML is flexible enough to be able to structure different types of data in a single file. Articles, essays, tabled databases, lists, definitions, and more. I don't know where you get HTML is not interoperable. HTML is by far the most common format there is, the entire internet uses it to share information. There is countless means \ tools, to pull in HTML, to process it, pulling the information you want out of it. So tell me how does XML a markup language serve the purpose but HTML does not?
2
**Examples of International Transfers** Although many international transactions obviously involve transfers of personal data overseas, there are some situations where it is less obvious that an international transfer of personal data is taking place. In some instances, organizations may perceive that they make no international transfers of personal data, when in fact the reality is otherwise. The following examples of international transfers are offered to hopefully widen the reader's perception of the types of circumstances in which the GDPR's provisions on data exports will become relevant: 1. A multinational organization, based in the United States, with offices in the UK and other European countries, maintains a computer network that connects all its sites. Considerable quantities of information (including personal data) are regularly transferred between various points on the network. 2. A UK company engages in cross-border list rental whereby lists of customers or marketing data are transferred to organizations abroad. 3. A German company's entire database is transferred to Spain as a result of the purchase of the company by a Spanish organization. 4. The forwarding of an email containing customer details by a person in the UK to a person in Hong Kong. 5. The transfer to India of files containing digital voice dictation for the purpose of such data being converted to Word documents (e.g., letters) before being returned to the UK by email (cross-border digital dictation outsourcing). 6. The HR department of a global organization with offices in the UK is to be moved from Ireland to Singapore. 7. A UK company publishes the names, home address, and mobile telephone numbers of its staff in an internal directory, which is made available to branches of the company located in third countries. **Scope of Data Transfers** The concept of transfer is not defined by the Regulation. However, transfer is not the same as mere transit. Therefore, the fact that personal data may be routed through a third country on the way from an EEA country does not bring such transfer within the scope of the restriction of the Regulation unless some substantive processing operation is conducted on the personal data in the third country. In practice, there are two common situations that have been a source of concern in the past, but that are not subject to the restrictions on data exports: 1. Technical routing of packet-switch technology (such as internet email and web pages), which may involve random transfers of personal data between computer servers located anywhere in the world; and 2. Electronic access to personal data by travelers who happen to be physically located for a short period of time in a place that does not afford an adequate level of protection --for example, a person who logs on to a computer system based in the EU to access data from a foreign airport. In addition, following the European Court of Justice decision in the Swedish case of *Bodil Lindqvist*, where an individual merely loads personal information onto a website that is hosted in that state or another Member State so that the information can be accessed by anyone who connects to the internet, this does not necessarily constitute a transfer of data to a third country. However, where there is an international exchange of information about individuals with the intention of automatically processing that personal information after it has been exchanged, that should be regarded as a transfer for the purposes of the Regulation, even if the original exchange does not qualify as processing of personal data. An example of this would be where information is provided by someone in the EU over the telephone to someone in a third country who then enters the information on a computer. **Remote Administration of Servers** When the big technology companies offer 'local' data storage on servers in the EU, generally the maintenance and support of the servers is performed by teams based in the EU, precisely in order to avoid doubts regarding possible remote 'processing' of data from outside the EU. The key question is what does server "administration" mean exactly and how one can ensure that any of the functions performed when "administering" the server do not constitute "processing" of the data stored on the server (bearing in mind the very broad definition of processing below). If you do anything that constitutes an "operation on the data", including but not limited to storing it, encrypting it, moving it, restructuring it, making it available, erasing it or destructing it, then administration of the server equals processing of the data stored on it.
1
i do have everything on the privacy policy but i cant be sure there is no one that i know that can check it my website is on en and heb i cant be sure if i will have eu i know i will have mosly israeli players but eu i dont really know i live in israel and will host the website on israel like the game server are host on eu i cant really be ompliant because its just game server that playing in it nothing much yes its log ip but this is mosly game server work its log it on the database for bans and sercurity and i dont know what the game server host collect i want to try to be compliant but there is no one that can help me i did privacy policy and tos i still doing but there is no one that can really check it if i did it good i dont really want to get fine or problems with the gdpr i see alot of israeli communtiy that have eu players but they just dont care about it
1
... unless you use it in a non-compliant manner (e.g. pull that data and make a marketing database of some sorts).
1
"a large database of donors and followers" Which means that you will be mailing them with requests on donations so it's purpose is marketing. Is consent also required when you have a business to business mailinglist with no marketing purpose? For instance a mailinglist on are services up or down?
1
> I thought a private person would not need to comply with GDPR. Poor phrasing from my part. This is what I mean. Although it is not entirely true also: if you enter into the personal business of selling personal data without a registered legal structure, you're still in violation of the GDPR (among others). Now, in the database in email shared among the HR service, it's still a matter of internal controller vs. internal processor. The IT service is only the processor. Their role is to deliver a service securely to HR, and comply with their order. It's the HR department that is the data controller, and therefore responsible for managing its processes involving personal data. If you want to know what the HR department thinks of you behind your back, ask them, and see what type of response you get.
1
> Am I being needlessly difficult? No, it is your privacy, your data, it is only up to you how 'difficult' you want to have it to be able to 'use' their services. > Is it reasonable to expect a mobile telecoms operator to have a photo of you and your passport number? I don't think so, I have no clue why they would need a face that goes with the data, or why the passport number is even useful to them. What they are required to do for their law, is on top of what they are required to do for you because you are a UK citizen, so if your law requires them to encrypt your data and give you the right to delete it (For example when you aren't their customer anymore) than they should do so at your request. even if Italian law would be that they need to keep the data for x amount of years. I wonder what their follow up it gonna be, either they are going to tell you, you can't be their customer, or they will accept the passport anyway. For me, personally, I wouldn't want them to have the GPS of my bike + my face & passport number, if someone would breach their database that user could easily impersonate you, steal your bike, and get away with it.
1
> Anyone who can get hold of my data could conclude" By themselves? Will this require access to another set of data? There won't be a name of the patient and no date of birth (but age at time of treatment), but the practice and dates at which measurements characterizing a treatment were recorded would be stored. Assume a worst case full data breach (of the data we hold, not the data matching these records to the patient). I would see both below examples as maybe a little contrived, but possible. If patient x, y and z have all the same operation and x and y have presented themselves for a few checkups at specific intervals. If Patient z is still due this checkup, then a PI waiting outside of the practice could identify the date and a subset of people one of which would likely be z. It would need a fair bit of additional subject matter experience but it's still possible. It would also be possible if this data is breached to identify if a health condition has been improving or worsening. Here in the UK it can be mandatory for a GP to release certain basic information about a patient who is absent from work to his employers. Disagreeing to this can as far as I now give the employer the right to terminate the employment earlier. An employer could potentially make an informed guess to match the information they have on the employee/patient to a breached database and thus conclude a prognosis given third-party medical advice.
1
> Blocking EU users would be very, very stupid for a company that has a very large portion of its user (and customer) base in Europe Why? If you've ever looked at ad revenue per region then you wouldn't clearly noticed that Europe pays multiple times less in ad revenue than the US. If Europe then adds conditions that make it even worse then European users end up being a negative. >You are allowed to keep the backups without altering them in case of deletion requests, but you cannot save them needlessly. I do understand. But then I have to construct a second database and system that deletes the data that has been requested to be deleted when using the backup. That's going to be a nightmare if something goes wrong. >You just need to store it in such a way it's no longer considered personal data, which is really not difficult. Basically everything is personal data under GDPR. >If you save all personal data forever and you dont have valid reasons to do so, privacy is breached. It's not because the user gave this information away freely. GDPR tries to pretend that this is how it should be, but real life doesn't work like that regardless how much Brussels bureaucrats want it. >The data will not be in the hands of FSB. Except that the GDPR does not concern itself with state organs nor do these rules apply to EU institutions. Oh, and don't forget the millions of websites that don't and will never comply with GDPR. >Without GDPR or similar regulation, your data is not safe. The data is not safe even with GDPR. In your example GDPR would make you feel good but provide no benefit because of what I mentioned above. >We dont know what countries that in 20 years will use personal data gathered from annexed countries or hacked backups. And as was mentioned above: the GDPR will not help in this case. Now consider that Europeans very often use websites that are outside of Europe because we seem to be unable to create services that people want. There are no guarantees that those services outside Europe will give a single damn about this law. Congratulations, you made European websites even less competitive. >but if thats what they want to do, thats fine with me. And this is why GDPR turned me from being pro-EU to anti-EU. Because other people are fine in Europe with being screwed over as long as they get feel-good legislation that's going to hurt our IT sector.
1
> Dont think EU has no control of over you. The law is setup in such a way to protect EU citizens from any company using their personal information. I don't think they don't, I know they don't. > However, consider this. It only needs one customer to ask his information to be removed from your database. And how are you going to answer him? By not replying? That won't look good. I've already had two. I responded with a denial, and sent them a link to the declaration of independence along with an offer to pay for a book on how jurisdiction and soverignty works.
1
> It would be down to the original company to notify anyone on their database that they are going to cease doing business and close down the website. Which works for already registered users. But this is assuming a user that never heard nor used software from that company prior to the event, and just discovered this piece of software. The company has no way of notifying them. > The scammers would also be at fault as they are knowingly breaching GDPR I should have phrased my question better by asking if it would *just* be the scammers at fault. E: Fixed the phrasing.
1
> there is a forum who it's unused The forum is no longer used? Then you need to anonymize all personal data (such as usernames), prevent logins, clear out all IP Addresses from your database, clear out all e-mail addresses from your database, and ensure that no data that can be used to identify an individual exists. You then need to destroy any backups of your forums containing that data. If the forums are no longer used, you do not have a reason to keep that data any longer.
1
> You don't need consent. Also request of footage needs to be very specific, and is possibly impossible, depends on the circumstances. You cannot (succeed) at a deletion request. In all likelyhood if you do a request the data is saved way longer than normal. Fantastic, so is that falling under any part of GDPR? How does that apply to a service on the web?(Such as those that sell CCTV monitoring products with web viewers/tools) There are some SaaS out there I believe that provide storage and remote viewing to users. Are these businesses treated in the same way? > Also request of footage needs to be very specific What kind of specific and why? They've got PII data of you in the footage, is your identification along with date/time and location not enough? Does this equally then apply with a users IP? Sometimes cited as personal data, sometimes not(one of the threads about gdpr on reddit link/cite a ruling in germany where it is considered PII, even when obfuscation or masking by stripping out some data was done). I'm pretty sure ones own photographic identity qualifies far more as PII than the IP address would have. So how can this be applied to the usage of IP addresses to be exempt like in this CCTV footage containing explicit PII? Providing additional PII that verifies/links that the requested occurrences of an IP address(since each record may not actually represent that particular identity, and technically a user can very well have multiple IP addresses via home/mobile connections, public wifi, internet cafes, etc), actually are related to the user requesting deletion of such records, is not sufficient evidence to approve such an action? And that's legal under GDPR? It'd be rather difficult to prove such, especially if the full IP isn't retained, and no other PII information was stored by you that could identify the user. Far more difficult than that CCTV footage could be verified. --- > There is an exception for strictly personal use. So if I capture analytics data, strictly for personal use of my site, I don't require consent from the user of what I store? Is it any different from the tourist taking multiple pics or video for personal use, but inadvertently acquires personal information(photographic identity, location, time/place, activity, etc) of those in the vicinity, which they may share with their friends on a social network privately or publicly. If it captured something interesting/funny, in particular of one of those background individuals, perhaps it goes viral. What happens now? Still considered personal use? > No, unless it is through emails, then it can be different. Eh? So I don't need any consent to serve relevant ads based on a visitor to target them to products that could interest them? That sales rep(including third parties that put up a stand to promote a product) doesn't require consent to profile you based on any information you've walked in with(clothing, style, any accessories that indicate/express interests), or if they've seen you previously and now have prior information, perhaps the sales rep worked at a different store in the past, etc). > No, the mall doesn't need your consent. So consent for iframes that aren't same-origin, where those 3rd party vendors may do something with your personal information, isn't required? That responsibility falls onto those vendors handling their content presented in an iframe as if someone had visited their own site? By having those iframes, regardless of what they do, I do not have to be aware and keep track of what they're doing in regards to GDPR and seek consent from users? > No, GDPR has a limited scope, it needs to be an (partly) automated proces, or if analog, the data needs to be stored in a organized database. See art. 2(1) GDPR " *This Regulation applies to the processing of personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system. * " Aren't our biological inputs automated processes? And our brains store information, we remember/lookup that information, is it not technically a form of database? > This is not personal data under the GDPR, see last answer about the material scope. The identifier for tracking if you've been to the event or have access to the event isn't considered personal data? It may contain a UUID which I thought can contribute to being classified as PII similar to how IP addresses can? It'd also link you to a location/event at a certain date/time, along with interest. The automated processing would be in gaining access quickly as the identifier confirms you've already been seen/processed before. Prior to gaining the identifier, some exchange was met, and you may end up in a database before collecting your identifier as you are about to access/visit the service/event/location, or it was first in first serve for a certain amount of visitors on arrival.
1
>No. Even manual processing falls under GDPR. The full article reads : and to the processing other than by automated means of personal data which form part of a **filing system or are intended to form part of a filing system.** This is an organized (non electric) database
1
A bit odd you don't state **you are the site owner and create a title that looks like a 3rd party post.** You could clearly have posted here for advice, there has been some excellent feedback to others who have done so. I've had to take legal advice on GDPR as well and believe you'd have a perfectly legitimate interest case as long as you allow users to remove themselves from your database and separate identifying and pseudonymous data so that any such users can be removed from backups or at least become pseudonymous in the process. All I see GDPR doing to you is to remove the value the data may have for bulk emails or selling the data onwards which GDPR pretty effectively stops in the tracks. I do agree that the EUR 20M fine is a terrible move which means large companies get away with relatively low risk whilst individuals and small business risk fines that can be multiples of their revenue.
1
Actually have been thinking that an separate database with all the change requests is accessible via API and restoring a backup would also update it based on the change list (please forget me, please freeze my data etc)
1
Are you saying that there's a difference between an explicit field in database specifying someone's ethnic origin and possibility of deriving the same ethnic origin using other data without actually storing the ethnic origin anywhere?
1
As a belated response: * **Processing in the context of employment** is more difficult, because the GDPR largely delegates that to member state law. This could make things easier (e.g. by providing additional legal basis for processing) or more complicated (e.g. protecting employees from being forced to consent). * As a service provider you may want to be a **Data Processor** instead of a Data Controller, because that lets you give most of the compliance obligations back to your clients. This requires that clients sign a **data processing agreement** (DPA), which lists your and their obligations and under what legal basis you will process data in non-EU countries. In practice, this contract should be based on the **Standard Contractual Clauses** published by the EU, except that the most recent version was not yet updated for the GDPR. Tip: contracts are not generally subject to copyright so you can borrow parts of the data processing agreement from other services, but you will still need a lawyer to ensure the thing is legally valid in your jurisdiction (international contract law is a bit much for lay persons like us). * If you are a Processor you don't need to manage legal basis of processing and erasure requests yourself, you just need to **assist the Controller** (your client). In practice this should be some admin interface where data can be exported or deleted and so on. * The third party that you send emails through should be a (sub-)processor on your behalf. You need to sign a DPA with them as well. Note that if you are a Processor, you can only change subprocessors with the Controller's consent. In practice this means that you'd alert them a month in advance and they can either accept the change or quit your service. * Despite not being a full Controller you still have compliance obligations like keeping **Records of Processing**, essentially a table where you list all the kinds of processing you perform. Small companies are usually exempted from this, but it's a good tool anyway and you aren't exempted as the data processing is not occasional. * As a processor, you do not need a **legal basis** for processing because you are merely performing processing on the controller's behalf at their explicit instruction. Were you to need a legal basis, **consent** shouldn't be your first choice. Instead, **legitimate interest** is often better, though that first needs a check where the data subject's interests and rights must be balanced against the controller's legitimate interest. * The **right to be forgotten** can be tricky. To what degree it has to be honoured depends on the legal basis for processing (e.g. you can't keep any data if the basis was consent, but you may not have to honour the request at all if there is an overwhelming legitimate interest to keep the data anyway). Deleting metadata by assigning the items to “deleted user” can be a good choice. A pseudonym like “user123” can also be OK if the controller's legitimate interest requires that different items are still attributable to the same user. However, be aware that pseudonymous data is still personal data! There might also be personal data within the user-generated content, not just the metadata. * Whether you are controller or processor, you have various basic obligations such as taking **appropriate organizational and technological measures** to ensure the security of processing. Measures should be proportional to the risks you face. You have a lot of leeway here to use your professional judgement, as long as you can explain your choices. * Encryption in transit like TLS/HTTPS is a minimum baseline that can be expected for any website. * Encryption at rest is more debatable, but storing your database on an encrypted filesystem is a clear best practice. To which degree this is possible also depends on your cloud provider. * Organizational measures include things like controlling which persons have access to the database, and your internal processes you use. * If you log in through your laptop, how do you protect the keys on the laptop? Passwords, full disk encryption, password managers… Threats might include generic spyware through viruses, APTs that are targeting your clients, or simple theft of your hardware. * Security of processing does not only mean preventing unauthorized access/Confidentiality, but can also imply ensuring the Availability of the personal data (compare the C-I-A triad). This is not only a contractual SLA question, this is also a GDPR compliance question. For example, you may need to take frequent backups to ensure some amount of availability. Again, use your professional judgement.
1
As an American and small business owner, I have no problems with most of the privacy regulations. It's the 'right to be forgotten' bit that I take issue with. It's onerous and probably not feasible for small companies. My site has millions of individual HTML pages for mailing list archives dating back to 1995. Everyone who has their messages in the archives gave consent, but now, if somebody changes their mind I have a *ton* of work to do. I have to search through all of those files and find which ones have their information. Then I have to remove those files and update all of the HTML pages that link to them. These aren't in a fancy database where I can just change a link -- this is raw HTML from the early days of the web.
1
As people have pointed out the human mind is clearly out of scope. But if I'm understanding this correctly the argument is that of the former employee then writes this PII into an in scope system like a file system or database then the original employer in some how at fault. This isn't the case since the data was exfiltrated through an out of scope means. That being said proving this would be difficult if a employee with a very good memory, the right access to data prior to leaving a post and a grudge could expose PII public on say pastebin and there is no way to prove how that data was exfiltrated. In these cases the company would have to fall back on to it's GDPR compliance documentation and data security documentation to prove its not in the wrong. One final note if the employees new employer was found holding PII they didn't have the right to hold then the new employer would definitely be in the wrong.
1
At the end of the day it will be Google (to stay at that example) that has data in their database, which require consent, but to which no one has the consent. I'm no lawyer, but I don't thing that judges will care how they got into their database specificly. I can't imagine "but they promised not to deal with anything E.U. related" would be a valid defense in court.
1
BAU - Business as Usual - the people who will have to cope with any changes you might make as a consultant after the GDPR "push" is over and it becomes a set of embedded processes. I've done this three times for 2000, 4000 and 500 staff. In the larger companies we had a lot of databases and different types of data processing - most of it "sensitive" data. We had in the end about 10 Excel files, each one with about 10 tabs for each business area. However, we shared data with around 1000+ processors - each one required a Data Sharing Agreement!
1
be aware: they rip all your contacts to add to their database! So you share your contacts lists with them. ​ [Website](https://findnumberapp.com/en/about) [google play store page](https://play.google.com/store/apps/details?id=com.poztech.numberfinderapp&pageId=none) I don't know if they are on Apple devices
1
But do I have to geo-restrict the data to the EU? We have a prod database that lives on AWS in Canada. We'd like to continue to store personal data in the database that lives in the Canada region. Anything involving keeping specific data in databases in specific physical regions is overly complicated and we'd like to avoid this if possible.
1
But the IMDB is not a database of famous/public/celebrity people - it is a database of people involved in the movie/tv business of which the original post apparently was in the past.
1
Change management could simply be a documentation update. If you just want to be able to react to your database change, you can't simply avoid the need of an Impact Analysis... Which must be done prior to the change, with the DPO preferably. So change management will be a must, and an update to all processes to assess whether a full DPIA is required before starting coding. Now all depends on how you manage your internal processes, you might probably already have a change management process in place to ensure that new code don't break anything that already works. In that case, update the process to remember to use a DPIA when needed.
1
Dont think EU has no control of over you. The law is setup in such a way to protect EU citizens from any company using their personal information. If you have a small business or only a small portion of your customers comes from EU, you are probably right. However, consider this. It only needs one customer to ask his information to be removed from your database. And how are you going to answer him? By not replying? That won't look good. If you invest a day into this subject, you have the basic answers and you can professionally answer any incoming question from a customer.
1
Email is more straightforward than calls, since ePrivacy limits your options. If these are previous customers then you'd have to give them a clear opportunity to opt out at the time you collected their details. If you did that and they didn't opt out then you're likely to be OK, as long as there's an unsubscribe option in any message you send. If they're not previous paying customers then you can't email them without consent. The ICO suggests that legitimate interests can be an appropriate basis for marketing calls as long as there has been no opt out and the number isn't registered with TPS. However, you then need to consider the balancing test. The ICO loosely paraphrases this as considering whether people would expect you to use the data in that way, and any potential negative effects your marketing could have on the recipients. In general, a one-off "we're just working through our database checking if you're still interested" call might be OK, but if you work at a casino then calling or emailing lapsed customers might be a brilliant way to cause recovering gambling addicts to relapse. If you offer payday loans then contacting people who haven't taken a loan in a few months might perfectly target those people who are just getting their finances back in order and cause them to fall back into a cycle of spending money they can't afford.
1
Error: SQLSTATE\[HY000\] \[1044\] Access denied for user 'u685279342\_argo'@'localhost' to database 'u851190737\_argo' Since I'm unable to read the article, I'll just say that the data subject has a lot more rights under GDPR, which suggests a lot has changed.
1
Exactly. This works the same way for the situation where someone asks to have their Personal Data erased from someone's database. You need to record that you erased that subject's data, so you need to keep some identifiable record of it. There's even an article that talks exactly about that exception (can't remember which). Btw, the "Cookies' law" was set before the GDPR.
1
First, don't worry: the GDPR is not about catching small fish, but about containing abuses. If you are at peace with what you do with your customer files and your payroll data (the 2 main sensitive databases in a regular company), you won't get much more than a few sweats if by extreme bad luck you get audited. The only thing that could be sensitive in a regular company is if marketing is doing some borderline things with the customer data, such as reselling it or crossing this data with other datasources behind the back of the customers. This used to be tolerated, but requires caution to do right now. Next, you should still take the issue responsibly and proceed to actually trace and understand what is being done with personal data in your company: what data you collect, who controls it, how is it stored, what processes you run on it, and what safety/emergency procedures you have to contain security risks. This sort of internal audit is usually useful in all cases. But first of all, your company should designate a Data Protection Officer (DPO), who will oversee the whole compliance process and be responsible for it. This person can train herself in just a few hours of browsing the web, there not much to know unless you work with sensitive data. And, depending on the size of your databases, assuming a mid-sized company with 100 employees and a few 1000's of customers, plan a few days of work doing the audit, then a few hours every other month to ensure you stay clear in the law.
1
For the record. i am not a laywer. Just a guy making his living in giving aid to companies who struggle with GDPR. The GPDR excludes data for personal and household use. With household, think of your hobby's. If you use business card for personal use. No problem. You don't need consent. Just like the contacts \(names and numbers of other people in your phone. They are for personal use. However, if you store them in your company CRM database with the purpose to share information with your colleagues, this data is subject to GDPR compliance. And you need their consent. This leads to a strange catch22 situation, that **before** you accept the business card you need their consent to process their information. \(???\) To solve this, i use common sense. \- The business card is given out of free will, with the expectation that you use the information to contact him/her \(the intent is clear\) So you could argue there is implicit consent for you to process the information. =\> In court this will not hold, since formally you need explicit consent. \- I have no direct financial gain in storing the personal data =\> not a solid argument, since in a business environment the contact exchanged to create some financial gain, possibly on both sides \- If there is a contract between their company and yours, one could argue that this kind of data refers to the consequence of fulfilling the contract and thus part of the informationprocessing agreement which you needed anyway. \- in Dutch law there is a clause 'redelijkheid & Billikheid', roughly translated as "reasonableness". The means for a heavy GDPR procedure is not in balance to the risk of a business card abuse. So a lightweight process should arguable be sufficient. For example: I don't have formal consent, however the use and access to the CRM database is part of our regular IT security policy. And therefore I have reasonably done my best to comply to GDPR. Feel free to comment.
1
from the perspective of the company that owns the old database.
1
GDPR breaches mean loss of confidentiality, integrity or availability of personal data of natural persons residing within the borders of the EEA. Breaches are reportable if they impact on the rights or freedoms of data subjects. So for example, a hack of a database leading to ID Theft of customers is a reportable breach. If a hospital copies medical records to a USB stick, and it's lost in the post, that's a reportable breach. If a rogue employee deletes personal data of fellow employees without authorization or permission, that's a reportable breach. If you need more help, ask about paid consulting.
1
Good question! I don't think a Geo IP from Europe would result in different results, as the results are based on the response of the website. I am using a droplet from Digitalocean in the AMS3 (Amsterdam) data center. I am assuming you are referring to a result you've got from an Geo IP lookup database. Unfortunately Geo IP databases are often not updated in real time. You can see via [https://ping.eu/traceroute/](https://ping.eu/traceroute/) that the server is located in the Netherlands.
1
Gotcha. I come from old school mysql and its' been years to that effect to forgive me for butchering this. So in this case you have another database (or table) that just holds deletion requests? And when you restore the main database (say your customer lists) from old backups, you run a script to delete anything in the body of data that's list in this table/database. Ok, but the point of deleting data, or the right to erasure is so that the organization no longer has access to your old data. Right? So effectively, your organization still has access to the old data. I mean I can see if this is automatically done by a service provider like Salesforce, but what if your database in-house?
1
Great reply, thank you! Would you say the same applies to an otherwise anonymous IP recorded to the WordPress database by a security plugin \(like Wordfence or Sucuri\)? Also, if the server\-log or security\-plugin record includes the User Agent string, along with the IP \(as many do\), does that change anything?
1
Guess you'd need to implement a 'quick and dirty' temporary cover up solution here, especially if your company's blocker is development availability time. A potential suggestion could be to make a GDPR compliant duplicate of this database, and host it on a GDPR compliant server, even if this duplicate would be non functional for the system it's supposed to support; for now it can rely on the actual DB(the non compliant one) Consider it a decoy DB. In case that anyone comes knocking at your office door; you point out this DB. Most likely the first audit team will not be technical minded. Be warned tho; if they send in a technical audit team they will end up finding the old DB, so you should still try and keep pushing for the actual nuke.
1
Have a privacy policy, clear and transparent information on why you keep the information for how long and who you share it with if anyone. Have a dedicated simple update information function, subject access request with proof of identity procedure, unsubscribe function. Don't email someone if it's not account related, like for marketing unless they specifically subscribe for it. Encrypt all PII in your database and increase server security if you can. Check where you server is located if you don't directly host it... is it even in the EU? Secure your db back ups also. Write up simple docs in case you face an audit in the future to show your logic, procedures, security, SAR handling plan, data removal plans, priviacy policies etc. Take steps toward compliance at the very least.
1
He said 25% was foreign and very low from EU. So basically just a tinny little part of that 25% was from EUROPE. “something that sounds dead simple to fix”. Since it’s so dead simple to fix you can go ahead and fix it for him them and viola problem solved. Like seriously it’s something he does in his spare time and I don’t recall him saying he serves ads on his website so why should he waste money trying to comply. He website is probably more secured than some European government databases. “But hey, rather block 25% of your web traffic”. Thesame way you have the right to be forgotten because it’s your data, he has the right to block whatever region he wants because it’s his website. It goes both ways don’t expect to get something without giving away something. There are other big economies in the world that he can tap into.
1
Here are some recommendations; 1) Create a list of ALL data that you have (e.g name, address) 2) A- Create a flow of where what data is coming from (e.g website, email) B- List who is proving the data, is this the user himself, or another firm/source that provides the data? 3) Create a flow where the data is stored, and with who it is shared (e.g database, laptop) (Finance team, lawyer firm) 4) Check which legal base of processing your companies are under (e.g consent, contract obligations) Based on the above you can quickly see where are your risks that need to be fixed. Keep in mind the information gathering can either be quick or take months depending on the size and age of your companies, but these are absolutely necessary steps to get you started.
1
Hidden fields are essentially exactly the same as text boxes, fully editable on the clients machine. Except that you need to be very slightly IT literate to mess with them, because they are 'hidden'. https://chrome.google.com/webstore/detail/hidden-form-finder/adglgkhcpfdcocgekhbkghpajnbgcekd?hl=en Is just 1 example of how someone who is only barely aware of extensions could mess with it. If you must use a hidden field, using the hidden field to store an ID that links to the content in a database would be better, as then if people mess with it, they can only mess with it to another valid value if they already know it. Where as if the whole text is in a hidden field, I could easily change it to "I agree to give my unborn babies to AfterMorningCoffee in exchange for free fake news" The chance is lower if it's just a javascript post request, as they would need to be seriously hunting in your scripts in order to mess with you. But if you want the safest answer, Store the date the 'campaign' started, store the date the 'campaign' ended, store the type of campaign e.g. email, website etc, store the text used / language presented to the user in case of localization. Then link the users consent to a campaign id. Then in case of a dispute, you can say, Between x date and y date, we were running the following campaigns. 1,2,3,4 You agree'd to 3, which had the following text in this language on this date. That looks a lot more professional then, "User consented their email address to us on the 25th December 2015, the text was: 'Im a smart ass hacker messing with your scripts lol'" And you can validate that it's at least a valid campaign, and reject the consent if the ID doesn't match. The fool proof method, would be having a session id of some kind, record what campaigns you **showed** to the user. and then validate that they consented to one that's been shown. But most of this is probably hypothetical overkill for something that is just covering your ass in case of a dispute, and unless you are running some really dodgy sign ups, probably more effort then it's worth considering the extra data you would need to store, which is what this whole mess is about anyway.
1
https://au.godaddy.com/whois/results.aspx?domain=youtube-nocookie.com Domain Name: YOUTUBE-NOCOOKIE.COM Registry Domain ID: 1538936882_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.markmonitor.com Registrar URL: http://www.markmonitor.com Updated Date: 2017-12-22T10:31:31Z Creation Date: 2009-01-23T20:25:05Z Registry Expiry Date: 2019-01-23T20:25:05Z Registrar: MarkMonitor Inc. Registrar IANA ID: 292 Registrar Abuse Contact Email: abusecomplaints@markmonitor.com Registrar Abuse Contact Phone: +1.2083895740 Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited Name Server: NS1.GOOGLE.COM Name Server: NS2.GOOGLE.COM Name Server: NS3.GOOGLE.COM Name Server: NS4.GOOGLE.COM DNSSEC: unsigned URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/ >>> Last update of whois database: 2018-06-18T08:13:28Z <<< Whilst the name servers currently point at google, I don't trust registrar. edit youtube.com: Domain Name: YOUTUBE.COM Registry Domain ID: 142504053_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.markmonitor.com Registrar URL: http://www.markmonitor.com Updated Date: 2018-01-14T10:29:29Z Creation Date: 2005-02-15T05:13:12Z Registry Expiry Date: 2019-02-15T05:13:12Z Registrar: MarkMonitor Inc. Registrar IANA ID: 292 Registrar Abuse Contact Email: abusecomplaints@markmonitor.com Registrar Abuse Contact Phone: +1.2083895740 Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited Domain Status: serverDeleteProhibited https://icann.org/epp#serverDeleteProhibited Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited Domain Status: serverUpdateProhibited https://icann.org/epp#serverUpdateProhibited Name Server: NS1.GOOGLE.COM Name Server: NS2.GOOGLE.COM Name Server: NS3.GOOGLE.COM Name Server: NS4.GOOGLE.COM DNSSEC: unsigned URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/ >>> Last update of whois database: 2018-06-18T08:19:14Z <<< After more research on markmonitor, it may be legit?
1
I am just staring into the GDPR field as well. The first things that I am concerned about are structured vs unstructured data and the relevant PII concerns. There are tools from the big vendors that deal with unstructured data and content conversion plus indexing. The biggest problem I have run into is that legal teams do not have a comprehensive set of rules that define PII over other data. I would like to see the larger firms define regular expressions and policies that define what constitutes the relevant PII vs would need to be removed. Then from an IT perspective rules/policies can be created that help govern what classifies as what would need to be removed. Conversation need to be had at the Legal Team/CEO level what constitutes what should and should not be removed. Once the above has been determined, policies for unstructured data classification can be defined and dealt with. The structured data (I.e. Database applications) can be well defined by their developers and measures put into place where that data can be removed upon request.
1
I believe you can store such requests' associated data in a separate security database. That would be for security purposes only (legitimate usage) and therefore compliant. It all comes down to usage though, and whether your particular case might need such a protection. ICO UK suggests that you should retain a skeleton of the original deleted data (otherwise you can't even tell if it was ever deleted, or be there in the first place). So that's one way to go. However if you believe in your particular case that "forgotten" requests might end in a security issue, and/or that you need to protect your firm from such issues, you can move the data from your clients' database (for example) to the security database and keep that "in the locker". Nobody will market or share that data anymore, in the original context the data IS deleted. But it will be available as per a security context only. Just keep the minimal amount of data you need and for a feasible time period, and store it very carefully and encrypted. You can also hash the entry (for example by person's name, IP or whatever your master identifier is) and therefore you can only access it if you use the original identifier in the first place (I've seen people already hashing emails like that). If a security event occurs, you will be able to access that data as to solve the security issue, but NOT as the original usage for which you had consent. It should be within your legitimate usage rights if used solely for security. GDPR should not be seen as an anti-security law. There is a trade-off between privacy and security, and we just have to set the fine line in the right place.
1
I concur with @NoUserLeftException \- an addition to this is that if you do send e\-mails to your users \(e.g. Direct Marketing\), you do need to obtain consent if you have not previously obtained consent from your users. This **also** applies for current customers, because you have not enabled customers to opt\-out at the moment of sales \(i.e. untick a checkbox for consent\). If you don't obtain consent from your customers for direct marketing, then you should delete their records from your direct marketing database, only.
1
I contacted Sophos about a firewall, one of their resellers contacted me regarding that lead, which is fine and expected. A few days later I start getting invitations to their gdpr webinars. These continued despite my attempts to unsubscribe, it took a series of tweets showing screenshots of the while sequence to get removed from their databases. The irony was not lost on me
1
I didnt think GDPR covered anyone but EU citizens. That means that a US citizen in an EU database only has the protections of US law. Right? I dont suddenly become an EU data subject by having my bytes pass through their servers.
1
i do have everything on the privacy policy but i cant be sure there is no one that i know that can check it my website is on en and heb i cant be sure if i will have eu i know i will have mosly israeli players but eu i dont really know i live in israel and will host the website on israel like the game server are host on eu i cant really be ompliant because its just game server that playing in it nothing much yes its log ip but this is mosly game server work its log it on the database for bans and sercurity and i dont know what the game server host collect i want to try to be compliant but there is no one that can help me i did privacy policy and tos i still doing but there is no one that can really check it if i did it good i dont really want to get fine or problems with the gdpr i see alot of israeli communtiy that have eu players but they just dont care about it
1
I do keep a complete history of user agreement version along the text and date in my database, for the sake of traceability. if a user accepts a specific version say 1.0.0, until he renew his account if there is newer version at the time of the renewal then that newer version will be the one that he has to agree to.
1
I don't see how the identifiability of the pseudonym is relevant, except at the margins. The fact that there is a pseudonym at all, which is persistent, likely makes the account Personal Data, and therefore subject to GDPR. A numeric identifier that doesn't mean anything is personal data according to GDPR if the controller can use that number to look up more info in a database. It is possible to legally refuse authenticated data deletion requests in several circumstances. The most common is Overriding Legitimate Interest, which is a very fuzzy and flexible term, but "fraud detection" is specifically included. Ongoing performance of contract is another. Unfortunately, there's almost no guidance (other than "fraud detection") what counts as valid overriding legitimate interest. A controller is required to balance the privacy of the data subject against their own legitimate interest. So the fact that the username is more identifiable may nudge that towards redacting the username, but it may not, depending on the circumstances. No one can hazard a guess unless you provide more info about the service, and what reasons the controller may have given for refusing the deletion request. A controller can also selectively delete some data, but retain other data they consider more important or less sensitive, in order to fulfill their overriding legitimate interest.
1
I have a privacy policy and ToS (which will need to be updated due to GDPR) but it is on a website which players who happen to join my game server may not ever visit. As of now no one else has access to the server or database and I don't expect that to change. I don't even have e-mail addresses, only IP addresses and in-game nicknames. I could maybe hash IPs so that I should be able to check if they match but I won't store the actual IP address. But I'd still be storing the results from geolocating the IP, so not sure hashing just the IP in the database/logs would make much of a difference.
1
I have the same question. I don't collect any data, not even analytics and use only admob. I don't have external servers or databases and use sharedpreferences to store local info. I have a consent dialog that informs the user about the terms of usage which exits the app if does not agree with the them.
1
I need to do more reading on this as I hadn't even considered customers, thank you. We have some spreadsheets with their outstanding orders. And a database with prices and part numbers.
1
I really like the idea. I’ve been working on making a web app that leads you through becoming compliant. It allows import of all database fields for you to categorise. Then add processes, retention etc. etc. Then it creates the complete human readable policy for you. Maybe you and I should team up. If we joined the two together we’d have a very good sales funnel. Start with yours. They find they are not compliant. Then pay monthly for the tool that generates 100% compliant statements. We could work on cookie policies etc too. What do you think?
1
I suppose that being in a database makes it a bit harder to argue that asking you to search the data is excessive, but otherwise the same applies. I don't think adding the user agent changes anything either, since we've assumed that the IP alone may be enough to identify a user.
1
I think google analytics stores a partial IP to get around it. The good thing about hashing is its one way unlike encryption. That's why passwords are hashed in databases. Hashing an IP can't be undone; meaning the value you get from hashing looks nothing like an IP and you can't use that value to get the IP back.
1
I think it depends on which type of cookie it is. I doubt that this text is GDPR compliant since they mix up different types of cookies. ("cookies for better browsing experience", "cookies for targeted advertisements",...) See this article: https://www.cookiebot.com/en/gdpr-cookies/ In addition, always when you need an opt-in, you have to comply with Art.7(1) (source: https://gdpr-info.eu/art-7-gdpr/) >>Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data. That means you need some kind of consent database.
1
I think it would be better. Like I said, if it is in the same database and that database is restored, you lose the updates since the last backup, effectively wiping your record of processing and then breaching if the data is restored with no further follow\-up.
1
Hi thanks for the comments. We are based in the United States and write primarily for US based audiences. Nonprofits in the US have some leeway here, unless they are specifically marketing to EU residents. From Forbes: https://www.forbes.com/sites/forbestechcouncil/2017/12/04/yes-the-gdpr-will-affect-your-u-s-based-business/#3cff04d66ff2 "The organization would have to target a data subject in an EU country. Generic marketing doesn’t count. For example, a Dutch user who Googles and finds an English-language webpage written for U.S. consumers or B2B customers would not be covered under the GDPR. However, if the marketing is in the language of that country and there are references to EU users and customers, then the webpage would be considered targeted marketing and the GDPR will apply. Accepting currency of that country and having a domain suffix -- say a U.S. website that can be reached with a .nl from the Netherlands -- would certainly seal the case." Note: Nonprofits that collect donations online will have a lot of sensitive financial information in their database, and even if they are not required to follow GDPR guidelines for their US based donors, they should be very careful to take extra steps to protect this information.
0
I suspect you are out of luck. A quick glance at the GDPR seems to allow for databases like the IMDB to exist, see I think Chapter 3/Section3/Article17/3(d) though I am not a lawyer.
0
**Privacy policy** **1. Introduction** 1.1 We are committed to safeguarding the privacy of our website visitors and service users. 1.2 This policy applies where we are acting as a data controller with respect to the personal data of our website visitors and service users; in other words, where we determine the purposes and means of the processing of that personal data. 1.3 We use cookies on our website. Insofar as those cookies are not strictly necessary for the provision of our website, we will ask you to consent to our use of cookies when you first visit our website. 1.4 Our website incorporates privacy controls which affect how we will process your personal data. By using the privacy controls, you can \[specify whether you would like to receive direct marketing communications and limit the publication of your information\]. You can access the privacy controls via *\[URL\]*. 1.5 In this policy, "we", "us" and "our" refer to *\[data controller name\]*.\[ For more information about us, see Section 13.\] **2. Credit : https://securign.com** **3. How we use your personal data** 3.1 In this Section 3 we have set out: \(a\) the general categories of personal data that we may process; \(b\) \[in the case of personal data that we did not obtain directly from you, the source and specific categories of that data\]; \(c\) the purposes for which we may process personal data; and \(d\) the legal bases of the processing. 3.2 We may process \[data about your use of our website and services\] \("**usage data**"\). The usage data may include \[your IP address, geographical location, browser type and version, operating system, referral source, length of visit, page views and website navigation paths, as well as information about the timing, frequency and pattern of your service use\]. The source of the usage data is \[our analytics tracking system\]. This usage data may be processed \[for the purposes of analysing the use of the website and services\]. The legal basis for this processing is \[consent\] OR \[our legitimate interests, namely \[monitoring and improving our website and services\]\] O*R \[\[specify bas*is\]\]. 3.3 We may process \[your account data\] \("**account data**"\).\[ The account data may \[include your name and email address\].\]\[ The source of the account data is \[you or your employer\].\] The account data may be processed \[for the purposes of operating our website, providing our services, ensuring the security of our website and services, maintaining back\-ups of our databases and communicating with you.\] The legal basis for this processing is \[consent\] OR \[our legitimate interests, namely \[the proper administration of our website and business\]\] OR \[the performance of a contract between you and us and/or taking steps, at your request, to enter into such a contract\] O*R \[\[specify bas*is\]\]. 3.4 We may process \[your information included in your personal profile on our website\] \("**profile data**"\).\[ The profile data may include \[your name, address, telephone number, email address, profile pictures, gender, date of birth, relationship status, interests and hobbies, educational details and employment details\].\] The profile data may be processed for \[the purposes of enabling and monitoring your use of our website and services\]. The legal basis for this processing is \[consent\] OR \[our legitimate interests, namely \[the proper administration of our website and business\]\] OR \[the performance of a contract between you and us and/or taking steps, at you request, to enter into such a contract\] O*R \[\[specify bas*is\]\]. 3.5 We may process \[your personal data that are provided in the course of the use of our services\] \("**service data**"\).\[ The service data may inclu*de \[specify da*ta\].\]\[ The source of the service data is \[you or your employer\].\] The service data may be processed \[for the purposes of operating our website, providing our services, ensuring the security of our website and services, maintaining back\-ups of our databases and communicating with you\]. The legal basis for this processing is \[consent\] OR \[our legitimate interests, namely \[the proper administration of our website and business\]\] OR \[the performance of a contract between you and us and/or taking steps, at your request, to enter into such a contract\]* OR \[\[specify b*asis\]\]. 3.6 We may process \[information that you post for publication on our website or through our services\] \("**publication data**"\). The publication data may be processed \[for the purposes of enabling such publication and administering our website and services\]. The legal basis for this processing is \[consent\] OR \[our legitimate interests, namely \[the proper administration of our website and business\]\] OR \[the performance of a contract between you and us and/or taking steps, at your request, to enter into such a contract\] O*R \[\[specify bas*is\]\]. 3.7 We may process \[information contained in any enquiry you submit to us regarding goods and/or services\] \("**enquiry data**"\). The enquiry data may be processed \[for the purposes of offering, marketing and selling relevant goods and/or services to you\]. The legal basis for this processing is \[consent\] O*R \[\[specify bas*is\]\]. 3.8 We may process \[information relating to our customer relationships, including customer contact information\] \("**customer relationship data**"\).\[ The customer relationship data may include \[your name, your employer, your job title or role, your contact details, and information contained in communications between us and you or your employer\].\]\[ The source of the customer relationship data is \[you or your employer\].\] The customer relationship data may be processed \[for the purposes of managing our relationships with customers, communicating with customers, keeping records of those communications and promoting our products and services to customers\]. The legal basis for this processing is \[consent\] OR \[our legitimate interests, namely \[the proper management of our customer relationships\]\] O*R \[\[specify bas*is\]\]. 3.9 We may process \[information relating to transactions, including purchases of goods and services, that you enter into with us and/or through our website\] \("**transaction data**"\).\[ The transaction data may include \[your contact details, your card details and the transaction details\].\] The transaction data may be processed \[for the purpose of supplying the purchased goods and services and keeping proper records of those transactions\]. The legal basis for this processing is \[the performance of a contract between you and us and/or taking steps, at your request, to enter into such a contract and our legitimate interests, namely \[the proper administration of our website and business\]\] O*R \[\[specify bas*is\]\]. 3.10 We may process \[information that you provide to us for the purpose of subscribing to our email notifications and/or newsletters\] \("**notification data**"\). The notification data may be processed \[for the purposes of sending you the relevant notifications and/or newsletters\]. The legal basis for this processing is \[consent\] OR \[the performance of a contract between you and us and/or taking steps, at your request, to enter into such a contract\] O*R \[\[specify bas*is\]\]. 3.11 We may process \[information contained in or relating to any communication that you send to us\] \("**correspondence data**"\). The correspondence data may include \[the communication content and metadata associated with the communication\].\[ Our website will generate the metadata associated with communications made using the website contact forms.\] The correspondence data may be processed \[for the purposes of communicating with you and record\-keeping\]. The legal basis for this processing is \[our legitimate interests, namely \[the proper administration of our website and business and communications with users\]\] O*R \[\[specify bas*is\]\]. 3.12 We may process *\[identify general category of data\]*.\[ This data may include *\[list specific items of data\]*.\]\[ The source of this data is* \[identify source*\].\] This data may be processed f*or \[specify purpos*es\]. The legal basis for this processing is \[consent\] OR \[our legitimate interests, na*mely \[specify legitimate inter*ests\]\] OR \[the performance of a contract between you and us and/or taking steps, at your request, to enter into such a contr*act\] OR \[\[speci*fy basis\]\]. 3.13 We may process \[any of your personal data identified in this policy\] where necessary for \[the establishment, exercise or defence of legal claims, whether in court proceedings or in an administrative or out\-of\-court procedure\]. The legal basis for this processing is our legitimate interests, namely \[the protection and assertion of our legal rights, your legal rights and the legal rights of others\]. 3.14 We may process \[any of your personal data identified in this policy\] where necessary for \[the purposes of obtaining or maintaining insurance coverage, managing risks, or obtaining professional advice\]. The legal basis for this processing is our legitimate interests, namely \[the proper protection of our business against risks\]. 3.15 In addition to the specific purposes for which we may process your personal data set out in this Section 3, we may also process \[any of your personal data\] where such processing is necessary\[ for compliance with a legal obligation to which we are subject, or\] in order to protect your vital interests or the vital interests of another natural person. 3.16 Please do not supply any other person's personal data to us, unless we prompt you to do so. **4. Providing your personal data to others** 4.1 We may disclose \[your personal data\] to any member of our group of companies \(this means our subsidiaries, our ultimate holding company and all its subsidiaries\) insofar as reasonably necessary for the purposes, and on the legal bases, set out in this policy.\[ Information about our group of companies can be found at *\[URL\]*.\] 4.2 We may disclose \[your personal data\] to \[our insurers and/or professional advisers\] insofar as reasonably necessary for the purposes of \[obtaining or maintaining insurance coverage, managing risks, obtaining professional advice, or the establishment, exercise or defence of legal claims, whether in court proceedings or in an administrative or out\-of\-court procedure\]. 4.3 We may disclose *\[specify personal data category or categories\]* to \[our suppliers or subcontractors\]\[ identified at *\[URL\]*\] insofar as reasonably necessary f*or \[specify purpos*es\]. 4.4 Financial transactions relating to \[our website and services\] \[are\] OR \[may be\] handled by our payment services providers, *\[identify PSPs\]*. We will share transaction data with our payment services providers only to the extent necessary for the purposes of \[processing your payments, refunding such payments and dealing with complaints and queries relating to such payments and refunds\]. You can find information about the payment services providers' privacy policies and practic*es at *\[URLs\]. 4.5 We may disclose \[your enquiry data\] to \[one or more of those selected third party suppliers of goods and services identified on our website\] for the purpose of \[enabling them to contact you so that they can offer, market and sell to you relevant goods and/or services\].\[ Each such third party will act as a data controller in relation to the enquiry data that we supply to it; and upon contacting you, each such third party will supply to you a copy of its own privacy policy, which will govern that third party's use of your personal data.\] 4.6 In addition to the specific disclosures of personal data set out in this Section 4, we may disclose your personal data where such disclosure is necessary for compliance with a legal obligation to which we are subject, or in order to protect your vital interests or the vital interests of another natural person.\[ We may also disclose your personal data where such disclosure is necessary for the establishment, exercise or defence of legal claims, whether in court proceedings or in an administrative or out\-of\-court procedure.\] **5. International transfers of your personal data** 5.1 In this Section 5, we provide information about the circumstances in which your personal data may be transferred to \[countries outside the European Economic Area \(EEA\)\]. 5.2 We\[ and our other group companies\] have \[offices and facilities\] in *\[specify countries\]*.\[ The European Commission has made an "adequacy decision" with respect to \[the data protection laws of each of these countries\].\]\[ Transfers to \[each of these countries\] will be protected by appropriate safeguards, namely \[the use of standard data protection clauses adopted or approved by the European Commission, a copy of which can be obtained f*rom \[sou*rce\]\] OR \[the use of binding corporate rules, a copy of which you can *obtain f*rom* \[source\]\] OR \[\[specify appropriate safeguards and means to* obtain a copy\]\].\] 5.3 The hosting facilities for our website are situated in *\[specify countries\]*.\[ The European Commission has made an "adequacy decision" with respect to \[the data protection laws of each of these countries\].\]\[ Transfers to \[each of these countries\] will be protected by appropriate safeguards, namely \[the use of standard data protection clauses adopted or approved by the European Commission, a copy of which you can obtain from *\[source\]*\] OR \[\[specify appropriate safeguards and means to obtain a copy\]\]*.\]* 5.4 *\[Specify category or categories of supplier or subcontractor\]* \[is\] OR \[are\] situated in *\[specify countries\]*.\[ The European Commission has made an "adequacy decision" with respect to \[the data protection laws of each of these countries\].\]\[ Transfers to \[each of these countries\] will be protected by appropriate safeguards, namely \[the use of standard data protection clauses adopted or approved by the European Commission, a copy of which can be obtained f*rom \[sou*rce\]\] OR \[\[specify appropriate safeguards and means to obtain a copy\]\]*.\]* 5.5 You acknowledge that \[personal data that you submit for publication through our website or services\] may be available, via the internet, around the world. We cannot prevent the use \(or misuse\) of such personal data by others. **6. Retaining and deleting personal data** 6.1 This Section 6 sets out our data retention policies and procedure, which are designed to help ensure that we comply with our legal obligations in relation to the retention and deletion of personal data. 6.2 Personal data that we process for any purpose or purposes shall not be kept for longer than is necessary for that purpose or those purposes. 6.3 We will retain your personal data as follows: \(a\) *\[personal data category or categories\]* will be retained for a minimum period o*f \[perio*d\] followin*g \[dat*e\], and for a maximum period *of \[peri*od\] follow*ing \[d*ate\]. *\[additional list items\]* 6.4 In some cases it is not possible for us to specify in advance the periods for which your personal data will be retained. In such cases, we will determine the period of retention based on the following criteria: \(a\) the period of retention of *\[personal data category\]* will be determined based o*n \[specify criteri*a\]. *\[additional list items\]* 6.5 Notwithstanding the other provisions of this Section 6, we may retain your personal data where such retention is necessary for compliance with a legal obligation to which we are subject, or in order to protect your vital interests or the vital interests of another natural person. **7. Amendments** 7.1 We may update this policy from time to time by publishing a new version on our website. 7.2 You should check this page occasionally to ensure you are happy with any changes to this policy. 7.3 We \[may\] OR \[will\] notify you of \[changes\] OR \[significant changes\] to this policy \[by email or through the private messaging system on our website\]. **8. Your rights** 8.1 In this Section 8, we have summarised the rights that you have under data protection law. Some of the rights are complex, and not all of the details have been included in our summaries. Accordingly, you should read the relevant laws and guidance from the regulatory authorities for a full explanation of these rights. 8.2 Your principal rights under data protection law are: \(a\) the right to access; \(b\) the right to rectification; \(c\) the right to erasure; \(d\) the right to restrict processing; \(e\) the right to object to processing; \(f\) the right to data portability; \(g\) the right to complain to a supervisory authority; and \(h\) the right to withdraw consent. 8.3 You have the right to confirmation as to whether or not we process your personal data and, where we do, access to the personal data, together with certain additional information. That additional information includes details of the purposes of the processing, the categories of personal data concerned and the recipients of the personal data. Providing the rights and freedoms of others are not affected, we will supply to you a copy of your personal data. The first copy will be provided free of charge, but additional copies may be subject to a reasonable fee.\[ You can access \[your personal data\] by visiting *\[URL\]* when logged into our website.\] 8.4 You have the right to have any inaccurate personal data about you rectified and, taking into account the purposes of the processing, to have any incomplete personal data about you completed. 8.5 In some circumstances you have the right to the erasure of your personal data without undue delay. Those circumstances include: \[the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed; you withdraw consent to consent\-based processing; you object to the processing under certain rules of applicable data protection law; the processing is for direct marketing purposes; and the personal data have been unlawfully processed\]. However, there are exclusions of the right to erasure. The general exclusions include where processing is necessary: \[for exercising the right of freedom of expression and information; for compliance with a legal obligation; or for the establishment, exercise or defence of legal claims\]. 8.6 In some circumstances you have the right to restrict the processing of your personal data. Those circumstances are: you contest the accuracy of the personal data; processing is unlawful but you oppose erasure; we no longer need the personal data for the purposes of our processing, but you require personal data for the establishment, exercise or defence of legal claims; and you have objected to processing, pending the verification of that objection. Where processing has been restricted on this basis, we may continue to store your personal data. However, we will only otherwise process it: with your consent; for the establishment, exercise or defence of legal claims; for the protection of the rights of another natural or legal person; or for reasons of important public interest. 8.7 You have the right to object to our processing of your personal data on grounds relating to your particular situation, but only to the extent that the legal basis for the processing is that the processing is necessary for: the performance of a task carried out in the public interest or in the exercise of any official authority vested in us; or the purposes of the legitimate interests pursued by us or by a third party. If you make such an objection, we will cease to process the personal information unless we can demonstrate compelling legitimate grounds for the processing which override your interests, rights and freedoms, or the processing is for the establishment, exercise or defence of legal claims. 8.8 You have the right to object to our processing of your personal data for direct marketing purposes \(including profiling for direct marketing purposes\). If you make such an objection, we will cease to process your personal data for this purpose. 8.9 You have the right to object to our processing of your personal data for scientific or historical research purposes or statistical purposes on grounds relating to your particular situation, unless the processing is necessary for the performance of a task carried out for reasons of public interest. 8.10 To the extent that the legal basis for our processing of your personal data is: \(a\) consent; or \(b\) that the processing is necessary for the performance of a contract to which you are party or in order to take steps at your request prior to entering into a contract, and such processing is carried out by automated means, you have the right to receive your personal data from us in a structured, commonly used and machine\-readable format. However, this right does not apply where it would adversely affect the rights and freedoms of others. 8.11 If you consider that our processing of your personal information infringes data protection laws, you have a legal right to lodge a complaint with a supervisory authority responsible for data protection. You may do so in the EU member state of your habitual residence, your place of work or the place of the alleged infringement. 8.12 To the extent that the legal basis for our processing of your personal information is consent, you have the right to withdraw that consent at any time. Withdrawal will not affect the lawfulness of processing before the withdrawal. 8.13 You may exercise any of your rights in relation to your personal data \[by written notice to us\] OR \[by *\[methods\]*\]\[, in addition to the other methods specified in this Section 8\]. **9. About cookies** 9.1 A cookie is a file containing an identifier \(a string of letters and numbers\) that is sent by a web server to a web browser and is stored by the browser. The identifier is then sent back to the server each time the browser requests a page from the server. 9.2 Cookies may be either "persistent" cookies or "session" cookies: a persistent cookie will be stored by a web browser and will remain valid until its set expiry date, unless deleted by the user before the expiry date; a session cookie, on the other hand, will expire at the end of the user session, when the web browser is closed. 9.3 Cookies do not typically contain any information that personally identifies a user, but personal information that we store about you may be linked to the information stored in and obtained from cookies. **10. Cookies that we use** 10.1 We use cookies for the following purposes: \(a\) \[authentication \- we use cookies \[to identify you when you visit our website and as you navigate our website\]\[ \(cookies used for this purpose are: *\[identify cookies\]*\)\]\]; \(b\) \[status \- we use cookies \[to help us to determine if you are logged into our website\]\[ \(cookies used for this purpose are: *\[identify cookies\]*\)\]\]; \(c\) \[personalisation \- we use cookies \[to store information about your preferences and to personalise the website for you\]\[ \(cookies used for this purpose are: *\[identify cookies\]*\)\]\]; \(d\) \[security \- we use cookies \[as an element of the security measures used to protect user accounts, including preventing fraudulent use of login credentials, and to protect our website and services generally\]\[ \(cookies used for this purpose are: *\[identify cookies\]*\)\]\]; \(e\) \[advertising \- we use cookies \[to help us to display advertisements that will be relevant to you\]\[ \(cookies used for this purpose are: *\[identify cookies\]*\)\]\]; \(f\) \[analysis \- we use cookies \[to help us to analyse the use and performance of our website and services\]\[ \(cookies used for this purpose are: *\[identify cookies\]*\)\]\]; and \(g\) \[cookie consent \- we use cookies \[to store your preferences in relation to the use of cookies more generally\]\[ \(cookies used for this purpose are: *\[identify cookies\]*\)\]\]. *\[additional list items\]* **11. Cookies used by our service providers** 11.1 Our service providers use cookies and those cookies may be stored on your computer when you visit our website. 11.2 We use Google Analytics to analyse the use of our website. Google Analytics gathers information about website use by means of cookies. The information gathered relating to our website is used to create reports about the use of our website. Google's privacy policy is available at: [https://www.google.com/policies/privacy/](https://www.google.com/policies/privacy/).\[ The relevant cookies are: *\[identify cookies\]*.\] 11.3 \[We publish Google AdSense interest\-based advertisements on our website. These are tailored by Google to reflect your interests. To determine your interests, Google will track your behaviour on our website and on other websites across the web using cookies.\] OR \[We publish Google AdSense advertisements on our website. To determine your interests, Google will track your behaviour on our website and on other websites across the web using cookies. This behaviour tracking allows Google to tailor the advertisements that you see on other websites to reflect your interests \(but we do not publish interest\-based advertisements on our website\).\] You can view, delete or add interest categories associated with your browser by visiting: [https://adssettings.google.com](https://adssettings.google.com/). You can also opt out of the AdSense partner network cookie using those settings or using the Network Advertising Initiative's multi\-cookie opt\-out mechanism at: [http://optout.networkadvertising.org](http://optout.networkadvertising.org/). However, these opt\-out mechanisms themselves use cookies, and if you clear the cookies from your browser your opt\-out will not be maintained. To ensure that an opt\-out is maintained in respect of a particular browser, you may wish to consider using the Google browser plug\-ins available at: [https://support.google.com/ads/answer/7395996](https://support.google.com/ads/answer/7395996).\[ The relevant cookies are: *\[identify cookies\]*.\] 11.4 We use *\[identify service provider\]* to *\[specify service\]*. This service uses cookies for *\[specify purpose\(s\)\]*. You can view the privacy policy of this service provider at *\[URL\]*.\[ The relevant cookies are: *\[identify cookies\]*.\] **12. Managing cookies** 12.1 Most browsers allow you to refuse to accept cookies and to delete cookies. The methods for doing so vary from browser to browser, and from version to version. You can however obtain up\-to\-date information about blocking and deleting cookies via these links: \(a\) [https://support.google.com/chrome/answer/95647?hl=en](https://support.google.com/chrome/answer/95647?hl=en) \(Chrome\); \(b\) [https://support.mozilla.org/en\-US/kb/enable\-and\-disable\-cookies\-website\-preferences](https://support.mozilla.org/en-US/kb/enable-and-disable-cookies-website-preferences) \(Firefox\); \(c\) [http://www.opera.com/help/tutorials/security/cookies/](http://www.opera.com/help/tutorials/security/cookies/) \(Opera\); \(d\) [https://support.microsoft.com/en\-gb/help/17442/windows\-internet\-explorer\-delete\-manage\-cookies](https://support.microsoft.com/en-gb/help/17442/windows-internet-explorer-delete-manage-cookies) \(Internet Explorer\); \(e\) [https://support.apple.com/kb/PH21411](https://support.apple.com/kb/PH21411) \(Safari\); and \(f\) [https://privacy.microsoft.com/en\-us/windows\-10\-microsoft\-edge\-and\-privacy](https://privacy.microsoft.com/en-us/windows-10-microsoft-edge-and-privacy) \(Edge\). *\[additional list items\]* 12.2 Blocking all cookies will have a negative impact upon the usability of many websites. 12.3 If you block cookies, you will not be able to use all the features on our website. **13. Our details** 13.1 This website is owned and operated by *\[name\]*. 13.2 We are registered in \[England and Wales\] under registration number *\[number\]*, and our registered office is a*t \[addres*s\]. 13.3 Our principal place of business is at *\[address\]*. 13.4 You can contact us: \(a\) \[by post, to \[the postal address given above\]\]; \(b\) \[using our website contact form\]; \(c\) \[by telephone, on \[the contact number published on our website from time to time\]\]; or \(d\) \[by email, using \[the email address published on our website from time to time\]\]. *\[additional list items\]* **14. Data protection officer** 14.1 Our data protection officer's contact details are: *\[contact details\]*. **Free privacy policy: drafting notes** This is a standard website or web app privacy policy, which will help you to comply with data protection legislation, and has been updated for the General Data Protection Regulation \(also known as the GDPR\). This policy covers the following matters \(amongst others\): the collection of personal information; the use of that personal information; the legal bases for the processing of that information; disclosures of that personal information to third parties; international transfers of personal information; and the use of cookies on the website. This document might not be suitable for you if the ways in which you use personal information are complex or unusual. In any event, there are many aspects to data protection compliance. Publishing a privacy policy or statement containing the relevant information is only one aspect \- albeit an important aspect \- of compliance. **Section 1: Introduction** **Section 1.1** Optional element. **Section 1.2** "Personal data" is defined in Article 4\(1\) of the GDPR: "\(1\) 'personal data' means any information relating to an identified or identifiable natural person \('data subject'\); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person". **Section 1.3** Optional element. The inclusion of this statement in your privacy policy will not in itself satisfy the requirements of the Privacy and Electronic Communications \(EC Directive\) Regulations 2003 as regards consent to the use of cookies. Guidance concerning methods of obtaining such consent is included on the Information Commissioner's website \(http://www.ico.gov.uk\). **Section 1.4** Optional element. **Section 1.5** Optional element. **Section 2: Credit** **Section: Free documents licensing warning** Optional element. Although you need to retain the credit, you should remove the inline copyright warning from this document before use. **Section 3: How we use your personal data** Article 13\(1\) of the GDPR provides that: "\(1\) Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information: ... \(c\) the purposes of the processing for which the personal data are intended as well as the legal basis for the processing; \(d\) where the processing is based on point \(f\) of Article 6\(1\), the legitimate interests pursued by the controller or by a third party". Article 6\(1\)\(f\) of the GDPR provides that: "\(1\) Processing shall be lawful only if and to the extent that at least one of the following applies: ... \(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." **Section 3.1** Article 14 of the GDPR, which applies where personal information is not obtained from the data subject, provides that information about "the categories of personal data concerned" must be supplied to data subjects. Article 13 of the GDPR, which applies where personal information is obtained from the data subject, does not include an equivalent provision. Nonetheless, we have included references to general categories of data in this document, because this facilitates the identification of particular purposes of processing and the legal bases of processing \- information which
 
body
score (Sum)
IT Ops Topic: Penalty
Showing 26 rows, 1 columns
body
score (Sum)
>> There should be nothing onerous for a small business. A redesign of the system landscape is not onerous? ("Privacy by design") The research a one-man-show has to do for the gdpr changes is also not onerous? What about the concepts and all the bureaucracy you have to do (like all the mandatory documentation). What about the costs? If you have a question to a lawyer, it's from 350€ upwards. If you have multiple questions, you could pay very quickly, 2000€ or more. Since two months, I cannot proceed with my work because of gdpr and I'm still not finished. I already thought about cancelling all my work of the last 3 years because all this anger isn't it worth. Luckily, our government had weakened the gdpr in our country a little bit (warning instead of penalty and so on). I hope that EU will not fuck our country for this. Data privacy yes, but one can overdo it. And as you can see, exactly the small ones are upset while Google has no problem to reorganized their whole privacy data infrastructure and products (whereby they are still not finished, see for example AdMob).
6
*On the 21st of January 2019, the CNIL issued a penalty of 50 million euros against GOOGLE LLC under the GDPR for lack of transparency, unsatisfactory information and lack of valid consent for the personalisation of advertising.*
5
Definitely against GDPR as you know where and when an individual is going to be present there. You'd have thought the booking software company would want to fix it as they are going to lose customers if they don't! You could complain to the gym first in writing so it's documented (rather than the chats you've had so far) and say that it's in breach of GDPR and will be reported to your data protection department if they don't fix it. (If it's a chain of gyms, CC in the headquarters as that'll probably help more.) You should then contact your data protection agency for your country if they refuse to do anything as they are willingly breaking the law then. Penalty could be up to 4% of turnover but would probably be a lot less as it's not overly sensitive data (and you can only see the data if you're a member yourself) and then it would have to escalate get to that stage first. The threat of a fine is what gets businesses moving, not the fine itself!
4
https://www.twobirds.com/en/in-focus/general-data-protection-regulation/gdpr-tracker/penalties Administrative fines as prescribed in the GDPR are not permitted under Danish law. Fines will be imposed by the courts as a criminal penalty. However, the Danish Supervisory Authority may impose administrative fines in uncomplicated cases, where the person accused of the violation pleads guilty and agrees to pay the fine.
4
Some problems: Question 1) There aren't a definitive 'number of steps' to become GDPR compliant. You can cut that cake into a number of pieces, and it's a different cake for each business. 2) The *maximum* penalty is either 2% of annual income or €10M (whichever is greater), OR 4% of annual income, or €20M, depending upon the type of violation. 3) 'Avoiding a breach' and 'protecting citizens' are two parts of the same thing. If citizens' data is stolen, then that's a violation of privacy. 4) I'm not taking this stupid quiz any more.
4
It’s all about passion, if it’s not there it can be a boring job. When I joined the privacy team at my company I got a significant pay rise but a significant drop in position, now I am one of the team working under the DPO. I often stand in at meetings for her due to my experience and the best feedback I have had is about my passion about the subject and ability to make it less boring. Try have a bit of fun with it, I always like to open meetings with a bit of a dig at the law and, if I have one, a little story about a piece of case law, a penalty or something from my own experience. As long as the basics are right, a bit of comedic licence helps increase interest.
3
Thanks pperca. * A 4% penalty on total revenue for a website in the US being sued by an EU entity? Whew. That is far-reaching and unfair, but whatever thanks for the clarity on that. * When GDPR becomes global I'll address it. I'm worried about user disruption know what I mean? I don't want my clients to have to click any button. Know what I mean? * Yes, I'm going to address set up a privacy policy. * No we don't do online payment. We are an auto repair business. * Right, a clear Terms of Service page with an "I agree" button.. ok.. The problem is it'll be a page linked from the footer. Nobody will read it and nobody will click the button. * In respect to GDPR not applying to my business. I'm reading over and over again that it does apply because there's always that chance that 1) A site visitor could come from the EU. 2) A physical customer could be visiting the USA on a visa and come to our shop. Now I'm getting mixed signals.... UG! * I agree that getting hit with a fine is small. Attorneys don't wait for business they look for it and you know they are salivating over GDPR. Its a money maker of epic proportions. Maybe not now but later. Trust me.
3
Yes, it affects free site owners too. They can impose a financial penalty which is not based on revenue... and under UK law, directors of companies (or owners of services) are personally liable. For example, UK charities are not exempted from GDPR.
3
> Hello, does GDPR apply to individual small site owners that have free sites? Yes it does if you process or store PII (Personal Identifiable Information) > I have a website where people can register and post advertisement listings for free, the entire site is free and there is no payment for anything. No payment does not exclude you from GDPR (otherwise Google would be excluded too.) > I am not a business or organization, does GDPR still apply to me? GDPR does not apply to people processing personal data in the course of exclusively personal or household activity. (So yes it still applies to your website.) >if yes how would they fine a site for 4% of annual income if there is 0 income? The maximum penalty is 20 million euros or 4% of annual revenue (cashflow) **whichever is higher.** Note that this is the maximum penalty, which I suppose is for repeatedly offenders. > I googled it and weirdly there is absolutely no info about this If you try to find information that you are exempt from GDPR, than that is something you will not find. As you state in other post you process email addresses. As I assume these email addresses are used to login to the site (where login allows you to add/edit/remove posts.) One could argue that the email address is functionally required for the user to make use of the site functionality. One of the exceptions is: > 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; > Does Google Analytics counts as storing personal data? since i can't identify someone through GA. As I have understood Google Analytics itself does not contain PII, but if you can combine GA data with other data (E.g. the forum userid) then it is. > Am i liable if users publish personal info like phone number in listings that can be viewed by anyone? I don't know. One could argue that if persons publish their own PII that this counts as explicit consent. However I don't know if this is according to the letter of GDPR. The most I would worry about GDPR is the "right to be forgotten", can a user remove all their (PII) data from your site.
2
It's very unlikely a regulator will come after you for a first mistake, or even consider issuing a penalty against a small organization without numerous opportunities for that organization to reform its ways. The main target is big organizations; however, that hasn't stopped the understandable panic and for that the EU is squarely responsible. It hasn't been anything like forthcoming enough about how it affects smaller organizations - they only want Facebook, Google, et al.
2
You can't sue them because it is up to the authorities to find them either compliant or non-compliant, and in the case of non-compliance to determine the penalty. You can only report them to the authorities to alert them of possible non-compliance. [Article 77](https://gdpr-info.eu/art-77-gdpr/) grants you the right to report non-compliance. Article 82 states that the authorities will only you award you compensation if you suffered damages.
2
> "While this still doesn’t match the GDPR’s standard of such a fine (4% annual global turnover) it shows that DPA’s are taking matters seriously." It is a maximum penalty. It can obviously be less, based upon the circumstances of the specific case.
1
> A 4% penalty on total revenue for a website in the US being sued by an EU entity? Whew. That is far-reaching and unfair, but whatever thanks for the clarity on that. That's max. They don't start there. That's only for egregious situations where all attempts to ensure compliance have been met with a thumb to the nose.....
1
Basically I'm trying to find evidence that the university after disproportiantely with regards to my penalty for academic misconduct. As such I want to see the outcome letters for all cases of academic misconduct within the last 3 years I was at university. The personal data in the outcome letter would be the names of students and their student ID and I have asked for this to be redacted so they can not be identified.
1
I think you should checkout this blog as well [https://www.compliancehome.com/french-cnil-data-protection-agency-sanctions-google-with-e50m-penalty-for-gdpr-breach/](https://www.compliancehome.com/french-cnil-data-protection-agency-sanctions-google-with-e50m-penalty-for-gdpr-breach/) as I've found this blog best of GDPR data breach penalty. I was delighted to know about their satisfaction.
1
If the business isn't actively catering towards EU users(perhaps easier to think of a site in Japan that's in the Japanese language with a co.jp TLD, no content that is EU related), they're not required to respect the GDPR just because an EU user accesses their site. Highly unlikely any attempt to commenced legal action in regards to a GDPR violation is going to matter. Should that business later decide they want to expand into the EU market and it's users, obviously they would then have to give a shit and comply. If the EU wants to pack a sad and be a bully by marking foreign businesses that are clearly not interested in the EU to judge them negatively upon that business wanting to later enter the EU market and accommodate their laws at that point, it'd be a rather laughable decision. I suppose you're fond of the whole PC culture and SJW that came out about from that? Imagine if that were more enforced as a law from a foreign country with high penalty fees, where you have to ensure you respect your users and don't offend them while catering to their needs to be inclusive. That'd be a shit show. Perhaps China shouldn't have closed the world out with their internet in the mainland. Perhaps they could follow EUs approach and attempt to enforce their laws onto foreign countries too? I don't really know where this thread is going tbh. Respecting users privacy is great, but scenarios where a foreign law can have such an impact on you when you have no operational interest for whom those laws are designed to "protect", it's not right, nor something I'd encourage more of.
1
Really? I can think of one international company, Agregatre IQ in Canada (the Cambridge Analytica Scandal). [https://ico.org.uk/action-weve-taken/enforcement/aggregate-iq-data-services-ltd/](https://ico.org.uk/action-weve-taken/enforcement/aggregate-iq-data-services-ltd/) ​ And if the company has a company in the dpa's country, they will go after them, or use other enforcement powers there - for example Uber - [https://ico.org.uk/media/action-weve-taken/mpns/2553890/uber-monetary-penalty-notice-26-november-2018.pdf](https://ico.org.uk/media/action-weve-taken/mpns/2553890/uber-monetary-penalty-notice-26-november-2018.pdf) oh and Equifax - [https://ico.org.uk/action-weve-taken/enforcement/equifax-ltd/](https://ico.org.uk/action-weve-taken/enforcement/equifax-ltd/) ​ Facebook ... ;-) ​ There are international treaties that are enforcable, so if the regualtors or individuals want to, can afford to, action will be taken. ​ The FTC who are resonsible for Privacy Sheild are pretty weak, but they do enforce and have prosecuted US companies that have said they wrere on the PS list and were not. But, that's another barrel of fish. Also, if you want to do business in the EU, then due dilligence checks on processors or joint controllers would show a lack of "suffcient guarantees". ​ WE also have Convention 108, outside of the EU framework, covering of Data Protection as well, this is what the UK will use if it exits the EU. [https://www.coe.int/en/web/data-protection/convention108-and-protocol](https://www.coe.int/en/web/data-protection/convention108-and-protocol) alongside the UK GDPR and DPA 2018. ​ And in the UK, the ICO approach in year one, is easy does it, in year 2 they are focusing on enforcement - whatever shape that takes, not just fines. ​ Peace dudes :-D
1
Take a risk based approach of all of the options that you have - i.e. have a checkbox being the easiest, cheapest but least reliable vs having a parent scan their identification which is also relatively cheap and more reliable but introducing more risk. It would be good to get some additional context but i would strongly advice that you don't ask for payment card data as you are then going into PCI territory. Weigh up the pros and cons and fully evidence your decision so that if a complaint was raised, you can then work with the ICO (if in the UK) to establish a plan for bringing it in line as opposed to making a decision without justification which is more likely to give you a penalty.
1
This os usually how it works, either with guidance or a the penalty being for the company to implement the proper process. The ICO doesn't receive money from fines and take a very proportionate approach. They dealt with 17,300 cases and fined 16 times last year.
1
Wow, I may be missing something, but that case seems pretty crazy. >"III.4. Der Aufnahmebereich der Bildaufnahmen der gegenständlichen Kameras erstreckt sich wie festgestellt – neben dem unmittelbaren Eingangsbereich zum Wettlokal „[…]“ – auch auf weite Bereiche des öffentlichen Raumes vor demselben, konkret auf öffentliche Verkehrsflächen in einer Reichweite von ca. 20 Metern, wobei auf den Bildern Fahrzeuge und deren Kennzeichentafeln sowie Personen (Passanten) wahrgenommen werden können. Da von der Bildaufnahme ein großer Bereich des vor dem Lokal liegenden öffentlichen Raumes erfasst wird und zufällig dort vorbeikommende Verkehrsteilnehmer – bei welchen es sich naturgemäß nicht ausschließlich um Kunden des Wettlokals handeln muss – vernünftigerweise nicht damit rechnen müssen, aufgenommen zu werden, verstößt der Betrieb der Bildaufnahme gegen die in Art 5 normierten Grundsätze." They received a 2,400€ penalty because they set two visible security cameras to cover the entrance area of their business, and one of those also covered a public parking area with five parking spaces, where you could see licence plates. How many hundreds of thousands, if not millions of security cameras do exactly the same thing? How is one supposed to only cover such a specific area, stick tape all over a camera? I realise that there are other elements of the total 4,800€ penalty, such as inadequate signage and a failure to delete the data after 72 hours, but it still seems a pretty bizarre application of the law to me.
1
Yeah some of the areas are complete legalese. But a significant portion of the law is just setting up how the different regulatory bodies will work etc and isn't really applicable for most organisations or individuals. All that you described is just describing a group of companies I believe, and determining where the liability follows. From what I can tell it is found in a lot of other EU law. But remember the recitals just interpret the law, read all the articles first and use the recital linking to the article to guide you. Article 84 alludes to the various powers, which are left to the regulators. I am mainly going off the ICO. Article 84 Penalties 1. Member States shall lay down the rules on other penalties applicable to infringements of this Regulation in particular for infringements which are not subject to administrative fines pursuant to Article 83, and shall take all measures necessary to ensure that they are implemented. Such penalties shall be effective, proportionate and dissuasive. The ICO have draft regulatory guidance (https://ico.org.uk/media/about-the-ico/consultations/2258810/ico-draft-regulatory-action-policy.pdf) on their approach to their powers. Here are some useful bits, but they whole thing is worth reading: "When we will issue Assessment Notices We serve an assessment notice where we deem it necessary to gauge compliance with the provisions of the DPA or the NIS Directive because: • we have conducted a risk assessment or other regulatory action, which indicates a probability that personal data is not being processed in compliance with the DPA, together with a likelihood of damage or distress to individuals; or • it is necessary to verify compliance with an enforcement notice; or • communications with or information (e.g. news reports, statutory reporting or publications) about the controller or processor suggest that they are not processing personal data in compliance with the DPA; or • the controller or processor has failed to respond to an information notice within an appropriate time. "When we will issue Enforcement Notices Enforcement notices may be issued in the circumstances set out in [clause 146 of the Data Protection Bill] (e.g. where a data controller or processor has breached one of the data protection principles, where a certification provider or monitoring body for a code of conduct is failing to meet their obligations, or where a digital service provider has suffered a notifiable incident under the NIS Directive). The purpose of an enforcement notice is to mandate action (or halt action, such as processing or transfer) to bring about compliance with information rights and/or remedy a breach. Failure to comply with an enforcement notice invites further action, including the possibility of the ICO issuing a civil monetary penalty. " "In the majority of cases we will reserve our powers for the most serious cases, representing the most severe breaches of information rights obligations. These will typically involve wilful, deliberate or negligent acts, or repeated breaches of information rights obligations, causing harm or damage to individuals. In considering the degree of harm or damage we may consider that, where there is a lower level of impact across a large number of individuals, the totality of that damage or harm may be substantial, and may require a sanction."
1
You can have a screenshot of the map and offer click-through to an interactive map, or use OpenStreetMap. Apple Maps recently started offering their maps with strong privacy guarantees. You can compare vendors and select the one you think offers the best privacy. YouTube has a privacy-enhanaced embed widget which isn’t fully GDPR compliant but is still better than using the default one in terms of the data that is collected. You need to sign a data processing agreement with the vendor that limits what they can do with the data. As the website publisher, you’re responsible for their behaviour so you want to have it in writing. Otherwise you alone are responsible for whatever they do today or in the future. Many companies offer standard data processing agreement contracts that lays out what data you can send them and what they do with the data. Once you have that in order, you can introduce a consent-click gateway that the visitor can click-to-agree to sharing data with the vendor and load the widget. You have to get separate consent for individual purposes (serving ads/marketing, geolocation, personalization, etc.), communicate which purposes you’ve gotten consent with to the vendor using their consent-collection APIs, and keep in mind that [prechecked checkboxes](https://www.reddit.com/r/gdpr/comments/b4hatx/prechecked_cookie_boxes_dont_count_as_valid) aren’t enough. “Click to load YouTube video and agree to the Google Privacy Policy” isn’t enough as YouTube collects data for all sorts of purposes (recording in user’s history, ad selection, service personalization, search personalization, etc, etc.) that all require separate consent. There will be a noticeable delay after the user has given their consent since you can’t preload JavaScript libraries or anything from the vendor prior to getting consent (IPs are personal data in many contexts). You my be better off with linking to their website as your visitor then beleive that it’s the third-party site that is slow and not your website. (An example of perceived performance design by [reassigning the blame for the performance penalty](http://babich.biz/progress-indicators/#systemorcustomloopedanimation).) The best practice (in terms of user experience and legal risk) really is to do as much as possible yourself. Then you can just avoid collecting any data and don’t need to maintain relationships with third-party companies.
1
You need to comply with all laws or risk some form of penalty. The law has the mantra; only chase those with deep pockets. I doubt many ambulance chasers are interested in small players.
1
I hope Europe goes after them. $2 billion penalty (4%). But a breach doesn’t prove negligence so it’s not a sure thing by any means.
0
When people buy a service from a company, for exemple access to news, both parties have a mutual contract extending over an agreed period of time (4 weeks for 99c as of their website today). If the company selling services refuses to comply to the law of the country where the consumer is living, while having sold their product to the consumer, it is a crime. They might eventually reimburse customers, but they can be held accountable for a reduction in services that the consumer did not agree to when signing up. Creating systems that benefit society and fining outlaw corporations that refuse to comply to laws is the opposite of authoritarian (compare to: countries where the death penalty is still a thing). Laws should be made for and by the people, not for and by corporations.
0
Zuckerberg is that you? The largest fine so far took 7-8 months from start to finish: https://www.cnil.fr/en/cnils-restricted-committee-imposes-financial-penalty-50-million-euros-against-google-llc
0
body
score (Sum)
IT Ops Topic: Data Center
Showing 12 rows, 1 columns
body
score (Sum)
Of course not, that’s not the point. I would never suggest you need a data center in EU, but if you get customers from EU (and let’s over simplify and say that it’s not occasional, that you accept payments in euro for example) you have to comply with GDPR - which doesn’t mean having data centres in EU but just follow the rules
5
Doesn’t Facebook have a data center in Ireland? If so, it puts them firmly under GDPR.
2
B is a data processor, since B is storing the data. They are hosting the data in their data centers. Even if they have no access at a software level to the data, they could in theory remove the data (storage media) and delete ( shred or recycle the hard drives) and this in turn would affect your data availability but the integrity of the data as well.
1
Good question! I don't think a Geo IP from Europe would result in different results, as the results are based on the response of the website. I am using a droplet from Digitalocean in the AMS3 (Amsterdam) data center. I am assuming you are referring to a result you've got from an Geo IP lookup database. Unfortunately Geo IP databases are often not updated in real time. You can see via [https://ping.eu/traceroute/](https://ping.eu/traceroute/) that the server is located in the Netherlands.
1
I disagree with this (though maybe not in the case of MFP since they are a pretty big company and can easily take on the cost). We have a single datacenter in the US and we occasionally get users from the EU who want to buy some of our stuff. We're telling them - "sure you can buy but FYI the server is in the US so your data is stored here". Is everyone supposed to open a secondary data center in the EU?
1
I think they would probably argue that it was necessary for the provision of service (art 6.1b). I'm not sure on Twitters operations, but Id guess they have data redundancies all over the world to maintain the service if one data center went down. To do that, they'd have to copy your data to all of these.
1
Interesting. Likely means that they're going to be opening/will have to build and open an EU data center. My advice - follow up on this and try to get an exact time frame (or at least if this can be expected before the date of enforcement). Also, keep tabs on it. Once the GDPR hits mainstream news, you're going to undoubtedly have a large number of customers and consumers that wish to exercise their rights to be forgotten, data portability, data transparency, rights to audit, etc, against EU companies. And then there's gonna be that subset that expects the instant compliance and won't hesitate to contact the regulatory agency if they don't get it in as timely a fashion as possible. Just make sure that all of your bases are covered. Businesses are in for a rough ride over there in the EU.
1
just got off the phone with my lawyers, they basically told me to either a\) comply and ask users for permission to 'transfer data outside of country/region' with explicit info saying that 'us laws may be less protective of users data than eu' \- requires a checkbox b\) change to a provider with eu data centers c\) 'forget' to explicitly ask \- they did not recommend that option this is ridiculous, there are no eu alternatives that are as good as twilio and postmark, also when usa comes up with their legislation ill propably have to go another way round :D
1
Nope. A host is a processor. A search engine is a controller in the sense that they own the search results. Say Google didn't have their own data centers... it's the equivalent of having their host go into Google's database and remove the results. Google is also potentially technically both their own processor and controller when it comes to their search engine and results.
1
Not a lawyer, not legal advice. In our case we did it without privacy shield by using Explicit Consent (and making relevant changes in the privacy policy), which I think might be overkill but still. [LINK] (https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/international-transfers/) " A transfer, or set of transfers, may be made where the transfer is: made with the individual’s informed consent;" When signing up, there is a specific full-page form that asks our EU users if they are OK with storing the data in US servers which have lower privacy than the EU. There's even a little American flag there. For existing users, we've been telling them they have until May 25th to give consent for US transfer or their accounts will be wiped. Most of them gave it FYI. There is also a place where they can revoke consent in which case we apply erasure. Re (2) in your question, I think this is meant to apply for AWS members in the EU that are using US data centers. Not for actual end users. We also looked into getting Privacy Shield but at least in our own analysis, it looked like it would expose us to more liability than not joining it. Also, it's still not clear how the GDPR authorities plan on actually imposing fines on US companies that have no EU presence, but being in the Privacy Shield means they can ask the FTC to punish you (as far as I understand). For now we'll wait and see.
1
This is a valid concern. In the real world it's usually just a data center employee unplugging a cord and forgetting to plug it back in. EIG knocked my server offline and moved all my sites from Texas to a server in the Provo Utah data center on the 4th of July with new IP addresses without telling me. I had to change my holiday plans to figger out what happened. I don't use them anymore. The data center will normally just give you a discount next month. They assume you have a backup. If you pay them to do the backup, then they'll have it on a different server but it's usually at the same data center. I'm not very worried about someone destroying my server, I could get everything back up and running from backups, it would just be stressful and take me all day (and probably all night). What I care about is the data saved between the backup and the outage event. There's usually multiple hosting companies at the same data center, you get the best service if you host with the company that actually owns the data center. Currently I have a server at the data center in Lansing Michigan with no problems whatsoever, only 2 minutes of downtime this year, first downtime was for the Spectre/Meltdown fix in January, 2nd downtime was for an OS update. 2 minutes a year ain't bad.
1
I agree with this and as a US company, we did do the necessary GDPR changes and have a process to respond to DSRs. However, our data center is still in the US. We ask that permission as the first consent and we don't give the users any real choice (other than exiting). And realistically, if the US government comes asking us for information about EU citizens with court orders, gag orders and whatnot, we'll probably cough it up. I understand this is contrary to the spirit of GDPR (i.e. using the site shouldn't be conditional on consent). But we don't really have a choice. MFP is a bigger company so I imagine they could easily open up a DC in Europe. But stonewalling users who don't agree to data transfer to US territories seems like the only way to go if you only have servers in the US.
0
body
score (Sum)