Alert the Clients Systems of the Loss of Eligible Privacy Scope

[milstan]

problem

When user revokes consent, objects, restricts or when a retention policy comes to due date, the Eligible Privacy Scope changes.

The client system might be anaware of it, and continue perfoming unauthorised data processing (keeping data whose retention policy expired, or e-mailing the user who revoked consent).

solution

When there is a change in eligible privacy scope of a particular user, generate an event with the delta/change. The client systems can then listen to those events and implement procedures to react to them, depending on what part of privacy scope has been lost.

alternative (maybe consider implementing as well)

Let the client systems query the PCE to check if a particular privacy scope is eleigble for a particular user. This has the downside that the system would have to do it whenever they process data (and in the other solution they only react when there is a change in the eleigible privacy scope)

[milstan]

@m4rk055 @TheKinrar I realise that this is more important than I thaught.

In fact, consider the following situation: the user makes an OBJECT request, there is a part of the privacy scope that is lost (like MARKETING purpose). This might imply that we need to remove the user from e-mailing lists at MailChimp (or other e-mailing data storage).

We need a mechanisam in the devkit to support this. Could you please give it a thought and come up with the preferable way to approach this.

[m4rk055]

The client systems can then listen to those events and implement procedures to react to them, depending on what part of privacy scope has been lost

This solution requires a lot of dev/integration effort from clients.

If a client is using storage connectors:

We probably can't run delete automatically for a change of a user's privacy scope, as it's very specific depending of which triples were removed. But if we provide a set of default legal bases in advance (pre-defined legal bases for common cases), for any change in those LBs we can calculate the exact data to be deleted and deletion can be automatic (easy if a LB is associated with data in some global storage, like MailChimp).

If a client is not using storage connectors or a custom legal base was changed/expired:

DPO can receive "notifications" about required actions after a scope changing event occurs, which can be a part of the DCI.

Anyway, there should be an endpoint for querying a user's eligible privacy scope, used by a client's app server.

[milstan]

But if we provide a set of default legal bases in advance (pre-defined legal bases for common cases), for any change in those LBs we can calculate the exact data to be deleted and deletion can be automatic (easy if a LB is associated with data in some global storage, like MailChimp).

I was thinking how we can leverage the semantics of PRIV to achieve this more automatically. E.g. a storage connector can expose privacy scopes corresponding to operations commonly done on that storage over data.

These scopes are linked to legal bases in configuration.

When a part of scope is lost - PCE throws an event. And storage might implement an event listener. Then depending on the actual scope lost,there may be common actions.

For example, if the Processing Category 'STORING' is lost, then the action should be delete.

If 'USING' is lost for 'Advetising' then the storage only does something if indeed it is the storage that handles advertasing campains (otherwise it ignores the event). E.g. mailchimp connector would keep the user in the database but would remove the user from the campains (there is a notion of campains in Mailchimp) or would register 'opt out from all communication' at mailchimp service.

I.e. put on the storage the responsibility of knowing what data it has, what is done on it, for what purposes.

I get your point it may be a lot of work for the clients, but for most 3rd party services (mail chimp, typeform,..), the storage connectors would behave the same way for every client.

It seems to me much more complex and costly for clients to call the PCE endpoint every time they want to use the data to check if it is an allowed operation.

I still don't have this figured out completely, so I'd like to discuss more with you here.

[m4rk055]

note: Currently, a storage connector accepts 2 actions - get data and delete data. Actions are calculated by the PCE and propagated to connectors via DAC.

A connector can have a third action - reacting to changes of users' privacy scope. That action's payload contains a list of affected legal bases and the scope each legal base has lost (or if the complete legal base "expired" or is revoked). The connector chooses if and how to react to it.

It implies connector knowing the system's legal bases, which is out of scope of the original idea of the storage. But I currently don't know a better place for it, since it's handling is very specific, depending on the legal base (for common case legal bases, PCE can calculate delete actions).

Indeed, this solution is straightforward for global connectors but a bit of an effort for custom ones - maybe we discuss a marketing shift?

I was thinking how we can leverage the semantics of PRIV to achieve this more automatically. E.g. a storage connector can expose privacy scopes corresponding to operations commonly done on that storage over data.

These scopes are linked to legal bases in configuration.

I don't think this is relevant as "events" can be broadcasted and connectors choose if and how they should handle them.