Hacker News Reader

Comment by twakefield | Hacker News Reader

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.

View on HN

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

> The point is that your b2b customer is itself a b2c business that holds customer data in the product you sold them.

This is not true of most SaaS products I use on daily basis e.g. calendar, gmail, Slack, GitHub, code review tools, CI server, etc.

The GDPR applies to employees as much as it applies to customers. Internal tools are not exempt.

If Slack uses Google Analytics, it makes GA a processor for the consent that Slack has acquired from you to track you. GA would be a processor in this scenario, and Slack would be the controller and owner of the data stored on GA’s servers.

Slack would indeed be the controller of the data, since Slack is more of a standalone product. But they have less to fear from the GDPR, because tracking is not their core business. GA otoh is different, and the point that OP is making is that if you were to make an on-prem solution of GA, surely it would be simpler to make GA compliant with GDPR as a Processor rather than going over the top and go fully on-prem?

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!

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.

Reply on news.ycombinator.com