Problem with Privacy management data structure

[Matias Aaltonen]

Hello GRC Forum and fellow GRC implementers!

In a recent implementation we came across this problem with Privacy Management product's OOB data structure and process model, which, I think, weakens its suitability for privacy management in accordance with the EU General Data Protection Regulation (GDPR):

Business requirement:

Under the GDPR, different types of processing require separate documentation, including evaluations of legal bases, purposes, and risks.

In practice, multiple processing activities may relate to the same process, application, or organizational unit — for example, when an application processes personal data of both customers and employees. These represent two different data subject types, and the processing may differ in various ways, such as:

• Purpose of processing: customer relationship management vs. employment management
• Types of data: purchase history vs. payroll data
• Legal bases: consent vs. employment contract
• Recipients: marketing partners vs. payroll service providers

Problem with OOB Privacy management product:

A single processing activity can only be linked to one entity, and an entity cannot be associated with multiple processing activities. This data structure is overly simplified in relation to the accountability and documentation requirements under the GDPR.
In the example above: The application would be an Entity record and the requirement would be to have separate Processing activity records (separate for handling customer and employee information) associated to Entity. Both Processing activity records hold different information and have different Risks, so the requirement is to assess and evaluate these as separate Processing activity records.

The way I see this,
the solution is either
1. to enable multiple Processing activities associated per single Entity (requires quite a lot of changes to OOB logic)
or
2.to have additional Entity records created for Privacy management purposes (not a fan of this solution as Entities are used across all GRC Processes and I think the best practice is to have a single Entity record represent a single CI).

What are your thoughts or experiences to resolve this problem?

[Matthias Ferstl]

Hi Matias,

Although I haven't delved deeply into the Privacy Management Module, based on what you mentioned and my experience with GRC, I would suggest creating subprocesses for Configuration Items (CIs), specifically for applications.

This approach allows you to maintain your "1 CI -> 1 Entity" practice.

Additionally, it enables you to clearly assign risks to subprocesses within the application, as EU laws encourage the explicit assignment of  different rules (and thus controls) may apply when processing customer data compared to other types of data, which results in different risks as well.

The downstream and upstream mechanics will still reflect everything on the entity that has the subprocesses, ensuring the same outcome, but the source of truth will be more granular.

Kind regards,
Matthias

[Matias Aaltonen]

Thank you for your response, Matthias!

I think I understand your idea of leveraging the CMDB-side application and process classes in this matter.
Create new CI → which creates a new Entity → then the one Entity–one Processing Activity structure would work.

In the privacy management process, it is assumed that the Entity already exists so that a preliminary assessment questionnaire can be sent to the Entity owner. In the example case, a questionnaire would first be sent to the application owner, and only through that initial assessment would we find out what kind of personal data is being processed in the application (if any).

Of course, based on the questionnaire responses, it would be possible to create the necessary CIs and continue the process from there. Creating the CIs could indeed be a lighter approach than either of the ones I previously suggested. So thank you for the idea — I’ll need to look into it more closely.

[Matthias Ferstl]

Well i wouldn't suggest to create CI based on assessments, but I'm installing privacy Management right now to have a detailed look in it.

But to help me understand the main goal:

I understand that you basically want to apply risks (and maybe controls) to an entity IF the mentioned questionaire responses say (for example)"this one processes sensible data of customers", and "this is the responsible person for the risk of... exposure" (or smth like that).
So do you want to flag the entities or is it about Risks, responibilities and mitigation?

[Matias Aaltonen]

"So do you want to flag the entities or is it about Risks, responibilities and mitigation?"
Here is the link to solution overview to get the general idea of the process.
https://www.servicenow.com/docs/bundle/yokohama-governance-risk-compliance/page/product/grc-privacy-...

Trying to put it briefly:
Basically you gather information via different Privacy assessments from Users (usually the Entity owner) and the output of these assessments is
-Privacy screening assessment: does the assessed Entity process any kind of Personal Information (if yes, the Entity would get flagged Functional domain= Privacy and a Processing activity associated to Entity record would get created for subsequent steps)  and who are the contact users for these
-Privacy Impact assessment:
A.You gather all the required information about the personal information being processed (types of personal information, categorisation, upstream and dowstream data flow etc.)
B.Identifying relevant Risks and Controls from Privacy management point of view (based on assessment answers) and managing them accordingly via Risk and Compliance processes

So the Privacy management's Processing activity record is a whole thing of it's own and is the single point of entry for Privacy managers and analysts. But the process and data structure also leverages the common GRC tables and processes.

The main goal to resolve is that it is common that there multiple separate sets of data (in my example case two separate Data subject types: employees and customers) that need to gathered, assessed and tracked separately using the Processing activity records and following the Pricacy management process. 
As OOB there is a one-to-one limitation set for the Entity-Processing activity relation and there is no meaningful way of handling multiple separate sets of data under a single Processing actitivy record.