
EU GDPR – Another reason for SaaS to reconsider on-premise - aberoham
https://gravitational.com/blog/gdpr-impact-on-saas-vendors/
======
antoncohen
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.

~~~
twakefield
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
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

~~~
rvcdbn
> 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.

~~~
stingraycharles
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?

------
gtirloni
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...](https://gravitational.com/blog/time-to-reconsider-going-onprem/)

~~~
twakefield
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).

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

------
twakefield
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...](https://www.linkedin.com/pulse/nightmare-letter-subject-access-
request-under-gdpr-karbaliotis/)

~~~
louthy
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.

~~~
moduspol
> 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?

~~~
louthy
No - but it penalises you if you fail to follow best practice (like not
encrypting data at rest for example). So, the incentive to do the right thing
is greater seeing as you can be fined a percentage of your turnover.

~~~
moduspol
Indeed. Just pointing out the clear difference between that and what was
stated.

~~~
louthy
Thanks for clearing that up. I’m sure nobody knew what I meant until I made
the clarifying post above.

As an individual I am much more likely to trust an organisation that follows
GDPR regulations over one that doesn’t. That obviously doesn’t mean they’re
never going to have a data breach- but by law they will have to announce it
within 3 days, and will face massive fines if negligent - that, to me, is a
company I would prefer to give my business to - and was my point. Pedantry
doesn’t help.

~~~
moduspol
GDPR is very popular here on HN, but I think it's important to keep a level
head about what it actually does and what its real-world effects will be. That
is the entire point of this thread, after all.

The difference between "not having a breach" and "a legal obligation to
announce it within three days" is not semantic. It is absolutely material to
the real-world value of GDPR, and claims about it should reflect that.

------
vbsteven
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?

~~~
merinowool
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.

~~~
magnat
> 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.

~~~
merinowool
I don't think that is feasible, because you don't know if this data could be
easily decrypted in the future. What do you do with existing data written to
persistent media?

~~~
heavenlyblue
What do you do with the futuristic tech that allows one to read all of the
possible data written to a given hard drive?

Your point is highly hypothetical.

------
StreamBright
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.

------
roomey
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!

~~~
dane-pgp
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/](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
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).

~~~
dane-pgp
Thank you for that detailed analysis. Perhaps I should have emphasised that
the scenario I am suggesting is one where there are already multiple open
social networks that are communicating with each other using "industry
standard" W3C social network specifications.

If technology were in widespread use for allowing instant automated publishing
of social media posts to friends on other networks, then I don't see how
Facebook could legitimately claim that they can only implement a process that
takes weeks (or deluges their competitors with unwanted information). A court
should see this as malicious compliance and demand a more "reasonable" effort
from them instead.

This article:

[http://ejlt.org/article/view/546/726](http://ejlt.org/article/view/546/726)

makes a strong case (in section 3.2) that the GDPR's data portability right
should be considered in terms of EU competition law generally:

"In light of the above, it can be argued that a refusal of a dominant firm to
enable data portability might be seen as a form of exclusionary abuse as it
might drive its competitors out of a specific relevant market and increase
market concentration."

------
barry0079
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...](https://ico.org.uk/for-organisations/guide-to-the-general-data-
protection-regulation-gdpr/individual-rights/right-of-access/)

Edit: Formatting

------
marcrosoft
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
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.

~~~
deltron3030
>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.

~~~
gjulianm
Is it really that hard to implement the policies of the GDPR? The way I see it
it is basically breach notification and right to access/delete data, which
does not seem that difficult and probably not a burden for a startup to "not
grow as quickly".

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

~~~
gls2ro
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](https://www.eugdpr.org/gdpr-
faqs.html)

~~~
icebraining
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/](https://gdpr-info.eu/recitals/no-23/)

------
andy_ppp
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.

------
iscsisounddirty
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

------
fuscy
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
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.

~~~
fuscy
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.

~~~
qw
I guess there is nothing that restricts the amount of information you can
send. Why not just document everything and refer to that instead? Is there
anything in GDPR that states you need to give a specific answer tailored to
the individual customer?

~~~
fuscy
The easy part is providing the information about how the data is used because
it's do once, reuse always. Just refer to a document.

The hard part is the right to be forgotten which requires the company to
remove all information that pertains to a person. The tech stack still has to
implement some stuff here in order to reduce costs and make it easier.

Having to contact your database administrator because you can't delete
something without leaving dangling information all over is bad tech
implementation which will probably require a huge rework for some companies.

I wonder how you can send the information to the client. If you use GMail then
GMail will also know the personal information (they used to read your emails..
good stuff).

------
brockers
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.

