Processor ROPA Now Supported in Data Inventory for GDPR Compliance and Audit Readiness

Jacob G. · 2026-04-24T18:43:32.890Z

:ropa: Processor ROPA :ropa: What's new: Data Inventory now supports Processor ROPA; track data you process on behalf of customers, not just data you control. The split: • "Data you control" → Controller ROPA (employee data, your marketing, etc.) • "Data you process for others" → Processor ROPA (customer data in your product) Why it matters: • GDPR Article 30(2) compliance • Export Processor ROPA spreadsheets for audits • Clear separation between controller vs. processor activities Try it: Data Inventory → "Data you process for others" 🛼 This is currently rolling out and is planned to be available by next week to all with a privacy framework

10 comments

· Sorted by Oldest

Jacob G.
·
·
Jeff W.
·
·
Is there any provision for joint controller in that?
Jacob G.
·
·
Hey jeff: good q! Not as part of this update, but Ill make sure this feedback/question gets filed on your behalf 🙇
1
Edward T.
·
·
Hey Jeff W. - sorry for the delay - we have some areas in the "data you control" side for joint controller information. Is there something more that you would want or different? Do you want activities that you are a joint controller for to be displayed or managed separately?
Jeff W.
·
·
We produce risk intelligence. We have numerous data sources where we are a processor. We aggregate this data and layer on our analysis and we are controller of that amalgam. Our clients have data where they are controller. We match our data to theirs which, IIUC, results in joint controller status of that intersect. I don't want to enter things twice - as controller and as processor- so was thinking a joint control framing could be useful.
Edward T.
·
·
Right now you can add information about joint controllers to a processing activity, but I honestly don't think that we have a lot of customers who actually have joint controller relationships, or at least document them.
Jeff W.
·
·
Ah, the joys of being complex. 🙂
😅1
Edward T.
·
·
Let me outline a potential solution and you can tell me how / if this resonates:
For a processing activity where you act as a processor, you document your behavior strictly as a processor
On the side where you act as a controller, you can link to that other processing activity, and you describe the additional behaviors that you perform as a controller.
This is a pretty "light touch" connection; what more would you want to see to make this usable for you?
1
Jeff W.
·
·
From a tracking perspective, that makes sense. The challenge I see is that I'm then doing one link per client. That may be the "correct" way to do it for veracity but seems time consuming. I'll have to think more about it.
Edward T.
·
·
That does seem time consuming. When you talk about that "amalgam", it sounds like (correct me if I'm misunderstanding) you have multiple processing activities where you are the processor, and you want a single thing to describe how you act as a controller over all of that data? So it's like a one-to-many mapping. This is interesting, indeed. 😄

Jacob G.
·
·
Jeff W.
·
·
Is there any provision for joint controller in that?
Jacob G.
·
·
Hey jeff: good q! Not as part of this update, but Ill make sure this feedback/question gets filed on your behalf 🙇
1
Edward T.
·
·
Hey Jeff W. - sorry for the delay - we have some areas in the "data you control" side for joint controller information. Is there something more that you would want or different? Do you want activities that you are a joint controller for to be displayed or managed separately?
Jeff W.
·
·
We produce risk intelligence. We have numerous data sources where we are a processor. We aggregate this data and layer on our analysis and we are controller of that amalgam. Our clients have data where they are controller. We match our data to theirs which, IIUC, results in joint controller status of that intersect. I don't want to enter things twice - as controller and as processor- so was thinking a joint control framing could be useful.
Edward T.
·
·
Right now you can add information about joint controllers to a processing activity, but I honestly don't think that we have a lot of customers who actually have joint controller relationships, or at least document them.
Jeff W.
·
·
Ah, the joys of being complex. 🙂
😅1
Edward T.
·
·
Let me outline a potential solution and you can tell me how / if this resonates:
For a processing activity where you act as a processor, you document your behavior strictly as a processor
On the side where you act as a controller, you can link to that other processing activity, and you describe the additional behaviors that you perform as a controller.
This is a pretty "light touch" connection; what more would you want to see to make this usable for you?
1
Jeff W.
·
·
From a tracking perspective, that makes sense. The challenge I see is that I'm then doing one link per client. That may be the "correct" way to do it for veracity but seems time consuming. I'll have to think more about it.
Edward T.
·
·
That does seem time consuming. When you talk about that "amalgam", it sounds like (correct me if I'm misunderstanding) you have multiple processing activities where you are the processor, and you want a single thing to describe how you act as a controller over all of that data? So it's like a one-to-many mapping. This is interesting, indeed. 😄