January 12, 2018 at 12:18 pm
Complying with GDPR from a software point of view is making sure you have the mechanisms to ask for consent without preticked boxes to signal consent. Your customer must make an affirmative choice.
It is making sure your software has appropriate security for PII data. In DB terms use roles and membership of those roles. Make sure those roles are aligned to business usage.
Make sure you aren't vulnerable to SQL Injection attacks
Make sure your software uses credentials wisely
If possible use encryption but it isn't compulsory. Make sure your backups are secure.
Make sure your help text is clear and unambiguous. Don't be afraid to write for surviving brain donors. Ditto your technical documentation.
From a software development perspective do things the way you should be doing them anyway.
From a business process perspective make sure you have the mechanisms in place to handle requests. Think about data retention policies like you should have in any case.
Marketing people, figure out how to use this to your advantage. This is your opportunity to build a relationship & reputation with your customers. Treat your customers with the respect you should have been giving them anyway.
IT management catalogue your processes. This may help you bring some of your estimates in from the realms of polite fiction. At least it will enable you to cost change with greater certainty.
Think about the requests that might come your way. Expect a surge shortly after May 25th but tailing off shortly after. Maybe it's worth having an automated process to retrieve the data, like your customer facing staff have been begging for years?
Above all stop whining about it. Everyone is in the same boat. Small companies have a distinct advantage over bigger companies due to their lighter weight decision making structure and clearer priorities.
January 12, 2018 at 1:21 pm
BrainDonor - Friday, January 12, 2018 1:10 AMInterestingly, Brent Ozar has decided to stop selling in the EU for now, giving GDPR time to settle in. About 5% of his revenue is from the EU, so he doesn't believe it is worth his time and wants to wait and see how it develops.
He doesn't believe it's worth a risk right now. That's slightly different. I think that's a fair assessment as we have no idea how many legal trolls will attempt to file suit over this.
January 12, 2018 at 1:23 pm
a.crossley - Friday, January 12, 2018 2:12 AMThis is a great article - thanks.
One key area that I keep bumping into and haven't found a satisfactory SQL solution for is encryption. It's my understanding that GDPR states all personal data must be stored using encryption. When applied to SQL server that becomes a challenge for those of us living in the SME world that can't afford the full enterprise version of SQL (enterprise version includes encryption). The best option I have seen so far has been BitLocker to encrypt the whole hard disk, but this isn't viable when you're using a hosted server. Azure is encrypted, but I find that too expensive compared to cloud hosted SQL boxes.
I would be very interested to hear any comments on the area of SQL Server encryption and GDPR.
I think TDE will suffice for most of this, or Bitlocker, though each has some vulnerabilities. I think they're the best of what's available. I know this is EE only, though I do hope that MS will change this. Unlikely as I suspect they want to sell more licenses. However, not all data needs encrypting. Reasonable controls here, so names, emails, etc. should have limited access and some controls. Passwords should always be encrypted.
January 12, 2018 at 1:27 pm
peter.row - Friday, January 12, 2018 3:37 AMEven if you take it on the chin and do all the work. Then you are going to lose even more time/money because if anybody says prove it, how can you? Once info has every been stored that information could leak in any number of ways - screenshots, shared with third party system before you revoked your permission. It is an admirable goal but ignores reality. Fines should scale to the size of the business since large businesses will have more money/resource to put into the required changes.
You prove this as you would for an auditor. Show them, explain controls. Same for any lawsuit. Leaks are possible, but this law is intended to try and force businesses to make some effort, not just a token. Certainly you could get caught in a bad situation, but someone has to prove that you didn't do a good job. There is verbiage about making appropriate technical measures, and designing for privacy and security. That can mean changes, but I think these are good ones. Far, far too often we haven't considered these things as software is designed.
January 12, 2018 at 1:34 pm
peter.row - Friday, January 12, 2018 9:06 AMThe problem is with all these kind of things they might not be designed to trip you up - but they do. The world of technology is a massive place and thus no such legislation can prescribed any direct helpful advice of how you would update your software to comply. It's all down to millions of developers to interpret and re-factor as appropriate. The enormity of the work this involves is huge - and this lack of reality check is what often grates with such legislation.
There are problems with all regulation, and really with all rules. Or almost all. No rule or regulation can specify every case, situation, or technology.
Your responses seem to indicate and and concern, but have you read the regulations? This isn't a wholesale "the customer decides everything". The right to be forgotten or ask for erasure has bounds, and may require legal decisions to implement. In those cases, yes, you need to find a way to delete things, and ensure they are still handled with regards to DR/restores. That's a pain, but it's better than the current situation where a company may remove you, but isn't necessarily bound to worry about a restore. Or won't be penalized heavily.
The rules regarding transfers to third parties have some bounds and reasonable language that you disclose and protect this data. Once it's transferred, that's not your issue. The data then falls under the third party's control and they have responsibility/accountability.
You ought to read the regulation. IMHO, way better than SOX/PCI.
January 12, 2018 at 1:34 pm
David.Poole - Friday, January 12, 2018 12:18 PMComplying with GDPR from a software point of view is making sure you have the mechanisms to ask for consent without preticked boxes to signal consent. Your customer must make an affirmative choice.
...
Good summary, David
January 14, 2018 at 8:33 am
I'm even more perplexed
January 14, 2018 at 3:20 pm
Does anyone know how GDPR applies to EU citizens when they are overseas?
I work for a local government organisation and our country is popular with people from the EU and the UK in particular so we collect info on people who are temporary residents if, for example, they enroll for a service we provide or even just phone our call centre. Once they go back to the UK do they have the right to be forgotten because they are an EU citizen or do they have to consume the service whilst resident in the UK?
January 14, 2018 at 4:04 pm
CC-597066 - Sunday, January 14, 2018 3:20 PMDoes anyone know how GDPR applies to EU citizens when they are overseas?I work for a local government organisation and our country is popular with people from the EU and the UK in particular so we collect info on people who are temporary residents if, for example, they enroll for a service we provide or even just phone our call centre. Once they go back to the UK do they have the right to be forgotten because they are an EU citizen or do they have to consume the service whilst resident in the UK?
I haven't seen anything that requires an online service if one is not already available.
Reading through GDPR left me uncertain as to how the adopters of GDPR would enforce the regulation outside of the EU and UK. Without mutual cooperation agreements I don't see how it could be enforced except for political arm twisting.
How long do you retain people's data and for what purpose? Do you ask for consent before doing so? One option might be to destroy data that would allow you to identify a specific individual but allow you to derive value from aggregated information i.e. Brits under 30 tend to favour activity 'X' when visiting your country.
January 14, 2018 at 4:50 pm
David.Poole - Sunday, January 14, 2018 4:04 PMHow long do you retain people's data and for what purpose? Do you ask for consent before doing so? One option might be to destroy data that would allow you to identify a specific individual but allow you to derive value from aggregated information i.e. Brits under 30 tend to favour activity 'X' when visiting your country.
Thanks very much for your response. Examples would be dog registration, parking tickets, building consent, leisure classes e.g. swimming, reporting graffiti or noise complaints, applying for a building report or property search, hiring a facility.
Some of this can be done online and other things have to be done via the call centre but we would collect names addresses, phone numbers, email addresses and probably date of birth as well so that we can uniquely identify someone for if they contact us again in future instead of creating a duplicate record for someone. The data is unlikely to be archived and we employ a number of Business Analysts to report on the accumulated data and although the are using the raw data they wouldn't create reports that could identify individuals.
February 18, 2019 at 5:17 am
a.crossley - Friday, January 12, 2018 2:12 AMThis is a great article - thanks.
One key area that I keep bumping into and haven't found a satisfactory SQL solution for is encryption. It's my understanding that GDPR states all personal data must be stored using encryption. When applied to SQL server that becomes a challenge for those of us living in the SME world that can't afford the full enterprise version of SQL (enterprise version includes encryption). The best option I have seen so far has been BitLocker to encrypt the whole hard disk, but this isn't viable when you're using a hosted server. Azure is encrypted, but I find that too expensive compared to cloud hosted SQL boxes.
I would be very interested to hear any comments on the area of SQL Server encryption and GDPR.
The GDPR does not stipulate encryption, it only stipulates that adequate measures must be taken to protect the data.
In practical terms, for most circumstances, encrypting a database really does nothing to help with protecting the data in it. Why? Most data breaches will occur using a valid data connection, as in staff accessing the data directly or an application that does same. While it is not impossible for data to be copied through a malicious party making a copy of the raw databae file, the malicious party doing this is likely already to have enough access to the system to compromise the data protection. This does not mean that database file encryption is worthless, but its impact on GDPR is negligable.
February 18, 2019 at 5:24 am
CC-597066 - Sunday, January 14, 2018 4:50 PMDavid.Poole - Sunday, January 14, 2018 4:04 PMHow long do you retain people's data and for what purpose? Do you ask for consent before doing so? One option might be to destroy data that would allow you to identify a specific individual but allow you to derive value from aggregated information i.e. Brits under 30 tend to favour activity 'X' when visiting your country.Thanks very much for your response. Examples would be dog registration, parking tickets, building consent, leisure classes e.g. swimming, reporting graffiti or noise complaints, applying for a building report or property search, hiring a facility.
Some of this can be done online and other things have to be done via the call centre but we would collect names addresses, phone numbers, email addresses and probably date of birth as well so that we can uniquely identify someone for if they contact us again in future instead of creating a duplicate record for someone. The data is unlikely to be archived and we employ a number of Business Analysts to report on the accumulated data and although the are using the raw data they wouldn't create reports that could identify individuals.
A more thorough approach would be to anonomise the data before Business Analysts get hold of it, preventing them from accidentally including personal data or identifying individuals. This is the principle of reducing the scope and access to the data to the minimum that is required - in this case the Business Analysts have, or should have, no requirement to identify individuals therefore they should not be able to. This is sometimes harder in practice, but a good aim.
February 18, 2019 at 5:38 am
David.Poole - Sunday, January 14, 2018 4:04 PMCC-597066 - Sunday, January 14, 2018 3:20 PMDoes anyone know how GDPR applies to EU citizens when they are overseas?I work for a local government organisation and our country is popular with people from the EU and the UK in particular so we collect info on people who are temporary residents if, for example, they enroll for a service we provide or even just phone our call centre. Once they go back to the UK do they have the right to be forgotten because they are an EU citizen or do they have to consume the service whilst resident in the UK?
I haven't seen anything that requires an online service if one is not already available.
Reading through GDPR left me uncertain as to how the adopters of GDPR would enforce the regulation outside of the EU and UK. Without mutual cooperation agreements I don't see how it could be enforced except for political arm twisting.
How long do you retain people's data and for what purpose? Do you ask for consent before doing so? One option might be to destroy data that would allow you to identify a specific individual but allow you to derive value from aggregated information i.e. Brits under 30 tend to favour activity 'X' when visiting your country.
There are no computing or online requirements specified in the GDPR. If the data is stored on pieces of paper in a filing cabinet it is still covered and there is no requirement to change this for any reason.
The GDPR covers data of all EU citizens when processed by an organisation that either operates within the EU or provides services to EU citizens while they are in the EU. Protection is also extended to the personal data of all individuals by organisations that operate within the EU. What this means is:
An EU citizen travelling outside the EU providing personal data to an organisation that is also outside the EU is not covered. For example, an EU citizen travelling in the US and providing personal data to a car hire company has no protection from the GDPR (and being the US, has no data protection whatsoever).
Any individual, regardless of the nationality, within the EU providing data to an organisation within the EU is covered. For example, a US citizen travelling within the EU providing personal data to a car hire company has the same protection within the GDPR as an EU citizen.
If an organisation outside the EU provides services to an EU citizen while this citizen is in the EU is bound by the GDPR. It does not matter where this organisation is located, or operating from, the EU's citizen must be covered by the GDPR. This is the scenario that has caused the most panic among organisations that are based in a regime with no data protections, such as the US. If such an organisation wants to do business with EU citizens then they must follow the rules. While some take great upset at this reality, in essence it is no different to the trade in physical objects. For example, if an object is illegal to trade in the EU but legal in the originating organistion's country, this doe not make it legal in the EU - e.g., do not try and sell ivory or firearms to individual in the EU (these are just two obvious examples).
February 18, 2019 at 5:48 am
peter.row - Friday, January 12, 2018 8:54 AMThe customer was made aware of third party usage when they agreed. BUT then afterwards asked you to remove all data. You complied but the third party obviously still has any data you shared with them. Since the customers point of contact was your software then they are going to blame you not the third party.
From what you are saying the company/software would be fine presuming you could show that no such data was being stored any more, is that correct?
You should have a contract with the third party so they remove on your request. Or you should clearly let customers know who is going to process their data before they authorize you to send their data to a third party.
Regards Ramon
February 18, 2019 at 8:44 am
Question: Is a company that provides a product or a service to a person in Europe always subject to the GDPR?
Answer: No.
While the GDPR purports to apply extraterritorially to a company that is not based in the European Union, but “offer goods or services” to a person that is located in the European Union, the European Data Protection Board has emphasized that merely providing service to individuals that happen to be in Europe is not enough to trigger the GDPR. Instead the EDPB has implied that the subjective intent of a company to offer products to Europeans must be evaluated. Specifically, the EDPB has focused on whether a company was “targeting” Europeans when providing a service, or whether a company has “demonstrate[d] its intention to offer goods or services to a data subject located in the Union.”1 The EDPB’s interpretation of the extra-territorial reach of the GDPR relies on language within the recitals of the GDPR that suggests that a company must “envisage” the offering of services into the Union in order for the regulation to apply extra-territorially.2
In order to determine whether a company intends to offer goods or services into Europe, the EDPB has suggested that supervisory authorities consider the following non-exhaustive list of factors:
Based upon the guidance provided by the EDPB there are several situations in which an American company may physically provide a product or a service to individuals that are in Europe, but not be subject to the GDPR. For example, if a company markets an App only to Americans, but an individual uses the App while in Europe on vacation, the EDPB has made clear that the company would not be subject to the GDPR because it did not intend to target Europeans.4 This determination should not be impacted by the mere fact that if the company examined its web logs it might have knowledge that a user entered the App via Europe).
Viewing 15 posts - 16 through 29 (of 29 total)
You must be logged in to reply to this topic. Login to reply