December 18, 2017 at 3:21 pm
So, you studied every healthcare related law in every country your customers were from?
And you keep that knowledge up-to date, in case you'll get a contract opportunity in a healthcare related business.
And you also can be a legal adviser for insurance companies, as you studied all the relevant laws.
Right?
I bet no. Otherwise you's be a lawer by now and would not bother attending this forum.
Threre are a lot of laws and rules regulating business activity in each particular field.
It's the responsibily of the business to convert relevant regulations into company policies.
It's a job for lawers, not BI developers, no matter how experienced they are.
Asking an employee to interprete and apply the law him/her-self is plain stupid, not to mention - dangerous.
Employees must be presented with company policies, and that's what they should know and follow.
But not before they're hired.
_____________
Code for TallyGenerator
December 18, 2017 at 3:25 pm
Thom A - Monday, December 18, 2017 3:13 PMSergiy - Monday, December 18, 2017 3:04 PMSo, to be able to deliver goods to any of EU addresses I have to collect all the info listed above from potential customers.
And they have to give it to me, in order to buy anything online.Are you sure it's about protecting customer's privacy, not exposing his/her most detailed personal data to as many foreign entities asd possible?
I think you're missing the point. You don't have to collect all that data to conform to GDPR; you have to conform to GDPR is you collect ANY of that data. The two statements are not mutually exclusive.
Without collecting that data I cannot tell if my customer is from EU.
And if GDPR should be even considered.
_____________
Code for TallyGenerator
December 18, 2017 at 3:37 pm
Sergiy - Monday, December 18, 2017 3:25 PMThom A - Monday, December 18, 2017 3:13 PMSergiy - Monday, December 18, 2017 3:04 PMSo, to be able to deliver goods to any of EU addresses I have to collect all the info listed above from potential customers.
And they have to give it to me, in order to buy anything online.Are you sure it's about protecting customer's privacy, not exposing his/her most detailed personal data to as many foreign entities asd possible?
I think you're missing the point. You don't have to collect all that data to conform to GDPR; you have to conform to GDPR is you collect ANY of that data. The two statements are not mutually exclusive.
Without collecting that data I cannot tell if my customer is from EU.
And if GDPR should be even considered.
If you intend to sell/deliver products/services to individuals in the EU then you already know that you need to conform to GDPR, doesn't matter if you know your customer is from the EU. Which, when followed to its conclusion means you should probably treat all customers as if they are from the EU so that you have a single code base with which to work.
December 18, 2017 at 3:39 pm
Hugo Kornelis - Monday, December 18, 2017 8:05 AMSergiy - Monday, December 18, 2017 7:03 AM1. I have a Facebook account (registered to my personal email, so this falls under the definition of identifiable natural person.2. I am a EU citizenBased on the two verifiable facts above, the obvious conclusion is that I have now given solid proof that Facebook holds personal recorrds of at least one EU citizen. They will need to follow GDPR.
What course of actions you'd suggest me to take to verify these 2 "verifiable facts"?
I don't know why you want to verify this yourself, but the stpes are fairly easy. For the first step, go to facebook.com and type my name in a search box. For the second, come by my house and I'll show you my passport. (I will not post a copy here, for obvious reasons).
I have a database of some 3.5 mil customers around the globe.
Some of them are businesses, some of them are real people.
Now, I need to verify their EU citizenship status.
Are you suggesting me to sibmit 3.5 mil Facebook searches?
And then going 3.5 mil addresses on different continents asking for passports?
Please, don't be a troll, give me a real course of actions, which I can actually follow to know if my business has to comply with GDPR.
_____________
Code for TallyGenerator
December 18, 2017 at 3:54 pm
Lynn Pettis - Monday, December 18, 2017 3:37 PMIf you intend to sell/deliver products/services to individuals in the EU then you already know that you need to conform to GDPR, doesn't matter if you know your customer is from the EU. Which, when followed to its conclusion means you should probably treat all customers as if they are from the EU so that you have a single code base with which to work.
Is it about EU only?
Or should I treat every customer as a citizen of USA, Australia, Russian Federation, Turkey, Zimbabwe, etc.?
I have customers in every country in the world, except probably KPDR.
Should I and every other employee study the legislation of every coutry in the world?
You know, that anti-terrorist legislation in USA is quite opposite to GDPR in terms of personal data handling.
Does it mean no company will be allowed to sell goods on both sides of the straight?
_____________
Code for TallyGenerator
December 18, 2017 at 4:28 pm
Sergiy - Monday, December 18, 2017 3:25 PMWithout collecting that data I cannot tell if my customer is from EU.
And if GDPR should be even considered.
it should be considered because of the bold part in your next quote (and the following one, which I bold too):
Sergiy - Monday, December 18, 2017 3:39 PMI have a database of some 3.5 mil customers around the globe.
Some of them are businesses, some of them are real people.
Now, I need to verify their EU citizenship status.
Are you suggesting me to sibmit 3.5 mil Facebook searches?
And then going 3.5 mil addresses on different continents asking for passports?Please, don't be a troll, give me a real course of actions, which I can actually follow to know if my business has to comply with GDPR.
You don't need to verify your customer's citizenship status, the fact of the matter is you state that your clients are from around the world. If you accept customers from the EU, then GDPR applies. End of story.
Now, if you want to treat the customers that are members of the EU separately to those outside, that is totally up to you. If you do want to treat them separately, then yes, you will need to determine which customers are from the EU, and then complete the processes that are required by GDPR. Of course, you don't have to split out your customers, you could just treat every single one the same, and ensure that you conform with DPR across the board. Then, regardless of if the customer is from the EU or not, you're covered.
To put it another way. Let's say I live in the USA, and I'm setting up a company where I'm going to sell paintings. At first, I plan to only sell to customers within the USA. Fine, I don't need to conform to GDPR, as I don't deal with the EU. Now, let's say, 6 months later, I find I've been having interest from customers within the UK, who want to purchase my paintings, and so I decide that i want to start selling items to customers there too. Now (even before I have a customer) I have to start ensuring I'm GDPR compliant. Why? Because I'm planning to trade with a country within the EU, and once i start taking those orders I MUST be compliant. no ifs, no buts.
Sergiy - Monday, December 18, 2017 3:54 PMIs it about EU only?
Or should I treat every customer as a citizen of USA, Australia, Russian Federation, Turkey, Zimbabwe, etc.?
I have customers in every country in the world, except probably KPDR.
Should I and every other employee study the legislation of every coutry in the world?You know, that anti-terrorist legislation in USA is quite opposite to GDPR in terms of personal data handling.
Does it mean no company will be allowed to sell goods on both sides of the straight?
Does it apply to the EU only (sort of)? Yes, GDPR is EU legislation, but like I said above, it applies to anyone that is dealing with the EU, or it's citizens. To use the example again, being located outside of the EU (Let's say Japan), but selling goods to customers in France would mean you are effected by GDPR.
I'm not quite sure what you mean by the last paragraph (which I've put in Italics).
Now, you may also be thinking "Well, I'm outside of the EU, so GDPR doesn't applied to me." or "I'm outside of the EU, so the EU can't fine me". Firstly, the second statement is wrong, it does. Why, because of my answer to the next one. Yes, you're right the "EU" can't fine you, not directly. They can, however, talk to your government and push the fine through them; should they consent, then yes, you'll be seeing a hefty fine coming your way. If you're government, however, decides not the confirm and the EU finds that you aren't conforming (or even worse, have a data breach), then expect sanctions to be made against your company. Yes, you're not being fined, but even if we (at a conservative estimate) say that 1 million of your 3.5 million customers are within the EU, you're going to lose every single one of them.
The consequences are not dealing with GDPR are very real. They may well seem "veiled threats" right now, but I would not be surprised to start hearing in a couple of years the large fines that have been given out to non-compliant companies that suffered breaches through negligence or poor security choices. The Eu have really given people time to prepare, at least to a degree; we've been prepping at work for the last 12-18 months, and we're a long way from finished.
One of the most important things I've learned is ensuring that you document and prove that you are compliant, or at least making as many steps to ensure you are. As an example, a company we deal with sends us a file every month with a lot of our customer's details on it. That file is a passworded Excel file, and the person sends the password in a separate email. That password is the same every month... And it's not a secure password. We have repeated asked them to change their ways, and they haven't, so what have we done? Evidenced our requests to them asking them to change their rpocess (ie.. use SFTP). We've evidenced the emails from them, stating that they won't change things. Why? Because if a breach does occur due to the poor choices made by them, we have the evidence to say "it's not our fault". We still will likely be (partially) held accountable, but the fines would likely be mitigated, as we took all the steps we could to stop the breach. On the other hand, the company that sends us those files would be seen to be negligent; and that does not look good in the eyes of the EU and GDPR. Failure from negligence is never a valid reason; it's just inexcusable.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
December 18, 2017 at 5:47 pm
Sergiy - Monday, December 18, 2017 3:54 PMLynn Pettis - Monday, December 18, 2017 3:37 PMIf you intend to sell/deliver products/services to individuals in the EU then you already know that you need to conform to GDPR, doesn't matter if you know your customer is from the EU. Which, when followed to its conclusion means you should probably treat all customers as if they are from the EU so that you have a single code base with which to work.
Is it about EU only?
Or should I treat every customer as a citizen of USA, Australia, Russian Federation, Turkey, Zimbabwe, etc.?
I have customers in every country in the world, except probably KPDR.
Should I and every other employee study the legislation of every coutry in the world?You know, that anti-terrorist legislation in USA is quite opposite to GDPR in terms of personal data handling.
Does it mean no company will be allowed to sell goods on both sides of the straight?
I'm not sure if yo're just being argumentative for the sake of it, or fully misunderstanding the point.
This isn't about treating customers from different nations differently. It is about following the laws of the countries where you do business. If you sell in the EU, you have to register for and pay VAT. If you sell in the USA, you have to collect Sales Tax. If you're a Turkish company selling goods to Niger, you need to know the import and export regulations of both countries. If you're a truck driver, you better switch to the other side of the road when entering the UK. Etc etc. If you don't want to be hindered by all these laws, then don's sell in the EU, don't sell in the USA, don't export from Turkey to Niger, and don't drive your truck to the UK. GDPR is just another extra law, which affects all EU companies, and all other companies that choose to do business with EU citizens within EU territory. EU companies have no choice, non-EU companies do have a choice: continue to earn money over here (and comply with our new laws). Or stop selling to EU citizens within EU territory.
The GDPR does not state: "you must keep data of EU citizens safe while keeping other data unprotected". It only says to keep data from EU citizens safe. The EU has no jurisdiction over what you do with other data. However, you will understand that it is far easier to encrypt the entire column with credit card numbers, and to anonimyze data before loading it on the test system, instead of encrypting cc-numbers and anonimyzing data for EU-related data only. So as I said: no need to treat different customers differently, just a minimum level of data protection that you must apply to your data and your procedures.
"Should I and every other employee study the legislation of every coutry in the world?"
No. But your truck drivers should know the traffic rules in each country they drive in, or at least know enough about it to understand when they should check for additional information before crossing the next border. Your financial staff should know the different tax regulations of all countries you sell to or buy from, or at least know enough to understand when they should ask legal to get them the details they need. Your salespeople should know which of your products cannot be exported to some countries, and know when to check before closing a sale. And your data professionals should know the rules applying to data in the countries where you do business, or at least know enough to realize when it is time to get legal involved to ensure that the company doesn't unknowingly violate any laws.
"You know, that anti-terrorist legislation in USA is quite opposite to GDPR in terms of personal data handling."
That's not true, but I'll get to that. First a digression. The anti-terror laws in USA are actually in some sense similar to GDPR: they, too, are regulations that apply not only to USA airlines, but also to other airlines that want to fly to the USA. The anti-terror rules force airlines to provide advance passenger information. Airlines may chose to not collect this information and not fly to the USA. Or they can continue to fly to the USA but then they need to provide this information. Now it is totlally up to them to decide if they want to collect this information only on USA-bound flights or simply ask all passengers to fill out the information; that is a choice for the indvidual company.
But I assure you: if ever a KLM flight lands in a USA city without the advance passenger information, then "should I and every employee study the legislation of every country in the world" will not be an acceptable excuse. You fly to our country, you better play by our rules.
So I don't know why you claim that GDPR and anto-terror regulations are opposed. I *assume* (but correct me if I am wrong) that you think the requirements of anti-terror regulations to gather personal information are countered by the GDPR because GDPR is about protecting personal data. However, GDPR does not forbid companies to collect personal data. GDPR is mostly about things such as keeping personal data safe (encryption, not testing with production data, backup storage, etc); sharing (don't sell my phone number to telemarketing without my consent); informing (tell me what data you have on my when I request this; give me the right to make corrections if you have verifiable incorrect data); and indeed the famous right to be forgotten (which for the record is limited: I can not make you forget data that you are required to keep for financial audits, legal reasons, etc).
So yes, airlines can ask me for my advance passenger information; thhey can collect and store that data. As long as they take all the needed precautions to keep that data safe. Seems reasonable to me.
They can share this information with the USA immigration authorities. Since I know that they will do this (it's stated quite clearly on the website when I am asked for this information), this too seems reasonable to me.
Once the information is no longer needed (i.e., after my flight), I can choose to be forgotten. The airline no longer needs this information. Of course, this does mean I'll have to re-enter for my next USA flight. This, too, seems reasonable to me.
And regardless of how I personally feel about this, the USA border protection agencies are not bound by the GDPR (article 3 if I recall correctly, I quoted it here in a post I made a few hours ago). So they can do whatever they want with it. (Well, not actually. There are still a lot of other regulations about data security, some of which appply specifically to government bodies. And US border authorities obviously also have their own USA rules. But alll of those are now not subject to change, so that simply remains as it always was).
"Does it mean no company will be allowed to sell goods on both sides of the straight?"
LOL! No, not at all.
We had an uproard for a short while when the rules were new, but in spite of the anti-terror rules EU citizens are still flying to the USA, and EU carriers are more than willing to take their money. Perhaps a few airlines that had a very limited number of flights to the USA decided it's not wirth it and to aim for other markets, but other airlines will have filled that gap.
With GDPR it will be the same. There will be an uproar (how dare the EU force us to do this), then a realization (hey I'm doing business in their jurisdiction, they DO indeed have this right), a contemplation (how much will it cost me to comply? how much of my yearly turnover is coming from the EU), and then a decision. Some companies will withdraw, others will take the steps to comply and continue to do business in the EU.
December 18, 2017 at 8:54 pm
Sergiy - Monday, December 18, 2017 3:25 PMThom A - Monday, December 18, 2017 3:13 PMSergiy - Monday, December 18, 2017 3:04 PMSo, to be able to deliver goods to any of EU addresses I have to collect all the info listed above from potential customers.
And they have to give it to me, in order to buy anything online.Are you sure it's about protecting customer's privacy, not exposing his/her most detailed personal data to as many foreign entities asd possible?
I think you're missing the point. You don't have to collect all that data to conform to GDPR; you have to conform to GDPR is you collect ANY of that data. The two statements are not mutually exclusive.
Without collecting that data I cannot tell if my customer is from EU.
And if GDPR should be even considered.
That's pure nonsense. It doesn't matter where your customer is from. It does matter what the deklivery address is and what the invoicing address is - if the delivery address is in the EU and you took the order at a location in the EU or on the web, the GDPR regulations will apply to data concerning the person(s) taking delivery, and if the invoicing address is in the EU and you took the order at a location in the EU or on the web the regulations will apply to the person(s) paying. Since you generally know both the invoicing address and the delivery address you don't have to dig up any extra data. If you don't know the invoicing address you presumaly have no PID on the payer, so the payer's information is not covered by the regulations. If you say you don't know the delivery address I won't believe you unless delivery was to an IPA rather than a physical address, and if it's to an IPA you are probably safe to treat that IPA is a valid indicator of location and apply or don't apply the regulations accordingly.
The bunk you've spouted about a vast bureacracy is also pure nonsense (and I'm shocked that Hugo accepted it). Data protection laws are enforced by individual EU nations, not by a separate central bureaucracy. The current set of regulators will be adequate to cope with the new rules. Take a look at the preent USA-EU data protection agreement to see how it works (and then take a look at the way the US government and big companies really operate to see that the agreement will probably be declared invalid (becauseit's lip service only, if it's even that close to real conformance) by an EU court judgement the first time it's challenged on behalf of an EU citizen).
Quoting those maximum figures for penalties is also misleading - those numbers are an upper bound that national implementation of the regulations is not permitted to exceed, each nation can set a lower upper bound, and it's expected that countries will set lower limirs. The regulations also require that the penalty in each individual case should be proportionate to the damage done - if only a few people are affected the penalty should be lower, if data is exposed by a new malware attack that gets past decent anti-malware softwre and decent security design in applications and effectively breaks Linux or Windows or whatever the penalty must be lower than it would be if the company had built for example a wide open SQL injection route that can get the data or had not bothered to install any anti-malware software at all or sone something else irresponsible (like disabling Windows Defender to improve performanace).
I imagine that there will have to be some international coordination for breaches by a company breaking the regulations in all EU countries simultaneously, and that may need some extra bureaucracy and fines closer to the limit stated in the regulation, but that won't be a vast army of bureaucrats nor will it result in unreasonably large penalties.
Tom
December 18, 2017 at 9:06 pm
ZZartin - Monday, December 18, 2017 10:42 AMHugo Kornelis - Monday, December 18, 2017 8:06 AMZZartin - Monday, December 18, 2017 7:37 AMOn a side note is there some particular reason that the EU is doing this? Or is just an overly paranoid idea?Privacy protection of their citizens.
(Grant's more cynical answer might also apply.)
That was my question, what caused this new law? Was there some major breach in the EU that warranted it or is it just paranoia? Or the cynical reason i hadn't even considered, because yes persisting customers information is a pretty major requirement for a lot of businesses....
I think there were two causes. One was the volume of data revealed because of really rotten security (mostly in American companies) over the last decade or more; the other was growing public concern that personal data was being improperly used so as to result in a vast reduction of privacy and a lot of nuisance advertising (far too many cold calls).
Tom
December 19, 2017 at 5:25 am
Grant Fritchey - Monday, December 18, 2017 7:38 AMFor example, knowingly releasing a patient's healthcare information to unauthorized people can result in jail time. I wouldn't expect someone who has never worked with healthcare data to know this, but if you're applying for a senior DBA position and you have healthcare in your background, be prepared for me asking you about it. Also, I'd expect that you'd want to know the legal requirements of your position as you move from job to job, industry to industry. They do vary. I had to go through extensive background and drug tests to work for a Wall Street firm (bonded). I didn't have to do anything while working for dot com. I had a bunch of requirements I had to meet dealing with the insurance company. My responsibilities legally for Redgate are different again (and a lot less stringent).
So, you studied every healthcare related law in every country your customers were from?
And you keep that knowledge up-to date, in case you'll get a contract opportunity in a healthcare related business.
And you also can be a legal adviser for insurance companies, as you studied all the relevant laws.
Right?
I bet no. Otherwise you's be a lawer by now and would not bother attending this forum.
Threre are a lot of laws and rules regulating business activity in each particular field.
It's the responsibily of the business to convert relevant regulations into company policies.
It's a job for lawers, not BI developers, no matter how experienced they are.
Asking an employee to interprete and apply the law him/her-self is plain stupid, not to mention - dangerous.
Employees must be presented with company policies, and that's what they should know and follow.
But not before they're hired.
No, of course not. But I did do a review with legal when making decisions on sharing data, exposing data, although, none of that was early in the career. When you're new you either don't know, or don't have to care because you're not the decision maker. Once you become the responsible party, yeah, you should check with legal. Note, I didn't say "DO ALL THE LEGAL RESEARCH YOURSELF". Cut me a little slack here. Or are you just trying to go hyperbolic to prove some kind of point?
----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software
December 19, 2017 at 5:27 am
Lynn Pettis - Monday, December 18, 2017 3:37 PMIf you intend to sell/deliver products/services to individuals in the EU then you already know that you need to conform to GDPR, doesn't matter if you know your customer is from the EU. Which, when followed to its conclusion means you should probably treat all customers as if they are from the EU so that you have a single code base with which to work.
Yep. Pretty much this. Safest approach. If you do EU business, treat all customers as if they are from the EU. It's the safe way to go.
----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software
December 19, 2017 at 5:31 am
Hugo Kornelis - Monday, December 18, 2017 5:47 PMdon't drive your truck to the UK.
There's just no arguing with Hugo. I'm with you on this.
NOTE: This is how I've been approaching Hugo's edits on the book too. HA!
----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software
December 19, 2017 at 7:02 am
Sergiy - Saturday, December 16, 2017 6:06 AMMichael L John - Friday, December 15, 2017 7:18 AMBut, the astounding thing is that out of 6 candidates we have interviewed, only ONE had any understanding of the upcoming GDPR regulations.
The other 5 had never even heard of it. Wait, you mean to tell me you are an IT professional, and you have never even hears of this???Why should they have?
GDPR is rather legal subject, with very little relevnce to technical implementations. It's a company lawer which must understand it, not a report developer.And - do you have such an understanding yourself?
Can you give a definition for "data subject"?
Is it a EU citizen, as described in one part of the legislation, or a EU resident, as described in another part?
After it's clarified - how can you tell that a customer record in your database contains personal data for such a "data subject"? How do you or your BI developer should know if a record with a dodgy family name belongs to a EU citizen, or to a contractor residing in an EU country for a limited time, or a gastarbeiter from Ukraine on a work permit with no residential rights?
How DBA's in Ali Express suppose to know which personal records in their database belong to citizens of which EU countries? Did you ever submit your citizenship information when buying something online? And even if you did - how a vendor suppose to verify correctness of such information? Get direct access to Intenal Affairs databases of every EU country???Right-to-be-Forgotten.
What if I want to be forgotten by a Police department?
What about a private investigator database? Their normal operations definitely "require regular and systematic monitoring of data subjects". So, according to GDPR, I must be able to force them to "forget me".
It's also interesting how they plan to enforce this right for the private information of EU citizens collected by FSB (better known as KGB) or CIA?
And if FSB could not be forced to open their data collections for inspections by EU authorities, why Facebook must be any different? Especially - there is no solid proof that the personal records held by Facebook are of actual EU citizens.
This is a bit more that a report developer position. And, even if it was "only a report developer", I would hope that they would have at least heard of it. Considering the skills, experience, and accomplishments listed on the resumes, it's about what I expected.
And, yes, I do have a deep understanding of it myself. It's my job.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
December 19, 2017 at 7:20 am
Sergiy - Monday, December 18, 2017 3:21 PMGrant Fritchey - Monday, December 18, 2017 7:38 AMFor example, knowingly releasing a patient's healthcare information to unauthorized people can result in jail time. I wouldn't expect someone who has never worked with healthcare data to know this, but if you're applying for a senior DBA position and you have healthcare in your background, be prepared for me asking you about it. Also, I'd expect that you'd want to know the legal requirements of your position as you move from job to job, industry to industry. They do vary. I had to go through extensive background and drug tests to work for a Wall Street firm (bonded). I didn't have to do anything while working for dot com. I had a bunch of requirements I had to meet dealing with the insurance company. My responsibilities legally for Redgate are different again (and a lot less stringent).So, you studied every healthcare related law in every country your customers were from?
And you keep that knowledge up-to date, in case you'll get a contract opportunity in a healthcare related business.
And you also can be a legal adviser for insurance companies, as you studied all the relevant laws.
Right?I bet no. Otherwise you's be a lawer by now and would not bother attending this forum.
Threre are a lot of laws and rules regulating business activity in each particular field.
It's the responsibily of the business to convert relevant regulations into company policies.
It's a job for lawers, not BI developers, no matter how experienced they are.
Asking an employee to interprete and apply the law him/her-self is plain stupid, not to mention - dangerous.
Employees must be presented with company policies, and that's what they should know and follow.
But not before they're hired.
No, of course not. But I did do a review with legal when making decisions on sharing data, exposing data, although, none of that was early in the career. When you're new you either don't know, or don't have to care because you're not the decision maker. Once you become the responsible party, yeah, you should check with legal. Note, I didn't say "DO ALL THE LEGAL RESEARCH YOURSELF". Cut me a little slack here. Or are you just trying to go hyperbolic to prove some kind of point?
It would be really nice to be able to just sit in a cube and be completely oblivious to the rest of the world. But, when your position is one of a senior level, being well versed in the various regulations better be part of your job description.
In our case, we are a global company. Determining our GDPR compliance has been a group effort. Everyone has been involved.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
December 19, 2017 at 7:52 am
Facebook is a commercial company that tries to make money by offering their services to (also) EU citizens. That means they are subject to EU law.
"there is no solid proof that the personal records held by Facebook are of actual EU citizens."
1. I have a Facebook account (registered to my personal email, so this falls under the definition of identifiable natural person.
2. I am a EU citizen
Based on the two verifiable facts above, the obvious conclusion is that I have now given solid proof that Facebook holds personal recorrds of at least one EU citizen. They will need to follow GDPR.
I love this.
Viewing 15 posts - 60,721 through 60,735 (of 66,000 total)
You must be logged in to reply to this topic. Login to reply