EU GDPR – Another reason for SaaS to reconsider on-premise

https://gravitational.com/blog/gdpr-impact-on-saas-vendors/

by aberoham • 8 years ago

145 102 8 years ago

twakefield3• 8 years ago

This post was inspired by "The Nightmare Letter: A Subject Access Request under GDPR" [0]. Which shows the potential scary consequences of subject access requests.

There's a lot of FUD around this topic. I've seen posts opinions ranging from "no big deal" to "this is actually good for U.S. SaaS" to "This is going to kill SaaS". It will be interesting to see how enforcement of the GDPR plays out.

At the moment, with Facebook transgressions in the news, the pendulum seems to be swinging towards privacy. We'll see how far it swings.

[0] https://www.linkedin.com/pulse/nightmare-letter-subject-acce...

louthy3• 8 years ago

As a CTO at a European SaaS company I don't particularly find 'The Nightmare Letter' nightmarish at all. If you're doing your job properly then this stuff isn't hard.

It's had very little effect on our day-to-day - yeah, it's cost us real cash money in lawyers, and additional training for GDPR, but most of what is going to be legislation we were already doing. As an individual I welcome this legislation - it should really help to stop the shoddy practises that clearly go on (based on the amount outrage I've seen on this issue). GDPR seems, to me, to be proportionate and reasonable.

I don't see this helping US SaaS companies, because once GDPR is in-place then I'd consider EU SaaS providers to be more attractive. It's a real selling point that your data isn't leaking or being mismanaged.

If anything I see this as a potential boon for the SaaS companies doing their job properly, because the companies that have in-house systems (or have their own bespoke solutions) are going to have to prove those systems themselves - and have all the answers to The Letter. Whereas a good SaaS company can take those problems off their hands.

ryandrake• 8 years ago

Nothing in that nightmare letter seems unreasonable for an end user to want to know, and I'd be hesitant to do business with a company that can't answer those questions about their own business. If those "nightmare" questions are the bar, it's a pretty low bar.

adventured• 8 years ago

I don't see this helping US SaaS companies, because once GDPR is in-place then I'd consider EU SaaS providers to be more attractive. It's a real selling point that your data isn't leaking or being mismanaged.

That doesn't make any sense. If GDPR is in place, then US SaaS firms won't be leaking & mismanaging your data, the whole point is they'll have to start complying or else.

US SaaS firms will still have a vast advantage because: they're radically larger with far greater financial resources, have a drastically larger VC environment of initial funding, and still have the world's largest homogeneous economy as the base hub to initialize out of and get to huge scale to easily afford to spend anything they need to on compliance.

What the EU just did is make the compliance picture far more difficult and complex for small European competitors as a whole. With Brexit, the EU lost 15% of its economic mass, further aggrevating this concept of regulatory & compliance splintering across Europe. The European splintering will only get worse as individual European non-EU nations come up with their own rules on this type of stuff.

Salesforce or Workday can more easily comply with a dozen compliance approaches across the whole of Europe, than a given start-up in Portugal or Greece can.

moduspol3• 8 years ago

I don't see this helping US SaaS companies, because once GDPR is in-place then I'd consider EU SaaS providers to be more attractive. It's a real selling point that your data isn't leaking or being mismanaged.

Does GDPR prevent data from being leaked or mismanaged?

hectormalot• 8 years ago

I suspect that the 'nightmare GDPR letter' pushes the boundaries on what the GDPR would probably intent as a reasonable request, and I wonder if it would hold up in court if challenged by one of the companies.

I think most of the provisions make a lot of sense if you look at them in a simple way. It's not unreasonable to ask a company:

* what information on me do you keep?

* what are you using it for?

* can you provide me with a copy of my data? (with interesting situations where the data itself might be privacy or competitively sensitive, e.g. can I expect a company to share derived insurance scores with me? what if the data also includes other people's data?)

* can you erase my data?

As for impact on small SaaS businesses, I think it is relatively limited. .e.g For my SaaS side business I could probably answer the nightmare request within a day, if I would get 1+ request per week we could probably automate the response, with the exception of manual ID validation. Information deletion is something that the app wouldn't handle well at the moment and would be a bit more work.

Thinking of it in this way, this is probably only a problem for a) large user bases (in which case I hope companies have the capacity to automate these requests efficiently), and b) data hoarding / ad companies (for which I don't really feel sorry)

kenbaylor4• 8 years ago

For any company that is compliant with GDPR (after 25th May 2018), the answers your 4 questions (2 on data collection, other 2 on data subject rights) must already be in their privacy notice on their website, with instructions for how to contact their data protection officer.

wukerplank• 8 years ago

The privacy laws in my country were nearly as restrictive as GDPR and now they get a bit stricter. No big deal. GDPR is only stating the obvious and actually it is sad that the protection of most private information is not common sense but needs to be enforced with rigorous punishment.

Spearchucker• 8 years ago

I've had that letter bookmarked for months now, and the thing that worries me most is that for example, as a subject that hasn't ever owned an Android phone, doesn't use Google, Gmail or have a YouTube account - if I send that letter to Google, what stops Google from just straight-out lying to me? How do they prove their honesty to me if they say "we got nothing on you"?

kenbaylor4• 8 years ago

This is a key reason why there are data protection officers under GDPR. They report to the highest level of management (mostly the board) and are independent. They are also called mini-regulators. They ensure the company is compliant.

If they are not doing their job, (and you are not content with their reply), you then appeal to the Data Protection Authority (DPA, Privacy Regulator in the country). The DPA has full powers of subpoena (and a whole lot more), and are not to be trifled with.

megous• 8 years ago

I also wonder how sending requests will work for companies maintaining shadow profiles. PII is defined quite widely, for example my phone number is PII because it can be used to uniquely identify me.

So how to get my PII deleted from FB's servers, for example? FB mines other people's phones for this data continuously, so will they setup a blacklist, so that my phone number will not get mined ever again from other people's phones? Blacklist will have to contain my phone number in order to work. Somewhat self-defeating. Hashing will not do much, because the search space is so small.

Also, they may have my phone, and some guess at my identity. Providing a much stronger link between my identity and my various other identifying information (phone no, emails, ...) to random shady companies and hoping they'll use it to delete data they may have on me... uh. It does not add up to something sensible.

gtirloni3• 8 years ago

This article feels the need to repurpose the term "on-premises" to mean "self-hosted".

From a previous article [0]:

In the SaaS context, “on-premise” historically meant deploying a separate instance of your SaaS application to your customer’s server room or data center, behind their firewall. More recently, this term may also include deploying to the customer’s private cloud at a cloud provider like Amazon Web Services or Azure

I'm a bit baffled this is necessary. You go from two terms that are widely understood to now having to add a disclaimer every time you say "on-premises".

0 - https://gravitational.com/blog/time-to-reconsider-going-onpr...

twakefield3• 8 years ago

Point taken. I've struggled with this because we see these terms intermingled in practice.

This is probably because most of our customers (SaaS vendors) think of everything that is not traditional multi-tenant SaaS as "on-premise". Also, self-hosted does connote the customer's IT is running the application, where a lot of times we see the vendor running the application (just on customer infrastructure).

gtirloni3• 8 years ago

Ah, the vendor running the app on the customer's infrastructure. Got it. Thanks, that makes sense.

amarkov2• 8 years ago

The motivation is that both kinds of "on-premise" create roughly similar engineering challenges. (Your app has to be adaptable to heterogenous execution environments, all your code changes will be in a partially released state for indefinite periods of time, it's hard to immediately diagnose whether a reported problem is your fault or user error...)

threeseed• 8 years ago

Self hosted may as well be on premise for most companies though.

The whole point of SaaS is that someone else manages the app. If you've ever worked in an enterprise you would understand that it can take months/years and significant amounts of money to get an app "installed". Often there needs to be a business case, project and resourcing plans, security and risk reviews, legal compliance checks etc.

The infrastructure (cloud versus on premise) is just one part of a dozen and not usually the most challenging.

gtirloni3• 8 years ago

What's your point w.r.t. using "on-premises" when "self-hosted" (on-premises or not) would suffice? I don't get it, sorry.

roomey• 8 years ago

Genuine question, do people realise Facebook Europe (among others) is headquartered in Ireland, and has to abide by fairly strict rules already? Eg. I can write them and they have to provide me with any personal information they have on me at the moment, for a nominal fee. I could probably get most of the questions on the nightmare letter above answered!

lovich• 8 years ago

"strict" only applies once they've been punished for violating those rules, which has not happened with those Irish regulations as far as I am aware. Facebook gives some information out, but does not give it all[1]

[1]http://www.zdnet.com/article/facebook-releasing-your-persona...

kenbaylor4• 8 years ago

Most of the EU litigation has been against Facebook.

They have spent many millions in EU GDPR projects (such as the ability to download all records, which is in the news cycle right now).

Under the current legislation, they can be sued by each regulator in each country separately (this has happened to them multiple times). Under the GDPR, they will mostly be sued by just the Irish Data Protection Authority (other EU regulators will funnel issues to the Irish DPA first).

dane-pgp2• 8 years ago

There's one particular aspect of the GDPR which I realised recently could have a significant effect on Facebook. The regulations give users a specific right to data portability, with the wording:

"In exercising his or her right to data portability pursuant to paragraph 1, the data subject shall have the right to have the personal data transmitted directly from one controller to another, where technically feasible."

https://gdpr-info.eu/art-20-gdpr/

Conceivably, a Facebook user could demand that Facebook support automatically sending their Facebook posts to their friends on third party social networks. I imagine that an EU court would not be very sympathetic to Facebook claiming that it isn't technically feasible for a (large, monopolistic, American) company to support this use case when small open source (European?) competitors have implemented the W3C social networking standards (e.g. ActivityPub) with no trouble.

Once Facebook is forced by the GDPR to publish data to competing sites, I imagine it will feel compelled to also support receiving data from people on those sites, otherwise the one-way flow of data would put Facebook users at a disadvantage. But then there is basically no reason to use Facebook, as users of competing sites would still be able to see and be seen by their friends on Facebook.

This is such a disastrous outcome for Facebook that I wouldn't be surprised if lawyers at Google (or some other big company) were already working on the legal complaints they are going to launch come May, when the GDPR comes into force.

stordoff• 8 years ago

That needs to be read in conjunction with A.12(3):

The controller shall provide information on action taken on a request under Articles 15 to 22 to the data subject without undue delay and in any event within one month of receipt of the request.

Whilst you may be able to require that Facebook send the data to a competing service, I would not read A.12(3) as requiring it to be done immediately -- Facebook could (somewhat reasonably) claim that gathering all information about an account takes some time. This limits its usefulness.

Further, A.20(1) specifies the "right to receive the personal data concerning him or her", which I would read as making a request under A.20 returns all data relating to you, and does not oblige the controller to return only specifically requested and/or new data. You have have to be comfortable with the entirety of that data being send to the third-party, and they must be set up to process the deluge of information.

Not only that, but A.12(5) provides that:

Where requests from a data subject are manifestly unfounded or excessive, in particular because of their repetitive character, the controller may either: charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or refuse to act on the request.

Repeated requests to facilitate sending posts to a third-party could quickly been seen as excessive, in which case Facebook could refuse to process the request, and I doubt that the courts would treat such requests as being within the spirit of the rights granted under A.20 (it is a right that enables moving to a new controller, rather than being intended to synchronise data between controllers on an ongoing basis).

antoncohen2• 8 years ago

This doesn't make a lot of sense. If you are a SaaS provider that has the option of selling your software as on-premises, you are almost certainly a processor not a controller.

Put another way, when a consumer goes to a consumer site and gives it personal data, that consumer site is the controller. When the controller uses a third-party SaaS to process or store the data, that third-party is a processor.

If you are a controller you need to ensure that your processors are capable of handling GDPR requests, e.g., they can delete specific data for a user or provide a dump for a user. The processor (third-party SaaS) will have to write that capability into their software.

Bringing that SaaS software on-premises doesn't change much. It eliminates the processor, but if I'm a controller purchasing some big SaaS-like product to run myself, I'm going to insist it have GDPR features built-in. The third-party SaaS vendor will have to write GDPR feature whether they sell it as SaaS or on-prem.

twakefield3• 8 years ago

Maybe I'm missing the point of your comment but a typical reason for delivering an application on your customer's infrastructure is that they don't want their data to leave their infrastructure. It's usually b-to-b where the customer is typically an enterprise buyer using their own data storage. So, the customer knows how its data is being processed.

pdpi• 8 years ago

The point is that your b2b customer is itself a b2c business that holds customer data in the product you sold them. Irrespective of whether it’s hosted or on-prem, you’re considered a processor in GDPR parlance, and your customer is a controller. Your customer needs to be able to handle consumer GDPR requests, so, if your software ever touches end-user data, it needs to be able to handle whatever those GDPR requests might be

antoncohen2• 8 years ago

True, one of the primary reasons enterprises want software to run on-premises is so data doesn't leave company. But this article is talking about SaaS software, specifically it is talking about fairly complex software where the software provider might actually manage the software even though it is running on-promises at a customer site.

This type of software is delivered as virtual machines, or in the case of Gravitational they package up Kubernetes. Think something more like GitHub Enterprise (if GH managed it) instead of Oracle Database.

The enterprise running the software would be providing block storage as part of their virtualization infrastructure, but they would have little insight into how the data is stored. It would be a black box. The software would need to provide sufficient APIs to get GDPR data out (deletes, dumps, etc.).

As an easy example let's say I make a SaaS logging service. I can tell my customers (the controllers) that I know nothing of their data, they send me a JSON blob and I index it, I have no idea what parts of the data are personal. They can either not send personal data in the logs, or they can use our APIs to search, extract, and delete data when a customer makes a request. For me, I wouldn't have to service any additional requests or write any additional features, it makes little difference if I deliver the software as SaaS or on-prem[1].

A harder example would be a SaaS CRM product, maybe it includes a support ticket system, a forum, purchase records, etc. All of that is locked up in a GUI, with no meaningful API. As a SaaS product I would have to write features so my customer (the controller) could dump and delete data for a specific one of their customers. I know what the records are, how they relate to individuals, what rows in what tables in what DBs matter. My customer (the controllers) doesn't know any of that. If it was delivered as on-prem software it would still need features to dump or delete that data.

[1] It isn't quite true that there is little difference between SaaS and on-prem. There are trade offs in both directions. With SaaS you have to deal with all the sub-processor stuff, ensuring they are GDPR compliant and getting consent from the controller to use each sub-processor. If it is on-prem you can pass that burden to the controller. On the other hand updating software and troubleshooting it a lot easier if you run it yourself, versus having it locked away in some enterprise virtualization system you can't access. And it is easier to write your software to run on your infra instead of all the mixes of infra that enterprises run. But then again if you are running a multi-tenant SaaS you are going to have to deal with big scaling issues, but if it runs on-prem at each customer site you have effectively sharded your data. Now you just have to make sure you can reliably run a schema change across 1000 DBs, spread across the worlds, that you can't monitors and can't access. Yep, there are trade offs.

lifeisstillgood• 8 years ago

Let's say you are an Appointment Reminder Saas to pick an HN relevant example. You are selling to a Dentist practise in Germany. The Dentist is the controller of the personal data. Your software processes the name, address, phone number of the Dentists patients. If a patient wants their records deleted (maybe moved house) then on-premises or not, your software needs to support such deletion.

if you sell it as a normal hosted sass, you are the processor and must delete and audit the deletion. if you are selling it as a packaged software (on-premises by any other name) then the Dentist is also the operator or processor - you are hands off the data. but not in the clear.

Because almost no-one buys packaged software anymore and absolutely no-one will buy it unless it says "GDPR-compliant" on the box so no matter what you have to support this.

https://www.eugdpr.org/glossary-of-terms.html

Edit - oh already answered!

tooba3• 8 years ago

In that instance it's not always the case that SaaS will default to be a processor. GDPR describes a controller as 'which, alone or jointly with others, determines the purposes and means of the processing of personal data;'

Where a SaaS provider steps into more complex analytics or has some freedom in the process, there's an argument that they're joint controllers and bear those responsibilities. The difference between cloud and on- premises is that you're actively processing personal data in SaaS.

In many cases, the processor/controller relationship will be correct. But GDPR is focused on active compliance so it's something which should be actively considered and documented.

StreamBright• 8 years ago

The entire on-prem vs. cloud is orthogonal to GDPR. Your stack either compliant with it or it isnt, regardless if you run on AWS or on OVH.

77pt774• 8 years ago

Can I just say that my service doesn't cater to EU residents?

galvin• 8 years ago

If you don't target EU customers and you don't have an EU presence, sure.

Other businesses who want to be GDPR compliant might not be able to use your service either.

gls2ro• 8 years ago

As I am interpreting the GDPR (IANAL) it is not about what you say, it is about if you have or have not users from EU.

See [0] specifically the phrase "It applies to all companies processing and holding the personal data of data subjects residing in the European Union, regardless of the company’s location"

[0] https://www.eugdpr.org/gdpr-faqs.html

icebraining6• 8 years ago

More or less; if you just happen to be accessible from the EU, but have otherwise no connection to the EU at all, you're probably not subject to the GDPR:

"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. (..) 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"

https://gdpr-info.eu/recitals/no-23/

PeterisP3• 8 years ago

Sort of - you have to actually not cater to EU residents, simply saying so might not be sufficient, and (for an exaggerated example) a company implementing a signup screen that says "wink wink nudge nudge press quit if you're from EU" while having 25% of their business income from EU credit cards would be likely treated not as compliance but as malicious evasion.

You have to avoid touching personal data of EU residents; various exceptions are understandable (e.g. people using some measures like VPN to circumvent some restriction), but in general if you do somehow happen to have a sizeable amount of such data, then obviously you're "catering to EU residents" in some way no matter what you claim.

briandear2• 8 years ago

“25% of their business income from EU credit cards..”

Where did that 25% come from? Did you just make that up? My point is that some arbitrary EU regulator is going to tell a US based company (or Chinese, Russian, Canadian, etc.,) who that non-EU company is catering to? Under what jurisdiction does this happen? Where does a company representative show up to defend their case? They get to fly to Brussels? How does due process work? How does the EU learn about the percentage of credit card transactions? We’re going to expand their powers to track credit card transactions of individuals? No privacy concerns there right? We are going to support increased privacy violation to protect people from privacy violations? You trust your government that much? Given the history of many European countries, it would seem quite dangerous to give countries more surveillance power.

I am all for increased data hygiene for sure, but the EU has lost its fucking mind if they think they’re just going to be able to start telling non-EU companies what they can and can’t do when those companies aren’t even in the EU. The EU could start blocking websites, which would put it in the same level as China or Turkey. Did Pirate Bay ever get blocked in the EU despite enabling whitespread copyright abuses? Is the EU finally going to draw the line here?

If someone from France calls my US phone number — they are coming into my house. It isn’t like I am showing up at their house forcing them to buy my product. If I am a US company and I refuse to do business with an EU citizen — now we have national origin discrimination, which is illegal in the EU.

My SaaS product is subject to US HIPAA and the HITECH act which directly conflict with this European law. I am required to maintain detailed access logs for 7 years, but to do that, now I have to violate an EU law. We have EU patients who see US medical professionals. So now we are in a hell of a pickle. We have to violate HIPPA to follow the EU. Interestingly, HIPAA is actually stricter around privacy than the EU law — except there are still conflicts, especially around audit logs and data retention.

Additionally, to avoid servicing EU customers, a Canadian company would have to violate the EU national origin discrimination law? Or they’d otherwise be forced to conform their systems to a framework to which they had zero representation in creating? Who represented the Canadian companies when this law was being written by the EU? Because if the EU is going to imply that Canada is subject to said law, then Canada ought to have had a voice in its creation right?

The people who supported and created this law — let’s not pretend this is about privacy. This is about creating trade barriers. The recent obsession with the EU and US tech companies is further proof that there is a clear bias, or perhaps an inferiority complex from the EU. France especially.. they’re actually going after Apple because of the iOS and Mac App Store but they don’t do a damned thing when (Dutch-based) Booking.com takes high percentages of hotel/lodging bookings, including keeping customer data. Basically Booking.com is just like an App Store for hotels — hotels agree to a percentage of revenues for the marketing benefit of being in the Booking “store.” But France doesn’t sue Booking.com for that. But they sue Apple on behalf of French developers? Booking.com also prohibits lower pricing being offered to other distribution channels. But the EU or France isn’t trying to sue Booking.com for high commissions they are suing Apple over.

Give me a fucking break. This law is nothing but a trade barrier wrapped in some feel-good packaging. Is the EU really going to fine BNB bank 5% of global revenues when BNP shares my banking data to telemarketers in their insurance division without my explicit permission or knowledge? Of course not. BNB is French.

tooba3• 8 years ago

You can decide not to allow EU citizens to use your service. However, the EU has a population of 508 million citizens. It's the largest population in the world after China and India. GDPR is a genuine attempt to balance the rights of data subjects against ever advancing technology. You'd be excluding yourself from one of the world's largest markets on the basis that you don't want to protect your customer's rights.

bkor• 8 years ago

A colleague (not direct colleague) was fined because he, while executing his normal responsibilities, accidentally broke a German custom rule. He's not German, nor located in Germany. German custom fined him at his private residence. He performed this work on behalf of the company. German customs didn't care; figured out where he currently lives and sent the fine to him personally (his name is on it). So he's basically liable according to German customs.

If you do business with EU then you have to follow certain laws.

77pt774• 8 years ago

What happens if he doesn't pay?

I'm really interested in more details about this case.

marcrosoft2• 8 years ago

I’m not sure why this doesn’t come up more but the EU does not have any authority to force non EU companies to do anything. Please stop pretending that GDPR effects US companies not operating in the EU.

martimarkov• 8 years ago

Because we live in a global world. Why would you build a startup to only be capable to NOT work in EU. When building a company and you want to have any dealing with EU companies. And there are a lot of those it just makes sense to adopt the most strict framework and deal with it.

marcrosoft2• 8 years ago

Oh, because of the internet I can serve a EU customer from the US without EU regulation. Why would a startup setup a nexus in the EU?

raquo2• 8 years ago

For the same reason you typically don't optimize for the Chinese market even though it's also huge.

There is a significant cost to compliance, even if you do it right from the very beginning (assuming it's even possible for GDPR right now), and for a lot of startups it's not worth it to spend time on that because they'll most likely be dead for unrelated reasons before they get any significant amount of GDPR clients.

It makes more sense to spend the effort on not dying instead of chasing incremental gains in markets with complicated regulatory requirements, unless dealing with those is explicitly your business proposition.

deltron3030• 8 years ago

Why would you build a startup to only be capable to NOT work in EU.

Because adopting the lowest common denominator (GDPR etc.) won't let you grow as quickly, and you might not need the EU market to reach your personal and business goals, or your point of exit.

It might make more sense to split into a EU division once you can really afford it and are established in your main market. I think that this will happen, many will see the EU market just as feature and option to scale an already established business, even companies within the EU. They might start in the US first, and block EU access.

jkaplowitz• 8 years ago

It does affect US companies where either they, their staff, or their customers have sufficient ties to the EU for the EU to exert their authority, and where the GDPR applies by its own terms. Which is more US companies than many think.

Whether "not operating in the EU" is a different threshold than the above is a semantic argument that's less interesting to me than the substantive ones.

hartator• 8 years ago

I agree. The US is an independent country. The way international law works is only if we have similar law here. Like trademark agreemwnts. Or like China can sue you to post pro-gay things online in Cantonese. That makes no sense.

icebraining6• 8 years ago

If you do business with people in the EU, the EU has jurisdiction. That doesn't mean they can enter the US to arrest someone, but they can (for example) tell payment processors in the EU to stop accepting any payments to the company.

PeterisP3• 8 years ago

Every major consumer tech company that comes to mind is operating in EU. Facebook, Google, Twitter, Apple, Microsoft, Amazon, etc all are under EU authority in this regard despite being headquartered in USA; they have a sizeable business, thousands of employees and billions of assets in EU.

Also, if your SaaS company is selling globally (which is true for most large SaaS) then if your B2B customers are in EU, they'll require GDPR compliance if they're going to use your service for any customer data. So companies like Dropbox, Stripe, Mailchimp, Salesforce, etc are also affected and have already stated the steps they'll take to be GDPR compliant.

closeparen2• 8 years ago

An argument has been made that while you may be US only, your bank probably wishes to maintain good relations with the EU and might hand over your money on its behalf.

andy_ppp• 8 years ago

Just slightly off topic, has anyone done an opinionated legal analysis of what GDPR means in the context of delivering a complex application. For example let’s say a recruitment company internal system. I think business people and lawyers alone struggle to grasp the meaning and spirit of the rules.

vbsteven2• 8 years ago

Assuming that a SaaS provider is the `processor` in the GDPR. Could it comply to the GDPR by providing the following features through either API or admin panel?:

* Trigger json/zip export of all data for $user_id

* Delete all data for $user_id

* List all events where data for $user_id has been sent to $third_party

When building a new SaaS service from in 2018, this does not seem to be that much work if you design your system with these requirements in mind. A simple way to tag every resource in the database with $user_id, and an event log for third party interactions should be enough.

Am I missing something?

merinowool2• 8 years ago

How do you delete data from backups written to persistent media?

When having CQRS/ES architecture (immutable events), how do you delete that data where by definition events can't be modified/deleted.

Just two examples, but there is much more.

bennyp1012• 8 years ago

You are not expected to delete data from backups, but you will probably want to put something in place where you ask for consent to store their name or something so that you can remove them again if you ever restore from a backup.

vbsteven2• 8 years ago

Interesting. Is it required to delete data from persistent data immediately or is it sufficient to retain the $to_be_deleted_user_id for preprocessing when restoring a backup?

Same for event processing, can we get by with a preprocessing step that filters out data when reprocessing the event list?

magnat• 8 years ago

How do you delete data from backups written to persistent media?

You encrypt each user's data with unique symmetric key and store the key in HSM or other external, rewritable media. When requested, you delete the key for a given user, rendering user data in backups unusable.

fuscy3• 8 years ago

This letter is interesting.. and paints a bleak future.

What is stopping someone who wants to make easy money (like me) from going on Fiverr and selling my GDPR request letters?

Example: 5$ for 5 (could be anything) GDPR request letters to any company of your choosing?

This way, a malicious actor can buy thousands of GDPR requests and DDoS anyone but big companies like Google.

The cherry on top is that they have 1 month to comply so after they remove the information, I can simply repeat the process after the time limit. So they will eventually have to implement some kind of banning process which will affect their FTUE/onboarding giving the competition an advantage.

I bet this is the most basic idea that will appear in the blackhat world where they can probably poison the data compliance of various companies so that their services get shuttered.

CJefferson• 8 years ago

I hope people do send lots of GDPR requests. I plan on doing so myself.

The answer is very simple. You should have a simple automated one-click method of knowing where all data relate to each user is, and an automated way of clearing it all. Job done.

fuscy3• 8 years ago

My "business" idea would probably last until the tech stack catches up. At this moment there is no easy way to handle this request for a simple helpdesk clerk without involving some pricier jobs.

Even with the tech, it still requires a human (for now) to read the request, understand it and process it.

Perhaps the future is AI interpreting the request and doing all the operations automatically or providing the client with a panel that can do all of these without having to contact the company.

bennyp1012• 8 years ago

The regulation doesn't specify how a Subject Access Request is delivered, they encourage you to send it in writing, but it doesn't have to be.

As a business, you cannot dictate how or where your customers/employees submit a SAR, so you need to be ready to pick up on the fact that it could be asked anywhere.

So it is actually worse, because you need to train all staff up to recognise a SAR in all areas that you communicate with customers.

MattBearman• 8 years ago

Although this is a risk, it has been somewhat accounted for in GDPR:

(from ico.org.uk - https://ico.org.uk/for-organisations/guide-to-the-general-da...)

"Can I charge a fee for dealing with a subject access request?

You must provide a copy of the information free of charge. However, you can charge a 'reasonable fee' when a request is manifestly unfounded or excessive, particularly if it is repetitive.

You may also charge a reasonable fee to comply with requests for further copies of the same information. This does not mean that you can charge for all subsequent access requests."

tooba3• 8 years ago

Subject access requests have existed for twenty years in the UK. The Information Commissioner's Office provides free guides on how to request data. Most people aren't aware of their right to do this. Organisations can charge under the current legislation but often don't.

A lot of organisations forget to discuss the scope of a subject access request. If you imagine an employee at an average company, an undefined subject access request can include months or years of pension contributions, internet and email logs, training records, meal choices for their end of year party... if their issue is a recent performance review, the scope will often be email chains or HR documentation relating to that. The incentive for them is that they can often have the data they're interested in a short space of time rather than wait longer for pages of data they've got no need in. If you do this, make sure it's a genuine conversation with them and it's documented as to the scope they agreed.

Remember that right to be forgotten isn't an absolute right especially where you're relying on basis other than consent. If you ask your employer to erase all data about you, they'd have an argument under 17.1.a. to argue that it's necessary to keep that information in order to pay you. Nor can you ask the police or tax office to erase your data.

piaste• 8 years ago

This idea smells of 'one weird trick lawyers HATE'.

I'd be very surprised if a court saw nothing wrong with spamming otherwise-legal requests nonstop every month, in exchange for monetary payment by a third party to boot. I imagine it could easily fall under harassment, or abuse of the court, or some other misdemeaner with sufficient leeway to interpretation (which it would be totally appropriate to apply).

Also, consider that the fact that they are GDPR requests isn't really germane to your idea. Surely there already exist some kind of requests that a customer can legally submit to a company and which can be individually burdensome to answer - perhaps specific to a particular sector, say banking, medical, or insurance. Yet I am not aware of anybody trying this particular route to cripple their competitors.

Another thing, say that the company being spammed stops responding to those malicious requests. Nothing is gonna happen unless you actually file a complaint against them for not responding, and you probably aren't going to do that for a few dollars, especially when you know you are acting in very far from good faith.

majewsky• 8 years ago

This way, a malicious actor can buy thousands of GDPR requests and DDoS anyone but big companies like Google.

FWIW, request letters like this have been possible in Germany for multiple decades, and I haven't heard of any DDoSing of companies yet. Here's a representative e-mail template whose lineage goes back to 1998:

German: http://www.ulm.ccc.de/old/chaos-seminar/spam/spam-bsdg-auffo...

English: https://translate.google.com/translate?sl=auto&tl=en&js=y&pr...

I have sent similar letters in the past and always received prompt answers.

barry0079• 8 years ago

According to ICO guidelines: "Where requests are manifestly unfounded or excessive, in particular because they are repetitive, you can:

charge a reasonable fee taking into account the administrative costs of providing the information; or refuse to respond."

I wonder if that would apply to the letter?

[0] https://ico.org.uk/for-organisations/guide-to-the-general-da...

Edit: Formatting

iscsisounddirty• 8 years ago

That makes no sense, SaaS makes it harder to be compliant with GDPR since you have to rely on other companies to ensure erasure, and compliance. I know of specific companies who were left vulnerable since they had no idea what was being kept on AWS

brockers• 8 years ago

While I generally applaud the idea, I cannot help but notice that the most likely abuser of users personal data is the governments of the EU itself.

EU GDPR – Another reason for SaaS to reconsider on-premise

Related Stories