Controllership

[JasonMWhite]

A common issue that we face is the need to know which data we hold as a controller vs as a processor. Depending on the role in which we are acting, we can have different requirements for retention and permitted uses.

This can be more than a simple controller/processor split. There are also situations where we could be a co-controller, or there could be several independent controllers.

Have you thought of how you might extend the data subject taxonomy to include a controllership dimension?

[cilliankieran]

Really good point @JasonMWhite. You're right the current taxonomy doesn't account for data stewardship (i.e. the party responsible for its handling), however we have been looking at a few ways to model this and would welcome your thoughts.

The two approaches we've most closely evaluated so far are:

1. Approach similar to ISO 19944
In 19944 the grammar allows you to state the source scopes of data and the result scopes. These scopes are grouped into those that the organization is responsible for and those that sit up and down stream of the system scope. This provides an implicit reference to controller / processor but it's not immediately clear to a non-privacy engineer and we feel pretty strongly that it should be easy for any dev to pick this up and understand how to describe these constructs.

2. Registering and Declaring I/O (Sources and Destinations)
The taxonomy you're seeing here is a draft and only part of the work that's been carried out to date, we'll be releasing more early next week that will help provide much more context. In the next release, you'll see you can use the taxonomy to describe a given project/application or dataset (data storage entity). These descriptions of systems can be at the macro system level, individual service or groups of services in a repo - we think of most things in projects you're working on. The benefit of this approach is that you can declare and describe types of data associated with a given project (entire system or portion of a system) and declare its sources and destinations of data. Sources and destinations might be within the scope of your application (i.e. service-to-service) or inter-application (i.e. a 3rd party sending data to you).

We think the benefit of this approach is you can describe just your applications in isolation and their data behaviors or their behavior relative to other systems - this relationship provides context to identify the controller or processor of the data.

This is our working hypothesis after evaluating several solutions over a few years so would welcome any thoughts you have but it'd be great to share more on how we think about adding this context once you see the release next week also.

[JasonMWhite]

I see the value in being able to specify, at a more granular level, the applicable stewardship to a dataset or element. I could see it getting overcomplicated very quickly if one went all the way down to the microservice level, but certainly useful at a brand or product category level. Allowing the implementing organization the freedom to specify familiar labels here would be key to utility.

Another approach I've found useful in some circumstances is to group uses by user type, as this is often how users are referenced internally. It can help to provide a familiar mapping to implementing teams, who usually aren't well-versed in privacy. Given a flexible architecture, these approaches aren't incompatible.

Sometimes data elements for which we are acting as controller are shared with other companies for whom we are acting as processor, and vice versa. We usually separate those into two distinct copies of the data for simplicity, but a more intelligent data governance solution could label each individual element with two separate stewardship scopes, modifying in response to erasure requests and retention policies of course.

[cilliankieran]

Yes, agree with you on all points @JasonMWhite.
In relation to the granularity; we took the design decision to accomodate as much flexibility as possible, but as you've rightly pointed out it's likely that it'll largely be project or product level - again it's designed to be flexible.

Your proposed approach to create a relationship between data uses and user type makes a lot of sense - in fact some of our earlier tools already have this ontological structure and as you say it makes a lot of sense here. As I read your comments it strikes me that we could/should make the relationships in the ontology more flexible than they are today to support these constructs of groupings - it's definitely something we'll look at.

To give context, we're currently at the phase of evaluating the syntax for ontological descriptions of relationships between entities int the taxonomy so that you can describe these relationships and roles relative to each other. I'll gather our current thinking on this and share it with you to get your feedback here in the next few days, I think much of this will help to clarify how you could use this to apply multiple labels to a given data element so that they can be evaluated in different contexts (you as controller, vs you as processor on the same element)

Bear with us - we're sprinting towards a major public release next week but I'll pick this up with you after that.
Thanks again for the detailed feedback!