Art. 30 GDPR - records of processing activities

Questions
1

Hi everybody and thanks to anyone will answer to my question.

This is my first time developing an APP, my users will be keeping records of health related data, which are considered very private, and I am bit puzzled… I am not sure I really understood what is needed to build to cope with the Art. 30 of the GDPR, which says:

Records of processing activities

Each controller and, where applicable, the controller’s representative, shall maintain a record of processing activities under its responsibility.

That record shall contain all of the following information:

  • the name and contact details of the controller and, where applicable, the joint controller, the controller’s representative and the data protection officer;
  • the purposes of the processing;
  • a description of the categories of data subjects and of the categories of personal data;
  • the categories of recipients to whom the personal data have been or will be disclosed including recipients in third countries or international organizations;
  • where applicable, transfers of personal data to a third country or an international organization, including the identification of that third country or international organization and, in the case of transfers referred to in the second subparagraph of Article 49(1), the documentation of suitable safeguards;
  • where possible, the envisaged time limits for erasure of the different categories of data;
  • where possible, a general description of the technical and organizational security measures referred to in Article 32(1).

Obviously we, as providers of a service which is in line with the GDPR, will have to help our customers to collect and retrieve those records worm and tidy.

How to build such a system?

The first idea I had was building a record of all activities all users do when they use the APP, and display it in a repeating group, giving some search filters. I wonder if we can retrieve data from the server logs for users in the APP, so I won’t need to build a specific thing to record

I’ll try to sum up the concepts in 3 questions:

  1. Am I right when I think that I have to build a record of processing activities in my APP (especially since my users will record very private data)?
  2. Is there a way to retrieve data from the server logs?
  3. How long should the users keep the record?

Thanks,

Ric

2

I would be really, really careful about storing health data in Bubble. I’m not so sure it’s a good idea, to be honest. It might be worth reaching out to Bubble Support for this specific case, I’d be curious what they’d suggest.

In general, I personally would not store anything on Bubble that includes credit card information, social security numbers, sensitive health data that can be linked to a person, and similar types of data.

3

this is a really bad news for my case!!!

I have been working so hard on my app, it would be really hard to accept

I’ll contact the support straight away to see what they suggest :frowning_face:

4

Hey @andrewgassen

Is your position that Bubble has specific shortcomings in protecting data? Or that by storing the data you open yourself up to oversight like PCI, HIPAA, etc., as you would on any platform?

I hope @josh or @emmanuel comment on this as well.

5

We’ve heard from Bubble before that it’s not HIPAA compliant, and we as Bubble developers don’t have the ability to solve that problem if we’re relying on their infrastructure. I wouldn’t say it’s a shortcoming, just that it isn’t built for that purpose.

1 Like
6

Thanks for answering, @andrewgassen

If my users will be in Italy, I will still need to be HIPAA compliant? Or that is only for USA based APPs?

Since I read

I was all happy because thought that Bubble would be safe for storing health related data. As a newby in this field, I didn’t have a clue all this data protection levels even existed! I thought that having a https URL would allow me to collect any kind of data. This is crazy, I know, but this happens, I guess, when you give to children a database to play with :joy: :rofl:

A workaround could be storing data in an external database? I saw this one, for example

7

So, when thinking about storing sensitive data on a technology platform, there are two related but different kinds of risks you should think about managing:

  • Security risks
  • Compliance risks

Security risks are the risk of data getting lost, stolen, leaked, hacked, etc., causing harm to the people you are storing data about, and exposing your business to reputation and liability risks.

Compliance risks are the risk of you or your company being exposed to legal liability for failing to comply with relevant regulations and laws.

These two things are closely related, because laws and regulations often dictate security precautions that need to be taken. But they aren’t necessarily the same: you can have an extremely secure system that doesn’t fully comply with a specific regulation because the regulation imposes requirements about how the system is implemented or documented that you haven’t adhered to, and you can have a system that fully complies with regulations but that still gets hacked.

At the end of the day, risk management is something that’s context-specific: you have to evaluate the size of your business, the kinds of data you are storing, what the regulatory environment for you and your peer companies looks like, and make a judgment about how you want to approach risk mitigation as a company. The strategy that a three person company handling customer emails in France adopts to manage their risk is probably not appropriate for a thousand person company handling financial records in Brazil.

As a general rule, the @Bubble team will not give advice about compliance. This is because laws and regulations vary by country, industry, and type of data, and we are not necessarily in a position to understand and give good, context-specific advice for your situation. Giving legal advice is something that should be done with extreme caution, and we don’t feel like we currently have the expertise as a team to give guidance to users on what they can or cannot do.

What we can do, though, is share information about our security practices, and what standards we comply with as a company. In the thread you linked to, I talk a bit about our security practices, and I am currently working on an extensive document that I plan to share in the next few weeks going into our security practices in much more depth, since we want to be transparent about our security regimen to help our customers evaluate if we are secure enough for their purposes.

In terms of compliance, as @andrewgassen notes, we have not yet made an effort to comply with HIPPA’s requirements for storing sensitive medical information. HIPPA is an American law, so may not be relevant to all our users, but most countries have their own laws about storing medical information.

It’s important to note that Bubble cannot comply with regulations such as HIPPA or the GDPR for you. You can build on the most compliant, secure platform in the world, but if you use it to build an application that shares your users’ data with the entire internet, you will likely be in violation of regulations regardless. What we can do is take measures to make it easier for our users to build compliant applications on top of our platform. On the GDPR thread you linked to, we discuss some of the specific measures that we are taking for GDPR, but whether or not those measures are sufficient for our customers to be compliant depends on how you use Bubble.

6 Likes
8

Well stated…looking forward to the security practices document and thank you in advance for providing! I for one fall into the camp needing a secure environment, but not compliance.

Detailed posts like this from “the source” go a long way to alleviating concerns – at least for me – so I very much appreciate you taking the time.

9

Hi Josh, were can I find the security document?

10

Did you manage to get to a solution with this?
I am in a similar situation and my approach would also be using an external provider for the sensitive data. (like Chino)