Question - Mandatory GDPR fields in data flow analysis

Hi

In Data Flow Analysis of any data asset the Procesor / Controller / Controller Representative are mandatory fields. What should we do when the data is processed and controlled in house? I guess there should be an option to tick if 3rd parties are involved (then of course we need to have this information). Or do I see something wrong?

Thanks
Fabian

An interesting question. We are not documenting in Eramba GDPR process flows for internally managed and hosted systems where we are the Controller. We are only documenting GDPR processes flows that involve third party processors. Are you documenting data flows related to yourself as a Controller or as a Processor (are you a Processor)?

I jsut wanted to check if I could use Eramba for describing all significant data flows in our Company, about 90% are completely internal = we are Controller and Processor at the same time.

I came accross the same “Problem”.
According to GDPR § 30 we are required to document all processes (internal and External).
In case of internal processes there is no difference between processor and Controller since the Controller is in Charge of the processes.
the difference between Controller and processor is only relevant for suppliers (in case of § 28 GDPR).

btw. our Company is located in Germany so GDPR applies to us in full extend. I also act as the DPO in our Company. If you have some in-deep questions on GDPR-Implementation I might try to help.

1 Like

As the fields you mentioned are general attributes it seems you would identify your own company as processor and controller, and your own rep if applicable. It seems all the other GDPR required fields when adding the analyses still apply. Perhaps an eramba feature request would be to remove the requirement for the Processor roll? That seems to be the only field that would not apply to a Controller.

Since we’re on a deadline I’m mainly focused on external processors, but your post made me think to circle back and document the internal as well as you described.

Thanks to you both! We are located in Switzerland and are lucky enough to not have to comply with GDPR (at least according to our legal advisors). Anyway we are concerned and the Swiss law will be amended accordingly. My biggest pain right now is the documentation of the data flows / data inventory . Anyway, we are having some more time, swiss law execution is not the fastest (which is great for this one).

I assume I will add a “3rd Party” which is in fact our own Company… Anyway, it might make sense to change this feature in Eramba.

Yes, for other reasons (such as internally developed key applications) I have added our company as a “Third Party” supplier so I can reference as needed in eramba. Always interested in how others have addressed these issues if there is a better way.

nope - you dont see things wrong … my “hack” was to create a Third Party with the name of the company i work for and put it there.

how about a checkbox called “Not Applicable” or “Ourselves” ?

Processor and Controllers always exist, no matter the data in question. They might be the same person/company/etc (as fabian pointed out) or different, but there is always a processor and a controller otherwise you are not able to apply half the articles in the law (which mention one, the other or both).

For example, in the scope of the data of your suppliers your company is likely to be the controller (you have the need for their data) and the processor (you look after that data) on your systems, etc.

In the scope of the staff that keeps your facilities clean, the controller is the company that hires that staff (lets say the cleaning company) and your company could be the “processor” in the scenario you collect their personal information to issue them badges, etc. If you dont need their data in any way (unlikely), then you are not liable.

The ICO website makes understanding gdpr pretty easy (is not that is really complicated either), in regards to the roles involved:
https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/key-definitions/

the point i believe Fabian is making is that his company is controller and / or processor and there is no way to select his company on the dropdown (unless he creates it as a third party as i did).

ps. GDPR is EU law and applies to all EU countries equality, there is no difference to any EU country other than the articles where the law leaves it clear to the members to adjust as wished (Rec.40; Art.6(2), etc…just search for “Member States may” on the law and you will see examples).

I’ve read these ICO pages many times! :tired_face: The nuance I’m trying to answer (by conversations, web searches, and articles) is whether a Processor is always necessary or required to be defined. It seems the answer is “no”, which is why I suggested loosening the field restriction in eramba. Here’s my reasoning (I’m not a lawyer!).

Since a Processor is someone who processes “on behalf of the Controller” (ICO) it seems the Processor is by definition a third party. In the Venn diagram of obligations and responsibilities to the Data Subject, the Controller is the outside circle; Controllers inherently have all the obligations related to processing personal data. It’s when they engage a third party that a third entity defined as “Processor” enters the picture. Article 28 starts with “Where processing is to be carried out on behalf of a controller…” and goes on to detail the requirements placed on that third party and the relationship to the Controller and the Data Subject. If the Controller never engages someone else to process data on their behalf, there is no Processor (big “P”). Clearly, the Controller is processing data and subject to all the requirements under GDPR. Perhaps your example of cleaning staff and security badges fits well here. Unless I’m engaging a third party in that process, there is no Processor, though clearly I am processing data and have obligations.

All that said, you and I can attempt to interpret and argue the points, but it will be up to lawyers and courts to give the final answers.

As a non-EU entity, I appreciate the structure implemented in eramba as it helped us focus and documented what was required. It’s this one field that I felt could be relaxed to clarify situations where there is no third party being engaged. It is certainly not a major issue to have put yourself in there as a placeholder.

on that one we agreed !! it is bloody confusing i know and here in Europe we like to make things insanely complicated for god knows what reason…but that is politics and that is not what is discussed here in this forum :]

to make things easier for us all i’ll add a “not applicable” checkbox on the next release:

https://github.com/eramba/eramba_v2/issues/1337

1 Like

Sorry, but this statement is not correct at all! There is no way that a Controller can be the Processor (or vice versa), these must be different legal entities. If e.g. a company processes data within the same legal entity, the company is the controller and there is no processor. If the company uses another legal entity, even if it is a part of the same group in a holding, this legal entity is the processor. The sole criterion for being the controller is “defining the purposes and means” Art. 4 (7) GDPR, there is no additional criterion as what data, processing step etc. is carried out.
Having said that, unless somebody is processing data as a service-provider for customers, one is always the controller, no matter if we process the data on our own or if we outsource to any other legal entity.
Therefore, I would like to see instead of the “not applicable” checkbox a means of checking “we are controller” or the like.

Just my 2 cents

I notice that “not applicable” checks are added on this page now, but are not functional. Is there an ETA on when those will be enabled?

My company acts as a processor for some of our customers and in other cases as a controller depending on which of our products are used by our customers. I would have to add ourselves as a third party to get around this currently as another person mentioned in this thread.

Thanks,

SG